A compelling AI demonstration is not evidence that an organization can operate the solution at scale. The model may work in a controlled pilot while the surrounding business system remains unprepared: processes vary, data ownership is unclear, teams do not know who approves changes, integrations are fragile, and no one is accountable for support after launch.
That gap explains why technical promise can fail to become repeatable business impact. Before leaders ask which AI product to buy, they should ask a more demanding question: Are we ready to make this capability work reliably inside everyday operations? A practical AI readiness review brings that question into the operating model—where value, process, technology and people must meet.
AI readiness is an operating-model question
AI is often managed as a technology acquisition: select a use case and platform, launch a pilot and present the results. Scaling exposes what the pilot avoided. Real users handle exceptions, source data changes, compliance becomes concrete and support teams receive unfamiliar incidents.
Ivan Stefanovic’s public LinkedIn reflection highlights this challenge: AI ambition can move faster than the processes, roles, data ownership, governance and support needed to sustain it. Experimentation should reveal those gaps before investment and dependence grow.
A Lean view treats technology as one element of a value stream. Analyze the customer need, information flow, decision, human action, exception and feedback loop. AI is ready to scale only when that whole system can deliver and improve the intended outcome.
The seven-part AI readiness checklist
The following framework can be used before a pilot, at a scale gate or when an existing initiative is stalled. It is not a certification or a universal maturity score. It is a structured management conversation designed to make assumptions visible.
| Readiness dimension | Question leaders must answer | Warning signal |
|---|---|---|
| Business value | Which measurable customer or operational problem will improve? | The case is built mainly around the novelty of the technology |
| Process | Where will AI change the flow of work and decisions? | The current process has no owner or stable baseline |
| Data | Who owns data quality, access and meaning? | Critical limitations appear only during model development |
| Governance | Who may approve, monitor, override or stop the solution? | Accountability is spread across committees |
| Technology | Can architecture and integration support reliable operation? | The pilot depends on manual transfers or temporary access |
| People | How will roles, skills and standard work change? | Training is planned only after deployment |
| Support and learning | How will incidents, drift and improvement be managed? | No team owns the solution after the project closes |
1. Business value: start with a problem, not a feature
Define the target condition in business terms: shorter response time, fewer defects, better forecasts or less repetitive work. Name the customer, baseline, improvement direction and potential harm. If leaders cannot describe the problem without mentioning AI, the initiative may be technology-led.
2. Process: understand the work AI will enter
Map the current flow at the gemba: inputs, handoffs, decisions, exceptions, rework and waiting. Show where an AI output appears, who uses it and what action follows. Automating ambiguity can increase speed without improving flow.
3. Data: establish ownership and fitness for use
Data readiness is more than availability. Teams need agreed definitions, provenance, access rules, quality expectations and an owner who can resolve issues. Test whether data represents real operating conditions and important exceptions—not only a clean historical sample.
4. Governance: make decision rights explicit
Clarify who sponsors the outcome, owns the process, accepts risk, approves deployment and monitors performance. Define the boundary between recommendation and automated action. Escalation and stop conditions must exist before an adverse event.
5. Technology: design for production, not presentation
A prototype can tolerate manual steps that fail at scale. Review integration, access, latency, resilience, observability, version control and vendor dependence. Ask how updates will be tested and rolled back, and whether the complete service can handle real volume and variation.
6. People: redesign work with the users
AI changes tasks, judgment and accountability. Involve frontline users early. Define standard work for accepting, questioning and overriding an output, and build capability for routine use and exception handling. Adoption is a design requirement, not an end-stage campaign.
7. Support and learning: plan the life after launch
Every scaled system needs an owner, service expectations and a feedback loop. Decide how users report problems, who triages them, how drift is reviewed and how improvements enter a controlled backlog. Connect technical measures with operational outcomes.
Use a scale gate, not a perfect-readiness gate
No organization will be fully ready before learning begins. The goal is to expose and manage uncertainty. Rate each dimension with a simple status:
- Green: ownership, standards and evidence are sufficient for the next level of use.
- Amber: a known gap exists, with an owner, countermeasure and deadline.
- Red: the gap could undermine value, control or reliable operation and has no credible countermeasure.
A bounded pilot may proceed with amber items. Scaling should pause when a red condition affects critical data, accountability, safety, compliance or support. The gate must produce actions, not a decorative score.
A practical 30-day readiness sprint
- Frame: agree the business problem, target condition, scope and process owner.
- Observe: map the real workflow and interview the people who handle normal work and exceptions.
- Assess: review the seven dimensions with evidence, not optimism.
- Prioritize: select the few gaps that could prevent learning or safe operation.
- Experiment: run a bounded test with users, explicit controls and a review cadence.
- Decide: scale, revise, hold or stop based on operational and customer evidence.
The pilot should test whether the organization can create value, not whether AI is impressive. Stopping can be a good result when it prevents a larger investment in the wrong problem.
Questions for the management team
- Can we state the business problem and baseline without referring to the chosen tool?
- Is one person accountable for the end-to-end operational outcome?
- Do process users understand how their work and judgment will change?
- Are data definitions, quality ownership and access decisions explicit?
- Can we explain when a human must review or override an output?
- Does the production design remove the manual workarounds used in the pilot?
- Who supports, monitors and improves the service after deployment?
- What evidence would make us pause, redesign or stop?
AI scale is not the multiplication of pilots. It is the creation of a repeatable operating capability. When leaders treat AI readiness as a cross-functional system, they can invest with clearer priorities, learn faster and avoid shifting unresolved organizational problems into technology.
Frequently asked questions
Does AI readiness require perfect data?
No. It requires known limitations, clear ownership and data that is fit for the specific use. A bounded experiment can help improve data, but leaders should not scale a dependency they cannot monitor or govern.
Who should own an AI readiness assessment?
The business or process owner should be accountable for the outcome, with active participation from data, technology, risk, security, operations and frontline users. Delegating the assessment entirely to IT leaves essential operating-model questions unanswered.
When should an AI pilot be stopped?
Stop or redesign when the use case lacks meaningful value, critical risks cannot be controlled, necessary data is not fit for use, or the organization has no viable ownership and support model. Stopping is learning when the decision is evidence-based.
Source and further reading
This article develops the operating-model insight shared by Ivan Stefanovic in his public LinkedIn post, AI Readiness Trumps Technological Appeal for Success. For a related perspective on organizing for effectiveness, read his Lean Community article Strategic Strategy: Organization Design.
Illustrative photograph. Photo: Taylor Vick / Unsplash.
He has more than 15 years of experience in organization design, organizational changes, business process design & improvement, strategy development, and performance management. His work spans different industries, such as banking, oil & gas, gaming, and telco. Besides the profit sector, Ivan has been working with the government and non-profit sectors as well.
Ivan holds a BSc and MSc in Management, as well as a PhD in Strategy and organization from the University of Belgrade, Faculty of Organizational Sciences. He is a Certified Lean Six Sigma Black Belt, Certified Business Architect, Certified Performance Management Professional, and Change Management Practitioner.
