The answer is conditional. Make the conditions visible.
Focused records of process and system choices under explicit premises—because a decision without its context becomes a rule nobody remembers how to challenge.
01Register18 records
- ADR / 001Make ERP customer creation asynchronousProtect the commercial workflow from ERP latency while making pending state and recovery explicit.Accepted for stated premisesIntegrationERPResilience
- ADR / 002Place commercial KPIs by action horizonChoose CRM, data platform or warehouse from latency and actionability—not from one universal source-of-truth claim.Proposed patternAnalyticsCRMData
- ADR / 003Use code at orchestration boundariesKeep transparent local rules declarative; move stateful, cross-system orchestration behind tested service boundaries.Proposed patternAutomationGovernanceIntegration
- ADR / 004Separate commercial approval from financial validationTwo decisions with different owners, evidence and SLAs should not share one approval step—even when one form collects the data for both.Proposed patternProcessGovernanceERP
- ADR / 005Separate commercial identity from legal customer identityAn account is a commercial relationship; a legal entity is a registered organization; an ERP customer is that entity in one of our companies. Model three linked identities—not one record that means all of them.Proposed patternIdentityCRMERP
- ADR / 006Represent regional variation through configuration, not CRM forksLegitimate local differences belong in declared configuration points and, rarely, registered extensions—never in copies of the global data model or lifecycle.Proposed patternCRMGovernanceVariation
- ADR / 007Treat uncertain integration outcomes as unknown, not failedA timeout says nothing about whether the receiver committed. Model ‘unknown’ as its own state, resolve it by request key, and only then retry or fail.Proposed patternIntegrationResilienceERP
- ADR / 008Run reconciliation as a permanent control, not an exception processDelivery guarantees fail silently. A scheduled comparison of expected and actual populations—with an owner for every kind of difference—is part of the architecture, not cleanup.Proposed patternIntegrationDataGovernance
- ADR / 009Model long-running automation as a run record with a state machineWhen automation spans steps, systems or days, give each run an identity, a state and step-level guards—so it can wait, fail, resume and finish exactly once.Proposed patternAutomationOrchestrationOperations
- ADR / 010Automate exits, not only entriesEvery automation that creates work when a record enters a state must also define what happens when it leaves it—or the downstream state goes stale.Proposed patternAutomationRevOpsData
- ADR / 011Define pipeline stages by business state and exit criteria, not probabilityA stage says what is true about the deal and what must happen to leave it. Probability and forecast category are derived from that—never typed in its place.Proposed patternRevOpsPipelineCRM
- ADR / 012Govern targets as versioned data with a publication and freeze pointPublish targets from planning at a declared grain and phasing, freeze them per period and revise them as new versions—so year-to-date performance is reproducible.Proposed patternRevOpsTargetsData
- ADR / 013Grant agent authority per action and consequence, never by confidenceClassify every action an agent could take—read, recommend, draft, execute, human approval or forbidden—by its consequence and reversibility. Confidence changes how work is presented, not who may commit it.Proposed patternAIAuthorityGovernance
- ADR / 014Expose agent capabilities as bounded tool contracts, not raw system APIsEach tool states purpose, input, output, permissions, preconditions, side effect, failure and reversibility—and enforces them in code, so the prompt is not the last line of defence.Proposed patternAIIntegrationSecurity
- ADR / 015Name process, system, data and KPI ownership separately“Owner” is not one concept. Name the process owner, stage owners, decision owners, system owners, data owners and KPI owners separately—so the exception always has a name.Proposed patternOperating modelOwnershipGovernance
- ADR / 016Record every local variation with a reason, owner, scope, cost and review dateLocal differences are decisions, not habits. Each one is classified—global change, configuration, local extension or rejected—and recorded with its reason, owner, scope, cost and review date.Proposed patternOperating modelVariationGovernance
- ADR / 017Measure adoption by process compliance and management use, not loginsLogins measure access. Adoption is measured by whether work moves through the intended process, whether decisions are made from system evidence and whether the parallel way of working has gone—each signal with an owner and an action.Proposed patternAdoptionMeasurementGovernance
- ADR / 018Retire parallel tools by classification and date, not by mandateA spreadsheet next to the CRM is often a signal of a missing capability. Inventory each parallel tool, classify it—required temporarily, replaced, integrated or retired—move its legitimate value, then freeze and retire it on a date with an approver for exceptions.Proposed patternAdoptionCRMOperating model