The stated concern at the start of a discovery programme is almost always data security. Where will the information sit, who can access it, what happens to it afterward. Those are reasonable questions with technical answers, and they get resolved.
Underneath them there is frequently a second concern that surfaces later in the conversation and is harder to put on an agenda. That one is about the findings.
Leaders know their organization runs on more than what is documented. They do not know how much more, and they are being asked to commission an exercise that will produce a number. A security review that keeps circling back to scope is sometimes a security review. It is sometimes a leadership team working out what happens when the gap becomes explicit.
Once that is named directly, the usual framing shifts. An executive in the room eventually says some version of a sentence that resolves it: the processes themselves cannot be the sensitive part. What the exercise surfaces is a large amount of work that was never written down, which is a description of the company rather than an accusation about it.
Key takeaways
- The hesitation before discovery is often about the findings rather than the method.
- Not knowing how your organization runs is the normal state of a large company, not a management failure.
- An AI programme is usually the first initiative with enough budget behind it to force the question into the open.
- The uncertainty itself is the first finding: an organization that cannot predict what its people will say has already learned something.
- The output is a working record the team owns, which is what changes the exercise from an audit into an asset.
- Programmes that name the concern early move faster than programmes that resolve it through scope reduction.
Why the apprehension is reasonable
Nobody wrote it down, and everybody knows that
Large organizations run on an enormous volume of undocumented practice: the approval sought informally, the spreadsheet bridging two systems, the regional adaptation made years ago, the method one person developed for handling a case type.
Every leader knows this layer exists. Very few have a sense of its size. Commissioning an exercise that will measure it means committing to find out, and the honest position before that exercise is that nobody knows what the number will be.
The question has never been asked at this resolution
Operational reviews, audits and process mapping exercises have all happened before, at a sample size and a level of detail that produced manageable answers.
Asking the whole population, with follow-up questions, at a level of detail that reaches the exception handling, is a different exercise. Prior experience does not calibrate expectations for it.
The findings arrive attached to decisions
A diagnostic that produces observations can be absorbed. One that produces quantified effort per area, with dispositions and owners, produces a set of things that now have to be decided.
Some of those decisions touch arrangements that people are comfortable with. The apprehension is partly about the workload that accurate findings create.
Being surprised in front of a board is expensive
A leader who has told a board the operation is efficient, and then commissions an exercise that quantifies the gap, carries the cost of that revision personally.
That is a rational concern and it has a straightforward resolution: the gap exists either way, and the choice is between discovering it internally on a schedule or encountering it during a programme that was supposed to deliver something else.
What the hesitation is about
Three concerns that arrive together
| Concern | Stated as | What resolves it |
|---|---|---|
| Data handling | Where does the information go | Architecture, certification, residency |
| Employee reaction | How will people receive this | Framing, voluntary participation, visible follow-through |
| What the findings will show | Rarely stated directly | Naming it, and the first set of results |
The first is answered in a procurement review. The third is answered by the exercise itself, which is why it tends to stall the decision.
Why the uncertainty is itself the finding
A leadership team that cannot predict what its people will say about how work happens has learned something before the programme starts.
In a well-run organization that is not an indictment. It reflects the structure of large companies: each level holds a partial view, no role is positioned to see all of them, and nothing in normal operation assembles them. The gap forms quietly and nobody is responsible for noticing.
What makes it actionable is that the condition is measurable. The organization can establish how large the gap is, which processes carry it, and what it costs. That converts an uncomfortable uncertainty into a set of findings with owners.
Why an AI programme forces the question
This has been true for a long time and it surfaces now for a specific reason.
Previous initiatives could proceed on the documented process. A reporting project, a system upgrade or a policy change could be scoped from the official description and absorb the gap during implementation.
Pointing an AI system at a process requires knowing what the process does, including the exceptions, because the system will encounter them. Scoping from documentation produces a system that handles the standard path and fails on everything else.
So the question of how work actually happens arrives attached to a programme with budget, a sponsor and a deadline. That is usually the first time the organization has had to answer it with real consequences for being wrong.
How programmes get stuck, and what moves them
| Pattern | What it looks like | What moves it |
|---|---|---|
| Scope reduction | Each review narrows the population further | Naming the real concern directly |
| Indefinite review cycle | Security questions that have been answered return | Separating data handling from findings |
| Pilot that never expands | A small success with no decision to scale | Agreeing in advance what result triggers expansion |
| Sponsor hesitation | Approval present, start date moving | Framing the output as an asset the team owns |
The fourth row is the most common and the easiest to resolve. A sponsor who expects an audit behaves differently from one who expects a working record of how the company operates, and the difference is in how the output is described rather than in what it contains.
What makes the output an asset rather than an audit
Four properties, and they are design choices rather than communication choices.
The team owns it. The documentation, the process map and the findings live with the organization and keep being useful after the engagement. An output that leaves with a provider is a report.
It is non-attributable. Findings aggregate to processes and teams rather than to individuals. This is what makes honest participation possible and it is also what keeps the output usable as a management tool.
It carries dispositions. A finding with a recommended action and an owner is a work item. A finding without one is a criticism.
It produces a baseline. The numbers from the first pass become the comparison for the next, which turns the exercise into a measurement capability rather than a one-time verdict.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform. The concerns described above come up in most engagements, and the regulated ones surface them earliest.
Discovery Cycles run AI-led interviews with explicit, voluntary participation, where people choose to take part and choose what they share. Workspaces allow separate areas with anonymization applied, so output cannot be attributed to individuals. Horizon is SOC 2 compliant, uses encryption, role-based access control and anonymization, and does not train models on customer data. The Process Library keeps the resulting documentation with the organization, navigable and updated across cycles.
La Segunda Group, one of Argentina's main insurance companies with more than 90 years of experience and 1,200 offices nationwide, ran discovery on its long-term injury claim process under exactly these conditions.
The process was long and manual, spread across several systems and spreadsheets with little integration, handling more than 700 active cases with high effort and limited visibility. The stated goal was to simplify the process, reduce manual work and gain transparency, which required finding the friction points and repetitive tasks first.
Horizon interviewed seven case managers and two medical auditors, reaching 100% of the team involved. The full process was mapped and analyzed in 48 hours. In under five weeks the engagement delivered a complete BPMN process map, a dashboard of insights grouped by effort and impact, and 10 key findings covering automation, integration and workflow redesign opportunities, saving more than 30 discovery hours.
The participation numbers are the part that speaks to this topic. Conversation satisfaction was 8.2 out of 10 and 90% of participants said they would talk again. In a regulated insurer, on a critical process, the people being asked how they actually work found the exercise worth repeating.
The results were then used to begin building a new medical follow-up platform for chronic case management, with the dashboards guiding next steps on automation, alerts and system integrations. The map became something the team built from.
That is one engagement under specific conditions rather than a projection for any organization.
Readiness checklist
Before commissioning a discovery programme:
- Has anyone named the concern about what the findings will show?
- Is the data handling question separated from the findings question?
- Can you predict roughly what your people will say about the process in scope?
- If the answer to question 3 is no, is that acknowledged as a finding?
- Is participation voluntary, and is that stated clearly to participants?
- Will output be aggregated so it cannot be attributed to individuals?
- Will findings arrive with dispositions and owners rather than as observations?
- Does the organization keep the documentation afterward?
- What result would trigger expansion beyond the first scope?
- Who will communicate what changed as a result?
Question 1 is the one that unsticks most stalled programmes. The concern is usually present and usually unnamed, and naming it tends to resolve it faster than another round of scope review.
Common mistakes
Resolving a findings concern with more security documentation. The answer does not address the question, so the review cycle repeats.
Reducing scope until the exercise is safe. A narrow enough scope produces a result nobody disputes and nobody can act on.
Framing it as an audit. Changes how the sponsor behaves and how participants answer.
Letting findings be attributable. Participation quality drops immediately and does not recover.
Delivering observations without dispositions. Produces criticism rather than work items.
Collecting without showing what changed. The next cycle has a participation problem that no design choice can fix.
FAQ
What do leaders worry about before a process discovery programme?
Three things arrive together: how the data will be handled, how employees will receive the exercise, and what the findings will show. The first is answered in a procurement review. The third is rarely stated directly and is frequently what holds the decision.
Is it normal for a company not to know how its own processes work?
Yes, in large organizations it is the standard condition. Each level holds a partial view, no role is positioned to see all of them, and nothing in normal operation assembles them. The gap forms quietly and nobody is accountable for noticing it.
Why do AI programmes force this question into the open?
Because pointing an AI system at a process requires knowing what the process does, including the exceptions, since the system will encounter them. Earlier initiatives could be scoped from the documented process and absorb the gap during implementation. An AI programme cannot, and it arrives with budget and a deadline.
How do you keep process discovery from feeling like an audit?
Make participation voluntary, aggregate output so it cannot be attributed to individuals, frame questions around difficulty rather than compliance, deliver findings with dispositions and owners rather than as observations, and leave the documentation with the organization.
What if the findings are worse than expected?
That is the common outcome and it is the reason to run the exercise. The gap exists whether or not it is measured, and the practical choice is between establishing it internally on a schedule or encountering it mid-programme, when a deliverable depends on the process having been understood correctly.
How do you get a hesitant sponsor to proceed?
Name the concern about the findings directly, separate it from the data handling question, agree in advance what result would trigger expansion, and describe the output as a working record the team will own rather than as a verdict on the operation.
Not knowing is the normal condition
Very few large companies have an accurate account of how they run. That is a property of their structure rather than a failure of their management, and the leaders who hesitate before a discovery programme are usually right that the answer will be uncomfortable.
The part worth saying out loud is that the gap is already there. Measuring it is the only version of the situation where the organization gets to decide what happens next.
See it. Fix it. Own it.