Change projects
Plan larger changes with to-be versions, impact checks and approvals.
A change project is how you change processes together, like a branch and a pull request in software. A new ERP, a new returns flow or a reorganisation usually touches several processes. In a project you work on to-be versions of them while everyone keeps using the live processes. When the project is ready, its changes go live together.
When to use a project
- Edit a process directly for small changes to one process: a new step, a corrected role, a clearer description. Publish it with a note, and the history records it.
- Use a project when a change touches several processes, needs to be checked against the processes around it, or must go live on a given date.
Starting a project
Choose Projects in the sidebar, then New project. Give it a name, and optionally a goal and a planned go-live date. Open projects also show in the sidebar under Active projects.
Or start from a process: open it and choose Start a change. Pick an open project or start a new one; the process gets a to-be version in it.
What a project holds
A project holds only what it changes:
- Changed processes: each gets a to-be version, a copy of its published version. Open it with Edit to-be and change it like any process: steps, roles, systems, links, ISO clauses, KPIs and risks.
- New processes: they exist only in the project until it goes live.
- Retired processes: marked to be retired when the project goes live, not changed.
Add them under Add to the project: choose a live process and Change it or Retire it, or type the name of a new process. A link from a to-be version to a process that doesn't exist yet adds it to the project as a new process.
While a project works on a process:
- The live process shows a banner, Being changed in the … project, so others know a new version is coming. If two projects change the same process, the banner names both, so the teams can coordinate.
- A to-be version shows To-be version in the … project, with a link to the live version.
- To-be versions and new processes stay out of the landscape, the process list, search and the gap checks until they go live. They can't be published on their own: they go live with the project.
Impact checks and findings
As you edit the to-be versions, Steplane checks the project against the processes around it, the way they'll be after go-live. Within the project, changes are checked against each other: if one to-be stops producing an output and another stops needing it, that's fine. Impact on the project page lists what it finds:
| Finding | Severity |
|---|---|
| An output another process takes in is no longer produced by any process | Warning |
| A process links to, or runs, a process the project retires | Warning |
| An ISO clause is no longer covered by any process | Warning |
| A system is removed, but a subprocess the process runs still uses it | Worth a look |
| A KPI is removed | Worth a look |
| The usual gaps in the to-be and new processes, such as a step without role | As usual |
Each finding names the process it's about; that process's owner owns it. Fix what you can in the to-be versions, and the finding goes. If the project can go live with it anyway, choose Accept risk… and say why; the note stays with the project for reviewers and auditors. Reopen undoes that. Open warnings block go-live; findings worth a look don't.
Some problems no rule can see, such as "the new returns flow skips the quality check, but Complaints assumes every returned item was inspected". Add them with Add a finding, or ask Claude to analyse the project: it reads the to-be versions and the processes connected to them, and adds what it finds.
Compare next to a changed process shows its live and to-be versions side by side, with added, removed and changed steps marked, as in the history.
Keeping to-be versions up to date
Someone may change and publish a live process while your project works on its to-be version. Swapping the to-be in later would then lose that change, because the to-be was copied before it. So the project page marks such a to-be Out of date, and the to-be version's own page says so too.
Choose Out of date to see exactly what changed in the live process since the copy. Copy what applies into the to-be version, or decide it doesn't apply, then choose Reviewed. The project can only go live once no to-be is out of date.
Approval
If your organization has approvers (Settings → Approvals), marking a project Ready for review asks them to approve each changed and new process in it, in order: for example its owner, then the Quality manager. The project page shows where each one stands, and the approvers find it in their inbox. Editing a to-be version starts its approvals over.
Going live
Go-live on the project page lists what still stands in the way:
- the project is Ready for review
- no to-be version is out of date
- no live process has unpublished edits that going live would overwrite
- every changed and new process is approved (if your organization has approvers)
- no open warning in the impact checks (fix it, or accept it as a risk)
When everything is ticked, choose Go live… and add a note for the history if you like. Everything goes live together: each to-be version replaces its live process, new processes are published, and retired ones are retired. Each gets a new revision, marked Project go-live, and the old versions stay in the history.
Reverting a project
If a project that went live turns out wrong, Revert project… puts every process it changed back as it was before go-live, as new revisions. Processes it added are retired, and processes it retired are restored. If one of them has changed again since go-live, revert that process on its own first.
Status
A project is Planning while you work on it, In review when it's ready to be checked and approved (Ready for review; Back to planning reopens it), Live once it has gone live, and Reverted if it was put back. Cancel project discards its to-be versions and new processes; the live processes never changed.
With Claude
Claude can start projects, add processes to them and edit the to-be versions, for example: "Start a project for the new ERP, change Goods receipt and Purchasing in it, and replace the old ERP with SAP in their steps." Claude tells you the to-be versions to look at, and nothing changes for others until the project goes live.