Make the new system fit the work people need to do
A system deployment is a chance to understand how work moves between people, information and approvals. Stratiis helps organisations map current processes, define the desired way of working and test it before a wider rollout.
What is business process mapping for a new system?
Business process mapping records the steps, roles, information, decisions and exceptions involved in a task. For a new system, it helps the business compare how work happens today with how it should happen after deployment. The map informs requirements, configuration, testing, training and ownership.
Connect software choices to real outcomes
Clear processes make requirements easier to explain and the final result easier to assess.
Defined work
Show where a task starts, who acts and when it is complete.
Visible handoffs
Find delays, duplicate entry and unclear responsibilities between teams.
Better requirements
Describe the decisions, data and controls the system needs to support.
Measurable change
Agree how time, quality or experience will be compared after launch.
What should business process work include?
The level of detail should fit the size and risk of the change. These questions help teams move from assumptions to a usable design.
| Area | What to establish | Useful output |
|---|---|---|
| Purpose and outcome | Why the work is done and what a successful result looks like. | Agreed goal and measures. |
| Current steps | Tasks, handoffs, delays, workarounds and existing systems. | Current process map. |
| People and decisions | Roles, approvals, ownership and escalation points. | Responsibility and decision map. |
| Information | What data is created, checked, shared or retained. | Data needs and ownership. |
| Exceptions and controls | Unusual cases, errors, security and compliance requirements. | Exception paths and control needs. |
| Future workflow | How the system and people should work together after change. | Future process, requirements and test cases. |
Process owners and frontline users should validate the map; written procedures alone may not show how work actually happens.
Look beyond the main happy path
The steps that seem simple on paper may depend on several systems, teams and exceptions.
Current work
Observe the task from request to completion and record workarounds.
Roles and approvals
Identify who can start, review, approve or change each stage.
Data and records
Confirm which information the workflow needs and where it is maintained.
Exceptions
Map rejected requests, missing information, urgent cases and failures.
Connected systems
Check integrations, file exchange, notifications and reporting dependencies.
Adoption and support
Plan guidance, feedback and ownership after the new process goes live.
From current work to a tested future process
Each stage should involve the people who own and use the process.
Discover
Agree the problem, outcome, scope, users and measures.
Map
Record current steps, information, handoffs and exceptions.
Design
Define roles, future steps, system needs and controls.
Validate
Test real scenarios with users and refine before rollout.
New System Deployments connects this process work with configuration, data, testing and handover.
Get the right voices into the design
The process owner decides the business rules. Users explain the practical work. Technical teams and suppliers show what the system can support.
Before configuration
Confirm who owns the process, who approves changes and which teams are affected. Agree the boundaries of the project and the measures that will show whether the process improved.
During delivery
Review proposed changes with representative users. Record decisions, exceptions and unresolved requirements. Keep the supplier and internal team aligned on what will be configured, trained and supported.
IT Project Management can coordinate those decisions and milestones.
How can you tell whether the new process works?
Test outcomes people need to achieve, including the unusual cases that often cause delays.
| Test | What it checks |
|---|---|
| Typical journey | A common request can move from start to finish. |
| Different roles | Each user sees the right task and information at the right time. |
| Approval and rejection | Decisions route correctly and reasons can be recorded. |
| Incomplete information | The process handles missing data without losing the request. |
| Connected systems | Required data and notifications reach the right destination. |
| Reporting and support | Owners can see progress, resolve issues and maintain the workflow. |
Record acceptance criteria and open issues before launch. These results should inform training and the system deployment handover.
Should you simplify, automate or replace the process?
Start by removing unnecessary steps and clarifying ownership. Some work then benefits from workflow automation; other work needs a better data structure, system change or training. The right approach depends on volume, variation, risk and the value of the improvement. Automation, Data and AI Readiness can help assess a candidate use case before a pilot.
Simplify
Remove avoidable approvals, duplication or unclear handoffs.
Standardise
Give teams a shared, documented way to handle common cases.
Automate
Use defined rules for suitable repeatable steps.
Measure
Review results and exceptions after the change is in use.
Connect process design to delivery and support
The workflow should influence technology choices, user guidance and the ongoing service model.
New System Deployments
Coordinate configuration, data, testing, launch and handover.
Projects & Digital Transformation
Connect process improvement to business outcomes.
Technology Roadmaps
Prioritise systems and process changes over time.
Co-managed IT
Add delivery capacity alongside an internal IT team.
Business process design explained
Why map a process before choosing software?
Mapping shows the outcome, steps, roles, information and exceptions the software must support. It helps the business compare products and avoid configuring a system around assumptions.
Who should be involved in process mapping?
Include the process owner, people who perform the work, teams that receive handoffs and the system or data owners. The mix depends on the task being changed.
How detailed should the process map be?
Detailed enough to make decisions about roles, data, approvals, exceptions and testing. A high-risk or complex workflow may need more detail than a simple request process.
What is the difference between current and future process maps?
The current map shows how work happens today, including workarounds. The future map describes the agreed steps after change and provides a basis for system requirements and testing.
Should every existing step move into the new system?
No. The team should decide whether each step still serves a purpose. Some can be removed, combined or handled differently before the new system is configured.
How are exceptions and unusual cases handled?
Identify them during discovery, assign an owner and test the agreed route. Examples include rejected approvals, missing data, urgent work and service interruptions.
How do we measure process improvement?
Set a baseline and compare relevant measures such as turnaround, rework, errors, user effort or customer experience after rollout. Review whether the change adds any new support burden.
Can Stratiis work with our software supplier?
Yes. Stratiis can help align business requirements, technical dependencies, testing and handover with your supplier. Product-specific configuration responsibilities should be agreed for the project.
Make the next system support the way your business works
Tell us which task, handoff or system is causing difficulty. We can discuss discovery, requirements and a practical next step.
