A BA asks: when replacing a system, how much do you need to care about the as-is state?

A BA asks:

During IT project implementations, how easy is it to determine the level of the (AS-IS ) detail required? Do you prefer the solution (TO-BE ) be informed by the AS-IS or rather should it be independent of the current set up? As IT professional do you think we dwell too much on the past and fail to solve the issue or we fix our own problems leaving the real pains (challenges) experienced by business?

There are two aspects of developing a superior solution that need to be taken into account here:

  1. The need to investigate the real problem to be solved, rather than focusing on the solution that exists today and reproducing it in the new set up at the risk of replicating inefficiencies from the past.
  2. The need to understand what exists today and why it was built in a certain way so that you don’t end up removing from the new solution critical pieces that turn out to be required to fully solve the business problem.

Imagine that you’re working on the requirements to replace a system used for routing support requests to the appropriate support staff members. In the legacy application, you have a screen where a manager looks at the list of new tickets and decide who to assign the work to based on the level of complexity and other attributes.

In the new system, the assignment of tickets may very well be automatized using business rules or even machine learning. In that case, the as-is process of displaying a list of tickets pending assignment would be replaced by an automated process. Still, it’s important to interview the managers making the manual assignment about their as-is process (e.g., to understand the considerations they make to select the right support person to work on a ticket so that this knowledge can be used to specify the optimal automated solution in the new system). Likewise, the managers should be interviewed about the to-be process (e.g., to understand the concerns they may have with the automatic assignment and elicit information that may lead to new requirements such as the need to allow a manager to override the system assignment based on human judgment or knowledge the system doesn’t have, like when an employee calls to say he’s taking a sick day and his tickets need to be reassigned).

So the answer to this question is, when replacing a legacy system, you should make sure you understand 1) how things work today; 2) why they work a certain way (which could be “no good reason, we’ve always done things like way” or “there is this very important reason why we use a three-digit code to identify the urgency of a ticket even though two digits would suffice). This is how you equip yourself with the knowledge to determine which portions of the as-is process can be eliminated or improved, and which ones needs to stay to ensure the business needs are properly met.

Sure, there are things in the as-is process that you may not need to investigate too deeply (for example, the exact screen of the system used to input each type of information). But anything related to the steps involved in the process, how often certain functions of the system are used, the alternative paths used in the process, need to be understood in a decent level of detail in order to mitigate the risk of missing critical requirements that if ignored would cause the to-be system to fail to meet the business needs.

Photo credit: JoniVan Bogaert


  1. It’s a great topic worthy of a longer discussion! There’s definitely an art to going “just deep enough” and I use a number of heuristics, mainly risk-based.

    One I find particularly useful is aligning the process (and various levels of sub-process) on a matrix that has as it’s axes “Well Known – Unknown” and “Simple – Complicated/Complex”. That can be undertaken as an individual or group exercise, in the mind or on paper – depending on the context.

    Given that there’s never enough time anyway to blitz the whole As-Is state anyway, this gives me a clue as to where to direct my efforts.

    • Hi, Rob,

      I totally agree, there are a number of heuristics that we can use to figure out the right balance for the effort to understand the as-is state to prevent critical information from being ignored as you build the to-be state, without getting so bogged down in details that we don’t make progress fast enough.

      Coincidentally, I’m currently working on an article for Modern Analyst dedicated to this topic based on a suggestion received a year ago from the editor of the website, and will let you know when it’s published so you can chime in there as well. Thank you for stopping by!

  2. Duane Banks

    Hello again to my favorite BA!

    We haggled a few months ago about problem-focus. I suggested that a general understanding of the problem is critical, and that BAs should limit their problem-focus to a general level of understanding.

    You countered, “to me, solution = “means of solving a problem”, and outcome = “the end result”. To determine what the right solution looks like, you first need to define the problem well — what is getting in the way of achieving the desired end result and needs to be addressed by your solution.”

    I had agreed with this; and still do to an extent.

    If “define the problem well” involves drilling down into the details *of each* As-Is process (beyond level 1 business process maps), then I believe that to be overkill. Certainly, you should drill drown as needed for any critical process, but I don’t do so for all As-Is processes. I map out As-Is level 1 process maps (and update existing level 1 maps based on To-Be needs). And I map out To-Be process maps with as much detail as needed to help flush out user stories, use cases, and/or detailed requirements. So, this is what I mean by “general understanding of the problem.”

    And if the desired outcome is well-defined (and well-collaborated), an outcome-focus (rather than a problem or solution focus) encourages solutions beyond our perception of the problem, as aptly explained at this link: http://knowledge.wharton.upenn.edu/article/idealized-design-how-bell-labs-imagined-and-created-the-telephone-system-of-the-future/.

    • Duane wrote: “If “define the problem well” involves drilling down into the details *of each* As-Is process (beyond level 1 business process maps), then I believe that to be overkill.”

      Oh, I’m in total agreement here, Duane! It’s an important distinction to make, especially since a) the as-is process often includes questionable decisions that have nothing to do with the real problem to be solved; and b) the business circumstances may have changed substantially since the as-is process was defined.

      What I’m trying to emphasize in this article (and will expand in a new one being written for Modern Analyst) is that it’s not only important to understand the problem to be solved (which requires investigating the current business needs independently of the as-is state), but also investigate why things are a certain way in the as-is state (especially when you are considering removing them from the new solution because they seem inefficient or unnecessary).

      The answer could be the “small pan syndrome” that I describe here: https://www.linkedin.com/pulse/what-cooking-ham-tells-us-good-business-analysis-more-adriana-beal, but as I’ve seen multiple times in real-life projects, there could also be an entirely valid reason to retain the unusual behavior in the new solution in order to make it fit for purpose.

      Thanks for helping draw the line between “problem definition” and “understanding the as-is state at the right level to make sure critical aspects of the old solution are not left behind when you replace it”.

Leave a Reply

Your email address will not be published.