Play 1: Model the Operating Reality
Give AI the map before you give it the keys
Play 1: Model the Operating Reality
Goal: a connected model of how the enterprise actually runs, that people and AI can both read.
Why first
Every later play depends on this one. Connecting systems without a model just moves data around. Opening AI to the enterprise without a model hands it fragments. Putting agents on jobs without a model means each agent invents its own idea of the business.
What to model
Start with the minimum viable operating model — enough to answer the questions leaders actually ask, and no more:
- Direction: strategic themes, bets, objectives and key results.
- Work: the initiatives, products and value streams that carry the strategy.
- Money: budgets, forecasts and actuals at the level decisions are made.
- People: teams, owners and the capacity behind the work.
- Technology: the applications and capabilities the work runs on.
- Rules: the standards, controls and obligations that apply.
- Decisions: what was decided, by whom and why.
Use a reference model so you're not starting from a blank page, then shape the last mile to how your company actually talks and works. Keep your own names; keep the standard structure underneath so frameworks and benchmarks still apply.
How to run it
- Pick one question that matters. "Where is our technology spend going, and is it serving the strategy?" or "Which initiatives are at risk, and what do they put at risk?" Model what that question needs.
- Model in conversation, refine by hand. Modern tools let you describe how the business works and have AI propose the objects, relationships and fields. Use that to move fast, then have an owner review and refine.
- Name an owner for every part of the model. A model nobody owns decays into a plausible, wrong picture.
- Write down the decision rights. For each kind of decision in scope, who owns it and who must be consulted.
Outputs
- A working operating model for the first domain.
- An owner for each object type and each key relationship.
- A short list of decisions, with their owners.
Signs it's working
- Leaders can answer the question that started it from the model, not from a deck.
- Two people asking the same question get the same answer.
Pitfalls
- Modeling everything. Ontology bloat kills adoption. Model what decisions need; leave the rest as attributes, tags or documents.
- Modeling the org chart instead of the work. The reporting line is one relationship, not the model.
- Doing it once. The model has to change as the business changes — see Play 7.