The change went live. Why hasn’t the value followed?

The new system is live, but spreadsheets still carry part of the work it was expected to replace.

What Cohentia examines: Cohentia examines what people still use spreadsheets to complete, check or report.

That does not automatically mean people are resisting the system. The spreadsheets may cover workflow, reporting or exceptions the new process does not support.

What Cohentia examines: Cohentia examines which requirements the new process covers and where people still need a workaround.

Maintaining both may create duplicate updates, conflicting records and extra checking. Removing the spreadsheets too early could also disrupt work that depends on them.

What Cohentia examines: Cohentia traces the additional effort and the work that would be affected if the spreadsheets were removed.

Establish what the spreadsheets are compensating for before deciding whether to change the workflow, configuration, reporting or training—and when they can be retired.

What Cohentia examines: Cohentia identifies what must work before the workaround can safely be removed.

The training is complete and the licences are paid for. Day-to-day work has barely changed.

What Cohentia examines: We map recurring tasks, licence use and the rules people have for using AI.

Cohentia examines whether training was not connected to recurring tasks, approved information or clear rules for checking outputs.

What Cohentia examines: We check task suitability, approved information and responsibility for reviewing outputs.

If this is happening, licences remain underused. A few people experiment independently, creating inconsistent practices.

What Cohentia examines: We trace underuse and inconsistent practices into licence cost and management effort.

Identify usable tasks and adoption barriers: focus the rollout, establish working rules or reconsider licence allocation.

What Cohentia examines: We compare a focused rollout, clearer working rules and licence allocation.

The project has closed, but the costs it was meant to remove are still there. It is unclear who owns the remaining work needed to realise the benefit.

What Cohentia examines: We map the benefit case, current costs and the work that remains after project closure.

Cohentia examines whether benefits depended on retiring old work or changing operating practices that nobody was accountable for completing.

What Cohentia examines: We check which savings depended on retiring old work or changing operating practices.

If this is happening, new costs sit alongside old costs. Teams carry both processes and have less capacity for further change.

What Cohentia examines: We trace the combined load of old and new processes into cost and capacity.

Trace each benefit to its operating conditions: assign ownership, remove duplicate work or revise the benefit case.

What Cohentia examines: We link each remaining benefit to an owner and a verifiable operating change.

The acquisition is complete, yet approvals and everyday work now take longer. Teams are navigating two sets of expectations.

What Cohentia examines: We map approval routes, policies and handoffs across the acquired businesses.

Cohentia examines whether legacy approval routes, roles and policies overlap without a clear combined operating model.

What Cohentia examines: We compare overlapping controls and roles with the intended combined operation.

If this is happening, decisions require multiple approvals. Informal routes emerge, weakening accountability and integration.

What Cohentia examines: We follow duplicated approvals into delays, informal workarounds and integration effort.

Map conflicting responsibilities and duplicated controls: agree what to combine, retain locally or remove.

What Cohentia examines: We test what should be combined, retained locally or removed.

An automated process repeatedly needs manual rescue. The team is spending time maintaining the workaround as well as doing the work.

What Cohentia examines: We map failed runs, input records and the manual rescue work around the automation.

Cohentia examines whether inputs vary, exceptions lack an owner or upstream processes change without updating the automation.

What Cohentia examines: We test input variation, exception ownership and upstream changes.

If this is happening, manual rescue work grows alongside the automated process. Each patch makes maintenance harder.

What Cohentia examines: We trace rescue work and patches into maintenance effort and operating reliability.

Locate failure conditions: standardise inputs, define exception handling, redesign or pause the automation.

What Cohentia examines: We compare input standards, exception handling, redesign and a controlled pause.

The organisation chart has changed, but decisions and work still move through the old routes. People are unsure what the new roles can actually decide.

What Cohentia examines: We map the organisation chart alongside actual decisions, budgets and handoffs.

Cohentia examines whether reporting lines changed while decision rights, budgets, incentives and handoffs stayed the same.

What Cohentia examines: We compare new responsibilities with unchanged authority, incentives and resources.

If this is happening, new roles sit over old working arrangements. Ownership becomes disputed and escalations increase.

What Cohentia examines: We trace disputed ownership and escalations into delay and duplicated work.

Compare formal roles with actual authority and workflow: align responsibilities, resources and decision rights.

What Cohentia examines: We identify the operating changes needed for the new roles to function.