<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=321162&amp;fmt=gif">

Cure your organisation of critical memory loss


It is a herculean task. Having to recover lost business expertise to understand how disparate systems work together to support critical business operations. Learn how to prevent the situation and how to regroup if the worst has already come to pass.

Imagine you need to prepare a specification for a new system, but the person who knew the ins and outs of the current system has already left the company. In the existing solution, there are several complex modules and plenty of change requests that were implemented without proper documentation. When users begin testing the new solution, you discover that an entire group of users doesn’t have access to a critical feature.

The best way to avert this situation is to make sure your documentation of the process is updated whenever changes happen. That may sound easy in theory, but can be very difficult to achieve, as there is always something more urgent than documenting process and system behaviour.

Tip 1: Adjust your reward system to support creating and maintaining the knowledge base

Include relevant documentation for mission-critical systems in the performance review of your business analysts, project managers, system analysts, and software engineers.

In an agile team, reserve a portion of the retrospective meetings to go through a checklist to see if there’s anything important to add to or to replace, within the organisational knowledge base.

In the prototyping process, ask the project manager to document how will the proposed solution work, what was missing, and what was done to fix it.

[FREE TEMPLATE] Business Process Analysis

Tip 2: Specify what kinds of information needs to be captured and categorised

Use an efficient collaboration tool such as a wiki system, with a structured hierarchy, and make sure your tool has a powerful search engine to help the team find information quickly and easily.

This knowledge base should include:

  • requirements specifications
  • business process diagrams
  • all, even small deviations from the original user-facing requirements in the final implementation
  • decisions that affect the user experience that had a dissenting opinion
  • unusual user-facing behaviour the system has compared to similar applications
  • user-facing changes applied to the system after the go-live.

Make sure you include the “why” behind a constraint, decision, change, or anomaly as this is the most neglected piece of information in system documentation and the cause for practically all headaches, excess costs or even failure when enhancing or replacing a legacy system.

The context and rationale for previous decisions are necessary to distinguish between the aspects of the solution that must be preserved and questionable decisions that will only diminish the value delivered by the new system.

Knowing not just what, but also why the current practices are in place is critical for a business analyst to make the right decisions during requirements discovery. Armed with this information, a BA can validate with key stakeholders to ensure efficiency of the new system.

Focus on information about the business problem being solved, the business rules involved, the user-facing properties required, and the reasons for those requirements existing.

Tip 3: How to recover when the information is already lost or forgotten

Step 1: Map the “as-is” process using automated process discovery software such as Minit. This will provide a great start since the process maps will include all the nuances of the process, its variants, process exceptions, unusual transactions, bottlenecks, deviations, and potential risks. Minit can discover processes without prior knowledge or a specified process model and create process maps from data logged during normal execution of the process.

Step 2: Enlist users, software developers, and other people with knowledge to discuss the “as-is” process map. Ask them about the reasons for why the process follows a particular path, why deviations occur and uncover the reasons for why things are done a certain way.

Step 3: Investigate more deeply the knowledge areas that tend to create problems whenever a legacy system is being enhanced or replaced, look for things like:

  • explicit or implicit business rules that should be enforced by the system
  • permission rules that must be preserved
  • special filtering or sorting features that need to be available for slicing and dicing data
  • special considerations regarding data retention
  • special considerations regarding time-consuming queries
  • special considerations regarding the cardinality or hierarchy of objects in the system
  • any quality attributes (performance, reliability, scalability, security, interoperability, etc.) that need to be kept or enhanced

Step 4: Schedule some time with key stakeholders from the business and IT to share your core findings. It’s quite possible that by seeing the results of your discovery process, someone will remember additional constraints or dependencies that nobody had mentioned yet.

Download Minit Brochure to learn more


Learn more about Minit's process discovery capabilities

Simona Parnicka Marketing Manager at Minit

15. 01. 2018