An issue raised by E. Scott Menter in this discussion on process mining where he writes: "Everybody is way too focused in general on the 'as-is' or current state of a process. Sure, there is some information that's worth knowing—but in general, I find the obsession with the precise documentation of a process you're about to replace a little odd." What do you think?
Yes. At a high level it may be acknowledged that the process is "broken" and the focus should just be on modeling the to-be right out of the gate. The reality is, however, the as-is is and can be instrumental to understanding the "who, what and where" as to WHY it's broken. This is process discovery and though I believe that the heavier lifting and effort should be done in the "to-be," the "as-is" is oftentimes necessary to UNDERSTAND the existing processes and what's wrong with them because the organization, client themselves may 'think' it's actually one thing that's the problem and, after discovery, it turns out to be something else altogether.
Don't discount the exercise but, "yes," don't dwell on the "documenting to precision" ad nauseum, ad infinitum part. Just get to the point where you understand, then move on.
Just my tuppence, but I do spend a lot of time doing this and see the above a LOT.
Yes, if for no other reason than to capture the data used in the process.
Often times, there is nothing wrong with a business process that a little tweeking couldn't fix (as opposed to starting from scratch).
In my opinion, this question has a lot to do with change management. Ideally, you should just know how the processes run now (the “as is”), and then model and automate improving it (the “as it should be”). This is great in some organizations, mainly in the private sector.
But, this is not the case when the organization is very conservative. For example, in my experience working with Latam government agencies, it is a very bad idea to automate a process and at the same time change it. Too much change for people who have done the same thing, the same way, for 20 or 30 years. In these cases, it is much better to make one change at a time. First automate the process “as is”, introducing tools and automation. Then let the process run for a year, get objective measures (KPIs) and then improve what really has to be improved, but with the support of your users.
"Those who cannot remember the past are condemned to repeat it." according Spanish writer and philosopher George Santayana...
And to a certain degree I think this makes some sense. I want to learn why certain things worked better or worse. And I definitely do not want to make the same mistakes over and over again. Now... with faster evolving markets, technology etc. this becomes somewhat of a challenge. So therefore I believe in a hybrid apporach. You wouldn't want to capture every single process down to an infinite level of detail. But you do want a proper and relevant context! In 2013 I wrote a small blog about this which addresses specifically the concerns I have with applying process mining as a means to capture the AS-IS.
Summarized: I think you need to understand the context and big picture (say 1-3 levels max). From there you drilldown (e.g. using process mining) only on a need-to-know base.
It depends on the goal of the new process or digital transformation effort.
1.) If you want to move to a significantly new business model with significantly different set of processes, the "As Is" is used to make sure something really important in the old process(s) are not left out as a flow, step or policy. It is usually done last for verification.
2.) If you are looking to improve a process or design one with similar outcomes, then the "As Is" carries more importance and is usually done first
3.) If you are doing incremental trnasformation, the "As Is" is essential to create the necessary transofrmation steps.
I don't see where an "As Is" doesnt show any value. It's question as if the "As Is" has a core role or advisory role.
Yes it is worth capturing the As-Is for all of the reasons above and a few more. First, if you don't have any measures for what is happening today, how will you objectively know how by much it will be better, faster, cheaper tomorrow? Next the Future always takes some time to arrive, so why not get the organisation into 'Change Mode' by fixing some of the smaller, easier issues first and gain some early paybacks ? And, sometimes, there are worthwhile benefits from the cumulative impact of small changes. Entropy, like household dust, just gathers in the corners of a lot of business process, and a spring clean every few years can work wonders!
In most cases "Yes", unless it is a rip-and-replace kind of development with a all new business process and features, with no take aways from what was built in the past (totally tangential)
Understanding of the AS-IS process helps in:
It is good to start fresh on a blank page and build everything from scratch, with no inference from the past AS-IS process.
But in an ideal realistic scenario : It is a tradeoff between Time | Effort | Revenue | GoTo Market needs | Investment of the Past
I am with Walter and Jim.
1) The top levels AS-IS is the must as an enterprise-wide project. Just be very clear how you define these levels – see ref1
2) Working with deeper levels depends on a particular business domain. Possible variants:
a) we don’t have any good processes, please start with TO-BE
b) we have perfect processes, please, start with AS-IS and just automate them a bit
c) we have processes, we want to change them but without their digitalisation we can't innovate them, please start with AS-IS, automate/digitalise them to better understand our options and then transform them.
Maybe working in the public sector gives me too specific of a background, but the as-is process review (perhaps not really necessary to be "meticulously" documented or reviewed ad nauseum) is absolutely necessary as a jumping off point. It's the introduction to the history, progress, problems, and background as to why you are there to fix it/improve it. It gives the SMEs a chance to remember anything they may have forgotten to document before, to discuss all the requirements/limitations of legislation, and to give insight to their own ideas about how their crappy or convoluted process could be improved. It gives the new analysts and developers a chance to play devil's advocate or at least provide an agnostic viewpoint when asking "why are you doing that" or "what about x?"
Is it possible to spend too much time doing this? Yes. Can the nitty gritty detailed review of how the current system peforms some specific function be saved for a future requirements review? Yes. Is the documentation of the as-is sometimes required as a milestone deliverable? Yes. And that's okay, although it can certainly be an exercise that wastes more time than it should. I think you'd be hard-pressed to improve something without knowing what you're starting with.
In my opinion, this is dependent on the objective of the company and its strategy. For improvement studies of existing processes, it is necessary to understand the ‘As-Is’ to identify the issue in a scientific manor. I have experience where I have done process improvements (Fast improvement) where ‘As-Is’ processes where not studies and I based assumptions on experience (you can call this a hypothesis) at the end it ended up being a correct judgment, but it could have been the other side.
We are at the point that things are changing so fast that judgment is needed in some cases and time spent on 'as-is' is not given. I prefer doing it correct and studding the ‘As-Is’ but we are also faced with a realistic world that regulations as an example,are forced on you and the time given to assess As-Is could jeopardize the process the project timelines, so we are forced to judge.
My other point is that if your organization are introducing a new product or service, in this case there is no ‘As-Is’ only ‘to-be’
I agree with Ross how can you improve something of you do not understand the something….? Interestingly our experience often shows that the managers often do not really know what people actually do and the exercise of exposing current processes often reveals surprises for all! That then opens the door to discussion on is there a better way and again this knowledge will likely lie with the people actually doing the job. So there should be a serious purpose to understanding the “as is” otherwise users’ cooperation in the bigger picture might be a challenge! Also never forget compliance/regulators who will want to know both current process and may have a view on changes.
As I have pointed out next generation build can be undertaken via the process model and this not only brings benefits of transparency where “the Map is the App” but it builds enthusiasm from users who can now contribute direct to implementation to new ideas. Another consequence is by mapping out the process there is by default a knowledge transfer whereby the process is then owned by the business not in the closed book of users protecting their “territory”….. Yes it happens and can be an issue to address.
The debate on BPM methodology concerning as-is versus to-be is at the core of the meaning and future of BPM.
Once-upon-a-time work processes were owned by skilled labour, trades people and engineering, including plant managers who were all former engineers.
The capitalist bargain was "we'll provide the capital and you'll provide the labour".
Since Henry Ford however, management has been intent on rationalizing the labour part of the deal - and not a bad thing given the standard of living many enjoy as a result. But as the history of Taylorism and industrial engineering shows, for many reasons work rationalization has been severely limited and often over-sold -- and un-rationalized tacit knowledge of work has remained as important as ever, at least until the present.
BPM technology is the core technology that carries the burden of this dream of management rationalization of work. It is in this context that our debate about "as-is" and "to-be" occurs. Because both as-is and to-be are the expressions of management's drive to rationalize work.
I see three determinants of further progress in the successful application of BPM to work automation. Each one of them turns signficantly on the as-is/to-be question.
1) CORPORATE GOVERNANCE - As-is work processes are contested terrain in terms of giving up work autonomy and tacit knowledge -- and the wages that accrue to that tacit knowledge (see Amazon warehouses for example).
2) BPM METHODOLOGY - To-be BPM is all too often a Platonic fantasy - and the subject of jokes and war stories in the bar after work. On the other hand, new process mining starts from the as-is, and because process mining is itself technology, goes a long way to solving problems of learning how tacit work processes actually function.
3) BPM TECHNOLOGY - Improvement of BPM technology is continuing, to the point that real-time "what you draw is what you execute" is viable and the round-trip latency will become a thing of the past. The implication is that through process mining and better BPM software, the distinction between as-is and to-be will diminish.