Rebuilding the management system of a buying group

Rebuilding the management system of a buying group is almost never a technical decision. It gets taken because a rebate campaign took six weeks instead of three, because a supplier has been waiting ten days for the breakdown of a figure, or because the one person who could run the chain is leaving in June. Ageing software is the terrain, not the cause.

The trigger is rarely the technology

The general managers who call us do not say their database is obsolete. They describe a process that no longer fits. That is good news for the project: a dated, measurable need can be scoped, priced and defended to a board, whereas a modernisation programme with no deadline slips from one financial year to the next.

• An annual process — the rebate close, subscription calls, agreement renewals — spills a little further into the next one every year.
• Member numbers have crossed the threshold beyond which nothing can be run from memory; it usually sits around fifty.
• The incumbent vendor announces end of maintenance, or a migration priced like a brand new project.
• A key person leaves, and half the business rules exist only in their head and in hidden worksheet tabs.
• A new activity — own brand, logistics, members abroad — fits none of the existing data structures.

All five share one consequence: the project has a deadline that management did not choose. That is a constraint, and it is also what makes it fundable.

Cut the work by process, not by module

The classic breakdown mirrors the software architecture: a technical foundation, a master data layer, a supplier module, a member module, then the reports. It is coherent on paper and damaging in practice, because it puts the first go-live after every piece has been assembled. We cut by business process instead: one complete chain, end to end, put live on its own.

The choice has a price, and we would rather state it: for a few months some data is entered twice, and the member master data stabilises through iterations rather than in one move. The alternative is asking a group to pay for a year without seeing anything work, betting that the specification written at the outset was right about everything.

The group's calendar is not negotiable

A central body runs on a calendar no software project can move. The batch plan is built from those dates, not the other way round. We record them during scoping, together with the people each one mobilises.

Migrating ten to fifteen years of data

A twenty-year-old group carries history nobody has ever cleaned: duplicate members, company names that vanished in a merger, product families renamed three times, contracts scanned onto a network share. Migration is the most consistently underestimated line item, and the one behind most budget overruns.

1. 1

   A real inventory of sources

   The legacy package, the campaign workbooks, the accounts, the scanned agreements and the mailboxes. The observed list is always longer than the one described at kick-off.

2. 2

   Three depths of migration

   Live data — members, suppliers, current agreements — migrated in full and cleaned; calculation data — declarations, campaigns — migrated over three to five financial years so a close can be replayed and growth compared; everything else archived as searchable records, without reprocessing.

3. 3

   Adversarial reconciliation

   Every migrated scope is checked against an external reference: accounting totals per year, active agreement counts, balances per supplier. Discrepancies are investigated one by one, never absorbed.

4. 4

   Written quality decisions

   Duplicates, missing registration numbers, members who left and came back: each cleaning rule is agreed with you and recorded, because one day somebody will challenge it.

We price the migration from a real extract pulled before signature, not from a verbal description of the existing system. On this line item it is the only way to hold a fixed price.

Orders of magnitude: duration, sequence and drift

1. Weeks 1 to 3: scoping of the first process and a clickable prototype. The deliverable is a written scope, a prototype you can handle and a firm price — not a study.
2. Weeks 4 to 10: build and go-live of the first process, in two-week sprints. This is the point where a member genuinely uses the new system.
3. Months 3 to 8: adjacent processes, in order of criticality and available calendar windows. Each batch is scoped with the experience of the last and stays fundable on its own.
4. Months 8 to 15: peripheral scopes, archiving, shutting down the legacy system, and reversibility — source code, documentation, handover.

For a group of fifty to eighty members and around fifty approved suppliers, the first process goes live in six to ten weeks and the full rebuild spans nine to fifteen months. That is not nine to fifteen months of waiting: it is one more scope entering service every six to eight weeks.

What stretches those ranges is almost never the technology. It is the unwritten rules that have to be reconstructed, the availability of the one or two people who know them, and the governance decisions a rebuild forces into the open: who approves an agreement, who may correct a declaration after closing, who gets to see other members' figures.

How these projects fail

• The big bang: eighteen months of build, a switchover across one weekend, and an annual close due three weeks later on a system nobody has practised on.
• Parallel running with no end date: the old system stays on just in case, double entry sets in, and nobody knows which figure is authoritative. The shutdown date is decided during scoping, not at the end.
• Forcing a package: six months of configuration to approximate a tiered scale the product cannot express, then bespoke development anyway, paid for a second time.
• The eighty-page specification written before any use: it freezes choices no user has tested and becomes the arbiter of disputes, in place of the software.
• Open-ended time and materials: the team becomes a monthly budget line with no enforceable scope and no exit date.

Who is writing this

MEKANO is a Lyon-based development studio specialising in management software for buying groups and member networks: supplier approval, revenue declarations, rebate and year-end bonus calculation, document management, member portals. We work at a fixed price, in batches, and the source code is handed over with its documentation. The most complete platform we have delivered runs the operations of a Lyon buying group of more than sixty member companies, on a Go, React and PostgreSQL stack.