The same process and component phases are applied to analysis/build/modify/improve efforts of every scope and scale. The two main things to vary are the breadth of the process analyzed and the number of phases worked through.
The breadth of an effort can range from a single sub-process, for example a single operation highlighted by the red circle in the figure below, to an entire business process. An effort can examine any portion of a larger process between those extremes.
Single sub-processes should be examined from a SIPOC point of view, as shown in the figure below.
Beginning Scope: Single Sub-Process
Questions that can be asked (and short run solutions and opportunities potentially identified) for each element of that sub-process as follows.
- 1. Source
- What is the source? A person? A supply of physical items? A supply of informational items? An automated system?
- Is the source always reachable when needed?
- When is the source available?
- What is the means of contact or communication with the source?
- Is the current source the best way to get the required input?
- Does the source know enough to consistently provide the correct input?
- Can the quality of the source be improved?
- When does the source acquire the desired input?
- What are the chances that the source does not have the input?
- What are the chances that the source has an incorrect input?
- 2. Input
- What is the input? (person, physical item, informational item)
- Have all qualities that may affect processing been identified?
- When is it received?
- How can its acceptability and correctness be evaluated?
- Is it properly formatted?
- Are the relevant values in range?
- Are the inputs well-defined?
- How are errors handled?
- How much can inputs vary?
- Is there any way to handle or correct inputs with errors or omissions?
- Can work proceed without the input? Are there assumptions that can be made by default?
- Are there any additional inputs that might be useful? Are they available? What would it take to incorporate them?
- Are inputs queued, and if so, how?
- Can multiple items be processed at the same time (in parallel)? Are there any differences in the items processed?
- 3. Process
- Are all required inputs available?
- How are multiple inputs synchronized so they are correctly handled together?
- Is there any way to proceed when inputs are wrong or missing?
- When and how are errors handled or reworked?
- What is the nature of the process? Does it involve a transformation of one or more properties? Combination of multiple inputs (assembly)? Breaking apart into multiple outputs (division)?
- Are there variations in the process? Are they based on characteristics of the inputs?
- Are decisions and operations well defined (by written procedures, logic tables, routing instructions?
- Are outputs deterministic or varying (stochastic)?
- If multiple output destinations (customers) are possible, how is routing determined?
- What percentage of outputs are routed to each destination and why? Should this change?
- Do outputs depend on human judgment?
- Can any operations be automated?
- Can any operations be streamlined, simplified, or reduced?
- Are calculations well defined?
- How much variation is acceptable? How can it be reduced?
- Can conditions that may lead to future errors be identified? (Condition-based Maintenance)
- What operating data best serve as KPIs? Are these captured, and if so, how? Is there a better way?
- How has the process changed over time?
- What factors cause variations in the outputs, time taken, or resources consumed?
- Do different operators get different results? Why?
- Do operators require any particular background, education, training, licenses, and so on?
- Who has the capability to effect any identified changes?
- What permissions are needed?
- How is the process initiated (triggered)?
- Does the process run continually or only occasionally (in batches, on rare conditions, etc.)?
- Is this sub-process on the main flow (all items processed) or a side or conditional flow (only some items processed)?
- 4. Output
- Are the criteria for acceptable outputs well defined?
- How are outputs judged against those criteria?
- Are all outputs tested, only some, or none? Why?
- Are any of the tests automated, or can they be?
- Are the causes of unacceptability identified and understood?
- What percentage of outputs are not acceptable?
- Can unacceptable outputs be reworked or repaired?
- Are any changes to the outputs desired?
- 5. Customer
- Who or what is the customer? (Person, physical, informational)
- Do different customers react to outputs in different ways?
- What alternatives do customers consider?
- What records are kept about customers?
- Are the outputs appropriate for the customer(s)?
- How are rejected outputs handled? Can they be reworked or corrected?
- When are customers available?
- Do customers ever change?
Some general questions can also be asked
- What are the installed costs for the process?
- What are the fixed and variable operating costs for the process?
- Are we examining the process in terms of quality, throughput, or both?
- Can the process be broken down even farther? For example, a given type of worker or workstation may perform multiple actions sequentially or conditionally based upon multiple criteria. The operation can be analyzed strictly in terms of resources consumed (including time), or in terms of specific transformations carried out.
- Is there any information certain analysts or other participants are not allowed to see?
The important thing to understand about the above is that the proper questions will be asked based on what is actually encountered. There is no fixed set of questions that can be put into a flowchart that will always lead to the right questions being asked, the right solutions being identified, and the right problems being “solved.” The goal is rather to be aware of the vast number of questions that can be asked, the vast number of potential solutions or modifications that can be applied, and how the fitness of identified alternatives can be compared.
Scaling Up in Scope: Multiple Sub-Processes
The next step up in scale is to examine a larger portion of a process, or an entire business process. This is something composed of many sub-processes as described above. In the topmost figure, consider not just a single sub-process as shown in the red circle, but the entire process as shown in the complete figure.
In this situation we differentiate between process nodes that are connected with the external world, especially involving inputs, and those that are contained entire within the organization. The organization should be able to answer all of the above questions for each phase of internal processes if the organization is sufficiently mature. At the very least it should be far easier to find the answers and effect any necessary changes. Finding answers and making modifications in processes connected to the outside world can be much more complicated and potentially time-consuming.
Another thing to consider is that different KPIs may exist or need to be identified to assess the performance of the whole system, or at least larger swaths of it. Analysis must also include queuing effects between the different process nodes, and throughout the system as a whole.
Scaling Up in Effort: Partial vs. Full Life Cycle, and Part-Time vs. Full-Time
When considering the scale of a potential engagement, the number of phases worked through can also vary. Initial engagements will typically help define the problem (Intended Use phase) and understand what is going on now (Conceptual Model / As-Is phase). If requirements or designs or fixes can be identified that will yield meaningful short term benefits, then those will be offered and/or implemented in the initial engagement. In general, however, initial engagements are only intended as the beginning of a longer process of identifying what needs to be done, what analysis and implementation methods are likely to be suitable, and to introduce customers to the analysis structure.
An analysis team can perform any phase of effort from defining a problem to figuring out what’s going on now to identifying requirements to helping identify and select different solutions and vendors to helping conduct implementation, test, and acceptance operations. A team can perform the work independently, can work with the customer through various phases, can train the customer to perform all this work on their own. The team can also be available continually or only intermittently to answer questions and provide reviews and incremental training and guidance, and can be on site or remote.