BibliotekSammanhängande läsvyEPUB
Matrix Publishing System
PUB-BUSINESS-001business-caseStatus: internal-reviewReview: currentTak: supported-with-gapRevisionslås: matrix-lock.json

Matrix business-case-ramverk

Detta är ett kalkyl- och beslutsramverk, inte en ROI-prognos. Belopp och förbättringar får endast publiceras när baseline, population, källa och attribution är dokumenterade.

Utgångspunkt

Matrix business case ska inte börja med “AI sparar 30 procent”. Det ska börja med en namngiven användare som försöker fatta ett beslut eller åstadkomma ett resultat i ett tvärsystemflöde (CLAIM-VALUE-002).

problem → nuvarande användarväg → mätbar friktion/risk
        → Matrix-förmåga → förändrad användarväg
        → verifierat outcome → ekonomisk konsekvens

Steg 1 — välj användarväg

Ett business case omfattar ett avgränsat use case, exempelvis:

  • analysera påverkan före AppWorks-uppgradering,
  • upptäcka dokumentförlust i ett order-till-arkiv-flöde,
  • skapa och granska en xECM-konfiguration,
  • sammanställa revisionsunderlag,
  • följa och styra en agent-/reviewkedja.

Dokumentera aktör, trigger, önskat slutläge, systemgräns, beslut och vad som händer om resultatet blir fel eller sent.

Steg 2 — bygg baseline

Baseline ska mätas före pilot eller märkas som saknad. Minsta kontrakt:

Fält Exempel
Population antal uppgraderingsanalyser per kvartal
Mätperiod föregående 90 dagar
Ledtid median och p90 från beställning till verifierat besked
Aktiv tid faktisk analystid per roll
Omgångar antal kompletteringar/rework
Fel beslut som senare behövde korrigeras
Incidentrisk frekvens × verifierad konsekvensklass
Coverage andel analyser med komplett källunderlag
Källa ärendesystem, tidsrapport, revisionslogg, observation

Utan expected population går det inte att bedöma täckning (CLAIM-VALUE-003).

Steg 3 — klassificera värdet

Produktivitet

  • minskad aktiv analystid,
  • färre manuella överlämningar,
  • mindre återinsamling av samma fakta,
  • kortare tid till beslut.

Kvalitet

  • större source- och object coverage,
  • färre tysta luckor,
  • högre andel verifierade postconditions,
  • färre omtag efter review.

Risk

  • färre oavsiktliga förändringseffekter,
  • kortare incidentduration,
  • minskad blast radius,
  • tidigare upptäckt av drift eller dokumentationsdrift.

Återanvändning

  • fler leveranser från versionerade standardsenarier,
  • mindre kundspecifik handkodning,
  • snabbare jämförelse mellan versioner och kunder,
  • reproducerbara generator- och dry-run-resultat.

Styrning

  • kortare tid att ta fram evidens,
  • större andel handlingar med mandat och read-back,
  • färre manuella undantag,
  • synlig review- och revisionsskuld.

Steg 4 — skilj aktivitet från outcome

Antal inloggningar, genererade grafer eller agentruns är adoption, inte verksamhetsvärde. Ett mätkontrakt ska länka:

capability use → förändrad användarväg → verifierat outcome

Exempel: “konsekvensanalys öppnades” är användning. “Beslutsunderlaget blev klart på 45 minuter med 100 procent deklarerad source coverage” är ett processutfall. “Färre produktionsincidenter” kräver längre observation och en trovärdig attribution (CLAIM-VALUE-004, CLAIM-VALUE-005).

Steg 5 — ekonomisk härledning

Tidsvärde

(baseline aktiv tid − ny aktiv tid)
× verifierad population
× belastad kostnad per timme

Tidsvärde är frigjord kapacitet. Det är inte automatiskt budgetbesparing eller minskad personalstyrka.

Undviket omarbete

(baseline omtag − nya omtag)
× genomsnittlig verifierad omtagskostnad

Riskvärde

förändrad verifierad frekvens
× avgränsad konsekvens
× attributionens styrka

Riskvärde ska helst redovisas som intervall. Extremt osäkra incidentkostnader ska visas som scenario, inte läggas in som säker besparing (CLAIM-VALUE-006).

Plattformskostnad

Räkna minst:

  • produkt- och implementationstid,
  • connector- och datakontraktsarbete,
  • modell-/inferencekostnad med coverage,
  • drift och förvaltning,
  • säkerhets- och compliancearbete,
  • utbildning och processförändring,
  • kostnad för kvarvarande manuella steg.

Beslutsmatris

Dimension Fråga Grind
Problem Är problemet observerat och återkommande? Baseline finns
Förmåga Finns landad eller pilotbar Matrix-funktion? Capabilitystatus
Användning Kan målrollen genomföra hela vägen? Verifierat use case
Outcome Finns population, metric och källa? Mätkontrakt
Attribution Kan förändringen rimligen kopplas till Matrix? Jämförelse/counterfactual
Ekonomi Överstiger intervallvärdet total kostnad och risk? Ägarbeslut

Pilotkontrakt

Ett första business case bör använda en 6–12 veckors pilot med:

  1. fryst baseline och mätperiod,
  2. en målroll och ett huvudflöde,
  3. högst tre outcomes,
  4. ett säkerhets-/kvalitetsguardrail,
  5. explicit manual fallback,
  6. mätning av både coverage och bortfall,
  7. beslutspunkt: investera, justera eller stoppa.

Stoppsignaler

  • baseline kan inte etableras,
  • användarvägen kräver fortfarande dold expertorkestrering,
  • output finns men read-back saknas,
  • endast aktivitet kan mätas,
  • kostnaden saknar usage coverage,
  • riskreduktion bygger på hypotetiska incidenter,
  • koncept-UI behandlas som levererad capability.

Kalkylbladets kolumner

metric_id, use_case, population, period, baseline_value, target_value, observed_value, unit, source_ref, coverage, freshness, attribution_method, confidence_class, owner, decision_status.

Spårbarhet

CLAIM-VALUE-002–CLAIM-VALUE-008.

Visuella referenser

Från belagt problem till portföljbeslut
Värdevy som skiljer målbild, mätbarhet och verifierat outcome