Monday, April 6, 2015

Process Modeling Tools

Description

  • This paper is designed to provide practitioners with an awareness of the various issues involved in the selection and application of commercially available software tools in the modeling activities of BPI projects. Given the rapid pace of innovation in computer based tools, some of the detailed information about specific tools is likely to be out of date in a relatively short period of time. Practitioners are encouraged to follow major developments with regard to these products, and to seek out more detailed, current information from external sources, as standards develop, prior to the selection of software tools for a major engagement.
  • Used in the process of identifying and representing the relationships between the components of a business model. The purpose of their use is ultimately to produce a model or representation of the “Future State” that drives the detailed activities of the business and system design-process.

When to Use

  • These tools are used in building the Holistic Business Model and the “To-Be” Process Model, in validating the processes in the “To-Be” Validation, and in building subsequent detailed processes and technology. The presentation method should be sensitive to the organisation’s ability to absorb the information and fit the organisation’s needs as opposed to the implementation team’s needs.

Approach

  • Throughout my career I have used a wide range of business process development tools/methodologies. Dynamic tools are best suited for modeling strategic relationships or detailed interactions of activities.  Static tools are best suited for modeling operations, processes and activities.  The following gives some general guidance on the use of dynamic and static tools, as well as some  pointers on the use of specific tools.
  • Dynamic modeling provide the ability to instantly represent the effect of changes in inputs and variables of the model.  This is an excellent application for simulating high-level strategic relationships, and can be a powerful tool for executives to understand the implications of their decisions.  The effect of decisions can be immediately seen by the changes made in model variables.  While this type of model cannot be used to run the business, it can provide important insights on the outcome of strategic decisions.  On the other end of the spectrum, dynamic models are the tool of choice for modeling detailed interactions of resources and observing the effect of constraints.  Examples of this type of modeling include  interactions of machine rates and process queue times; effect of varying demands on capacity; and simulation of new process designs.  The strength of the dynamic models is in their ability to show cause-and-effect relationships, as well as the ability to calculate process time and costs.  The major drawback of these models is that they are expensive, time-consuming to develop, and require a fully trained developer to create a model that will provide valid results.
Request for proposal-1.0.png
BPMN Sample Process developed using Bonitasoft Dynamic Modeler

  • Static modeling provides a graphical illustration of process flows, activities and costs.  Additionally, static modeling allows the user to break down processes hierarchically into increasing levels of detail.  Through static modeling, we can develop an understanding of processes by identifying the activities and organisational functions involved.  We can also identify the associated time and cost of each activity within the process.  The strengths of static models is their ability to graphically depict a process in a short period of time to facilitate the understanding of "As-Is" and "To-Be" designs.  Static tools are relatively inexpensive and easy to use.  Their drawback has been their ability to calculate associated time and costs.
Below is a static Business Process model created using Archi a free, open source, cross-platform tool to create ArchiMate models. ArchiMate is an open and independent Enterprise Architecture modelling language that supports the description, analysis and visualisation of architecture within and across business domains. ArchiMate is one of the open standards hosted by The Open Group1 and is fully aligned with TOGAF1.
Archi Business Process View.png

Stand-alone Documentation

  • This category is useful for mapping current and proposed process work flows, when quantitative modeling or simulation will not be required, or when the documentation capabilities of the modeling/simulation software are inadequate.  These tools are essentially graphics software and may have special functions that assist the consultant in documenting process work flows.  Some of the tools enable users to nest activities/processes within other activities/processes, and this simplifies the organisation and navigation of processes, and enables the storing and displaying, of various levels of detail. A Tool I use frequently for mapping out processes is ARIS Express. This tool provides the ability to develop processes in ARIS EPC format, and BPMN (Business Process Management Notation) 2.0. The EPC models can be imported into the ARIS modelling tool or exported as a document file in PDF or RTF format.
Sample BPMN Process Map.png

Integrated Documentation

  • These tools can be applied to document and/or model current/proposed processes.  A wide variety of applications with varying capabilities are included in this category.  There are typical reasons to select one of the tools from this category.
    • The unique functionality of a specific tool is required
    • The documentation capabilities of a modeling/simulation tool that is to be used in later stages of the project are adequate for documentation purposes (will link documentation with modeling/simulation, which will save effort/time)
  • In most cases, tools from this category will be used separately for one unique task within a project where these requirements apply.

Spreadsheet

  • Spreadsheets can be used in at least two ways to support Business Design modeling efforts; to calculate actual or expected process results (accumulated over time);  and to score workshop/assessment results.  Spreadsheets are the preferred tool for process "simulation", when only end results are needed (e.g., the average time to process 500 transactions, or the total amount of resources consumed), because they are much easier to use than any of the dynamic simulators.  However, if there is a need to view specific interactions of process variables over time (e.g. how does the transaction processing time vary during the day), or if complex stochastic effects have to be simulated, a continuous or dynamic simulation tool may be required.

Simulation

  • Computer simulation is the process of designing a mathematical and logical model of a business system and experimenting with this model on a computer.  A simulation is a dynamic portrayal of a system's operation through time.  In other words, simulation is the tracing of a specific time history of a system/process.  A computer simulation can also be described as a script (similar to a play script) that describes the activities that result as transactions are processed, and events occur.  A model is defined by specifying a set of variables that interact to create a process.
  • Dynamic simulation calculates process performance/results in many small increments over time to show specific time-varying process dynamics such as the number of vehicles waiting to be processed at different hours of the day
  • Most simulations include some degree of uncertainty expressed in terms of probability distributions.  As an example, the routing of transactions may be from A to B 90 percent of the time and from A to C 10 percent of the time.  Other variables such as the time to process a given type of transaction through a specific step can be expressed as probability distributions that reflect the varying processing times that are possible in real life.  This type of model is said to show the effect of stochastic or probabilistic processes.  It can be described as a play script that varies from performance to performance.  Multiple executions of stochastic models will yield different results, and may be used to predict the variability of real world processes.
  • A simulation is a dynamic portrayal of a system's operation over time.  This is vitally important to remember when considering the usage of simulation techniques.  Consider whether there is a real need to portray the operation of the system over time, or if the need is only to calculate the average or total statistics resulting from executing the process.  A simulation will show the specific interactions of system variables over time, in addition to providing end results.  However, simulation is complicated and time-consuming relative to spreadsheet analyses, and requires a higher level of sophistication on the part of the client design team.  Dynamic simulation models should only be used when there is a need to depict process dynamics, not just results.
  • Simulation models and tools can be classified as either continuous or discrete change.  Selection between these types of tools should be driven primarily by the objectives of the simulation effort.

Continuous Dynamic Simulation

  • Continuous dynamic simulation treats elements of process flow in an aggregate manner.  For example, in a model of an order-management system, all orders would be aggregated to comprise a total order flow, with no particular importance on any one order.  Individual flow elements, like orders in an order flow, are important only in the sense that they contribute to total order flow.  Information about individual transactions (e.g. an individual order) is collected only at the overall, aggregate level.  The limitation of this type of simulation is that it is not able to measure attributes of specific transactions (e.g. how long did it take to process order number 101?).
  • A continuous dynamic simulator should be used, when an aggregate view of process flow is sufficient or when dependent process variables change continuously over time.  As mentioned earlier, if the goal is to simulate the interactions between key process variables over time, rather than dynamic simulation is appropriate.  However, this tool should not be used to model strictly end results of processes; this can usually be achieved more efficiently by spreadsheet analyses.
  • It is important to note that continuous simulation can be used to model managerial policies and decision making, not just physical flows and activities.  It can be used to help answer questions such as “On what types of information should given decisions be based?” and “What should certain policies be?” by simulating information feedback structures embedded within all processes.

Discrete Dynamic Simulation

A discrete dynamic simulator should be used to simulate the attributes of individual entities flowing through a process, and to collect and analyse attributes about individual entities flowing through the process over time.  Discrete simulation, unlike continuous simulation, treats flow entities individually.  In an order management process, for example, statistics are maintained for individual orders, and it is possible to collect and analyze statistics about individual entities.  Model building to achieve this requires more detail and is more time-consuming than most continuous simulations of similar processes.

Combined Continuous/Discrete Simulation

  • This category is a combination of the previous two.  This type of tool should be used, when both continuous and discrete simulation are required within the same model.
  • The function of simulation languages — to simulate the performance of current/proposed process(es) — is identical to that of dynamic simulators (continuous and discrete).  Its modeling flexibility and power, though, is superior, since virtually “anything” can be done.  However, because it is so difficult and expensive to use, requiring expertise in writing code, it will usually not be a valid option.  In general, the tool's extra benefits from increased flexibility and power will not outweigh its added complexity of use and the time needed to learn the language.

Pseudotyping

These tools can be applied in at least three ways: as an interactive, electronic, color storyboard/ presentation of a project, plan or results; as an interactive model of a proposed system or application; as an easy-to-use front-end or interface for a process-simulation model.  With these tools, it is possible to create very user-friendly point-and-click interfaces and screens.

Stand-Alone Documentation

This category is useful for mapping current and proposed process work flows when quantitative modeling or simulation will not be required, or the documentation capabilities of the model­ing/simulation software are inadequate.  These tools are essentially graphics software and may have special functions that assist the consultant in documenting process work flows.  Some of the tools enable users to nest activities/processes within other activities/processes, which simplifies organization and navigation of processes and enables storing and displaying various levels of detail.

Integrated Documentation

These tools can be applied to document and/or model current/proposed processes.  A wide vari­ety of applications with varying capabilities are included in this category.  Typical reasons to select one of the tools from this category are:
  • The unique functionality of a specific tool is required
  • The documentation capabilities of a modeling/simulation tool to be used in later stages of the project are adequate for documentation purposes (will link documentation with model­ing/simulation, which will save effort/time)
In most cases, tools from this category will be used separately for one unique task within a project where these requirements apply.

Spreadsheet


Spreadsheets can be used in at least two ways to support Business Design modeling efforts: to calculate actual or expected process results (accumulated over time), and to score workshop/assessment results.  Spreadsheets are the preferred tool for process “simulation” when only end results are needed (e.g., the average time to process 500 transactions, or the total amount of resources consumed), because they are much easier to use than any of the dynamic simulators.  However, if there is a need to view specific interactions of process variables over time (e.g., how does the transaction processing time vary during the day), or if complex stochastic effects have to be simulated, a continuous or dynamic simulation tool may be required.

Friday, March 13, 2015

Process Mapping

Description

  • The depiction of processes in pictorial diagrams.
    • Activities and their relationship and sequence
    • The relationship of activities and functions
    • Steps that compose activities
    • What purpose each step provides
    • The relationship and sequence of the steps e.g. inputs/outputs, etc.

When to Use

  • Process mapping can be used at all three of the major tiers of process modeling: business-model processes, high-level process models and  “desk-top procedures” level.  It can be used for both "As-Is” Process Assessment and "To-Be" Process Model deliverables.

Approach

Process-modeling documentation is dependent on the purpose of the model and the subsequent tool that is chosen to document the processes.  As defined below, there are many choices depending on needs. These range from simple models for presentation and communication purposes to complex models for developing applications in the future. When developing the activities in the process models, use tools directly related to process development. When the processes have been sufficiently developed, transfer them to the process models described here.
These models are based on levels of detail.  Block diagrams are often used at the first “high level” or process level.  The second level of decomposition is the “activity” level, which is represented by process flowcharts, and, finally, the third level is the “step” level represented by the activity models.  Only areas that will yield benefits if analysed and designed should be decomposed into the more detailed levels.
  • Identify the process to be mapped
  • Create a process diagram for the selected processes
    • Use block diagrams to identify the major activities within the process
  • Identify and map the activities for the selected activities
    • Create process flowcharts connecting activities in sequence by functional area.
    • Identify functions related to process.
    • Identify the start and stop points of process.
    • Utilise activities developed in the block diagrams.
    • Further define activities.
    • Map activities to functions.
    • Determine and match inputs and outputs with adjacent blocks.
    • Identify the sequence of activities (activities may be concurrent or sequential).
    • Describe the relationship of activities along connection lines.
  • Create activity models
    • Identify core activity data
      1. Collect data on each activity, and describe activity in detail.
    • Select activities to decompose.
      1. Only decompose those areas where problems have been identified or may be identified through the decomposition.
      2. Include as criteria for selection : effectiveness, efficiency and opportunit
    • Classify activity steps and create symbols for each category.
      1. Operation: changes state of product toward final form or to meet internal requirements.
      2. Store: removes item from process for later retrieval (add qualifier if permanently stored versus temporarily stored versus destroyed or discarded).
      3. Decision: presents separate options.
      4. Move/transport: any move other than hand-to-hand transfer between  operations.  May be items, data or information moved to or from position/unit.
      5. Inspection/test: internal inspection (on-line review of own work), external inspection (independent test of others’ work)
      6. Delay: in process waiting time (queue, awaiting instructions, process related)
      7. Connector: provides mechanism to document linkages between process flow symbols on the process diagram, which may be separated and  difficult to connect without making the diagram cluttered.
    • Create columns or rows.
      1. Outside: documents, materials or information entering or leaving the function or unit in which the activity occurs
      2. Functions e.g. functional area, departments, job titles etc. (work moving from one function to another should be recorded under the new function column/row)
      3. Other areas involved in the activity (an activity may involved more than one unit)
      4. Note that downward or side-flow movement along columns or rows represents time continuation and sequential steps.
    • Place steps within their categories in the columns/rows.
    • Identify flow with solid lines drawn between activities with arrows pointing to the next step symbol.
    • Identify value-added operations (shade objects).
    • Add text to describe step, time taken, etc.
  • Verify data, information and flows

Guidelines

Tactics/Helpful Hints

  • Ensure that process decomposition only go as deep as is needed to identify problems or describe solutions that you are trying to fix.
  • Be aware that each activity or step should only decompose into a maximum of 1-5 other steps.  This ensures that the level of detail is consistent across process flow levels.
  • Know that consistency is the key to a clear, organised chart.
  • Understand that common pitfalls to process mapping are incomplete process diagrams and premature problem-solving.
Business Model Entity Diagram.png

  • Process decomposition becomes easier when structured within and Entity Relationship Diagram and decomposed from an Organisation’s Value Proposition and Profit Model. This is ensures metrics are applied to the Value Chain and Supporting processes so that Profit and Value Proposition objectives are monitored continuously and adjustments made to process design as when required.
  • From a business architecture perspective I believe ARIS to be one of the better tools. Although I do favour BPMN 2.0 as the preferred process nomenclature as there are many tools that can generate executable code from this standard. This enables standard software packages to be adapted to specific customer requirements whilst minimising customisation costs.

Tuesday, March 3, 2015

Process Characteristics Analysis

Description

  • A technique to identify and assess attributes of business processes, which potentially influence the candidacy of these processes for redesign.  The characteristics supplement other, purely “business impact” considerations, by recognising additional constraints or influences (e.g. prohibitive regulations) which must be weighed into the selection decision.
  • For example,  a process may be voted as having a high impact on the Critical Success Factors (see Process Impact Analysis).  However, if that process is highly regulated and changes in the regulatory environment appear highly unlikely, management may decide to focus its efforts elsewhere (thus eliminating it from the scope of the BPI initiative).

When to Use

  • Process Characteristics Analysis is used in conjunction with the Process Impact Analysis to identify Focus Areas for the BPI program.

Guidelines


  • Limit the number of process characteristics used in the analysis to the four to six, which have most significant contribution to Critical Success Factors. Consider the following points in making decisions.
    • Customer service impact
    • Financial impact: as measured by the cost of executing the process, or the amount of funds controlled by the process (such as procurement, materials management or accounts-payable processes).
    • Number of steps or approval levels
    • Duration: elapsed or applied cycle time
    • Legal and regulatory constraints: While such processes may not be easy to redesign, do not  rule them out if the business impact is high and the organisation is in a position to influence/lobby for changes to the regulatory environment.
    • Degree of automation – Be aware that processes that are already highly automated may be poor candi­dates for redesign.  Also, organisations may be reluctant to change radically those processes in which heavy investment in technology has recently been made.

Process Impact Analysis

Description:

  • Process Impact Analysis helps to determine which areas/processes of the organisation should be targeted for design.  This technique systematically assesses the impact redesigning candidate processes will have in terms of the Critical Success Factors, Key Performance Indicators and/or Shared Values and Guiding Principles.

When to Use

  • Process Impact Analysis is a technique to assist in the selection of initial Focus Areas for the BPI initiative. Subsequent, more detailed “As-Is” assessments are conducted as part of the Focus phase.

Approach

Process Impact Analysis draws upon the organisation’s Holistic Business Model, (Confirmed) Business Vision, Critical Success Factors, Key Performance Indicators and Shared Values and Guiding Principles. Depending on the client environment, the level of scrutiny of analysis will range from a subjective, qualitative assessment to a rigorous, quantitative approach. This choice is influenced by the number of processes being evaluated, knowledge of where problems lie within the processes, need for consensus and buy-in from management/employees and the relative sophistication of the organisation.
  1. Identify processes to be analyzed
  2. Develop process impact analysis framework
  • Determine areas most pertinent to process impact (e.g. Critical Success Factors, Key Performance Indicators and Shared Values and Guiding Principles)
  • Determine scoring/evaluation mechanism.  Possible presentation options include:
    • High/medium/low impact ranking of each area (H/M/L)
    • Shaded circles: filling in quarters of circle—empty equals no impact; full equals maximum impact
    • Quantitative scoring:  rating impact on a scale of one through ten
    • Allotted “money”: asking participants where they would spend a fictional, “X”
    • Number of dollars if they unexpectedly received a windfall
    • Weighted scores: ranking Critical Success Factors from most to least important, then scoring  each process (e.g. 1-10) to determine the average contribution to Critical Success Factors.
  • Complete the framework
    • Using the consensus, scoring system or other approach, finalise the opinions and decisions on the impact each process makes on the comparison information

Guidelines

Problems/Solutions

  • Scoring and ranking algorithms tend to be overly-complicated and often not easily understood.  It is more important that the client understands how the scores were derived than for the scores to be exceptionally precise or complex.

Tactics/Helpful Hints

  • Determine the scoring or other approach as part of work sessions with the client.  This allows the client to retain control over and take ownership of the selection of Focus Areas.
Analysing Business Processes.png
Example of a Quantitative Approach to Analysing the Impact of Business Processes on Critical Success Factors