Someone reads data nobody knows about.
A report, an integration or a spreadsheet pulls data from the old system every night. It shows up only when it stops working.
Before replacing a system
What breaks when you replace a system?
The vendor knows what the new system can do. Nobody knows for sure what the old one does today that nobody wrote down. That is where the switch gets expensive.
The maps never leave the user's computer.
What tends to be forgotten
Three things that show only when it is too late.
A process relies on something the system does.
A step in invoicing depends on the order system setting a status. The new system does it differently, or not at all.
Responsibility is unclear at the seams.
The data belongs to one unit, the system to another and the process to a third. None of them sees the whole chain.
An example
Three rows are enough to see that the switch is not just an IT matter.
- The order system reads data from the customer register.
- Invoicing depends on the order system.
- Customer service is responsible for invoicing.
The question: what happens if the customer register is replaced?
The answer in TopidarIf the customer register changes, the order system, invoicing and customer service are affected. Invoicing via the order system. Customer service via invoicing.
- 1
Start with the system you are replacing. Write down what reads from it, what is part of it and who is responsible for it.
- 2
Bring in someone from the business. They know which processes depend on the data.
- 3
Choose the What if tab and test the switch: remove a relation, or change it to the new system.
What the map does not tell you
The map shows what you have entered.
Topidar finds no dependencies by itself. It works from what people know and write down, and shows what follows from it.
The map gets better the more parts of the organisation take part. That is also why it is worth making together.