A practical digital change programme starts with a defined need and a plan to learn from evidence. The seven steps below help an SME organise the work, but they do not imply a fixed budget, timetable or guaranteed outcome.
1. Understand the current situation
Choose the processes relevant to the problem and map their participants, systems, data and exceptions. Ask users what actually happens, including workarounds that are absent from formal procedures.
Record the current cost and performance where they can be measured reliably. Identify gaps in the information rather than present estimates as facts. Assess the skills and time available to support change.
2. Define outcomes and responsibilities
Describe what should improve and why it matters. A useful objective identifies the measure, baseline, intended direction and review point. Any numerical target should be agreed for the organisation and supported by the available evidence.
Name a business owner and clarify who can make decisions about scope, resources and acceptance. Technology teams need access to those decisions; they cannot resolve every process or policy question alone.
3. Prioritise with value, complexity and risk
Compare candidate changes using expected value, effort, dependencies and consequences of failure. A promising small change can help test assumptions, but low visible complexity does not mean low risk.
Possible candidates include shared customer records, document status, reporting or an order handover. The right starting point depends on the business. No process is a guaranteed quick win at a standard price.
4. Select an approach and technology
Consider process simplification, configuration of existing tools, integration and custom development. AI is one option where its behaviour can be evaluated and controlled; it is not a required stage of maturity.
Check source access, supported interfaces, licences, security, data handling and operation. Test the required actions rather than rely on product names or connector counts. Include the cost of changing or leaving the selected platform.
5. Run a bounded pilot
Define the task, users, data and acceptance criteria. Include ordinary cases and meaningful exceptions. Establish how problems will be reported and who can stop or revise the test.
Compare the pilot with the baseline, including human review, corrections and support effort. A result may justify expansion, a different design or stopping the work. A demonstration is not automatically ready for production.
6. Prepare adoption and support
Explain the purpose and practical effect of the change. Provide task-based training, usable instructions and a clear support route. Involve users who understand both common work and difficult exceptions.
Monitor why the system is used or bypassed. The answer may be missing functionality, unclear responsibility or a process that needs redesign. Avoid treating every objection as resistance to technology.
7. Expand and review
Use pilot findings to plan wider use. Review dependencies, capacity, permissions and support before adding more users or sources. Plan migration and rollback where appropriate.
Continue to review outcomes, costs and risks after launch. Assign owners for software updates, data quality and changes to the workflow. A wider programme can contain completed projects while continuing to adapt over time.
Common planning mistakes
- Buying a platform before defining the required work.
- Assuming a new system will repair inconsistent source data.
- Omitting internal time, training and operation from the budget.
- Treating a pilot’s success as proof for every department or workload.
- Reporting released time as cash savings without explaining how costs change.
- Leaving maintenance and incident ownership until after deployment.
These are issues to examine in planning, not claims that a fixed proportion of projects fails for each reason.
Estimate the full investment
Include software, integrations, migration, testing, training, infrastructure and ongoing responsibilities. Compare options over a common period and state the assumptions behind expected benefits.
Project dates should reflect access to systems, decisions, dependencies and acceptance work. There is no universal timeline for an SME or a fixed percentage of the budget that represents change management.
FAQ
Do we need an internal IT department?
Not necessarily, but the organisation needs an accountable business owner and access to the technical and operational skills required by the project. External support does not remove internal responsibility for decisions and use.
How should employees be involved?
Include them in understanding the current work, testing the proposed change and identifying exceptions. Explain the purpose, provide practical training and make support available during adoption.
How should we choose the first process?
Choose a defined problem with useful evidence, clear ownership and manageable dependencies. Compare expected value, complexity and risk rather than select only by frequency or visibility.
When should a pilot be expanded?
When its agreed criteria have been met and the additional requirements for wider use have been assessed. Resolve significant quality, permission, reliability and ownership issues before extending the scope.
What does a process audit include?
The scope depends on the questions and evidence available. Within Q-Journey, AiP offers Express and Platinum variants, with Lean and Muda consulting included in Platinum. Deliverables and timing are agreed individually.
Discuss the next step
Q-Journey provides a path from process review to application development, with or without AI. A defined software requirement can be scoped through Q-Dev.
Contact QA10 with one process, the people involved and the result you want to achieve.