Service
Make the important decisions before the expensive ones.
Discovery turns an operational problem, and the rules around it, into an evidence-based system blueprint. It establishes where authority sits, which permissions govern which action, and what should be built — creating enough clarity to approve, phase, price or stop an investment responsibly.
Who this is for
- Executives who need to approve or decline an investment on evidence
- Operations leaders who own a process that has outgrown its tools
- CIOs and CTOs assessing feasibility, sequencing and delivery risk
- Teams preparing a business case, a tender or a procurement submission
The problems this addresses
- A process everyone complains about, with no agreement on where it actually fails
- Several possible solutions and no defensible basis for choosing between them
- A budget request that cannot be justified because the scope is still a conversation
- Systems and data whose real interdependencies are known only informally
- A core process that runs on spreadsheets, inboxes and one person's memory
- A previous attempt that produced software nobody adopted
What changes
- The operational problem is written down in terms the whole organization recognises
- The first phase is small enough to approve and large enough to matter
- Risks and assumptions are visible before they become change requests
- The decision to proceed, phase or stop is made on documented evidence
What Kerah can deliver
Capability, not a claim of past work. Final scope is established through discovery.
- Stakeholder and user interviews
- Current-state process mapping, including the workarounds people rely on
- System, integration and data inventory
- Data classification and sensitivity assessment, including personal, health and financial data
- Controller, processor and data-role mapping per country and data category
- Permission and approval mapping — which authority governs which action, and what must be approved before it is taken
- Build, buy or configure assessment against the platforms the organization already owns
- Options analysis with trade-offs stated plainly
- Target architecture and integration design
- Delivery sequencing and phase definition
- Estimation with stated confidence and the assumptions behind it
What you receive
Artefacts, not activities. Each one is something you can hold, read or run after the engagement.
- Stakeholder and user map
- Current process and pain-point map
- System, integration and data inventory
- Risk and assumption register
- Success measures agreed with the sponsor
- Target architecture
- Phased delivery roadmap
- Scope, exclusions and acceptance approach
- Delivery estimate and decision pack
How the engagement runs
- Fixed price, fixed duration
- Discovery is scoped and priced as its own phase so it cannot expand indefinitely, and so the decision at the end of it is genuinely open.
- Evidence over opinion
- Findings come from the people doing the work and from the systems themselves, not only from the sponsor's description of the process.
- Yours either way
- The blueprint is a deliverable, not a sales document. It is written to be useful if you build with Kerah, with someone else, or not at all.
Commercial shape. A discrete discovery phase with a defined duration, a fixed price and a named deliverable set.
Raised from the start, not before launch
Architecture, security and data decisions that are cheap to make early and expensive to retrofit.
How Kerah approaches security- Which data is personal, sensitive or regulated, and what that implies for architecture and residency
- Where authority actually sits in the current approval chain, and which decisions may never be automated
- Which actions require an approval, a licence or an authorised channel before they may be taken
- Who is controller and who is processor, per country and per data category
- Integration constraints imposed by systems Kerah does not control
- Operational readiness — who will run the system once it exists
- Whether a smaller process change would remove the need for software
Where this stops
- This is technology, product and process discovery. It is not general management consultancy, organisational restructuring or financial advisory.
- Kerah does not recommend a platform the organization could not realistically run itself, or leave.
- Estimates are stated with confidence levels. A single number presented as certainty this early would be misleading.
Other services
Enterprise Systems
One operational system where work is assigned, decisions are recorded, permissions are explicit and reporting comes from the same data people work in.
Digital Product Engineering
A designed, accessible product with a secure back end, built around the tasks people actually perform and measured after release.
Cloud, Data and Integrations
Defined interfaces, a documented data model and monitored flows, so information moves once and reporting can be trusted.
AI and Intelligent Automation
A bounded use case with defined success criteria, evaluation against representative cases, human review where it matters, and a fallback when the model is unavailable.
Managed Evolution
A defined support and release model with security maintenance, an owned backlog and a roadmap reviewed on a set cadence.
Security and Privacy Engineering
A system whose access model, data inventory, encryption, logging and deletion behaviour were designed together — and the documentation an assessor asks for, produced as delivery output rather than reconstructed afterwards.
Quality, Testing and Accessibility
A system tested in both languages by people who read both, measured against WCAG 2.2 AA, and exercised under realistic load and failure conditions before launch rather than after it.
Discuss a discovery phase.
Tell us what is not working today, who it affects and what a better outcome would change.