Skip to content
Is2Be

Where do I start?

Describe where you start and find the row that fits best: each route shows which steps to follow, in what order and where you decide. Not every project uses every step. Pick your kit’s tab; if the new process needs software, the process route ends where the software route begins.

Describe your situation and find the closest row. Each route gives the mode, the artifacts in order (with their prompt) and the phase gates, which are the human decisions. A route is a proposal: conditional artifacts (⚠) depend on the roadmap’s applicability matrix: each step states, in its fit (encaje), in which modes it is mandatory, conditional (and on what condition) or not applicable.

1. Pick the mode

Section titled “1. Pick the mode”
Your situation Mode
“We have a process that works badly (slow, costly, error-prone or complained about) and we want to redesign it” A — Redesign
“We need to create a process that doesn’t exist yet” or “the current process can’t be observed” B — Greenfield
“There’s a specific problem in one part of the process (a KPI, a step, a case type)” C — Focused improvement
“We don’t know what processes we have or which one to tackle first” D — Process architecture
“The process is already defined and we want to automate it (BPMS, RPA, AI, integration)” E — Automation
“The same process runs differently in each site, country or group company” F — Standardization
“We need to check whether we comply with a regulation or control framework, and fix it” G — Compliance

Torn between two modes? Pick C if the problem and its scope are contained; A if it spans several teams or the cause is unclear. If a root cause in C falls outside the scope, propose moving to A with a PDR.

2. Follow your mode’s route

Section titled “2. Follow your mode’s route”

Every route starts the same way: fill in PROCESO.md (template) and Phase 1.

Common Phase 1: charter → SIPOC → stakeholders → glossary. 🚪 Gate 1: the sponsor and process owner approve the charter.

A — Redesign

Section titled “A — Redesign”
  1. Common Phase 1.
  2. Discovery plan → interview guides ⚠ → document analysis ⚠ → event log ⚠ → synthesis → As-Is model → baseline. 🚪 Gate 2: participants recognize the As-Is as their real process.
  3. Value and waste → handoffs → risks and controls → requirements ⚠ → root cause. 🚪 Gate 3: the process owner validates problems and root causes.
  4. To-Be options → PDR → DMN rules ⚠ → automation → To-Be model → gap → business case. 🚪 Gate 4: sponsor (option and business case), process owner (operability) and Risk (controls).
  5. Model review → scenarios → simulation ⚠ → traceability. 🚪 Gate 5.
  6. Implementation plan → change management → SOPs → automation spec ⚠ → SDLC briefing ⚠ (only if the team decides to build software). 🚪 Gate 6: go-live.
  7. KPI dashboard → control plan → runbook → post-implementation review.

B — Greenfield

Section titled “B — Greenfield”

Like A, with these changes: in Phase 2 the discovery plan becomes a context-gathering plan and interviews are about requirements; there is no event log, As-Is, baseline or gap. Phase 3 focuses on requirements and risks. Target KPIs are set from benchmarks.

C — Focused improvement

Section titled “C — Focused improvement”

Like A, but with the charter limited to one sub-process and one KPI. The process map, context requirements and, for small changes, the To-Be options are usually skipped (the solution is recorded in a PDR). Handoffs ⚠.

D — Process architecture

Section titled “D — Process architecture”

Phase 1 with the process map as the main artifact → high-level discovery ⚠ → prioritization PDR. Each prioritized process then starts its own route (A, B, C, E, F or G).

E — Automation

Section titled “E — Automation”

Common Phase 1 → if the To-Be didn’t come from this methodology, at least value and waste (simplify before automating) → risks → automation → technology PDR → gap → business case → scenarios (they become the acceptance tests) → automation spec → Phase 7.

F — Standardization

Section titled “F — Standardization”

Like A, with discovery and the As-Is model done per variant (site, country, team) and a variant comparison in the synthesis. To-Be options include at least: adopting the best existing variant, a hybrid and a redesign. Legitimate differences are recorded as controlled variants in a PDR.

G — Compliance

Section titled “G — Compliance”

Common Phase 1 with {NORMATIVA} as the reference → discovery of the real process (document analysis is mandatory, event log if available) → risks, controls and regulatory requirements → gap between what happens and what’s required → remediation options and PDR → validation → control plan.

3. Between phases: how to use context

Section titled “3. Between phases: how to use context”
  • One conversation per phase. When a phase starts, bring PROCESO.md and the approved artifacts from earlier phases, not the whole conversation.
  • Within a phase, stay in the same conversation while the artifacts feed each other (for example, synthesis → As-Is model → baseline).
  • Don’t move on with a gate still open. If it’s approved with conditions, record them as assumptions or risks.

4. If software comes out of it

Section titled “4. If software comes out of it”

If in Phase 4 or 6 the team decides software is needed, the SDLC briefing is the input to the Spec-First methodology (Is2Be Software), Phase 1, Mode B.