From diagnosis through to
operations

How we read the subject

Most organisations we meet do not lack tools: they have too many. Bought one emergency at a time, never connected to each other. After a few years, nobody knows which server hosts what, which licences are still being paid for, or who holds administrator access to software installed by a supplier long gone.

An audit is not a judgement on what has been done. It is a snapshot dated: what actually runs, what it costs every year, what exposes the organisation, and what would block 30 % growth next year.

What we bring

• Full inventory of hardware, applications and contracts in force
• Mapping of data flows and dependencies between applications
• Maturity scoring on six axes, benchmarked against sector practice
• Costing of the risks: what an outage, a leak or a key departure would cost
• Remediation plan prioritised by effort / impact ratio

How we read the subject

An ERP on one side, a spreadsheet on the other, a CRM only the sales rep opens, and between them: manual exports on Friday evening. Every retyping is a chance to get it wrong, and every error surfaces three months later, in the middle of a close.

The problem is rarely the tool itself. It is in the gaps between the tools — where information stops, gets retyped, and loses its date, its author and its reliability along the way.

What we bring

• Solution choice made objective by a weighted criteria grid — we take no vendor commission
• Business configuration rather than custom development, whenever possible
• Connectors and interfaces between old and new, with history carried over
• Acceptance testing run by your teams on your real data, not on a demonstration set
• Progressive switchover, with parallel running and a rollback available

How we read the subject

Generative AI has produced many mock-ups and few production systems. The gap rarely comes from the model: it comes from the data you agree to give it, from access rights, and from what happens the day the answer is wrong in front of a client.

So we start from the use case that is dullest and most frequent — the one that takes hours every week without anyone mentioning it — rather than the most spectacular. That is where the gain is measurable and the risk is low.

What we bring

• Use cases qualified by volume, current cost and tolerance for error
• Agents connected to your documents and databases, with sources cited every time
• Guardrails: data boundaries, logging, human validation on anything binding
• Model chosen by sensitivity — hosted, sovereign or run locally
• Real gain measured on a narrow scope before any roll-out

How we read the subject

Handing out access to an AI assistant does not create usage. Three weeks later, half the licences lie dormant: staff have not seen what the tool changes for their particular work, and nobody dares ask for fear of looking out of touch.

Skill is not passed on by a one-hour demonstration. It is built on each person's real files, with a supervised right to make mistakes and someone to ask the silly questions.

What we bring

• Separate paths by discipline: management, accounting, sales, HR, technical
• Hands-on workshops on your own files, not on generic examples
• A library of approved prompts and templates, specific to your organisation
• A written usage framework: what can be entrusted to AI, and what never can
• Adoption tracked at 30, 60 and 90 days, with targeted catch-up

How we read the subject

In almost every organisation, a handful of tasks eats a disproportionate amount of time: reconciliations, chasing, consolidations, reformatting before circulation. They are invisible precisely because they are normal — we have always done them.

Automating is not about speeding up a bad process. It has to be simplified first: very often, half the steps exist only to compensate for a tool's shortcoming or a check that no longer has any purpose.

What we bring

• Timing of candidate tasks: frequency, duration, real annual cost
• Redesign of the process before any line of code
• Automating the chain of steps, the reminders and the consistency checks
• Full traceability: who triggered what, when, and with what outcome
• Manual takeover possible at any time, with no technical intervention

How we read the subject

With no written course, technical decisions get made one emergency at a time, on whatever budget is left at year end. Five years later, the information system is a pile whose logic nobody claims — and each new project costs more than the last.

A master plan is not a two-hundred-page document you file away. It is an arbitration: what you keep, what you replace, what you abandon, in what order and with what money.

What we bring

• Aligned with the organisation's strategy, not with technology fashions
• Target architecture described, and a path to it in fundable stages
• Multi-year budget trajectory, capital and operating costs kept separate
• Explicit governance: who decides, who arbitrates, how often
• Tracking indicators, so the plan stays alive instead of gathering dust

How we read the subject

When two departments present two different revenue figures in a committee, the debate is about the figures instead of the decisions. The cause is almost always the same: two definitions, two extracts, two cut-off dates.

A dashboard is only worth something if its definition is shared and its freshness known. An indicator with no owner and no written calculation rule always ends up challenged at the worst moment.

What we bring

• Indicator dictionary: definition, source, calculation rule, owner
• Data warehouse fed automatically, with history retained
• Dashboards by level: executive, department, operational
• Quality checks triggered on every load, with an alert on any discrepancy
• Automatic distribution to the right people, at the right frequency

How we read the subject

The incidents we see almost never come from a sophisticated attack. They come from an account left active after someone left, from a backup never actually restored, from a password shared in a group chat two years earlier.

Useful security is made of simple habits applied without exception, not of an expensive appliance installed once and forgotten. And compliance is only worth something if it describes what actually happens.

What we bring

• Review of access and privileged accounts, with deletion actually carried out and verified
• A real restore test — a backup never restored does not exist
• Hardening of workstations, servers and remote access
• A continuity plan written and rehearsed, with recovery times quantified
• Compliance work, processing register and staff awareness training

How we read the subject

Custom software is often an admission that the market has failed — sometimes it is simply the right choice. A regulated profession, a process that is your competitive edge, a need that three vendors each cover 60 % of: building becomes cheaper than contorting yourself permanently.

Provided the application stays yours: documented code, hosting you control, and no dependency that holds you hostage the day you change supplier. That is the principle behind SANKOFA, our OHADA audit software: no external library, deployable on ordinary shared hosting.

What we bring

• Functional scoping with users, mock-up approved before the first line of code
• Short, testable deliveries, every two weeks
• Code, database and documentation handed over in full, with no reversibility to negotiate
• Restrained technical choices, meant to last and to be picked up by others
• Maintenance and enhancements under contract, at a rate known in advance

How we read the subject

Moving to the cloud is not an objective: it is a means. Shifting a badly designed system as it stands means paying more for exactly the same problems, with a bill that changes every month thrown in.

The right question is the placement of each workload: what gains from moving, what must stay close to users, and what must be rethought before it goes anywhere. In our part of the world, link quality and data sovereignty weigh as much as the headline price.

What we bring

• Workloads classified: straight migration, redesign first, or keep on site
• Sized to actual use, with spending caps and overrun alerts
• Redundancy and cross-backups between two distinct locations
• Monitoring and alerts before the incident, not when a user calls
• Operations documentation handed over and explained to your teams

How we read the subject

Projects rarely fail for technical reasons. They fail when users discover the tool on switchover day, having never been consulted, and quietly go back to their old spreadsheets the following week.

Buy-in is won before, not after. It costs time at the start of a project and saves a great deal at the end — at precisely the moment when budgets are spent and so is patience.

What we bring

• Reference users identified at scoping, not at acceptance testing
• Regular communication on progress, including on what is going wrong
• Training at the workstation, on each department's real cases
• Reinforced support during the first weeks after switchover
• Adoption measured, and targeted correction where it does not take hold

How we read the subject

After go-live, a system's quality is judged by how fast an incident is handled — and just as much by how clearly you are kept informed while you wait. Silence costs more than the outage.

A support contract only means something if its response times are measured and published, including the months they are missed. Without that, the commitment is just a sentence in a quotation.

What we bring

• A single point of entry, with a response commitment based on declared severity
• Continuous monitoring: backups, availability, disk space, certificates
• Security updates applied, logged and reversible
• Monthly report: incidents, response times met or missed, preventive actions taken
• Continuous skills transfer to your teams, to reduce dependence