This is Flux Capacitor, the company weblog of Fluxicon.
You can find more articles here.

You should follow us on Twitter here.

Why You Can’t Skip the ‘As-is’ Process Analysis 7

With a background in process analysis I have always believed in the necessity of ‘as-is’ process mapping and measurement. Now working on Fluxicon, I had talked to a few people who told me that ‘as-is’ process analysis is overrated and should be kept short or best skipped if possible.

Instead, one should start from a green field and map out the process together with the employees as it ‘should-be’. Some of the reasons given were the following:

* Companies are not willing to pay for ‘as-is’ process analysis anymore (they want best practices implemented instead)
* ‘As-is’ analysis is frightening to people as it may uncover errors they have made or lead to downsizing
* One is too much limited in the thinking by how things currently are, disallowing truly new and better solutions

So, how important is the ‘as-is’ process analysis after all?

I was confused and decided to turn to people who should know: The open Lean Six Sigma group on LinkedIn. I asked the members of the group whether you could skip the ‘as-is’ analysis, and their answer was an unequivocal “no!”.

You can join the discussion here or read my summary below.

‘As-is’ process analysis

‘As-is’ analysis is the assessment of the current situation in various aspects:

  1. What is the problem? The problem is usually defined from a customer perspective. For example, if you call a call center for a broken device then you don’t want to tell the same story over and over again to different people, and you want the repair done fast.
  2. How are things done? This relates to the actual business process1 but also to the incentive structure of an organization. For example, are agents in the call center rewarded for speedy answers and transferrals rather than for actually solving the problem?
  3. Where are the root causes of the problems? A deeper analysis of the current situation with the problem in mind. For example, are there unnecessary communication steps between the call center and the repair center that—if removed—could speed things up?

After having a clear picture of the current situation and its problems, one then sets out to map a path of improvement steps towards the desired ‘to-be’ situation.

Why you can’t skip ‘as-is’

I got lots of great comments. Below, I summarize and quote some of them2 for you. You can find the full discussion here.

You need to know where you are if you want to reach your goal

The map metaphor came up to highlight the necessity to know where you are starting out in your journey.

Francisco: You cannot plan any change properly if you don’t know what your starting point is. It’s like starting to plan a trip without knowing where your trip is starting from, you won’t know how much petrol you will need, or whether you need a car or a train.

Sophie: We’ve identified we’re at point A, we agree we want to be at point Z. How do we make that journey? Are there any other decision points along the way? Maybe the terrain doesn’t look as we expected it to when we started our journey (budgets, resource, buy-in, tools). We need to know where we started from AND not only where we want to be but how we know when we’ve arrived.

Essentially, the ‘as-is’ forms the baseline for the whole improvement process and it’s a risk not to do it well.

Karl: I totally agree with the need for ‘as-is’ before the ‘to-be’. I have worked on a recent I.T. project where the customer didnt want any ‘as-is’ analysis. The risks of this were explained to the customer, but they declined. As a result, gaps and risks were missed and the project timeline was extended. This was a clear example of needing to do the ‘as-is’ stage, so my advice is do it and you’ll save yourself money, time, stress, angry customers and upset fellow work colleagues.

Eugene: I have always considered the “As Is” fundamental to getting the true measure of a project’s success level as well as the basic area problem definition and true corrective action process. I suppose it would depend on the industry and problem but I have seen way too many cases in past business of the process being correct and well documented but not followed or adhered to.

It’s an opportunity to socialize change

Fear of evaluation was turned down as an argument because it should be dealt with in different ways. Essentially, it is a management problem.

Frank: It is unfortunate if the employees fear it is an evalution. Not being clear on the goals of the effort, insufficient support amongst the formal leaders, or an informal leader in the ranks spreading that fear are all possible causes for that fear.

Jeff: I believe the people piece – the fear of evaluation – needs careful handling. Reinforcement of the idea that the purpose is not to catch people doing something wrong, but to find out what everyone (including management) IS doing, and even to catch them doing something right, will help people feel more at ease with sharing.

Furthermore, the fear of downsizing should be addressed through clear and open communication about what happens if, indeed, the improvement program leads to less people needed to do the job.

Mohammad: Some companies encourage their people for improvement activities by announcing that if any process releases some resources according to new improved methods of work, the resources released will participate in Kaizen Teams and have more training to be in quality circles, and other improvement activities, which people find more amazing than their previous regular work.

Even further, it was stated that particularly during the ‘as-is’ analysis one has the chance to involve and empower people to gain acceptance and support from the team that will be responsible for doing or managing the processes.

Frank: It is difficult for employees to develop ownership in a process if they are not fully involved in its development.

Jeff: Since knowing the “as-is” condition is critical to knowing if improvement is made, use the handling of its discovery as an opportunity to build workers’ confidence and help get them to open up about their ideas and suggestions in Improve.

Be: Ensuring a complete As-Is process analysis helps to change the culture of the organization. As some have mentioned, people don’t like doing ‘As-is’ analysis because it uncovers ugly truths. Part of a true lean transformation involves creating a culture where problems are not hidden, they are raised and treasured as opportunities. Sounds cliche, but never the less remains true.

Mike: I have observed another benefit in almost every project I have facilitated, team dynamics. The projects I have worked on involved multiple functional areas. Each area has optimized their processes over time which has contributed to the whole problem. Members from these areas begin to see the impact of their individual processes on the whole and as a result begin to work together as a team to improve the whole.

Don’t repeat old mistakes

It’s the opposite side of the coin of not wanting to be influenced by how things are done right now: If you start over from scratch, you are likely to make the same mistakes again.

Vera: It was amazing to me how easy it was in healthcare for things to slide back into the “as-is” without clear cut understanding about as-is and why it needed to change. Possibly because “as-is” is so inbedded as “the only way” to do a process.

Join the discussion

More reasons were mentioned, such as that one should leverage what is already in place, and that ‘as-is’ analysis is needed to build a business case. But the three themes above really stood out.

Do you have anything to add or object? Let us know in the comments below or join the discussion on LinkedIn here.


  1. In case you are wondering, this is where you might throw in process mining to complement and validate your discussions with a more complete and objective analysis of current process flows based on existing IT data.  
  2. I slightly edited some of the comments for brevity.  

Comments (7)

[…] This post was mentioned on Twitter by Christian W. Günther. Christian W. Günther said: RT @fluxiconlabs: Blog: Why You Can’t Skip the ‘As-is’ Process Analysis http://t.co/JthxAd1 #crowdsourcing […]

I have read the article with interest.

I was honestly hoping that somebody would come up with a really good argument in favour of the ‘As-Is’. Sadly, I was disappointed. All the arguments put forward are false arguments trying to support a flawed approach to business modelling.

Even the very famous, ‘If you don’t know where you are, how do you know how to get to where you want to be?’ is a totally flawed analogy, as getting from where you are to getting to where you want to be in process improvement is called a ‘Project Plan’.

The fact remains that looking at your current business processes will give you NO CLUE to what they ought to be. Business Processes are just like computer programs. As all good programmers know, that there is now way that you can derive from an existing piece of code what it is that it OUGHT to be doing.

So it is for business processes. There is no way you can derive from your ‘As-Is’ processes what it is that they OUGHT to be doing.

The only way to know what a business process ought to be is by defining what they ought it ought to be doing!!! There is simply no way around this. You cannot derive this from the ‘as-is’ processes.

Many of these bad practices have come about as a result of untrained analysts who have absolutely no idea how to find out from the enterprise WHAT it is that it OUGHT to be doing.

They also have no idea how to model this and simply model the the only thing they’re capable of modelling (although it is of absolutely no value to the enterprise), the current business processes.

They then lie to the business by telling them that this is the only possible starting point. It is for them, as bad analysts. However for the business, it is the worst possible starting point.

Now, it is very important to know that when I talk about ‘As-Is’ that I am talking about ‘As-Is’ Business Processes. I am not saying that analysts should not document existing (‘As-Is’) technology, existing priorities, etc. On the contrary, all of these will need to be known when going forward as it is vital to ensure that these will support what the enterprise OUGHT to be doing.

What I am very definitely saying is that modelling ‘As-Is’ business processes is a complete and utter waste of time – and of other peoples money!!! Let all analysts stop misleading the business community by pretending otherwise.

Regards
John

Dear John,

Thanks for your passionate comment! I appreciate it.

I can’t help thinking that we might be facing a terminology issue here, but perhaps you are indeed one of the few advocates of greenfield process definitions.

One thing that I would love to understand is whether you still measure the ‘As-is’ performance metrics of the process in some way (for example, the time it takes for the customer to get a reply to their complaint)?

And what do you think about process mining as a quick and objective diagnosis tool of ‘As-is’ processes (see, e.g., http://fluxicon.com/disco/ )?

When designing any project it’s important to understand what tools and techniques are appropriate and you do that by understanding what you want to achieve. It’s true that you should never use your current process to determine the future process but if your process is interconnected with many other processes it’s important to understand these dependencies so that a feasible scope can be defined. The As-Is can also be important in understanding the change impact from a process change or a new system. The As-Is process is also a useful way to discover systems which can be missed by systems analysis (systems developed by the business). At my current client we are tasked with replacing legacy systems which serve multiple business processes and implementing new processes. The As-Is analysis of systems and processes is the only way we can understand the key dependencies well enough to break the programme of work into manageable chunks and to show clearly the dependencies to ensure work proceeds in the right sequence. The fact that As-Is analysis shouldn’t be used to determine the to-be processes should not be used as an argument for not understanding the As-Is. As-Is analysis is a very important technique for ensuring a project is well thought out and that the scope of the project is secure and not likely to suddenly increase because of an ‘unforseen’ dependency. In my experience the only people who are against As-Is activity are solution vendors who know that if a project goes longer they will earn more.

Kyle, thanks a lot for adding your perspective. I particularly agree with the ‘The As-Is can also be important in understanding the change impact from a process change or a new system.’ part. We see that often and it’s a powerful use case of process mining: In a way, the As-Is of tomorrow is then used to measure how much (and if at all) the To-Be was actually achieved or not.

I do not think it is realistic to dismiss as-is as pure crap, not worth understanding (hmm, I think this is what they call an understatement).

After all, virtually all organizations you analyze are likely to be running for a number of years, even decades (albeit with varying degrees of success), which IMHO means that they must be doing something well. In fact, chances are that, if they survive and thrive, it is because they are doing, not just one, but MANY things well (something humans tend to overlook because, by focusing in improvememnts, we take for granted EVERYTHING & ANYTHING being well done).

As I see it, AS-IS contains lots of what Popper called “objective knowledge”. If you ignore it, you are very likely to make huge mistakes. Of course, you may be far cleverer than your client. I confess that I personally have never found myself in such a position, but if you are that lucky wise one and can afely ignore all they can say and have been doing, then, what the heck, just launch your own competing company and drive them all out of business! You are wasting your time working for such clueless folks instead of capturing the entire market!

As for me, I am very interested on the possibilities of using P. M. tools to simplify the AS-IS analyses while making it more accurate by using real data (so no valuable information slips through the cracks in workshops, etc.). I believe this can add lots of value, so I want to thank Anne for taking the time to gather these insights.

Thanks for your comment, Rafa! I agree and you make an important point: There is a lot of tacit knowledge, a lot of past decisions that were made some time ago for a good reason, and coming in without knowing the process and its past may make it look easy to say ‘Let’s simply start again from scratch and make everything better’. It typically does not work that way.


Leave a reply