We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

How much time should be spent capturing the as-is of business processes?

Vote 0 Votes
An interesting question and discussion on LinkedIn (which requires you to join), how much time should be spent cpaturing the as-is of business processes?

14 Replies

| Add a Reply
  • Depending on the overall comittment and readiness of the company, automating the as-is process might be the best place to start.

  • I saw this discussion in one of the LinkedIn groups and enjoyed reading the different responses.

    My POV is that an organization should spend as little or as much time needed to have a solid sense of its current state. Why? This understanding forms the baseline against which future improvements may be measured. This position assumes that the organization hasn't documented its current state for quite a while, if ever.

    The more salient question is: Why can't organizations create and maintain their business processes documents so that when it's time for an improvement effort only minor updates, and minimal time, are necessary?

    In the early 80's, a very smart person gave me really good advice: Document your processes so that you can understand where they are broken because automating a broken process achieves nothing.

  • I try to start with a Rule of 3: 3 working sessions with the process experts, owners, multi-stakeholder team per process (Define, Validate, Tweak). It will often take longer for consensus.

  • Like other elements of an Enterprise Architecture, only as much as is needed for contextual purposes. The focus of EA, BPE or whatever you want to call it is the Future State of the process. The Oracle EA Framework/Process as well as TOGAF all advocate for this type of approach.


  • We are finding that the As-Is can be captured in live mapping workshops straight into the process mapping tool with the business users (not analysts or other proxies for the end users). This inevitably gets quick win improvement ideas, so the As-Is is morphing into the To-Be. It also gathers momentum and buy-in to the analysis phase which used to take months.

    Now the project can get a return in days or weeks - so with a cloud based process mapping application you can get RBI (Return Before Investment). So you are getting the benefits before the invoice has been paid.

    BTW We find the "Raise PO to Invoice Paid" process is often very inefficient in clients - so this is a good place to start!!

  • Yes, time should be reserved for capturing the existing processes, for all but the most simple business processes. Otherwise, your solutions will be too radical, or miss some key failing of the current model. I recommend Six Sigma DMAIC/DMADV process improvement models, both of which start with Defining the current state of affairs.

    Bill Roth

  • If you do need to do process discovery you'll have to spend as much time as necessary. It's no good coming up with incomplete data because of a time limit. That would just result in defects in the process (re-)design and lead to errors in process implementation and process operations.

    Of course, the real question we should be asking (ourselves) is: Why didn't we keep our process documentations updated in the first place?


  • user-pic

    Reality of business processes in large organizations are that legacy remnants that may have no rhyme or reason - "that's the way it has always been done!" may the standard reply. Plus new technologies may help you completely throw away as-is processes with may be self-service ones. For example, if you can just get rid of phone registration and do only online/mobile registration and that too self-service saving yourself money in the process, why bother documenting old processes?

  • I would strongly advocate the use of a maturity model to understand where your organization is in the BPM journey. That would then dictate the relevance and importance of documenting As-Is processes. Generally speaking, the higher up on the maturity model you are, the lesser time you would need to spend on the As-Is.

  • I think that there isn't a clear answer for that question because it depends of the complexity of the problem that is being analyzed. However it's important to put a clear milestone or people will revisit the process indefinitely.

    Last but no the least some business processes must embrace a total redesign that is useless to look how it works today. People should start designing how it should be executed the next day.

  • 'Spending time' to capture as-is processes is a waste of time. The time must be spent on defining the business architecture models before anything can be captured, defined, guided or improved. The process in terms of flow is utterly irrelevant for improvements and if you bring in SixSigma you get more bureaucracy than before.

    Ideally, once the core elements of a business architecture are in place and the technology permits collaborative process creation, the business users can start to execute their processes as-is, following (top-down) objectives, targets and goals in real-time. That creates the transparency to identify of processes also create the expected outcomes. By default that produces the opportunity to improve whatever seems to be necessary, because there won't be a discussions if processes are this or that way and what they deliever. One can simply look at them ...

    Adding rules can then provide compliance, removing unneccesary activities increases efficiency and modifying them as needed increases customer satisfaction. We are now in an evolutionary mode in which all participants - executives, managers, process owners and customers - can provide input as to what should be improved.

    Let me add that a business architecture can be made for a single process as well. No need to do it enterprise-wide from the outset, which is a common fallacy with architecture efforts.

  • Aircraft pilots have a rule: when in trouble, gain the control over the plane first and then initiate a compensation manuever.
    We follow it when dealing with business processes, too. Which means: discover the existing process first, model it and execute within BPMS if appropriate; then proceed with improvements.
    So the answer is - as much time as necessary.
    But I believe the whole as-is/to-be paradigm is obsolete. "As really is" is more accurate term for what is discovered. Besides, we never implement it literally: there are always local inoptimalities that are easier to fix than to implement.
    As for the second part, "to-be" implies a one-time effort. By contrast, agility implies a list of desired process improvements scheduled for implementation under a series of process revisions. So we are talking about process releases N, N+1 etc. and not about to-be.

  • As-is part is about understanding what's going on. My company advises to model "as little as possible, as much as needed", because models are tools: they may help you, but you should not model for the sake of modelling.

    As for the to-be: Anatoly made a good point. This is not one-off initiative. Rather you should think of continuous improvement cycle.

  • As long as it takes; being realistic as -is analysis and modeling is iterative and a phase of a process improvement project – key word is project. Every project has a termination; every phase has to terminate for the next to begin. Defining the scope of as-is discovery has to be defined and controlled by limiting the effort to a time frame, one or more business units, percentage of processes or processes that have direct customer value, etc.

Add a Reply

Recently Commented On

Monthly Archives