Most process modelling methods start with analysis of the existing processes, an as-is model. One of the challenges with as-is modelling is deciding how much work to do. Very detailed as-is models can be time consuming (costly) and may drain the organisations tolerance for Process Management activities very quickly.
As-is modelling can also be quite hit-and-miss as the analysts try to decipher what the current process actually looks like, this can often be because there is not a single as-is process, there are many.
The main purpose of an as-is model is to give a Process Project the information it needs to work out where improvements are needed and what is the starting point for change?
On the other hand, to-be modelling is a description of future desired processes. To-be modelling requires analysts to be creative in solving problems and designing processes to achieve business outcomes, often with not so perfect information about what the organisation wants to achieve.
I find it fascinating to sit in a room and watch a selection of staff have a to-be model presented to them, you can see the defences rise – and everyone thinks it is not going to work – for different reasons.
So it doesn’t sound like either will work? not true.
My approach is to start with high-level to-be modelling. This often involves developing a future state, Process Architecture – aligning the organisations strategic goals with it’s process management goals. Further detail can be added about key processes in the form of IGOE Process Scope models (more on these in future posts).
When agreement has been reached on the future state, then we can go back and look at the as-is. This is limited to the processes that will transition into the new architecture and only to the level of detail required to find the areas of process improvement and develop the change plan to implement the new to-be models.
With this approach there are plenty of stops along the way to make sure that everyone is in agreement.
When you do Process Modelling, which type of analysis do you do first? How effective is it?
Craig,
I agree with you that focusing on the as-is process can ground participants in the current state, making innovation difficult. And I have also experienced the challenge of getting people to accept a future state that diverges to far from their current state / comfort zone.
When the future state is likely to be significantly different than the current state (i.e. not just an incremental adjustment) I prefer to start with establishing an explicit understanding of what the business is, using a business domain model that identifies and defines the business concepts and the relationships between them. This can be developed ‘offline’ if there is consensus on the concepts, but often discussion among a broad group identifies divergent perspectives and understanding and allows the differences to be resolved before they become critical issues later in the project.
Once this context is established, and with an understanding of the organization’s overall goals, establishing agreement on what the process goals / objectives are is much easier. And the domain model provides the terms that can be used to describe the future state process.
As processes have an impact on both the organisation and systems, I prefer to start with mapping the high level processes to organisation/systems (and vice versa). The reason behind this, is that if the organisaiton changes (BOM), or the systems change (application implementations, change requests etc.), then the impact on processes can be identified and the risks mitigated. Therefore I agree with Craig and Chris that you do not have to go to a high level of detail when documenting the as-is. What you do need is an thorough understanding of the as-is (by interviews/workshops) and process/time in motion measurement. It is always difficult to prove ROI/Quantative benefits, so if you measure the as-is and to-be, you can collect data to prove/disprove your assumptions, and ultimately justify your existance.
After all, in general, the as-is is the problem, so why spend too much time documenting it, when the chances are that you are going to change it!
Thanks for contributing Stephen,
When I initially read your comment I thought you were referring to using the organisations systems as a basis for the initial analysis, and therefore I reflected on when I have seen high-level systems diagram used as a starting point. In these cases I would feel confident to say that 100% of the time it has led to the wrong analysis being done – because as the systems were built, process compromises were made and compounded so that the systems no longer represented the processes that the organisation needed to support.
Have you had these experiences?
I would think that a “thorough understanding of the as-is … (including) time in motion” is a high-level of detail for as-is analysis, where would you draw the line to simplify what is being done on the as-is?
Cheers
Craig
Thanks for the great comment Chris,
Are you able to provide an example of the Business Domain model? How does it compare to a standard strategic analysis?
Thanks
Craig
Interesting question Craig.
In my experience, you can only get a rich understanding of how best to innovate effectively from AS-IS analysis that comprises of customer-perspective performance data as well as activity steps.
TO-BE analysis leaves a lot of room for conjecture and inaccurate assumptions to throw the process off track.
Craig,
The Domain Model isn’t significantly different than several other types of box-and-line diagrams; You may already be familiar with Conceptual Data Models from the ER world, Concept Maps from systems thinking or the Fact Model from business rules approach. The subtle difference is that you identify, and define the concepts (nouns) important to the business and the relationships (verbs) between them. This forces a common understanding among the participants, and flushes out undeclared / implicit assumptions.
It is equally important that the domain model be independent of implementation…a good domain model captures the essence of the business, and therefore is equally applicable to the AS-IS and TO-BE perspectives.
Failure to have a common understanding of the concepts of the business, and declaring assumptions, is at the very heart of bad process design and application systems requirements.