Running blind without system diagrams
Replacing a legacy business system is like replacing a piece out of a tower of wood blocks - a game of Jenga. You need to pull the old piece out and insert the new one in its place without collapsing the whole tower. It requires planning, precision, and a quick efficient move. In order to succeed, you need to first understand the tower itself - which piece supports which piece, etc. Therefore, I always ask for a system model diagram before starting a system deployment. To my surprise, most companies do not have such a diagram, so we end up drawing it together.
First, start by drawing as-is systems as squares in a diagram. These are your application boxes. Put the main operational system in the middle. Spread the rest of the applications around it. Cluster the applications by category such as financial systems, retail systems, e-commerce systems, warehouse systems, etc.
Next, list the functions of each system inside its application box. Focus on how you use the application rather than what it can do. Use abbreviations whenever you can. For example, an operational system may have PIM (Product Information Management), INV (Inventory Management), SLS (Sales Management), PUR (Purchasing Management), etc. Try to size the boxes with respect to the number of functions they do. The larger the size, the more functional coverage the application has.
At this stage, you should have at least a dozen or two application boxes of varying sizes. The next step is to draw interfaces to and from these boxes. Use arrows and label them with core data flows such as product master, sales orders, inbound shipments, etc. Use solid lines to indicate automated data flows that don't need human intervention. Use dotted lines to indicate data flows where a user copies/pastes, imports/exports, or manually transfers the data from one system to the other.
Now, we are ready to identify which applications we are planning to replace. Copy/ paste your as-is diagram to create a road-map diagram. Highlight the applications that you are going to replace in red. This would give you the first glimpse of interface work. Some will be irrelevant if you are collapsing systems into one. Some will need to be re-written. You may also create new interfaces - most likely temporary ones - if you are phasing system replacements. Here is an example.
It is a best practice in phased deployments to draw to-be system diagrams phase by phase to ensure nothing is left out. You can copy/ paste your road-map diagram into multiple to-be system diagrams showing the evolution of your systems as you go through your multi-phase go-lives. These diagrams will provide you with a reliable list of system integration work that needs to take place along your deployment.
If you are interested in learning more, please connect with me on LinkedIn, follow me on Twitter, or watch me on YouTube.
My name is Cem and this has been another gem.