What a Discovery Phase Looks Like for Automation and Modernization.
Before Nortis automates a process or upgrades an application, one to three weeks go into mapping how it actually works today. What happens in those weeks, what you get at the end, and why skipping it costs more than running it.
Nortis
You have a process that runs on manual work, or an application that needs upgrading. You've talked to Nortis. And the first thing on the proposal is not a build. It's a discovery phase.
If you haven't been through one, it sounds like a delay. A billable preamble before the real work begins.
It isn't. Discovery is the phase most likely to stop you from automating the wrong step, integrating the wrong system, or upgrading an application that should have been retired.
What discovery actually is.
Discovery is a structured period, typically one to three weeks, at the start of an engagement where we map the workflow or the application as it operates today, before any production code is written.
The goal is not a specification document that collects dust. The goal is to answer three questions with enough clarity that every later decision becomes easier:
- What actually happens today, step by step, system by system?
- Which of those steps should be integrated, automated, AI-assisted, kept under human control, or built as custom software?
- In what order, and what does the first delivery look like?
The answer to the second question is the whole engagement. Discovery is how we earn it.
Why skipping discovery costs more than doing it.
The process you think you run and the process your team runs are different processes.
The order form that "comes in by email" also comes in by phone, by WhatsApp screenshot, and as a PDF attached to a reply to last year's thread. The invoice approval that "goes to finance" goes to one person in finance, who checks a spreadsheet nobody else knows exists. The application that "just needs a framework upgrade" has a dependency that only compiles on the old runtime.
Automate the documented version of the process and the undocumented version keeps running next to it. Now there are two. Discovery finds the second one first.
What happens during discovery.
Every engagement is slightly different, but the arc is consistent: understand, define, plan. It follows the way Nortis works on every project.
Week 1: Understand what runs today.
The first week is about looking, not proposing.
Process walkthroughs. We sit with the people who do the work and watch them do it. Not "describe your process" but "show me the last order you handled, from the moment it arrived." The questions are specific: where does this number come from, who checks it, what happens when it's wrong.
System inventory. Which systems are involved, what each one holds, how data gets between them today. For most of our clients the answer includes an ERP, a CRM or e-commerce platform, Microsoft 365, and at least one Excel file doing the job of a database.
Exception hunting. The happy path is rarely the problem. We list what goes wrong, how often, and who sorts it out. Exceptions decide what can be automated outright and what needs a human review step designed into the flow.
Application assessment, when software is in scope. If an existing application is part of the picture, this is where the Application Health & Security Audit runs: framework and runtime lifecycle, a dependency risk map, the critical findings, and what blocks an upgrade.
The output of this week is a map of the current state: manual steps, systems, decision points, data sources, exceptions, bottlenecks, business risk, and time spent. Written down, and agreed by the people in it.
Week 2: Define the future workflow.
Now the question shifts from "what happens?" to "what should happen?"
For every step on the map we decide what it should become:
- Integrated. Two systems that should talk directly, so the person in between stops re-typing.
- Automated. A rule-based step that runs without anyone touching it.
- AI-assisted. A step that needs reading or judgement, such as pulling an order out of an unstructured email, with a defined confidence threshold and a human fallback.
- Kept under human control. A decision the business wants a person to make, with the automation preparing everything around it.
- Built as custom software. A gap no existing system covers.
The discipline is in the fourth category. The best automation designs keep fewer steps automated than the client first wanted, and more clarity about why each one is where it is.
Technical feasibility runs alongside. Does the ERP expose an API or only a database? Does the CRM allow writes from outside? What data has to be reconciled, and which system is the source of truth? Hidden complexity surfaces here, not in week six of the build.
Week 3: Plan the build.
The final stretch turns the future workflow into a plan.
Architecture. Which integrations, which automation workflows, which AI services, which internal interfaces, what monitoring, what security controls. For a modernization, this is the upgrade path: the sequence of framework, runtime and dependency moves, and the tests that have to exist before each one.
Roadmap. The future workflow broken into deliveries, sequenced so the first one removes real manual work on its own. A roadmap that only pays off at the end is a bad roadmap.
Estimate. A scope with stated assumptions, grounded in the map rather than in the first conversation.
What you get at the end.
Discovery produces a set of documents you own, whether or not the build happens with us:
Current-state process map. Steps, systems, decision points, data sources, exceptions, time spent.
Future workflow design. Each step marked integrated, automated, AI-assisted, human-controlled or custom-built, with the reason.
Integration and data requirements. What each system has to expose, and which one is the source of truth for each record.
Application health report, when an application is in scope. Lifecycle status, dependency risk, critical findings, upgrade blockers, security quick wins.
Architecture and implementation roadmap. What gets built, in which order, with the first delivery defined.
Estimate. Scope and assumptions for the roadmap.
When a question comes up mid-build, "should the approval step stay manual?" or "can the warehouse system write back?", these documents answer it.
What discovery is not.
Discovery is not a sales tactic. Its deliverables are usable by any engineering team. If the right answer is a product you can buy, or no automation at all, the report says so.
Discovery is not a requirements document. It defines enough to build the first delivery with confidence and leaves room for what the running workflow teaches.
Discovery is not optional for connected processes. A single script that moves a file does not need it. Anything that touches two business systems, carries money, or has exceptions does.
How to get the most out of it.
Bring the people who do the work. Not only the manager who describes it. The gap between the two is the whole point.
Bring the decision-maker. Week 2 is a series of "keep this manual or automate it" calls. If each one waits for a meeting, the timeline stretches.
Open the systems. Read access to the ERP, the CRM and the shared mailbox in week 1 saves a week of guessing.
Expect to hear "not yet." Some steps should not be automated at today's volume. That is the audit protecting your budget, not avoiding work.
Where to start.
Discovery is packaged as two audits, one per pillar. The AI & Automation Audit covers the process side: discovery, system mapping, automation and AI opportunities, integration requirements, prioritisation, and the implementation roadmap. The Application Health & Security Audit covers the software side. Many engagements need both, because automation eventually reaches the boundaries of the software it runs on.