Processes: process is not sacred|INEMA.CLUB-PRO

Lesson 7 · 15 min

A process with a version

At Horizonte, the process changes when someone complains loudly: a scare created the check of every order, and nobody wrote down when or why. Software does not change like that. It has a version number, a record of each change, and a tested way to go back. In this lesson you treat the process the same way and record the move from version 1.0 to 2.0.

Start the lesson
In a meeting room, a screen shows two colored block diagrams side by side, the one on the left longer; a woman holds a sheet with a checkbox and the team listens.

In this lesson you will

  1. 1Give the process a version number
  2. 2Turn a complaint into a proposal, not a change
  3. 3Promote step by step, with approval from whoever is accountable
  4. 4Write the trigger and the way back first

Objective: record the process change v1 → v2 with the reason, evidence, approver, phased rollout, and the way back, the way it is done with software.

01The cycle of a version

From the version in use to the next one, with the way back written down. Click each step.

Click each block of the diagram to see what it does.

Rule 3 of the agentic process (AI Management area): promoting and rolling back are steps, not accidents. LOOP-R cycle and the change contract of the Gestoria method (INEMA).

02Versioning in practice

Four rules. Horizonte is a fictional study company; the dates and decisions in the example are fictional too.

1. Number and history

Give the process a number. A change that cuts, moves, or merges a step bumps the whole version (1.0 to 2.0). An adjustment that doesn't touch the steps, like changing the deadline for a reply, bumps the decimal (2.0 to 2.1).

Keep a one-line history per version: number, date, what changed, why, who approved. It's what answers, six months from now, why the process is the way it is.

At HorizonteThe check of every order went in on 10/14 with no record. In the new history, it shows up as part of v1.0, with the reason Patrícia remembered: the improper discounts that week.

03Templates to copy: change record and version history

The record follows each change; the history has one line per version. The tabs show Horizonte.

Change record (v1 → v2)
CHANGE RECORD · process: <...> · from v<1.0> to v<2.0> · no. <001>

OBSERVED PROBLEM: <what happens> · source cases: <ids>
HYPOTHESIS: if <change>, then <indicator> improves without worsening <guardrail>
WHAT CHANGES: <steps eliminated, simplified, moved, merged> (redesign sheet attached)
PROPOSED BY: <name> · APPROVES: <name, different from who proposed>

EVIDENCE
  Baseline (v<1.0>): <indicators and values, period>
  Test (v<2.0>): <scope> from <date> to <date>
  Result: <values in the same format> · limitations: <...>

PHASED ROLLOUT
  Phase 1: <scope> starting <date> · approved by <name> on <date>
  Phase 2: <all cases> starting <date> · approved by <name> on <date>

ROLLBACK
  Trigger: <indicator> worse than <value> for <period>, or <guardrail event>
  Who decides: <name> · within how long: <...>
  How to go back: <steps, who does each one>
  Previous version kept at: <where>

DECISION: [ ] promote  [ ] reject  [ ] wait for more data · reason: <...> · <date>
Process version history
HISTORY · process: <...> · owner: <name>

| Version | Date | What changed | Why (problem and evidence) | Approved by | Status |
|---|---|---|---|---|---|
| 1.0 | <date> | version mapped (as it was) | <...> | <name> | <in use / kept> |
| 2.0 | <date> | <...> | <...> | <name> | <in testing / in use / rolled back> |

Rule: cutting, moving, or merging a step = a whole new version; an adjustment that doesn't touch the steps = decimal.
Prompt · review the change record
You are a process auditor. Below is the record of a process change in my
company. Don't decide whether the change is good. Point out:

1. Whether the problem has source cases or is just an impression.
2. Whether the hypothesis says which indicator improves and which one can't get worse.
3. Whether the person who approves is different from the person who proposed.
4. Whether the rollback trigger has a number and a deadline, and whether the steps
   to go back say who does each one.
5. What would be missing for someone, six months from now, to understand this change.

Record:
"""<paste>"""
Simulation: illustrative example

Change no. 001 · WhatsApp order → invoice · v1.0 → v2.0 · Horizonte, fictional study company

  • Problem: orders come back from billing because of incomplete registration and go through 4 handoffs (cases P1 to P5).
  • Hypothesis: by cutting the handoffs, checking only exceptions, and moving registration to intake, the time to invoice and the returns drop, with no discount outside the policy.
  • Proposed by: Patrícia · approves: Carlos.
  • Evidence: four-week baseline counted in the app and the ERP before the change; test in phase 1, for two weeks.
  • Phases: 1) registered customers with orders up to R$ 5k; 2) all orders.
  • Rollback: returns above the baseline for two weeks in a row, or one order with a discount outside the policy. Patrícia decides within one business day. Steps: Juliana goes back to copying into the spreadsheet and printing; Rafael turns off the automatic handoff to the ERP; finance goes back to typing it in. v1.0 is kept in the process folder.

04Practice

Horizonte's record is for practice; your process's record is for real.

1 · Horizonte's v1.0 → v2.0 record

20 min

Use the redesign sheet from lesson 4, the chart from lesson 5, and the indicator sheets from lesson 6. Fill in the change record and the history without looking at the tabs. Run the review prompt and fix what it points out.

Done when: the record has a problem with source cases, a hypothesis with an indicator and a guardrail, an approver different from whoever proposed it, 2 phases with a scope, 2 rollback triggers with a number and a deadline, and the steps back with who does each one; the history has the 1.0 and 2.0 rows.

2 · Your process record

30 min

Make the change record from the current version of your process to the redesigned one, and the history. Agree with whoever approves it before you start phase 1.

Done when: the record is complete, with the baseline from lesson 6 as starting evidence, the approver agreed in writing, the date for phase 1, and the current version saved somewhere another person can find it.

05Quick test

4 questions. The explanation appears after your attempt.

Question 1 of 4

An important customer complained about a delay. The owner wants to create a new check right away. What does a versioned process call for?

06Summary

Number and historyStep changed, whole number; adjustment, decimal. One row per version.
Proposal before changeSource case, hypothesis, test against the baseline.
Phases and approvalPilot scope first; whoever answers for it approves, never whoever proposed.
Way back written beforehandTrigger with a number, steps with names, previous version saved.

To go further

LOOP-R: guide to the improvement loop with a record and a back buttonLOOP-R: course for owners and managersAI Management Area: rule 3, promoting and rolling back are steps
Previous lessonNext lesson