My colleague Chris Taylor recently returned from a Nepalese hiking holiday with some useful and relevant perspectives on the old thorny issue of ‘as-is’ versus ‘to-be‘, inspired bizarrely by hiking boots!!
I thought I’d weigh in briefly as I’ve seen lots of companies struggle with this issue. On balance I’d agree with Chris and I’ll state a few additional reasons to what Chris has already mentioned (read his post to get the rest of what I think):
- gaining buy-in for process change is hugely important, we all know that. Presenting a crap ‘as-is’ process is a fantastic way to gain shop-floor buy-in to change, as people are metaphorically smacked in the head about how bad the existing process can sometimes be. It becomes apparent to everybody that change is required and the resistance frequently magically vanishes.
- baselining processes change is usually not easy to do however is often crucial to further process initiatives within an organization. If you can show a valid and valuable ROI on completed process change your internal business case is dramatically simpler to get by the people holding the budget. Obviously mapping ‘as-is’ gives you the tool to help this business case.
- IT implementations -I’ll explain in another post a real world example where mapping as-is would have potentially saved literally millions
You’ll note above that I said ‘on balance’, let me clarify: In an ideal world I think it is absolutely the right thing to do, however most of us don’t live in one. I’ve seen countless situations where senior executives will not be convinced as they want the ‘magic wand’ picture as quickly and as cheaply as possible.
Sometimes we need to be pragmatic, which might mean
lying being economical with the truth…. a ‘skunk works’ workstream building a certain amount of as-is in order to baseline, hidden from prying financial eyes, can be immensely valuable to the ongoing project/program and to your chances of being able to continue…
I’ve mentioned before that the world of process understanding is changing and we’re seeing both companies and analysts wake up to the new paradigm.
Firstly the realization goes something like this:
- The large majority of activities in businesses are not logged in any transactional system (ERP, CRM, BPMS etc)
- Processes are combinations of both automated (in the transactional systems) and non-automated activities
- To both delight customers and increase operational efficiency we need to understand, see and use both the automated and manual activities to allow us to manage holistic end-to-end processes
- Modern companies have spent millions on understanding, managing, standardizing, etc. the automated activities…
- … they have spent orders of magnitude less on the manual ones
- Thus there is a compelling need to apply the same level of rigor across the manual activities as well
- Business Process Management should be defined as managing the processes across the whole enterprise, both manual and automated, as shown below:
There are very few people who dispute this perspective (SAP, Microsoft etc agree with this picture) and there is also little doubt that increasing the number of automated activities is beneficial. However the vast majority, if not all of the BPM vendors and experts are exclusively focused ‘below the line’ ‘ i.e. increasing the number of activities that are automated, see Phil Gilbert of IBM talking recently.
However laudable and necessary, it’s absolutely fundamental to understand, as evidenced by the picture above, that the contemporary ‘BPM’ vendor’s view of BUSINESS Process Management is incomplete. In order to manage all of the company’s processes you will need a stack of technologies; any sales person peddling one software to manage all of your BPM needs is either lying or doesn’t understand.
So, what do we need to manage the ‘other 80%’?
- appropriate software
- implementation methodology
- a language
I’ll deal with these in a later post.