Case file03
Regulatory tracking tool
Compliance monitoring lived in shared spreadsheets. It now lives in an application tied to business software, with a trace of every decision.
- BUSINESS APPLICATION
- FRANCE / MONACO / SWITZERLAND
- REFERENCE ON REQUEST
What the client entrusted to us
An organisation subject to regulatory obligations tracked compliance in shared spreadsheets, alongside several business applications that did not talk to each other. Each check meant manually gathering scattered information, then recording the result elsewhere.
The risk was not the isolated error: it was the absence of trace. In case of external inspection, reconstructing a decision’s history meant finding the right file version, then trusting its modification date.
Management wanted a single tool able to build on the software in place rather than replace it, and to produce usable proof at any time.
The starting point
What the diagnosis revealed.
Before any technical proposal, we write down the real state — including what unsettles. This description, validated by the teams, is what makes the rest verifiable.
- 01
Compliance tracked in spreadsheets
Several shared files, competing versions, no update or locking rules.
- 02
Partitioned business software
Useful repositories lived in separate applications, with no bridge and no shared identifier.
- 03
Systematic re-entry
The same information was entered two or three times, with possible gaps between sources.
- 04
Unenforceable history
No reliable trace of who had validated what, on which date, on which basis.
- 05
Deadlines watched from memory
Obligations were tracked by email and habit, with no automatic alert in case of omission.
- 06
Undifferentiated access
The shared file distinguished no roles: anyone with the link could edit any row.
Constraints
What could not be compromised.
- 01
The tool must fit the real gesture
Monitoring teams work fast, often on two screens. Any extra input had to be justified by a gain elsewhere.
- 02
Do not replace existing software
The engagement covered a monitoring and proof layer, not an information-system change.
- 03
Authoritative traceability
Every decision had to be dated, attributed and kept, including after correction or cancellation.
- 04
Partitioning
Monitoring data was not to circulate outside the defined perimeter or transit through a third-party service.
- 05
Coexistence with the existing
Go-live had to happen without interrupting ongoing monitoring work or losing recent history.
The AIGYROS answer
What we built.
We started in the field, observing the real gestures of monitoring: which information is consulted, in which order, when a decision is taken. This step redefined the functional scope — fewer screens, but the right ones.
The data model was built around the notion of obligation: an obligation, its expected evidence, its owner, its deadline and its successive decisions. Existing software feeds this model through connectors, with no double entry.
The application was deployed in a partitioned environment, with distinct access profiles — read, entry, validation — and an audit log keeping every change, including corrections.
Go-live ran progressively, perimeter by perimeter, in dual run with the spreadsheets for one full cycle, then final cutover once gaps were explained.
Conduct
Four stages, held in this order.
Stated durations are orders of conduct magnitude, never commitments: each engagement is recalibrated on its own ground.
- 01Immersion phase, at the workstation
Observe
Observation of real monitoring gestures, information-source mapping, team and management interviews.
- Observation of daily monitoring gestures
- Information-source mapping
- Team and management interviews
- Written reformulation of the functional need
- 02Design phase
Model
Obligation-based data model, profiles and rights, monitoring-screen mock-ups, external-inspection scenarios.
- Obligation-based data model
- Profile and rights definition
- Monitoring-screen mock-ups
- Anticipated external-inspection scenarios
- 03Step-by-step construction phase
Develop
Connectors to existing software, application and audit log, regular demonstrations and joint acceptance.
- Connectors to existing software
- Application and audit log
- Regular demonstrations to teams
- Functional acceptance run with users
- 04Go-live phase
Deploy
Dual run with spreadsheets, user training, final perimeter-by-perimeter cutover and post-launch follow-up.
- Dual run with existing spreadsheets
- Profile-based user training
- Final cutover perimeter by perimeter
- Post-launch anomaly follow-up
What changes
Before, after — no showcase figures.
We do not publish improvement percentages: they cannot be verified from outside. What can be described, on the other hand, is the daily gesture that changes.
- Initial situationAfter the engagement
Initial situation: Shared spreadsheets, competing versions
After the engagement: One base, up-to-date compliance status
Initial situation: Information entered two or three times
After the engagement: Re-entry removed, connected sources
Initial situation: History reconstructed by hand
After the engagement: Dated, attributed, kept audit log
Initial situation: Deadlines watched from memory
After the engagement: Automatic alerts on obligations
Initial situation: Undifferentiated shared-file access
After the engagement: Distinct profiles: read, entry, validation
Initial situation: Dreaded external inspection
After the engagement: Exportable proof verifiable in minutes
Deliverables
What stays in your hands.
An engagement is also judged by what it leaves behind. Every deliverable is written to be read without us.
- 01
Data model
The structure of obligation, evidence and decision, documented and stable.
- 02
Application and connectors
The monitoring tool and its links to existing business software, with no double entry.
- 03
Audit log
The full decision history, viewable and exportable in case of inspection.
- 04
Acceptance file
Tested scenarios, results obtained and accepted gaps, validated with users.
- 05
Profile-based user guide
One manual per role: read, entry, validation.
- 06
External-inspection procedure
How a third-party check runs, from export to justification.
Excluded scope
What the engagement did not include.
A blurry scope costs more than an incomplete one. So we write it down in black and white, from the proposal stage: what is handled, and what is not.
- Replacing existing business software.
- Legal interpretation of obligations: rules were supplied and validated by the organisation.
- Opening the application to external partners, studied at a later stage.
- Taking over historic spreadsheets beyond the last two financial years.
A check is only as goodas the trace it leaves.
Case file
Regulatory tracking tool
Case 03 — Business application
Area of operation: France / Monaco / Switzerland
Other case files
Prendre contact
Does your situation resemble one of these?
Tell us about your environment, your constraints and what cannot be compromised. We answer with analysis, not a catalogue.