Use case 05
Fund the right builds. Kill the rest.
For ERP, AI & transformation programs
Published · By Junil Kim, CEO & Co-founder
Every stage gate asks for the same missing artifact: a defensible baseline of how the work runs today.
As-is process analysis is the work of documenting how a process actually runs today, before you fund an ERP or AI build against it. Most programs approximate it with workshops and system logs. Both miss the work that happens between systems, which is where transformations quietly fail.
For as-is process analysis, Aperture captures work inside systems and between them and produces an evidence-based baseline that ERP, automation, and transformation teams can use to scope, prioritize, and evaluate builds. Underneath it is an AI-native operations tool: we map how the work actually runs first, then deploy agents inside the files the work already lives in. This post is about the first step.
Every transformation program begins with the same question: how does the current process actually work?
Yet every business case brought to the steering committee claims a productivity gain against a “current state” that no one in the room can verify.
That weak baseline is where programs lose discipline. Pilots stall because no one can prove the before. Projects clear gates on optimism and miss checkpoints on reality. The portfolio keeps growing because, without evidence, there is no defensible way to say no.
What do workshops and process mining miss?
Programs answer the current-state question two ways.
The first is workshops and interviews: gather the people and reconstruct the process from memory, producing an as-believed map rather than an as-recorded one. The result is honest but incomplete. People remember the standard path and overlook the exceptions, and the exceptions are often where the time goes.
The second is system-log mining: analyze the event data already produced by the ERP and CRM. The result is precise but partial because it sees only what happens inside those systems. This is the core of process mining limitations: shadow processes that live in spreadsheets and inboxes leave no log events to mine.
Both methods miss the same place: the work between systems. The export to Excel. The approval in email. The re-keying from one screen into another.
This glue work is invisible to logs and too tedious for anyone to reconstruct fully in a workshop. In many transactional processes, it is where the hours actually go.
| Workshops | Process mining | Work recording | |
|---|---|---|---|
| What it captures | The standard path as people recall it | Steps that leave event logs inside systems | In-system and between-system work as it runs |
| What it misses | Exceptions and the work between systems | Spreadsheet, email, and re-keying steps | Nothing by design; capture follows the work |
What does ERP transformation without as-is evidence look like?
One public example makes the problem concrete. At Gartner's 2024 Supply Chain Planning Summit, polling reported by Lokad suggested that only about 32% of planners actually moved onto the planning tool their company implemented. Roughly two-thirds remained on spreadsheets.
Those tools were not bought carelessly. They were bought against an as-is picture assembled in workshops: a picture of the standard path that real work did not consistently follow, the same gap between plan and reality that shows up in planning itself.
The pattern extends beyond planning software. S&P Global reports that organizations scrap an average of 46% of AI projects between proof of concept and broad adoption. Its research also links lower failure rates with more disciplined project prioritization, including attention to business impact and data availability.
What is an evidence-based as-is process baseline?
An evidence-based as-is baseline is a record of how work actually runs, in systems and between them, with frequency and time attached. It is what an ERP current state assessment should produce, and the ground truth every scope decision rests on.
Aperture records exactly that and turns it into named workflows with hours and dollars attached.
For a program, this becomes the missing artifact at every gate: a defensible baseline. The business case gets a real denominator. The pilot gets a provable before. The steering committee gets evidence for a kill-or-fund decision instead of competing wish lists.
For an ERP migration, the recorded map provides an especially scarce input: a specification of what the legacy process actually does before you pay to rebuild it.
Why is killing a weak build a transformation win?
The cheapest build is the one you never fund.
A program that stops three doomed projects at the stage gate, with evidence, creates more value than one that politely pilots all three. The baseline is what makes that decision defensible in the room.
For delivery partners, the same evidence works from the other side of the table: it compresses the discovery phase itself.
If your program is deciding what to fund against a current state assembled from recall, the baseline is the first thing worth fixing. Talk to the founders.