Skip to main content
The operating model is not a read-only picture drawn once. Every altitude owns and improves processes at its own scope, so keeping the map true to how work actually happens is part of the job. This page covers how you make changes, and what happens when you want to change a process you run but do not own.

​
Own, run, or view

What you can do to a process depends on your relationship to it.

Own it

You are the process or unit owner. You can edit directly: change steps, dispositions, targets, and KPIs.

Run it

You perform a process whose definition is owned above you. You can suggest changes, which the owner reviews.

View it

Everyone in your organization can read the whole map, whether or not they own the process.
This mirrors how a company really works. A senior leader may own the definition of a sales process that dozens of teams run, while each manager owns the smaller processes local to their team. See ownership and governance for how ownership is assigned.

​
Editing a process you own

If you own a process, you can edit it in place. Editing follows the same inline style as the rest of the platform: click a name or description to edit it, and use the disposition and platform pickers on each step.
1

Open the process

From your unit cockpit or the map, open the process you want to change.
2

Adjust the steps

Add, rename, reorder, or remove steps to match how the work really runs. Keep it coarse: aim for 5 to 15 steps.
3

Set current and target dispositions

For each step, set how it is done today (current) and where it should head (target). The gap you create is what surfaces the step in the redesign backlog.
4

Add detail where it helps

Flag a step as a constraint, set its coordination burden, note the platform, owner, volume, and any risk or escalation notes.
5

Keep KPIs current

Update the process KPIs so the baseline, current, and target values reflect reality. This is what proves a redesign is working.
Setting a target disposition is the single most valuable edit you can make. It turns a static description of today into a plan, and puts the step on the backlog for delivery.

​
Suggesting a change to a process you run

If you run a process whose definition is owned by someone else, you do not edit it directly. Instead you suggest a change, and the owner reviews it. This keeps a single, trusted definition while still capturing ground truth from the people closest to the work.
1

Make your change as a suggestion

Edit the step or process as you normally would. Because you do not own it, your edit is captured as a suggestion rather than applied straight away.
2

The owner is notified

Your suggestion is routed to the process owner’s review queue as a proposed change, with a clear before and after.
3

The owner decides

The owner can accept your suggestion, adjust it, or reject it. If accepted, it becomes part of the live process.
This propose-then-approve flow is the default. Your organization admin can grant direct-edit rights to specific people where a team prefers to move faster. See ownership and governance.

​
Reviewing suggestions on processes you own

If you own processes, proposed changes from the people who run them appear in your suggestions queue. Each one shows exactly what would change. Accept it to apply it, adjust it first, or reject it with the reasoning captured. Nothing changes your process without your say-so.

​
Revision history and revert

Every process and unit keeps a revision history: who changed what, and when, with a field-by-field record of each change. Changes made by your team, by your Kowalah partner, or by the system are all attributed. If a change was wrong, you can revert it in one click and the map returns to its previous state. This makes the map safe to keep current. There is no penalty for editing, because nothing is ever lost.

​
What’s next

From map to delivery

Turn a redesign gap into a real Opportunity and Deliverable

Ownership and governance

How ownership, editing, and suggestions are governed