Following on from my last blog where I discussed business process identification and selection, the next logical step in designing business processes starting with the definition and refines of business processes.
Process Definition and Refinement
Definition happens the first time through, and refinement happens at each new version or revision. In definition the “as-is” details of the business process context, process details, and the process model are captured. This initial capture of “what the business does today” needs only to be performed once prior to first automation.
In the refinement procedure the “to-be” business process model includes incremental improvements to be carried into the first and all subsequent iterations of the continuous improvement cycle. In subsequent cycles, process activity metrics from real-world operation of the process should be available to help with refinement. At the completion of either definition and/or refinement technical concerns such as technical analysis, test case development, and UI Design are addressed in the next major activity.
Process Definition
Process definition is the activity in which the details of the core business processes, identified previously in the analysis phase, are expanded in a business process model which is later to become the executable model.
Capture Business Process Context
Initially I like to hold a workshop with the Process Owner and process participants (the end users who interact with the process and perform process steps) to understand the process from a high level.
Typically not all participants are available, or needed, for this step. I like to capture “the big picture” such as the goals, context, rules, etc. and to have an understanding of the high-level end to end flow of activities. I am not concerned with the HOW something is done.
I use a business process context template to drive the conversation and any white boarding that is required.
Capture Business Process Model
I always capture the model in an iterative manner and ass a continuation of the functional decomposition that I highlighted in the previous blog. I starting modeling starts by capturing the highest level process flow that represents the core business process identified in our earlier analysis.
I know some architects prefer to use a tool to capture the business process model but my experience is that it can bog down the analysis. They can be too complex for what I am trying to achieve and they create unnecessary distractions or put-off the business users.
So instead I like to whiteboard this using a small number of sticky notes (e.g. activity, decision, human, system). This allows me to easily move the activities around. I initially capture the happy path and the most common flows. I then work through the flow in iterations, start shallow, then fill in more detail. I like to identify the following:
- What is commonly done, and what decisions are made
- Who performs the activities, or are they automated
- Where are they done, and when (business calendar)
- Who makes decisions, and what business rules / policies / regulations are involved
- What are the goals, objectives, measurements, and KPI’s
- Initiating events, business objects, end state
The high-level core business process model can be linked to our function model. Now we can proceed with functional decomposition to the “level 3” business activities.
Drilling down a level deeper into the example we see the consultant completes a expense request, a coordinator reviews the request, and a manager approves it. The expense report is implicitly transferred between these participants and the activities, but the detail of the message flows is not yet developed at this stage in the modeling.
We can always use the functional model to check that the business tasks for this activity are showing up in the process model. As we move through this process of mapping our increasingly more detailed models to the function model we can ensure that process models are maintained at the right level of granularity. Finally we start to see application functions / services and human tasks (the things that people actually do) appearing in our model along with exception handling and external data relationships. This is the final stage of decomposition and corresponding to the “level 2” model which is now ready for technical preparations before finally becoming an executable model.
It is at this stage that I can complete and verify the business process context model to make sure we have covered everything and that the original assumptions were correct.
Identifying Supporting Applications
The mapping of business functions to applications can be surprisingly complex. The diagram below shows an example of a graphical representation of applications to a functional model mapping. This example uses the APQC PCF approach highlighted earlier. This form of diagram will make it easy to determine the application(s) involved in a process as well as where multiple applications happen to perform the same function.
Business Objects
Business objects are the pieces of information that flow between the activities in the business process model. In later technical design phases these will become the message flows in the technical representation of the model. But initially we need to identify the business objects that are necessary to perform each activity and are passed between them as inputs and outputs.
An important part of identifying business objects is a mapping of business objects to applications. This helps to determine which systems are responsible for the information needed in our business process flow.
The above diagrams is an example of a “CRUD” (Create, Read, Update, Delete) matrix showing, not only which applications hold the information we need, but also some insight into their level of responsibility for the data, e.g., whether they update or merely read it.
Some business objects are easy to identify, having perhaps just one “system of record”. When it is unique and stored in one place it’s easy to produce a canonical data model. Unfortunately most core entities, such as customer, product, etc., are not so easily defined. Stored across a wide variety of applications, these business objects are more difficult to define.
Elaborate Business Process Details
The next step is to collect a lot more detail about how the process actually works. This involves interviewing the people that actually perform the
process.
You should meet with each person or representative of a group that performs a business task or makes a decision as part of the process. Capture the details. During the discussion watch out for any issues such as unnecessary risks, delays, challenges, etc. It is not uncommon at this point to encounter inconsistencies. Examples of problems arising include the following:
- Differences between the process as stated by LOB owners and what the workers involved were actually doing
- Inconsistencies between business goals, objectives, business rules, regulations, and how the process is being performed
- ontradictory details captured from different participants in the process (e.g. person A said use system X, but person B said use system Y)
- Unnecessary steps, churn, risks, delays, duplicate data entries, etc.
- Inconsistencies in the way the overall process is carried out, e.g.:
- One group takes time to capture data that no one uses
- Two groups are doing the same work
- Decisions are not being made consistently throughout the process
- Known issues and suggestions (from task detail capture)
If the issues highlighted are minor, they can be corrected and the model re-published.If there are major issues raised however, it may be necessary to re-convene another workshop session to correct them.
Once the documented business process has been agreed, a decision needs to be made on whether another level of detail is required. If this is the case then another round of interviews/workshops will need to be scheduled.
Good Luck, Now Go Architect Model that Process
An Enterprise Architect's Musings 