Image may be NSFW.
Clik here to view.
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:
- 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.
- 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