Process Automation Assessment
Not every process is worth automating, and automating a bad one only makes it fail faster. We identify where manual work costs more than automating it would, with the business case for each candidate, and build the automation roadmap.
The assessment surveys the candidate processes, measures the real manual effort they consume, evaluates how ready each one is to be automated and calculates its return. It delivers a roadmap prioritised by return against complexity, agreed with the areas that own the process. Scope: up to 3 processes.
Know what to automate first
The processes with the highest return per unit of effort, not the ones that complain loudest.
Rule out what is not worth it
Which ones should be redesigned or eliminated rather than automated.
Justify the investment
Hours released and cost avoided per process, with figures from your own operation.
One surveys and maps the route. The other executes it.
These are two different services and it is worth knowing which one you need before contracting. The assessment does the first information-gathering exercise, builds the roadmap and aligns it with the business areas. The consulting practice executes that roadmap.
Process Automation Assessment — this page
Surveys, maps and aligns. It surveys up to 3 candidate processes, measures the manual effort, evaluates technical feasibility, calculates the return and builds the roadmap agreed with the owning areas. It runs two to four weeks depending on the size of the organisation. It does not implement, does not configure and does not operate anything.
Automation — execution
Executes the roadmap. It takes the roadmap and executes it: process redesign, building the automation, integration with the systems and support for whatever stays running. It works just as well if you already have a roadmap of your own.
Eight fronts per process evaluated.
A process can look like a good candidate and not be one. We review each front before recommending it, and rate feasibility on explicit criteria.
Process map
How it actually runs today, not how it is documented. Steps, exceptions and manual decisions.
Volume and frequency
How many times it runs, with what peaks and how long each run consumes.
Manual effort
Real person-hours spent, including the ones nobody counts: rework, corrections and waiting.
Quality and errors
How often it fails, what each error costs and how long it takes to detect.
Input data
Where the data comes from, in what format and with what degree of structure and reliability.
Systems involved
Which applications the process touches, whether they offer integration or depend on the screen.
Rules and exceptions
How stable the rules are and what proportion of cases is resolved by human judgement.
Impact of the change
Who runs the process today, what changes for those people and what preparation it demands.
Six phases, without interrupting your operation.
The assessment rests on interviews, process observation and analysis of existing data. No automation is built.
Scope and preparation
We define the candidate processes —up to three— and agree access to documentation and operating data.
Interviews and observation
With the people who run the process daily, which is where the exceptions nobody documented show up.
Effort measurement
Volume, times and rework, with operating data where it exists and structured estimation where it does not.
Feasibility analysis
Technical and process evaluation against recognised automation criteria, process by process.
Business case
Hours released, cost avoided and implementation effort, to calculate the return of each candidate.
Business alignment
Presentation of the roadmap with leadership and the process-owning areas, to agree priorities.
What your maturity is measured against.
The evaluation does not rest on the judgement of whichever consultant shows up, nor on a vendor catalogue, but on public and auditable frameworks your team can consult and your auditor will recognise. The business case is built on local costs: an hour of manual work saved is not worth the same in Bogotá, in Mexico City, or at a European head office.
BPMN 2.0
Modelling language. Standard notation for representing the process so business and technology read the same thing.
Lean
Analysis framework. Identifies waste, waiting and rework before automating, so inefficiency does not get set in stone.
Six Sigma (DMAIC)
Measurement guide. Structures the measurement of variability and errors, which is the basis of the business case.
CMMI for processes
Maturity framework. Provides the scale that makes the result comparable year on year.
ISO 9001
Quality guide. Reference where the process sits inside a certified management system.
RPA suitability criteria
Feasibility guide. Recognised rules for deciding whether a process is a candidate: repeatability, stability and structured data.
The frameworks are public and verifiable: anyone on your team can consult them and check the rating we deliver. That is the difference between an auditable evaluation and an opinion.
What it costs to automate blind.
The risk of automating badly is not that it fails to work: it is that it works, and the error multiplies at machine speed.
Automating the waste
You speed up a process that should not exist, and set an inefficiency in stone for years.
A return that never arrives
The investment is justified with hours estimated by eye and the saving never shows up in the P&L.
Exceptions that break everything
The 20% of cases nobody mentioned forces manual intervention and cancels the benefit.
A fragile dependency
The automation depends on a screen that changes with the system's next update.
Team resistance
You automate without preparing the people who ran the process, and adoption stalls from the inside.
Hidden maintenance cost
Every rule that changes demands an adjustment, and nobody budgeted who makes it.
What it costs you in time, said upfront.
An assessment that does not state the commitment it requires ends up delayed. This is what we need from your side to deliver on time.
Two to four weeks
Two weeks in organisations of up to 50 employees; four between 51 and 300. The timeline is agreed before starting.
Scheduled interviews
Sessions with the people who run the process daily and with the head of the owning area.
Read-only access
Queries against the platforms and existing documentation. At no point is a configuration modified.
A single point of contact
One person coordinating schedules and access. It is the factor that most affects hitting the deadline.
Whatever documentation exists
Process manuals, volume and time records, and error or rework reports, in whatever state they are in.
A closing session
The presentation of findings with leadership and the areas involved, where the roadmap priorities are agreed.
When it makes sense and when it does not.
It makes sense if…
Your team spends hours on repetitive tasks; there is frequent rework from manual errors; you are evaluating an investment in automation and need to justify it; or you already tried to automate something and it did not deliver the expected return.
Probably not if…
You already know which process to automate and want it built: go straight to Automation. Or if the problem is that the data is not reliable, that gets measured first by the Data Maturity Assessment.
What you gain from the assessment.
Prioritised candidates
The processes ordered by return against complexity, on explicit criteria.
A calculated return
Hours released and cost avoided per process, with data from your own operation.
Justified rejections
What is not worth automating and why — which saves more than many automations.
Documented processes
The real map of up to three processes, in standard notation, whether or not they are automated.
Risks anticipated
The exceptions and dependencies that usually surface mid-project, identified beforehand.
A decision with figures
A business case leadership can approve or reject with an argument.
Why this evaluation and not a tool demo.
The difference is not in showing that a robot can do the task: it is in proving that it is worth it, and how much it returns.
Evaluation, not demonstration
A proof of concept shows the technology works. This evaluates whether the process deserves to be automated.
Redesign first, automate second
If the process carries waste, it is flagged beforehand: automating it as-is multiplies the problem.
Recognised frameworks
The analysis rests on BPMN, Lean and recognised suitability criteria, not on the consultant's intuition.
Vendor independence
The recommendation is not shaped by whichever automation platform would suit us to sell.
Figures from your operation
The return is calculated with your volumes and your times, not with industry averages.
Continuity into execution
If you decide to proceed, the roadmap connects with Automation without surveying the process again.
As-Is, To-Be and the plan to get from one to the other.
Every assessment closes with the same structure, whatever the practice: where you stand today, where you need to be, what separates the two states and in what order that distance gets closed.
Current state — As-Is
The starting point surveyed with evidence, not declared in an interview: what exists, how it operates and how far it sits from what the business needs.
Target state — To-Be
Where the organisation needs to get to, defined with the business areas rather than imposed by the consultant. It is the benchmark everything else is measured against.
Gap analysis
Every difference between the As-Is and the To-Be, with everything required to close it: technology, processes, people, governance and budget. No gap is stated without what it demands.
Risk matrix
Each gap rated by probability and business impact, so priority does not depend on who pushes hardest but on what it costs to leave it open.
Work plan
The concrete sequence to reach the To-Be: what comes first, what it depends on, how much effort it takes and who should answer for each front.
Business alignment
The plan is presented and agreed with the areas involved. A roadmap signed only by IT does not survive the first quarter.
How what you receive is structured.
The central deliverable is a report with a fixed structure, designed so leadership reads the first pages and the technical team works with the rest.
Executive summary
Two pages: which processes are worth automating, which are not and what aggregate return is estimated.
Map of each process
The real process in BPMN notation, exceptions and manual decisions included.
Effort measurement
Volume, times, rework and person-hours per process, with the source of each figure.
Feasibility evaluation
Rating of each candidate against the suitability criteria, with the justification.
Business case
Hours released, cost avoided, implementation effort and estimated return per process.
Roadmap
Recommended sequence, with what has to be redesigned before automating in each case.
What you receive at the end.
- Current state (As-Is): map in BPMN notation of up to three processes, exactly as they run today.
- Measurement of manual effort: volume, times, rework and person-hours.
- Identification of exceptions and dependencies that affect automation.
- Target state (To-Be): the redesigned and automated process, agreed with the owning areas.
- Gap analysis between the As-Is and the To-Be, with each gap, its evidence and everything required to close it: redesign, rules, data, systems and exception handling.
- Risk matrix: each candidate rated by probability of failure and impact on the operation.
- Automation feasibility evaluation per process, on explicit criteria.
- Business case per candidate: hours released, cost avoided and estimated effort.
- Work plan to reach the To-Be: automation prioritised by return against complexity, with the prior redesign where the process requires it.
- Immediate-impact actions, executable without automation or budget.
- Executive presentation for committee and leadership.
- Alignment session with the areas that own the processes.
About the Process Automation Assessment.
How many processes do you evaluate?+
How does it differ from automation consulting?+
What if the process is not worth automating?+
Do we need volume and time data?+
Do you build anything during the assessment?+
Who should take part on our side?+
Is it useful if we already tried automating and it did not work?+
How often should we repeat it?+
Know what is worth automating before investing in doing it.
Book your Process Automation Assessment and get the real map of up to three processes, with the business case for each candidate and a roadmap prioritised by return.
Book my assessment → See the Automation →