BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, November 29 2016, 09:50 AM
  4.  Subscribe via email
With the speed of business today, do you think it still makes sense to capture the 'as is' of a process?
Zachary Kelemen Accepted Answer
I think that really depends on the level of knowledge the organization has of its process. If the business knows exactly how the process *should* be executed, capturing the current process could be a complete waste of time. Often times, however, the business doesn't really know whats going on underneath the hood and it requires that due diligence to capture that existing process in order to fully understand what needs to be modeled and improved upon. From a consulting perspective I see both sides.
Zack Kelemen - Digital Process Practice Lead at Rightpoint
Comment
This and...
  1. Patrick Lujan
  2. 3 days ago
Yes, because it is easy/quick to build at least a high level "as-is" process, but the main reason is you need to know what is good about a process currently in use and what is bad about a process currently in use.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
Bogdan Nafornita Accepted Answer
Just discussed this on Twitter today :)

For most customers, no. Or do it free of charge (truly). Nobody (see exceptions below) wants to pay to find out how much they suck today. And there is no real customer buy-in from doing so. It's generally a waste of time.

Exceptions may be a series of large institutions where they need to justify buying all those man-days.
Managing Founder, profluo.com
Comment
One exception is where there is huge disruption, so the As-Is and To-Be are very different, and you need to understand the change management issues. But do as little As-Is as possible
  1. Ian Gotts
  2. 3 days ago
Agree, Ian, but still, mapping out old processes may not be that useful in case of huge disruption. Case in point: I am helping a customer go from literally zero to one. I am sure that if I showed them the change management impact, they'd have run away screaming. Sometimes the plan is so intimidating that one simply gets down to doing. Now they already went through the worst and are already seeing the light.
  1. Bogdan Nafornita
  2. 3 days ago
+1 for "Nobody wants to pay to find out how much they suck". Wish I'd said that. :)
  1. E Scott Menter
  2. 3 days ago
If there is so much different between the AS-IS and TO-Be, do you think it is worth spending any time on understanding the past. Is change easier if you know what crap you leave behind?. mmm...maybe it is.
  1. Emiel Kelly
  2. 3 days ago
"there is so much different between the AS-IS and TO-Be" - did you use BPR???
Amit Kothari Accepted Answer
I think the real question is - who is going to listen anymore to a boring old BPM vendor that has invented some decades-only terminology called "as-is" which holds zero (or negative) business value to the average business user?

Fighting people with "as-is" mapping is doomed, because there is no "as-is" map that is actually accurate. Everyone does things inconsistently anyway - even before an "as-is" effort came into being.

The real answer is not to fight with change, but to provide tools that actually work for business users without effort - without needing mapping and all this other nonsense. Which is why huge spaces like collaboration and IM are exploding right now.

That applies for all generations, btw, not just gen x and gen y - who will rule the workforce in years to come.
References
  1. https://tallyfy.com/digital-transformation-puts-people-first/
Comment
Antoine Mottier Accepted Answer
Yes, mainly because you will not be able to improve the current version of the process without properly identifying what is wrong with it.
And also because in many situations processes in production are not really what you have in mind: peoples quickly adjust to faulty process :)
Comment
Always a good idea to Start Where You Are :)
  1. Christine Custis
  2. 2 days ago
Emiel Kelly Accepted Answer
A little sarcastically I always call traditional AS-IS modelling HAS-BEEN modelling. You are always talking about the past and try to understand why a process isn't performing as expected. And that's another problem; I think it is hard to understand, what I call, the dynamics of execution by process models as we see them often. I wrote about that here

The technology of process mining is already a little better in showing that dynamics, but it is still the past. While processes happen now. That is why AS-IS is more something like monitoring to me. Knowing all the cases in your process, their status and the possible problems. But that is still a speedometer without a throttle or a brake.

These insights must be turned into action. My ultimate goal is that every executed case is the trigger for process improvement, but that's probably not the case always. Sow how often are you able to change a process? Wrote about that here

So, AS-IS process modelling. I hope it will happen less and less and that process improvement becomes the daily task of every executor in the process.
Common Sensei at Procesje.nl
Comment
+1 for "has-been modeling" (with an extra bonus point acknowledging the subtle use of language by a non-native English speaker!)
  1. E Scott Menter
  2. 3 days ago
John Reynolds Accepted Answer
The client has some goals in mind for their process improvement project, so you need to know enough about what they are doing now to be able to propose specific improvements that will help them reach their goals.

Likely mapping the as-is process isn't going to help on its own. You need data.
Comment
Yeah the subtle (or not, I dunno) distinction I think you're making is this: it's important to know what you're not accomplishing now so you can measure that against what you're able to accomplish later. That analysis doesn't require "as-is" analysis of the process itself but rather a (frankly much simpler) analysis of the outcomes.
  1. E Scott Menter
  2. 3 days ago
David Chassels Accepted Answer
Yes and no...of course knowledge of how existing processes work is sensible but is it necessary to spend time "capturing" in some formalised way? Ironically this is what auditors were doing decades ago but results not shared with users! Today such an exercise will likely be seen by users as a waste if time. However if you can persuade users that this is now about how you think we can best achieve the required outcome AND in a format that they can readily understand AND it becomes the application...exactly as they articulate then this will attract users attention ..even excitement...?
Displaying in a graphical model with the relevant icons is not rocket science and all will readily understand. As that model becomes the working application at a click so the game changes. Users fear of change is removed and a new era of empowerment opens up. However there maybe other challenges such as " old IT" seeing their empire being challenged as coding is effectively removed. Then there are users who are reluctant to see their secrets exposed as such knowledge is transferred to the business. It becomes a paradigm shift and the " models" become the actual deployed processes as such by default the "as is" ......it's the future...
Comment
Fear of change is an important point; I believe that's a key driver for many when they engage in "as-is".
  1. E Scott Menter
  2. 3 days ago
All depends, as usual. It is mandatory to carry out some "situational awareness". So just ask people what they think about their "as-is" processes. (Of course, their opinions must be validated with other collected facts.)

My experience shows that top-level processes (L1 and L2) will be the same “as-is” for long time. Thus model them first to have a “big picture” view. Then use this view as a supporting structure to start small transformational projects. See [REF1] “Incremental transformation to #digital (explicit and machine-executable) processes.”

Again, all depends. Success of BPM in a particular enterprise depends on many aspects – see the 19th law of BPM [REF2].

Thanks,
AS
References
  1. http://improving-bpm-systems.blogspot.ch/2015/06/incremental-transformation-to-digital.html
  2. http://improving-bpm-systems.blogspot.ch/2015/07/laws-of-bpm-business-process-management.html
Comment
Agree with the fact that an overview of a process landscape is valuable. The Why and What? of processes doesn't change so often indeed. The who and how does.
  1. Emiel Kelly
  2. 3 days ago
... this.
  1. Patrick Lujan
  2. 3 days ago
Not sure I'm with you here, though I may misunderstand. I'm thinking that only the "why" and "what" matter: after all, that's what your new process is supposed to address. The "why" might be "increase customer retention" (not sure what the "what" would be, but as a guess, it would refer to metrics; e.g., what's our current customer retention rate?). The "who" (Fred calls sales to see if the deal has completed) and the "how" (the customer faxes in a complaint), well, those are gonna change.
  1. E Scott Menter
  2. 3 days ago
There are two types of WHY: 1) WHY do we need this process (outside-in viewpoint) and 2) WHY this process is like that (business design viewpoint). Scott's ' The "why" might be "increase customer retention" ' sounds like a justification for improvement or re-engineering.
Walter Bril Accepted Answer
Well... The issue is that for some weird reason (?) processes are often not being documented very well in general. So you get these projects as in "We need to implement that new ERP system." or "We need to become ISO certified." And thus: Therefore we need to map our processes. The way we do stuff around here say. Wait a minute. Why do we not have the latest and most up-to-date process documentation already? Ah... Because we only need to figure these dreadful things out when the sh$@t hits the fan right? So you don't have to map the AS-IS, as you already have these perfectly managed, owned etc.

So yes. It does make a great deal of sense to know what, why and how you are doing stuff...
Comment
Sandeep Johal Accepted Answer
Yes. An organization needs to know what it currently does. If not, how will they know they've improved/changed?
And how would past mistakes not be repeated? Professions such as lawyers, medical practitioners rely on current & past documentation on performing their work now and in the future. Major changes in the field were built on previous findings.
Most are after the target state - and if you quiz those individuals, they'd claim they know the current state. In my experience, it's rare for anyone to change without a peripheral (or in depth) understanding of where their journey starts.

Let's not confuse the inconvenience of As-Is (some experience) as an indication of its worth. Without it, we'd be guessing if we progressed.
Comment
Here again the important distinction seems to be the "as-is" process vs. the "as-is" metrics. The latter matter.
  1. E Scott Menter
  2. 3 days ago
I see we are getting a mix of yes/no here.

Can we please debate the amount of time to do the as-is for, say, one functional unit?

If their process has 50 steps, how long does it take to build an as-is that puts down the steps with attached images of the forms in use and roll that out to a small group of stakeholders so they can argue about the logic/forms? One hour, half a day, one day?

If the answer is one hour and you have 10 functional units contributing to the process, you have max 10 hours of prep to do before you go in to facilitate the to-be process.

I remember a large to-be process mapping a contractor of ours did for City of New York using our software (a compliance system across all boroughs) with something like 20 processes with 50 steps each - they had the option to do real-time mapping but chose to send people to meetings where they would take notes and then return with a paper process map 2-3 days later. It took forever and got to a stage where we had to come in. We e-mapped all of the processes in 2 days and then went to the stakeholders and made adjustments to the processes in real-time while on site. The turnaround time went from 2-3 days to 0 days.

We routinely, as part of strategy consulting, spend a day, at no charge, building a kbase of a customers infrastructure ( markets, products, competitors, technology options, regulatory bodies that impose standards/require compliance).

These exercises take 1 day, sometimes 2 days, never longer.

The client gets to see their corporate infrastructure (several thousand data points w/ links to URLs) and it makes for a good talking piece as opposed to showing them the infrastructure for, say, a grocery chain where the participants would IMO immediately glaze over.

We do it as much for us as we do it for them, avoids many awkward moments where you get questions and have to say "I'll get back to you".

Bottom Line . . .

I like to know where I am coming from as part of deciding where to go, moving forward.

Seems to me if you don't know where you are, it is a lot more difficult to make decisions re forward directions.

Alice: Would you tell me, please, which way I ought to go from here?
Cat: That depends a good deal on where you want to get to.
Alice: I don't much care where.
Cat: Then it doesn't matter which way you go.

Lewis Carroll, 1865
Comment
Rachel Accepted Answer
Just how deep of a to-be analysis required will depend wholly on what they plan on doing to the process.

No matter what they are doing with the process, it will always be helpful to capture the general as-is and its baseline metrics. Because no matter how amazing or revolutionary your new process/solution is... at some point quantifiable ROI and improvement metrics will be requested.
Comment
100% agree
Any medium/ large organization wants or should want an ROI for any significant initiative before they part with hard-earned money.

The ROIs of today are transitioning to SROIs and the folks who approve them no longer sit on stools and wear green eyeshades.

The new decision makers want to know what, when, who, where and why and are particularly interested in knowing how a new initiative might disrupt their golf games.
E Scott Menter Accepted Answer
Blog Writer
In a few of my comments above I note what appears to me to be a conflation of two distinct types of analysis:

  • As-is process: Who submits a request, where it goes from there, what happens when it exceeds a certain threshold or sits around too long without action, who signs, who secretly makes copies because they know the boss will lose it and ask for another, who is working around the process entirely, etc.
  • As-is metrics: What results are we achieving through the existing process? What are we trying to improve? What's most important to us, our customers, our other stakeholders?

Knowing your “as-is metrics” is critical, as I imagine we'd all agree. After all, your goal isn't process improvement, it's business improvement—and you'll only know if you managed that goal by looking at the metrics.

Hope you all had a great Thanksgiving (in the US) and/or weekend.
http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
Scott nails it IMO -

The goal is business improvement.

"As-is" metrics are critical.

Metrics are the result of performing at least some of the work consistently.

Absent a map of the "as-is", it seems to me analysis of metrics becomes a lot more difficult.
What if the "as-is" metrics are not available (i.e. existing systems are barebone, primitive and not connected, no one has ever recorded any relevant performance metric in any way, and has a very vague idea of what KPI means)?

Do you still engage with this kind of customer of just wait it out until they first grow some form of process/data maturity?
  1. Bogdan Nafornita
  2. 2 days ago
Agree. Any process improvement thing should start with the (right!) metrics. From some kind of process landscape you can make clear the result and goal of any process and try to find out how well the process is (eeuh did) performing.
This could be the trigger for traditional process improvement., You know with a team of process specialists, modelling as-is processes in a room on the 3th floor. Far away from the daily operations. They would only get distracted by those process improvements....
  1. Emiel Kelly
  2. 2 days ago
Ideally, metrics are an integral part of any process. Thus, for L1&L2 process capture we recommend to collect: classic flow-chart (no roles), primary business objects, security concerns and KPIs.
Good point, Bogdan. And it is the case many times. At least the lack of metric that really tell you if your process needs some improvement or not. Then you will probably will get an idea from more "soft" metrics like complaining customers, leaving customers, angry employees, sick employees, shouting managers, decisions based on hierarchy not on knowledge.

To be honest, those sound like perfect metrics to me. Let's get started!

  1. Emiel Kelly
  2. 2 days ago
Boris Zinchenko Accepted Answer
Any company exists as a manifestation of its business processes. These processes can be documented or not. But they objectively exist, even if not documented. Business processes of the company are most valuable asset because they express its mission, know-how and, ultimately, a certain degree of success, as far as the company has established its place in competitive business environment by using exactly these processes. It is equally true even in present rapidly changing business environment.

In this sense, 'As Is' processes comprise critically valuable asset of the company and should be mandatory documented. Any change initiative should be based on already existing processes running inside the company and proven in its operational practice. It is not possible to implement an abstract set of externally introduced processes, even if they comply to most trustworthy and well established BPM practice, unless these processes will adjust for a concrete specific of a company where they are implemented.

Successful BPM implementation is always an evolution. Professionally captured 'As Is' processes are the fundamental starting point in this evolution, which cannot be neglected or avoided in any circumstances. As a metaphor, 'As Is' processes are Archimedean point of BPM, by using which you can move the whole enterprise.

http://caseagile.com/wp-content/uploads/leverBigCorners.png
References
  1. https://www.math.nyu.edu/~crorres/Archimedes/Lever/LeverIntro.html
Boris G. Zinchenko, Ph.D. is Chief Technology Officer of CaseAgile LLC, an innovative software and business service company specializing in integration of platforms and environments for enterprise modeling. http://caseagile.com/
Comment
I am citing software source code management as a good example of a need for "as-is" documenting, whether you are developing new software or updating legacy software.

In our software development business, we go through "as-is" to "to-be" several times a year per software product, some of which have more than 1,000,000 lines of code.

With ten products needing new executables at different times over a year, this means we are continuously improving/adding new features/re-engineering.

Source gets updated, tables get updated, on-line documentation gets upgraded.

The environment of choice for managing all of this, after 25 years of experimentation, is a graphic free-form-search Knowledgebase..

Here below is the dashboard for a database conversion exercise we took on recently for a very old custom app we built in 1998 for a customer. They took over management of the source in 2007 but came back to us in 2016 for an upgrade (a twenty-week initiative).

The UI lets all of the programmers see the status of all database tables/source code units at one computer screen.

Two must-have features of a source management system like this are
a) auto version control
b) aliasing of nodes because a unit can reference multiple tables accordingly a conversion programming exercise typically requires re-working units several times as you unlink/link units to a new database environment.
References
  1. http://wp.me/pzzpB-Pg
Comment
John Morris Accepted Answer
There was a recent Tweet flurry initiatied (I think) by @Emiel relevance to today's question on "as-is". I commented:

@Procesje @ESMatBPL - Marvellous #BPM "as-is" GoogleMaps analogy - but consider also #tacit #work - No "zoom in" on as-is invisible #process

And then, in response to a new LinkedIn post coincidentally today by Dr. Custis (@Christine) on "fuzzy progression", I also noted:

Good validation on the "as-is" as part of a plan to progress. Some want to throw out the as-is ... but that ignores the "tacit", the richness of reality that is not part of explicit management purview.

The gist of of the discussion above is that "it depends", which is a good answer. BPM automation technology is inherently top-down, and that's a challenge. Because models are expensive and always only rough approximations. Seeing any process mining animation gives a flavour of the complexity of real processes. Sometimes one can start fresh. But one must be careful not to overlook the stored capital of real work practices.

It has crossed my mind recently that today's topic on "as-is" is of relevance in the current acrimonious debates on free trade. Free trade and outsourcing is easy to consider if one doesn't put much value on the "as-is" of plant or office. It may be that many services and processes are completely fungible. But probably not nearly as much as articles in business magazines and speeches at conferences would lead one to believe.
Comment
Isn't all "automation technology" top-down?

First we decide whether we want to build a submarine or an airplane. Then we work on assemblies.

My take is no point worrying about where the cotter pins should go unless/until the overall concept is clear, a master plan for the initiative has been mapped out, and agreed upon.

Maybe I am missing something?
Walter your question gets to the core of the BPM technology automation challenge. Managers would like to be able, like Captain Jean Luc Picard, to be able to say "Make it so!" And certainly direction and strategy are critically important for the success of any project. 
However, I think it's fair to say that we (whatever "we" is) do underestimate the importance of "the tacit". For example, to use your reference, with cotter pins there's a whole world of implied shop-floor knowledge associated with fasteners. 
MIT Professor David Autor writes about this persuasively in "Polanyi's Paradox" (available as a very readable PDF at http://economics.mit.edu/files/9835.) He explores how it is difficult to automate something we don't understand, which is the world of the tacit. 
I think an interesting example of this is the centuries-long success of the so-called "German Mittelstand", or typically family-owned mid-sized companies, often in machinery, chemicals and electrical manufacturing. It is an entire culture of engineering, tacit knowledge, on which strategies are built. "Make it so" is a statement that assumes so much. We ignore this at our peril.
  1. John Morris
  2. 1 day ago
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.