AI Readiness: Strategy and Operational Impact

A practical, self-paced course for SME leaders on evaluating and preparing an organization for AI within an operational excellence framework. You will assess readiness across seven dimensions, audit data quality, gauge workforce capabilities, prioritize use cases, define performance metrics and set sound governance so AI initiatives scale beyond the pilot stage.

Course structure

• Module 1: Foundations of AI Readiness (5 lessons). What AI readiness means for an SME, the main kinds of AI that matter in operations, and why so many pilots never reach the shop floor.
• Module 2: Strategy and the Use-Case Pipeline (5 lessons). How to find, score and choose AI use cases that solve real business problems, and how to decide whether to build, buy or partner.
• Module 3: Data Foundations (5 lessons). How to audit data quality, understand your data infrastructure, govern data responsibly under Canadian privacy expectations and fix data problems with DMAIC.
• Module 4: People, Skills and Culture (4 lessons). How to assess workforce capabilities, define roles for AI work, lead the human side of change and build practical AI literacy.
• Module 5: Governance, Metrics and Scaling (5 lessons). How to govern AI risk, define performance metrics, run disciplined pilots, scale to everyday operations and build a 90-day readiness plan.

Interactive labs

• AI Readiness Self-Assessment: Score your organization from 1 to 5 on seven readiness dimensions to see your maturity profile on a radar chart. Use the result to find the weakest dimension that will set the pace of your AI journey.
• AI Use-Case Prioritization Matrix: Rate each AI use case on effort or feasibility difficulty and on business value to see which are quick wins and which are strategic bets. Rename or add items to reflect your own pipeline.
• AI Use-Case ROI Calculator: Enter the manual hours, labour cost, share of work automatable and the build and running costs of an AI use case to estimate annual savings, payback and three-year ROI. Use it to test the assumptions in your business case.

How it works

• Work through 24 short lessons at your own pace. Each has key takeaways, an exercise for your own workplace and a quick knowledge check.
• Try the three interactive labs as you reach them in the course.
• Pass the 20-question final exam (70% or higher, unlimited retakes) to unlock your Chmltech certificate of completion.
• Free, with no sign-up. Your progress is saved in this browser.

Most owners first meet artificial intelligence as a product demo: a chatbot that writes emails, or a vendor promising that a model will forecast demand. The demo works. The question that matters is different: is your organization ready to make AI work, repeatedly, inside real processes, with real staff and real data? That is what AI readiness means.

AI readiness is the combination of conditions that let an organization move from interest to dependable results. It is not a single technology purchase. It is closer to plant readiness before a new production line: the line can be excellent, but if the floor is not level, the power is wrong and nobody is trained, it will sit idle.

The four layers of readiness

• Strategic readiness – leaders know which business problems AI should help with, and why those problems matter now.
• Technical readiness – the data exists, is good enough, and can be reached by the tools that need it.
• People and cultural readiness – staff have the skills, the trust and the time to use new tools, and managers can lead the change.
• Governance readiness – there are clear rules for risk, privacy, accountability and how decisions are checked.

A gap in any one layer can stop a project. A distributor with excellent data but no executive sponsor will see its pilot drift. A clinic with an enthusiastic manager but patient data scattered across paper forms and three systems will struggle to train or feed any model.

A worked example

Imagine a 40-person fabrication shop that wants AI to quote jobs faster. Estimators currently take two days per quote. A quick readiness check shows:

The shop is not ready to buy a quoting tool yet. It is ready to clean up its quote history, involve the senior estimator in design, and decide on an approval rule. Those steps cost little and make the eventual tool far more likely to succeed.

Why readiness first

Readiness work feels slower than buying software, but it prevents the most expensive outcome: a tool that is paid for, half-configured and quietly abandoned. In this course you will assess each layer, prioritize use cases, set metrics and build a practical plan to move beyond small pilots.

"AI" covers a wide family of techniques. Leaders do not need to build models, but they do need to recognize which kind of tool fits which problem. Choosing the wrong category is one of the fastest ways to waste a budget.

Five practical families

AI is not the same as automation

Robotic process automation (RPA) and simple scripts follow fixed rules: if the field says X, do Y. AI handles variation: invoices in different layouts, free-text complaints, images taken in changing light. Many valuable SME solutions combine the two. A rule moves the data; an AI step reads the messy document first.

The distinction matters for readiness. Rule-based automation needs a stable, well-documented process. AI needs that too, plus enough representative data and a way to handle the cases where the model is wrong.

Matching the tool to the problem

Ask three questions about any proposed use case:

1. What is the output? A number (forecast), a label (pass/fail), a draft (text) or a plan (schedule)?
2. What does it learn from? Your historical records, general knowledge built into a vendor model, or images you collect?
3. What happens when it is wrong? A slightly poor email draft is cheap. A missed safety defect is not.

Consider a clinic's intake desk. Summarizing a referral letter is a generative AI task with a human reviewing the result. Predicting no-show appointments is a predictive task trained on the clinic's own booking history. Both are "AI", but they need different data, different checks and different governance.

A word on hype

Generative AI tools are easy to try, which makes them feel like the whole story. For many operations problems, though, a modest predictive model or a well-designed optimization will deliver more measurable value. Keep the problem, not the headline technology, at the centre of your thinking.

Many organizations run an AI pilot, see a promising demo, and then nothing changes in daily operations. The pilot is neither killed nor scaled. Practitioners often call this pilot purgatory. Understanding why it happens is the first step to avoiding it.

Common root causes

• No owner in the business. IT or an outside vendor runs the pilot, but no operations manager is accountable for using the result.
• No baseline. Nobody measured how long the task took or how many errors occurred before the pilot, so success cannot be shown.
• Pilot data is not production data. The team hand-cleaned a sample for the test. Live data is messier, and performance drops.
• The process was never redesigned. The AI output arrives, but the workflow, roles and approvals stay the same, so the benefit is lost in handoffs.
• Integration was deferred. The pilot ran in a separate tool. Getting it into the ERP or scheduling system becomes an unplanned project.
• Trust was not built. Frontline staff were not involved and quietly work around the tool.
• No exit criteria. Nobody defined in advance what result would justify scaling or stopping.

A five-whys example

Imagine a regional distributor that piloted demand forecasting. Six months later, buyers still use their old spreadsheets. A five-whys session reveals the chain:

1. Why do buyers ignore the forecast? They do not trust it.
2. Why not? It was badly wrong on several promotional items.
3. Why? Promotions were not flagged in the sales history used to train the model.
4. Why? Promotion data sits in the marketing team's calendar, not the ERP.
5. Why? Nobody mapped which data the forecast needed before the pilot started.

The root cause is a readiness gap in data and process mapping, not a weak algorithm. Swapping vendors would not have fixed it.

Designing pilots to escape purgatory

A pilot should be designed as the first stage of deployment, not as a science experiment. That means naming a business owner, measuring a baseline, using realistic data, sketching the future workflow, planning integration early and writing go/no-go criteria before the pilot begins. Later in this course you will build each of these elements.

A good pilot answers one question: should we run this in production, and what would it take?

Operational excellence is the discipline of running processes that deliver value reliably, with waste removed and variation controlled. Lean, Six Sigma and continuous improvement are its core toolkits. AI does not replace them. It works best on top of them.

Do not automate waste

A classic Lean warning applies directly to AI: if you automate a wasteful process, you get waste faster. Before applying AI to a task, ask whether the task should exist at all. Consider a distributor whose staff re-key order details from emails into the ERP. AI could read the emails. But a Lean review might show that a simple online order form would eliminate most of the re-keying entirely, at a fraction of the cost.

Where AI strengthens Lean and Six Sigma

Using familiar frameworks

The DMAIC cycle (Define, Measure, Analyze, Improve, Control) maps neatly onto an AI initiative. You define the business problem, measure the baseline and data quality, analyze root causes and whether AI is the right lever, improve by piloting the solution with a redesigned workflow, and control by monitoring model and process performance after go-live.

PDCA (Plan, Do, Check, Act) suits smaller, faster experiments such as testing a generative AI assistant with one team for four weeks.

A worked example

Imagine a metal finishing shop with a high rework rate on powder-coated parts. The owner asks about AI vision inspection. Working through DMAIC first, the team measures rework by defect type and finds that most defects trace to inconsistent pre-treatment. A simple control on bath chemistry, with a checklist, removes much of the problem. Vision inspection is still considered, but now for a smaller, better-understood set of defects, which makes it cheaper and more accurate.

The lesson is not that AI is unnecessary. It is that a stable, understood process is the right foundation for AI, and that operational excellence methods tell you where AI will add the most value.

To assess readiness consistently, it helps to break it into dimensions that can each be scored. This course uses seven, drawn from common maturity-model practice. You will score your own organization on them in the lab that follows this lesson.

The seven dimensions

1. Strategy and leadership – Is there a sponsor, a stated purpose for AI, and a link to business goals?
2. Use-case pipeline – Is there a list of candidate problems, assessed for value and feasibility?
3. Data quality – Is the data your processes depend on accurate, complete and consistent?
4. Data infrastructure – Can data be accessed, combined and moved between systems securely?
5. Skills and capabilities – Do staff and managers have the skills to use, question and maintain AI tools?
6. Culture and change – Is there trust, openness to experiment and a track record of adopting change?
7. Governance and risk – Are there rules for privacy, accountability, risk review and acceptable use?

A five-level maturity scale

How to score honestly

• Score on evidence, not intention. A policy that is drafted but not used is a 2, not a 3.
• Score with a small cross-functional group, such as operations, finance, IT and a frontline lead. Different views reveal blind spots.
• Note one piece of evidence for each score so you can track progress later.

Reading the profile

The shape of the result matters more than the average. Imagine an engineering office that scores 4 on skills, 4 on culture, but 1 on governance. Its people are keen and capable, and are probably already using public generative AI tools with client documents. Its first priority is an acceptable-use policy, not another pilot.

By contrast, a food manufacturer scoring 4 on data infrastructure but 2 on use-case pipeline has capable systems and no clear direction. Its next step is structured discovery of business problems.

The weakest dimension usually sets the pace. Readiness planning means lifting the lowest scores to a workable level before scaling, while starting small, safe use cases in the stronger areas.

The most reliable AI strategies for SMEs begin with a short list of business problems that leaders already care about. Tools come later. This sounds obvious, yet many initiatives start with "we should be using AI" and then search for somewhere to apply it.

Anchor AI to strategic goals

Begin with two or three goals from your business plan. Typical SME goals include growing revenue without adding headcount, improving on-time delivery, reducing quality costs, or freeing skilled staff from administrative work. For each goal, ask which operational problems stand in the way.

Write a clear problem statement

A good problem statement, borrowed from the Six Sigma project charter, describes what is happening, where, how much it costs and why it matters, without assuming the solution. Compare:

• Weak: "We need an AI chatbot for customer service."
• Strong: "Customer service staff spend about half of each day answering order-status questions by phone, delaying responses to complaints and returns."

The strong version opens several possible solutions: a self-serve order tracking page, automated status emails, or an AI assistant. It also suggests a metric, staff time on status calls, that can be measured before and after.

The role of the leadership sponsor

Each priority problem needs a sponsor who owns the business outcome. The sponsor approves resources, removes obstacles, and decides at go/no-go points. In a small company this is often the owner or general manager. The sponsor should not be the vendor or the IT contractor, because they do not own the operational result.

A worked example

Imagine a 60-person HVAC services company. Leaders list three goals for the year. Under "improve technician productivity", they identify that technicians make repeat visits because the right part was not on the truck. The problem statement focuses on first-time fix rate. AI might later help predict parts needed for each job type, but the team starts by measuring how often repeat visits happen and why.

Starting from problems keeps AI tied to value, makes the business case easier to write and builds credibility with staff, who see technology applied to frustrations they recognize.

Once you know which problems matter, you need a structured way to find specific places where AI could help. Operational excellence tools are ideal for this because they make work visible.

SIPOC for scoping

A SIPOC diagram (Suppliers, Inputs, Process, Outputs, Customers) gives a one-page view of a process. It helps the team agree on boundaries and spot where information enters and leaves. Inputs that arrive as unstructured documents, emails or images are often good candidates for AI.

Value stream mapping for pain points

A value stream map shows each step, the waiting time between steps and where information flows. Look for:

• Steps where people read, interpret or re-type information
• Decisions made by experience that could be supported by data
• Long queues caused by a single expert's availability
• Rework loops caused by errors found late
• Manual checks of large volumes where only a few items have problems

Run a discovery workshop

A two-hour workshop with frontline staff and supervisors is usually enough to build a first list. A simple agenda:

1. Walk the SIPOC and current-state map for one process (30 minutes).
2. Ask each participant to note tasks that are repetitive, error-prone or dependent on one person (20 minutes).
3. Group the notes into themes (20 minutes).
4. For each theme, describe the possible AI role and the data it would need (40 minutes).
5. Agree on who will gather baseline numbers (10 minutes).

A worked example

Imagine a wholesale food distributor mapping its order-to-cash process. The workshop surfaces these candidates:

Notice that the last item may not need AI at all; a simple notification could solve it. That is fine. Discovery should capture all improvement ideas, then sort them.

Keep a living pipeline

Record each candidate in a shared register with the problem, the process, the sponsor, the data needed and a rough idea of value. Revisit it quarterly. A healthy pipeline means you always have the next well-understood use case ready when the current one is deployed.

A good discovery workshop produces more ideas than you can act on. The next step is to score them so that the first projects are both worthwhile and achievable. The value–effort matrix is a simple, widely used tool for this, and you will use it in the lab after this lesson.

Scoring business value

Rate value from 1 (low) to 5 (high), considering:

• Hours or cost saved per year
• Revenue, capacity or customer service gained
• Quality, safety or compliance improvement
• Link to a strategic goal and an engaged sponsor

Scoring effort and feasibility difficulty

Rate effort from 1 (easy) to 5 (hard), considering:

• Data availability and quality
• Integration with existing systems
• Process change and training required
• Risk and cost of errors, including privacy concerns
• Whether proven off-the-shelf tools exist

Reading the four quadrants

A worked example

Imagine a 50-person machine shop scoring four ideas with its leadership team:

• Generative AI to draft quote cover letters: value 2, effort 1 – a fill-in.
• Automated reading of supplier packing slips: value 4, effort 2 – a quick win.
• Predictive maintenance on the CNC fleet: value 4, effort 4 – a strategic bet, because sensor data is not yet collected.
• Full AI production scheduling: value 3, effort 5 – rethink, as routing data is unreliable.

The shop starts with packing slips, and in parallel begins collecting spindle load data so predictive maintenance becomes feasible next year.

Scoring tips

• Score as a group and discuss disagreements; they often reveal hidden risks.
• Use rough numbers where possible, such as hours per week, rather than gut feel alone.
• Re-score when readiness improves. An idea that is high effort today can become a quick win once data is cleaned.

Once a use case is chosen, you must decide how to deliver it. SMEs rarely need to build AI from scratch, but each route has trade-offs worth understanding.

The four main routes

Questions to ask

1. Is this problem unique to us, or does every business in our sector have it?
2. Do we already own software with a suitable feature?
3. Who will maintain the solution after go-live?
4. Where will our data be stored and processed, and who can access it?
5. Can we export our data and configuration if we leave the vendor?
6. What will the total cost be over three years, including subscriptions, integration and staff time?

Vendor due diligence

When buying, ask vendors for a trial on your own data, not just a demo with theirs. Ask how the tool handles errors and low-confidence results, what training is included, how pricing changes with volume, and whether your data is used to train their models. For personal information, confirm how the vendor supports your obligations under Canadian privacy law, such as PIPEDA or the applicable provincial law.

A worked example

Imagine an engineering consultancy that wants help drafting proposals. The partners consider building a custom tool. Working through the questions, they realize their office suite already includes a generative AI assistant at a modest licence cost. They choose to use it, invest instead in a library of approved proposal content and prompts, and set a rule that all drafts are reviewed by a project manager. Custom development is saved for a future idea: estimating project hours from past timesheets, which is genuinely specific to their firm.

A sensible default for SMEs is to use what you own first, buy for common problems, partner for fit and build only where the problem is truly yours.

A business case turns a promising idea into a decision. For an SME it does not need to be long; two pages is often enough. What it must do is make costs, benefits, risks and assumptions visible so the sponsor can make an informed choice.

Structure of a two-page business case

1. Problem and goal – the problem statement and the strategic goal it supports.
2. Baseline – current time, cost, error rate or service level, with how it was measured.
3. Proposed solution – the AI role, the route (buy, partner, build) and the redesigned workflow.
4. Benefits – hours saved, errors avoided, capacity or revenue gained, with assumptions stated.
5. Costs – one-time setup and integration, ongoing subscription and support, and internal staff time.
6. Risks and mitigations – data, adoption, accuracy, privacy and vendor risks.
7. Pilot plan and decision criteria – scope, duration and what result will justify scaling.

A worked example

Imagine an accounts payable team at a building products distributor handling supplier invoices. The team measures a baseline of 25 hours per week of manual entry at a loaded cost of $40 per hour.

The case also notes non-financial benefits: fewer late-payment penalties and faster month-end close. It states that the 60% figure is an assumption to be tested in the pilot.

Be honest about benefits

Saved hours are only real value if they are redeployed to useful work or reduce overtime or hiring. Say explicitly what staff will do with recovered time. Also include the internal effort of setup, training and exception handling, which is often underestimated.

Show a range

Present a conservative, expected and optimistic scenario. If the project only works under the optimistic case, it is a risky bet. Later in this course you will use the automation ROI calculator to test these numbers for your own use case.

In manufacturing, poor raw material produces poor product no matter how good the machine. Data plays the same role for AI. A model learns from data, and in operation it acts on data. If either is unreliable, the results will be too.

Three ways AI depends on data

• Training data – historical records a model learns from, such as three years of sales or a library of labelled defect images.
• Operating data – the live inputs the tool uses each day, such as today's orders or a new invoice.
• Feedback data – records of whether the AI was right, such as a buyer's correction to a forecast, which allow monitoring and improvement.

Generative AI tools bought from vendors arrive already trained on general data, but they still depend on yours. An assistant that answers staff questions about procedures is only as good as the procedures it is given. If three versions of a work instruction exist, the assistant may cite the wrong one.

Map the data a use case needs

Before any pilot, list the data elements the use case requires and where each lives. A simple data inventory looks like this:

A worked example

Imagine a regional distributor planning demand forecasting. The inventory above reveals that stock-outs are not recorded. That matters: when an item is out of stock, recorded sales drop to zero, and a model will wrongly learn that demand fell. The team starts logging stock-outs and flags past periods where sales were limited by availability. This one change does more for forecast quality than any choice of algorithm.

Data readiness questions

1. Does the data exist, and has it been recorded long enough to show patterns?
2. Is it captured consistently, with the same codes and definitions over time?
3. Can it be extracted from its system without manual copying?
4. Does someone own it and feel responsible for its accuracy?
5. Does it contain personal information that needs protection?

Answering these questions early is the cheapest risk reduction available in any AI project. The following lessons show how to audit quality, assess infrastructure and govern data well.

A data quality audit is a structured check of whether your data is fit for its intended use. It does not have to be elaborate. A focused audit of the few tables a use case depends on can be done in a few days with a spreadsheet and some patience.

Six dimensions of data quality

How to run a quick audit

1. Choose the tables and fields the use case needs, from your data inventory.
2. Define a simple acceptance threshold for each dimension, for example, "at least 95% of work orders have a failure code".
3. Pull a sample or the full extract and run basic counts, filters and pivot tables.
4. For accuracy, compare a random sample with the physical world or source documents.
5. Record the results, the gap to threshold and a suspected root cause.

A worked example

Imagine a food processor wanting to predict equipment failures from maintenance records. An audit of two years of work orders finds:

• Completeness: 1,800 work orders, of which 1,080 have a failure code (60%), against a threshold of 90%.
• Consistency: the same mixer appears under four different asset names.
• Timeliness: many orders are closed in batches at month end, so repair times are unreliable.
• Accuracy: in a sample of 30 orders checked with technicians, 6 had the wrong failure code (80% accurate).

The conclusion is clear: the data is not yet fit for predictive maintenance. But the audit also gives a precise improvement list: a mandatory failure code with a short pick list, a cleaned asset register and closing orders at the end of each job.

Make the audit repeatable

Turn the checks into a simple monthly scorecard. Data quality is not a one-time cleanup; it decays unless the process that creates the data is controlled. Watching the scores improve also shows staff that their data entry matters.

Fix the process that creates the data, not just the data itself.

Good data that cannot be reached is almost as limiting as bad data. Data infrastructure is the set of systems, connections and storage that let data be captured, combined, secured and delivered to the tools that need it.

A typical SME data landscape

• An ERP or accounting system holding orders, inventory and finances
• A CRM for customers and sales activity
• Line-of-business tools: maintenance, scheduling, electronic medical records, project management
• Shared drives and email holding documents and spreadsheets
• Machine controllers or sensors on the shop floor
• Many personal spreadsheets that quietly run key processes

Infrastructure maturity levels

Key questions for your IT partner

1. Which of our systems have APIs or scheduled exports?
2. Where would an AI tool read data from, and where would it write results?
3. Is our data stored in Canada or elsewhere, and does that matter for our contracts or sector?
4. Who has access to which data, and how is access controlled and logged?
5. How are backups and security updates handled?

A worked example

Imagine a 30-person engineering office whose project hours sit in a timesheet tool, budgets in accounting software and scope in proposal documents on a shared drive. Leaders want AI to estimate hours for new projects. The infrastructure review shows that both systems have exports, but proposals use inconsistent file naming. The first step is modest: a scheduled export of both systems into a single reporting database, plus a standard proposal template with a structured scope summary. That foundation supports the estimator and also improves ordinary project reporting.

Do not over-build

SMEs do not need an enterprise data platform before the first AI project. Build the infrastructure the next two or three priority use cases require, using secure cloud services where they make sense. Each project should leave the data foundation a little stronger than it found it.

Data governance is the set of roles, rules and routines that keep data trustworthy, secure and used appropriately. For an SME it can be light, but it cannot be absent, especially once AI tools begin using personal or confidential information.

Core governance roles

Canadian privacy basics

In the private sector, Canada's federal privacy law, PIPEDA, applies to personal information handled in commercial activity, while some provinces, including British Columbia, Alberta and Quebec, have their own private-sector laws, and health information is often covered by separate provincial rules. This is general guidance, not legal advice, but the principles behind these laws are familiar and practical:

• Be clear about the purpose for collecting and using personal information.
• Obtain appropriate consent and use the information only for that purpose.
• Collect and keep only what you need.
• Protect it with safeguards suited to its sensitivity.
• Be accountable, including for data processed by vendors on your behalf.

What changes with AI

AI raises specific questions. Is customer or patient data being pasted into a public generative AI tool? Does a vendor use your data to train its models? Could a model's output reveal personal details? Is a new use of existing data consistent with the purpose it was collected for? These should be checked before a tool goes live, ideally with a short privacy impact review.

A worked example

Imagine a physiotherapy clinic that wants AI to summarize intake forms for practitioners. Before the pilot, the clinic's privacy lead confirms where the vendor stores and processes data, that the data is not used to train the vendor's models, that only clinical staff can see the summaries, and that the clinic's notice to patients covers this use. A practitioner reviews every summary before it enters the record. These steps take a few days and remove the largest risks.

Keep governance proportional

Start with a one-page data governance charter: list key data domains, name an owner for each, set basic access rules, and state how AI tools may use each domain. Review it annually or whenever a new AI use case is approved.

When a data audit shows gaps, the temptation is a one-time cleanup: someone spends a weekend correcting records. Within months the problems return, because the process that creates the data has not changed. Six Sigma's DMAIC cycle offers a better approach: treat poor data as a process defect.

DMAIC applied to data

Common root causes of poor data

• Free-text fields where a pick list would work
• Fields that the person entering data does not understand or value
• Data entered long after the event, from memory
• Duplicate entry in two systems, leading to differences
• No feedback when data is wrong, so errors are never noticed

A worked example

Imagine a fabrication shop whose job records are needed for an AI quoting assistant. The audit shows that actual hours per job are only 70% complete and often entered at week end.

1. Define: actual hours by operation for every job, at least 95% complete and entered on the same day.
2. Measure: 70% complete; median entry delay of four days.
3. Analyze: a fishbone session finds that the only terminal is in the office, operators do not see why hours matter, and the job codes list is long and confusing.
4. Improve: a tablet at each work cell, a shortened code list, a five-minute explanation at the morning huddle of how hours feed quoting.
5. Control: the supervisor checks a daily completeness report; the monthly scorecard is posted on the visual board.

After a few months the shop has reliable data, and the quoting assistant can be trained on recent jobs with confidence.

Clean the history wisely

Fixing the process protects future data. For history, clean only what the use case needs, such as the most recent two years of a key table, and document what was changed. Sometimes it is better to start training on a shorter period of good data than a longer period of poor data.

One-time cleanups treat symptoms. Process control prevents recurrence.

AI changes what people do, not just what software does. A readiness plan must know what skills exist today, which ones each priority use case needs and how to close the gap. A skills matrix, already familiar from cross-training in Lean operations, is a practical tool for this.

Four groups of AI-related capability

• Leadership capability – setting direction, judging business cases, sponsoring change and asking the right risk questions.
• User capability – using AI tools effectively, writing good prompts, recognizing poor output and following review rules.
• Process and data capability – mapping processes, managing data quality, defining metrics and redesigning workflows.
• Technical capability – configuring tools, integrating systems, managing security and monitoring performance, whether in-house or through a partner.

Building a simple AI skills matrix

List roles down the side and capabilities across the top. Rate each on a four-point scale: 0 = no exposure, 1 = aware, 2 = can do with support, 3 = can do independently and teach others.

Reading the matrix

Look for single points of failure, where only one person has a capability, and for gaps against your priority use cases. In the example, nobody internally can configure or integrate tools, so the business depends heavily on its IT partner. Process mapping strength sits with the operations manager alone.

A worked example

Imagine a 70-person distributor whose first use case is automated order entry. The matrix shows the inside sales team will be the main users, yet their ability to judge output quality is low. The plan includes a half-day training on reviewing AI-extracted orders, a clear checklist of fields to verify, and pairing each user with a "super user" who reached level 3 during the pilot.

Close gaps in the right way

1. Train for widely needed skills, such as safe tool use.
2. Develop champions who learn deeply and support colleagues.
3. Hire only when a capability is needed continuously and is strategic.
4. Partner for specialized, occasional skills such as model development or complex integration.

Revisit the matrix every six months. It becomes evidence for the skills dimension of your readiness assessment.

AI initiatives cross departmental lines. Operations owns the process, IT owns the systems, finance owns the budget and frontline staff do the work. Without clear roles, decisions stall and problems fall between chairs. A RACI chart is a simple way to make accountability explicit.

Key roles in an SME AI initiative

• Executive sponsor – owns the business outcome, approves resources and makes go/no-go decisions.
• Product or process owner – a manager who owns the process the AI supports and will live with the result daily.
• Project lead – coordinates the work, schedule and communication; may be an internal improvement lead.
• Data owner and steward – ensure the right data is available and fit for use.
• Technical lead – configures and integrates the tool, internally or through a partner.
• Super users – frontline staff who test, give feedback and coach peers.
• Privacy or risk reviewer – checks privacy, security and other risks before go-live.

A RACI for an AI pilot

R = Responsible (does the work), A = Accountable (one person who owns the decision), C = Consulted, I = Informed.

Rules for a useful RACI

• Exactly one A per activity.
• Avoid too many Cs; every consultation adds time.
• Check that the process owner is accountable for operational outcomes, not the vendor or IT.

A worked example

Imagine a home care agency piloting AI-assisted scheduling for its care workers. Initially the IT contractor led everything. After building a RACI, the agency makes its scheduling manager the process owner, accountable for the workflow and for the final schedule. Two senior schedulers become super users. The executive director is the sponsor. The change clarifies that the AI suggests schedules and the scheduling manager approves them, which also helps with trust and with responsibility toward clients.

In small organizations one person may hold several roles. That is fine, as long as each role is consciously assigned and nobody assumes someone else is handling it.

Technology projects rarely fail because the software cannot do the job. They fail because people do not adopt it, or adopt it in ways that undermine its value. AI adds particular concerns: fear of job loss, doubts about accuracy and worries about being monitored. Established change models help leaders address these deliberately.

ADKAR for individuals

The ADKAR model describes five outcomes each person needs for a change to stick:

Kotter for the organization

Kotter's eight-step approach is useful at the organizational level. For SMEs, a condensed version works well: create urgency around a real business problem, form a small guiding coalition including respected frontline voices, communicate a clear vision of how work will improve, remove obstacles, deliver visible short-term wins and anchor the new way of working in standard procedures.

Address fears directly

• Job security: be specific about what will happen to freed time. Vague reassurance damages trust.
• Accuracy: show how errors will be caught and that people retain final judgment where it matters.
• Monitoring: be clear about what the tool records and how that data will and will not be used.
• Competence: recognize that experienced staff may feel their expertise is devalued. Involve them as designers and testers.

A worked example

Imagine a 45-person manufacturer introducing AI vision inspection. The quality inspectors are anxious. The plant manager meets them early, explains that defect escapes to customers are the problem, and commits that inspectors will move to root-cause analysis and supplier quality work. Inspectors label the training images, set the rules for when parts are sent for human review, and present early results at a plant meeting. Adoption is strong because the people most affected helped shape the change.

Use an ADKAR check during your pilot: ask super users where each colleague is on the five elements and target support at the first element that is missing.

Generative AI tools are now inside many products staff already use, and many people try public tools on their own. An organization is therefore using AI whether or not leaders have planned it. AI literacy and a clear acceptable-use policy turn this informal use into a safe, productive capability.

What AI literacy means for staff

• Understanding broadly how generative and predictive tools work, and that they can be confidently wrong
• Writing clear prompts with context, constraints and examples
• Checking outputs for accuracy, especially facts, numbers, citations and calculations
• Knowing which data may and may not be entered into which tools
• Knowing when human judgment must remain in control

Elements of an acceptable-use policy

A traffic-light approach

Many SMEs find a simple three-tier rule easy to communicate:

• Green: public or non-sensitive content in approved tools, such as drafting a generic job advertisement.
• Amber: internal business information in approved enterprise tools, with review before use.
• Red: personal health information, client confidential data or decisions about individuals, which need a specifically approved solution and process.

A worked example

Imagine a 25-person engineering office. Leaders discover that several staff use free chatbots to polish reports. Rather than banning AI, they license an enterprise assistant with data protections, issue a two-page policy with traffic-light rules, run a 90-minute training session with examples from real project work, and nominate two champions who share good prompts in a monthly lunch session. Use becomes visible and safer, and good practices spread.

Keep it alive

Review the policy every six months, as tools change quickly. Collect examples of good and poor use and fold them into training. Literacy is not a one-time course; it is a habit of thoughtful use.

Governance is how an organization makes sure AI is used in ways that are effective, safe, fair and accountable. Large enterprises may have AI committees and dedicated staff. An SME needs something lighter, but it still needs clear decision rights, a risk review and ongoing oversight.

Useful reference frameworks

Several established frameworks can guide your approach without being adopted in full. The NIST AI Risk Management Framework organizes activity into four functions: govern, map, measure and manage. ISO/IEC 42001 sets out requirements for an AI management system. In Canada, the federal government has published a voluntary code of conduct for organizations developing and managing advanced generative AI systems. Borrow the principles that fit your size and risk.

A simple AI risk register

Tiering by impact

Not every use case needs the same scrutiny. A practical approach classifies each one:

• Low impact: internal drafting or summarizing with human review. Light approval by the process owner.
• Medium impact: outputs that affect customers, costs or operations, such as forecasts or quote drafts. Risk register, defined review rules and sponsor approval.
• High impact: outputs affecting people's health, safety, employment, credit or legal rights. Full risk review, human decision-making retained, and specialist advice where needed.

Human in the loop

Decide explicitly where a person reviews, approves or can override AI output. Common patterns are reviewing everything during a pilot, then moving to reviewing only low-confidence or high-value cases once performance is proven.

A worked example

Imagine a staffing agency considering AI to rank job applicants. Its governance review classifies this as high impact, because it affects people's employment. The agency decides that AI may help summarize résumés against posted requirements, but recruiters make all shortlisting decisions, outcomes are reviewed periodically for unfair patterns, and candidates are told AI assists the process. A lower-impact use, drafting job advertisements, is approved quickly with simple review rules.

Keep a short AI register listing each tool in use, its owner, impact tier and review date. It becomes the backbone of your governance readiness.

If you cannot measure an AI initiative's effect, you cannot defend it, improve it or decide whether to scale it. Good metrics connect the technical performance of a tool to the operational and financial results the business cares about.

Three levels of metrics

All three are needed. A forecast model can be accurate, yet if buyers ignore it, inventory will not improve. Equally, a business outcome can improve for unrelated reasons, so tool and process metrics help show cause.

Leading and lagging indicators

Lagging indicators, such as annual savings, confirm results but arrive late. Leading indicators, such as the share of orders processed through the new workflow, signal early whether results are likely. Track both.

Setting good metrics

• Define each metric precisely: formula, data source, frequency and owner.
• Measure a baseline before the pilot using the same definition.
• Set a target and a minimum acceptable level for go/no-go decisions.
• Include at least one guardrail metric to catch harm, such as error rate or customer complaints.

A worked example

Imagine a distributor deploying AI to extract order details from emailed purchase orders. Its metric set:

• Tool: field-level extraction accuracy; baseline not applicable; target at least 97%.
• Process: minutes of staff time per order; baseline 6 minutes; target 2 minutes.
• Process: share of orders going through the new flow; target 80% by month three.
• Business: order errors reported by customers per 1,000 orders; baseline 8; target 4.
• Guardrail: same-day order cut-off met; must not fall below baseline.

With about 1,500 orders a month, saving 4 minutes each frees about 100 staff hours monthly. The team uses the automation ROI calculator to convert these figures into annual savings and payback, then checks them against actual results each month.

Report simply

Put the metrics on a one-page visual board or dashboard reviewed at a regular operations meeting. Metrics that are seen and discussed drive behaviour; metrics buried in a report do not.

A pilot is a controlled test of whether an AI solution works in your real environment and is worth scaling. Designed well, it produces a clear decision. Designed poorly, it produces a nice demonstration and a stalled project.

The pilot charter

Write a one-page charter before starting. It should include:

• Objective: the problem and the question the pilot must answer.
• Scope: which process, location, product line or team, and what is out of scope.
• Duration: typically six to twelve weeks, long enough to see normal variation.
• Metrics: baseline, target and minimum acceptable values.
• Roles: sponsor, process owner, project lead, super users and technical support.
• Risk controls: human review rules, fallback to the old process, privacy checks.
• Decision criteria: what result means scale, adjust or stop.

Use PDCA inside the pilot

1. Plan: configure the tool, redesign the workflow, train super users.
2. Do: run on real work at a controlled volume.
3. Check: review metrics and user feedback weekly; analyze errors by type.
4. Act: adjust prompts, rules, training or workflow, and repeat.

Go/no-go criteria

Stopping is a legitimate, valuable result. A pilot that shows an idea will not work, at modest cost, has saved the business from a larger failure.

A worked example

Imagine a clinic piloting AI to draft referral letters from practitioners' notes. The charter limits scope to one practice area and eight weeks, with every draft reviewed. The target is to cut letter preparation time in half, with a guardrail of zero clinically significant errors reaching the final letter. Weekly checks show time savings on track, but drafts often miss medication details. The team adjusts the template prompt and adds a checklist item. By week eight, targets are met and the sponsor approves rollout to two more practice areas.

Pilot with production in mind

Use real data, real users and, where possible, the real integration path. A pilot that relies on hand-cleaned samples or a separate tool nobody will use in production cannot answer the go/no-go question honestly.

A successful pilot proves that a solution can work. Scaling makes it part of how the business runs every day: integrated, supported, monitored and improved. This step is where many organizations underestimate the effort.

What changes when you scale

The control plan

Borrowing again from Six Sigma, a control plan keeps performance from slipping after handover. For each key metric it lists the target, how and how often it is measured, who reviews it and what action follows if it goes out of range.

Monitoring AI after go-live

AI performance can change over time even if nothing in the software changes. Customer mix shifts, new products appear, suppliers change document formats. This is often called drift. Monitor:

• Tool accuracy on a regular sample of reviewed cases
• The share of cases sent to human review or overridden
• User feedback and reported errors
• Business outcomes against the original business case

Set a trigger, for example "if more than one in ten extractions need correction for two weeks running, the process owner and vendor review the configuration".

A rollout sequence

1. Update standard work, training and the RACI for production roles.
2. Complete production integration and security checks.
3. Roll out in waves by team or site, with super users supporting each wave.
4. Retire old workarounds and duplicate processes once each wave is stable.
5. Hand over to the process owner with the control plan in place.
6. Review results against the business case at three and six months.

A worked example

Imagine a manufacturer scaling vision inspection from one line to four. The plant updates inspection procedures, trains operators on each line, and sets a weekly review of false rejects and escapes. On the third line, a different paint supplier causes a rise in false rejects. Because monitoring is in place, the team notices within days, adds new labelled images and restores performance.

Build reusable capability

Each scaled use case should leave behind reusable assets: cleaner data, integrations, templates, trained champions and governance routines. That is how an SME moves from one-off projects to a repeatable AI capability.

You now have the building blocks of AI readiness: a framework to assess where you stand, tools to find and prioritize use cases, methods to audit and fix data, approaches for people and change, and the governance, metrics and pilot discipline needed to scale. The final step is to turn them into a practical plan.

A 90-day structure

Plan for the weakest dimensions

Return to your readiness assessment. For each dimension scoring 1 or 2, write one action that will lift it by one level within 90 days. Keep actions small and specific, such as "name data owners for sales and inventory data" rather than "improve data governance".

A worked example

Imagine a 55-person industrial distributor. Its assessment scores governance at 1, data quality at 2 and use-case pipeline at 2, with stronger culture and infrastructure. Its 90-day plan:

• Week 2: issue a two-page AI acceptable-use policy and an AI register.
• Week 4: run a discovery workshop on order-to-cash; build the pipeline.
• Week 6: score eight ideas; choose order extraction as the quick win and demand forecasting as the strategic bet.
• Week 8: complete a data audit on sales history; begin logging stock-outs.
• Week 9: approve the business case and pilot charter for order extraction.
• Weeks 10–13: run the pilot with weekly reviews; reassess readiness at day 90.

Keep the cycle going

1. Reassess readiness every six months and compare the radar chart shape.
2. Refresh the use-case pipeline quarterly.
3. Review the AI register and policies at least twice a year.
4. Share results openly, including stopped pilots and lessons learned.

Readiness is not a gate you pass once. It is a capability you build with every use case.

Complete the final exam to earn your Chmltech certificate of completion. Then put the first two weeks of your plan on the calendar today, while the ideas are fresh.