Although there is almost unanimous consensus that mapping business processes for the to-be state is an important step in preparing for an ERP implementation, the same cannot be said for mapping the as-is state. There the opinions tend to diverge quite dramatically – almost in a binary way - into one of two camps: ‘Believers’ and ‘Non-believers’.
Believers go all-in on business process mapping, creating extensive, detailed, as-is maps as part of their ERP preparation. Their reasoning for doing so is quite sound: if you document both the as-is state and the to-be state, then the gap between the two represents the change that must be managed for the implementation to be successful. Thus, for Believers, as-is business process mapping serves as the foundation for their ERP change management activities. Logical.
Non-believers, on the other hand, take a very different view. It’s not necessarily that they don’t see any value in as-is process mapping (though that may be true for some), but rather that they would prefer to direct their efforts elsewhere. After all, “almost everything is changing”, so why spend so much time and effort creating as-is maps? Why not redirect that organizational energy toward creating better to-be state maps, or going after another ERP hot button, such as improving master data integrity? Again, logical.
Perhaps the most perplexing aspect of this divergence of opinion, is that it does not just stem from the naïve ponderings of inexperienced implementing organizations, who may only do one or two ERP implementations in their entire lifetime. It also comes from the so-called experts - system integrators and ERP software vendors alike - companies that do ERP implementations for a living. And the fact that the experts can’t seem to agree on what approach works best is a large part of what makes ERP preparation activities so confusing for implementing organizations.
But, in spite of what your system integrator or software provider might tell you, as-is mapping does not have to be an all-or-nothing proposition. You can derive significant value from as-is mapping without spending hundreds of manhours doing so. The key is knowing how, what, and what not, to map.
No need to dive in too deep when you first start mapping the as-is state. Document all the main process steps first, in quick, high-level block flow-form, before taking things to a lower level. I liken this to creating an outline, or table of contents, before writing the detailed content. It is far better to have a cohesive, high-level view of the entire end-to-end process than to have a scattered low-level view of certain areas, while other areas are completely missing.
In general, it really doesn’t matter what buttons you push today in your legacy system because those will all change - just like the Non-believers said they would!
Doing an across-the-board deep dive on all your as-is processes is extremely labor-intensive, and often a huge waste of time. Resist the urge to go deep in any area unless and until the need arises to do so. That need typically doesn’t present itself until you are well into the to-be state mapping and trying to improve an identified weak spot which requires deeper knowledge of the as-is state. Then, and only then, you should go deep into that one particular area.
In my experience, this is the single most important part of business process mapping and the one that is most often glossed over. This is where true integration happens, and where the system world meets the physical world. To understand how important area-to-area handoffs are, let’s look at one example. Consider, the typical interaction that goes on between the Business Planning area and the Manufacturing area. The kinds of questions one should try to answer as part of that as-is mapping exercise are things such as:
Because so many of these answers can fall outside of the formal system, it is very important to document both the as-is and to-be states for ALL area-to-area handoffs and incorporate those processes into the design, build and test phases of your digital transformation.
To get the most out of your as-is maps, use them early and often for things such as:
In summary, as-is business process mapping does not have to be an all-or-nothing endeavor. By keeping most of the mapping at a high level, and only going deeper at area-to-area handoffs and a limited number of identified critical areas, it is possible to derive almost all the value of fully detailed as-is maps, with only a small fraction of the effort.