Background
The client is a product IT company with its own CRM system. A major upgrade was planned: a new subscription management module needed to be built, synchronised with the billing system and the call centre API, while also cleaning up the relationships between clients, tariffs, and internal reference data.
At the start, the task seemed simple: "Draw up diagrams and describe the business processes." But it quickly became clear that no documentation for the existing architecture existed, requirements were being defined on the fly, and business logic was based on assumptions rather than rules.
Solution
A middle+ system analyst from ML Web Solutions joined the client's team.
What was done
Week 1 – Discovery through real users
The analyst spent the first week conducting interviews with internal users: managers, support staff, and engineers. Instead of simply documenting "as is", they asked uncomfortable questions:
Week 2 – Deliverables
After two weeks, the client received not just a set of BPMN diagrams, but:
Beyond the diagrams
The client specifically noted that the analyst "resolved disputes between business and developers because they understood both sides". There was no need to explain what idempotency is or how webhook request ordering works — the analyst built these considerations into the logic from the start.
Outcome & impact
The project is still ongoing. But even at the preparation stage, it became clear: without this level of systems thinking, the client would have sunk into feature chaos. Instead, they now have a structured architecture and a precise understanding of where the product is heading.
The client is a product IT company with its own CRM system. A major upgrade was planned: a new subscription management module needed to be built, synchronised with the billing system and the call centre API, while also cleaning up the relationships between clients, tariffs, and internal reference data.
At the start, the task seemed simple: "Draw up diagrams and describe the business processes." But it quickly became clear that no documentation for the existing architecture existed, requirements were being defined on the fly, and business logic was based on assumptions rather than rules.
Solution
A middle+ system analyst from ML Web Solutions joined the client's team.
What was done
Week 1 – Discovery through real users
The analyst spent the first week conducting interviews with internal users: managers, support staff, and engineers. Instead of simply documenting "as is", they asked uncomfortable questions:
- "Why do you do it this way?"
- "What happens if…?"
- "What if a client is on two tariffs at the same time?"
Week 2 – Deliverables
After two weeks, the client received not just a set of BPMN diagrams, but:
- A unified glossary of terms that had previously been used inconsistently across teams
- Proposals for reusing logic from existing services
- A REST integration specification for billing, including edge cases
- A roadmap for task decomposition for the development team
Beyond the diagrams
The client specifically noted that the analyst "resolved disputes between business and developers because they understood both sides". There was no need to explain what idempotency is or how webhook request ordering works — the analyst built these considerations into the logic from the start.
Outcome & impact
The project is still ongoing. But even at the preparation stage, it became clear: without this level of systems thinking, the client would have sunk into feature chaos. Instead, they now have a structured architecture and a precise understanding of where the product is heading.