What is in a connected model of your business?

More than process diagrams. It holds the processes, the steps and decisions inside them, the people who perform them and the seats they sit in, the systems and data each step touches, the material every statement was read out of, the controls that govern the work, and the changes you are considering. Most of all, the connections between them, because the connections are what answer questions.

This is the object model Omni works in, for technical evaluators.

The core, and what grows around it

This is the centre of the model: the work, the people who do it, the systems it runs on and the controls over it. Every object is linked to the objects around it, and the evidence, opportunity, delivery and value records below attach to this same centre. A question about any one of them is answered by following the connections to the rest.

What each object means

Five groups, one model. Nothing here is a separate module you buy: an AI system is governed by the same controls that apply to the process it runs inside, and the case for a change is argued from the same records the work is described in.

How the work runs

The operating picture: what happens, who does it, and what it runs on.

Process: A piece of work with a beginning and an end, like onboarding a customer or closing the month.
Step: One action inside a process: who does what, with which system, in what order.
Decision: A point where the work branches, with the outcomes each branch leads to.
Person or role: Who performs each step, and the function they perform rather than their job title. The model knows which steps depend on which people.
Position: A seat somebody decided should exist, held apart from the person in it, so a vacancy is something the model can show rather than an absence you have to notice.
System: The application a step runs in, so system dependencies are visible per step, not guessed.
Data object: The information a step produces or consumes: a claim, an invoice, a report.

What the model is built from

Every statement in the model can be traced back to the material it came from.

Source: A piece of material you handed over: a document, a pasted note, a wiki page, a recorded capture. Held as given, and withdrawn rather than deleted, because things point at it.
Claim: One statement read out of a source, carrying the exact words it came from and what kind of statement it is: how the business works today, what somebody intends, or what a vendor merely proposed.
Requirement: Something the business is committed to, written as the obligation it places on the work, with a permanent identifier that travels all the way to the delivery ticket.

What could change

Possibility, design and the case for acting, each a record rather than a slide.

Opportunity: An identified chance to improve, cited to the signals that raised it, and sitting at the stage the records prove: identified, designed, justified, in build, delivered or measured.
Horizon: Something observed outside the business that may matter: a vendor changing direction, a regulation on its way, recorded with its sources and an honest read on how strong the signal is.
Scenario: A proposed future state: what is replaced, retained, rewired, or eliminated, before you commit.
Business case: The financial argument for a change, built from named assumptions that each declare how well founded they are, with the derivation of every figure kept alongside it.

What it is worth

What you are aiming at, what is at stake, and what actually landed.

Goal: What the organisation is trying to achieve, with its own definition of done and a history of status reports rather than a single colour.
Value driver: What is at stake in one place: the outcome, the lever, where it starts, where it should get to, and what a unit of it is worth.
Benefit: The value a change is expected to deliver, measured against a baseline set before the work starts, and then recorded month by month as it actually lands.

What holds it to account

Governance as records in the same model as the work, not a separate binder.

Control: A rule about how work must be done, connected to the processes it applies to and the evidence behind it.
Policy: A position the organisation has taken, owned by somebody, with a review date the model can tell you has passed.
Risk: Something that could go wrong, with its severity and the controls standing between it and the work.
AI system: One use of AI, not one AI product: its purpose, its risk classification, who oversees it and what was approved. Two uses of the same model are two entries.

How the objects connect

Object	Connection	Linked to
Process	contains	Steps and decisions
Step	is performed by	A person or role
Step	uses	A system
Step	produces or consumes	Data objects
Control	applies to	Processes
Control	is backed by	Evidence, or visibly nothing
Scenario	proposes changes to	Processes and systems
Benefit	is attached to	A scenario, and measured against a baseline
Claim	is quoted from	A source, word for word
Requirement	is earned from	Claims, and carried into delivery tickets
Opportunity	is raised by	Signals in the model, and answered by a scenario
Business case	argues for	A scenario, using value drivers and reference figures
Position	is held by	A person, or nobody, which is a vacancy
AI system	is governed by	Controls, policies and a recorded approval

The connections are why coverage checks work: when a scenario replaces a process, every step, system, person, and data object in it must be accounted for in the future state, carried through, migrated, or consciously dropped with a reason. Nothing can be silently lost, because everything is linked.

See the model built on your own operation

A demo isn’t a slide deck. We show you your own operation: your processes, systems, and people connected, so you can ask it the questions you cannot currently answer.

Book a demo