State Charts, eller tillståndsdiagram, har blivit en grundläggande komponent inom systemmodellering, särskilt inom mjukvaruutveckling och ingenjörsdiscipliner. Deras uppkomst kan spåras till arbetet av David Harel, som byggde vidare på von Neumanns teorier och introducerade grafiska representationer för att beskriva systemtillstånd och övergångar. Under 1980- och 1990-talen fick State Charts stort genomslag och blev en integrerad del av objektorienterad programdesign, där de också inkluderas i Unified Modeling Language (UML). Idag används de inte bara inom mjukvaruingenjörskap utan även inom kontrollteknik och systemdesign, där de erbjuder ett visuellt sätt att förstå komplexa beteenden, identifiera potentiella problem och förfina designprocesser.

Det är viktigt att förstå att State Charts och objektlivscykler, som i många tekniska tillämpningar, inte bara handlar om att beskriva systembeteenden utan också om att fånga den kausalitet som påverkar ett objekts livscykel. Inom MMABP (Modellering av affärsprocesser) används State Charts för att uttrycka dessa kausala förändringar i den verkliga världen, vilket skiljer sig från traditionella tekniska modeller som fokuserar på ingenjörsmässig beteendeanalys. MMABP:s tillvägagångssätt påminner om ontologisk modellering, där det är avgörande att dra en tydlig gräns mellan ett objekts livscykel, som beskriver kausalitet, och ett systems beteende, som kan innefatta avsiktliga handlingar.

Denna distinktion kan vara svår att förstå om man utgår från en rent teknologisk (ingenjörs-) synvinkel. I jämförelse med Petri-nät, som också använder grafiska representationer för att beskriva systembeteenden, är State Charts mer specialiserade genom att tydligt representera tillstånd och övergångar. Trots de likheter som finns mellan dessa två modeller, är det viktigt att förstå att State Charts i MMABP inte syftar till att beskriva affärsprocessen i sig eller den infrastruktur som omger processen, såsom IT-system eller maskiner. Istället handlar det om att beskriva den logik och kausalitet som styr objektens interaktioner i den verkliga världen.

För att konkretisera denna åtskillnad kan man titta på affärsprocesser som "reaktiva system". Ett reaktivt system, enligt Harel, är ett system som ständigt interagerar med sin omgivning, och reagerar på förändringar i denna omgivning. Affärsprocesser passar in i denna definition, eftersom de också är en serie av interaktioner som svarar på förändringar från externa faktorer, exempelvis kundens behov, systemfel eller regulatoriska förändringar. Processerna utvecklas genom dessa förändringar för att uppnå sina mål. På samma sätt som reaktiva system, behöver affärsprocesser anpassa sitt tillstånd baserat på externa händelser.

Men även om affärsprocesser kan ses som reaktiva system, är det viktigt att inte förväxla en affärsprocess med själva systemet av ontologiska objekt som representeras i konceptmodellen. Användningen av State Charts i MMABP bör därför ses som en metod för att uttrycka den logik som är inneboende i verkligheten snarare än som en exakt beskrivning av affärsprocessen i teknisk bemärkelse.

För att kunna använda State Charts korrekt i konceptuell modellering, finns det några viktiga regler att följa, vilka säkerställer att modellen förblir konsekvent och korrekt i sin representation av objektets livscykel. En livscykelmodell för ett objekt måste vara fullständig och täcka hela objektets existens. Detta innebär att modellen bör börja med en skapandehändelse och sträcka sig över alla potentiella avslutningar av objektets liv, vilket inkluderar olika "dödshändelser". En annan viktig regel är att modellen ska vara algoritmiskt korrekt, vilket innebär att alla tillstånd bör vara tydligt avgränsade och att inga övergångar ska kunna leda till dödlägen. Varje tillstånd ska också ha åtminstone två möjliga utgångstransitioner för att säkerställa att varje tillstånd har alternativa responsmöjligheter. Detta är en viktig aspekt för att bevara den "modala logiken" i modellen, vilket skiljer den från att bara vara en sekvens av statiska tillstånd.

En livscykelmodell bör också vara konsistent med sitt sammanhang. Detta innebär att övergångarna mellan olika tillstånd ska reflektera förändringar i relationen mellan objekt eller transformationer av objektets attribut. Om objektet är generiskt, och dess generalisering är "dynamisk", ska livscykeln också reflektera denna dynamik i enlighet med OntoUML:s terminologi.

För att korrekt definiera och modellera affärsprocesser och objektlivscykler är det därför avgörande att skilja mellan tekniska och ontologiska perspektiv. Tekniken fokuserar på att modellera systembeteenden och interaktioner på en detaljerad nivå, medan ontologin handlar om att fånga den underliggande kausaliteten och de logiska relationerna i den verkliga världen. Denna distinktion är central för att förstå hur MMABP använder State Charts för att fånga verkliga affärsprocessers dynamik och kausalitet.

Hur integreras objektorienterade och processorienterade modeller i affärssystem?

I arbetet med att konstruera affärssystem är en central utmaning att förena olika typer av modeller – särskilt modeller som är objektorienterade och processorienterade. Dessa modeller används för att representera och analysera affärssystem på olika nivåer, men utan en noggrann integration riskerar de att bli fragmenterade och ofullständiga. Genom att noggrant analysera samverkan mellan objektens livscykler, processflöden och begreppsmodeller kan vi skapa en mer sammanhängande och effektiv representation av affärssystemet.

En grundläggande aspekt i denna integration är att förstå hur varje modell representerar olika delar av verkligheten. Processkartan (PM) definierar vilka objekt och relationer inom affärssystemet som är signifikanta för att kunna designa affärsprocesser korrekt. Här handlar det om att identifiera de objekt som behöver hanteras inom varje affärsprocess, samt att säkerställa att deras relationer beaktas på ett korrekt sätt. Samtidigt spelar modellen för begrepp (CM) en viktig roll i att definiera objektens egenskaper och hur dessa kategoriseras och relateras till varandra.

När vi går djupare i arbetet med detaljerade modeller, såsom processflödesmodeller (PF) och livscykelmodeller för objekt (LC), blir det uppenbart att dessa också måste harmonisera med varandra. Processflöden definierar de specifika stegen i affärsprocesserna, medan livscykelmodellerna beskriver de olika faser ett objekt genomgår under sin existens. En noggrann samordning mellan dessa modeller säkerställer att de relevanta objekten genomgår sina livscykler på ett sätt som är kompatibelt med de affärsprocesser som hanterar dem.

En central fråga i denna integration är hur vi säkerställer att alla modeller är konsekventa med varandra. Konsekvens handlar om att undvika motsägelser mellan de olika representationerna av samma fakta i olika modeller. Exempelvis ska inte en processmodell föreslå att ett objekt kan vara i ett visst tillstånd medan livscykelmodellen för detta objekt säger något annat. En annan viktig aspekt är konformitet, vilket handlar om att säkerställa att de lägre nivåernas representationer i modellerna följer de högre nivåernas regler och strukturer.

I en ideal situation sammanfaller alla modeller i en gemensam helhet. Detta innebär att processkartan, begreppsmodellen, processflödesmodellerna och livscykelmodellerna arbetar tillsammans för att ge en komplett och konsekvent bild av affärssystemet, både på en övergripande och detaljnivå. Vid denna punkt måste alla objekt och processer vara korrekt representerade och interagera på ett sätt som återspeglar den faktiska affärslogiken.

När man beaktar dessa samordnade modeller är det också viktigt att förstå skillnaden mellan konsistens och konformitet. Konsistens betyder att representationerna i olika modeller inte motsäger varandra, medan konformitet innebär att de lägre nivåernas representationer är anpassade till de högre nivåernas strukturer. Båda dessa aspekter är avgörande för att säkerställa att affärssystemet är korrekt modellert och att alla affärsprocesser kan genomföras utan logiska inkonsekvenser.

I slutändan handlar integrationen av objektorienterade och processorienterade modeller om att skapa en helhet där alla modeller stöder och förstärker varandra, vilket gör det möjligt att hantera och optimera affärsprocesser på ett effektivt sätt. Genom att noggrant beakta både konsistens och konformitet kan man säkerställa att alla delar av affärssystemet arbetar tillsammans mot samma mål och att alla objekt och processer behandlas på ett korrekt och effektivt sätt genom hela deras livscykler.

Hur kan en organisation utveckla sin mognad genom processbaserad transformation?

Utmaningen att hantera organisatoriska förändringar har lett till utvecklingen av begreppet organisatorisk mognadsmodell, som underlättar transformationen genom att beakta viktiga aspekter och konsekvenser på varje nivå av organisatorisk mognad. Det första mognadsmodellen för processdriven transformation av R. Nolan ledde till utvecklingen av flera samtida modeller. Bland dessa står M. Hammers modell ut som en av de mest omfattande, särskilt känd för harmoniseringen mellan processmognad och organisatorisk mognad. Denna modell ligger till grund för en metodologi för organisatorisk utveckling genom teknologisk framstegshantering, vilket i praktiken hjälper till att minska de risker som är förknippade med förändringar.

Flera författare har noggrant granskat mognadsmodeller och jämfört individuella kriterier. Modeller som Goncalves’, Lockamy och McCormack’s, samt Hertz’s mognadsmodeller jämfördes av Palmberg och fokuserar på processdefinition, prestandamätning och utvärdering, processförbättring, organisationsstruktur, tvåvägskommunikation och informationssäkerhet. Många av dessa modeller är inspirerade av Capability Maturity Model (CMM, CMMI). Fischers modell, som integrerar dimensioner som strategi, kontroll, processer, människor och informationsteknologi, citeras ofta. Den skapar nivåer för processhantering inom varje dimension och definierar organisationens nivå från begränsad expansion till integrering på den taktiska ledningsnivån.

M. Hammers modell, Process and Enterprise Maturity Model (PEMM), är en av de mest citerade och anses vara lätt att tillämpa. Den levererar omedelbara resultat när det gäller att förbättra processbaserade styrsystem och affärsprocesser. I sin artikel betonar Hammer vikten av att organisationer måste utveckla sina affärsprocesser för att säkerställa högre prestation över tid. Han identifierar två typer av egenskaper för utveckling: Process Enablers (egenskaper hos individuella processer) och Enterprise Capabilities (egenskaper hos hela organisationen).

Process Enablers omfattar bland annat:

  • Design (omfattningen av processens specifikation)

  • Performers (kompetens och kunskap hos de som utför processen)

  • Owner (ansvar hos högre chefer för processen)

  • Infrastructure (processstöd genom informations- och ledningssystem)

  • Metrics (mått för att följa processens prestanda)

Enterprise Capabilities omfattar:

  • Leadership (stöd från högre chefer för processskapande)

  • Culture (värderingar som kundfokus, lagarbete, personligt ansvar och vilja att förändras)

  • Expertise (metodologi för processomdesign och kompetens att använda den)

  • Governance (mekanismer för att hantera komplexa projekt och förändringsinitiativ)

Hammers system bedömer organisatorisk mognad genom att beakta egenskaperna hos både processenabler och företagskapabiliteter. Den övergripande kvaliteten på en organisation ses som en komplex egenskap där både processenabler och företagskapabiliteter uttrycker nödvändiga förutsättningar för kvalitet. Därför bör processmognad vara i linje med företagskapabiliteter och vice versa för att uppnå meningsfull organisatorisk utveckling.

Hammer definierade fyra nivåer av organisatorisk mognad och processmognad, som illustreras i hans modell:

  1. Traditionell ledning
    Vid denna nivå känner organisationen till begreppet processer, men förståelsen och acceptansen av termen "process" är fortfarande otydlig. Processer täcker endast fragment av affärsmodellen, och organisationen fokuserar på partiella eller lokala förbättringar. Infrastrukturen är ofta fragmenterad och baserad på linjeorganisationen.

  2. Aktiviteter som delar av processer

    Här får organisationen en processorienterad syn på sina aktiviteter. Varje aktivitet ses som en del av en större process och får sitt sammanhang i relation till organisationens övergripande mål. Processerna blir centrala och gemensamma för alla definitioner, beteenden och metoder.

  3. Organisationen som ett system av processer
    På denna nivå ses varje process som en grundläggande komponent i organisationens processystem. Här börjar organisationen behandlas som en enhet, och varje process bedöms i ett bredare sammanhang där hela organisationens mål och betydelse kopplas till verksamheten.

  4. Organisationen som en del av processystemet på marknaden
    På högsta nivån betraktas processerna inte bara i organisationens egna kontext utan också ur ett kundorienterat perspektiv. Här sträcker sig besluten bortom organisationens gränser för att inkludera kunders och samarbetspartnernas behov. Processer anpassas för att passa externa tekniska och professionella standarder.

Denna mognadsmodell representerar en utveckling från en grundläggande förståelse av processer till ett avancerat stadium där organisationen är djupt kopplad till marknadens och kundernas behov. Organisatorisk mognad är en nyckelfaktor som måste beaktas vid införandet av en processdriven organisation. Om organisationens mognadsnivå inte beaktas under transformationsarbetet riskerar hela projektet att misslyckas. Hammers "processaudit" ger en global förståelse för de framgångsfaktorer som är avgörande för ett sådant projekt, samt deras inbördes relationer och praktiska åtgärder som behöver genomföras vid olika mognadsnivåer.

Enligt Hammers mognadsmodell PEMM utvecklades även en metod för att utveckla en processorganiserad organisation, som har publicerats som en CEABPM-standard av den Central-Europiska föreningen för affärsprocesshantering.

För att effektivt genomföra en transformation baserad på processer är det avgörande att förstå inte bara de konkreta förändringarna som krävs, utan även att organisera arbetet med att bygga och upprätthålla processer i samklang med organisationens övergripande kapabiliteter. Mognadsmodeller som PEMM underlättar detta genom att ge en konkret väg för att gradvis utveckla och förbättra alla delar av organisationens processer och kapabiliteter, vilket gör det möjligt för företaget att anpassa sig långsiktigt till förändrade marknadsförhållanden.

Hur kan företagets affärsarkitektur modelleras effektivt?

Affärsprocesshantering (BPM) och affärsarkitektur är två fält som på ytan kan verka separata, men i verkligheten arbetar de ofta med samma grundläggande modeller. Trots detta är det vanligt att BPM-modeller inte tillräckligt abstraherar från detaljerna i processerna för att kunna fungera effektivt på en strategisk nivå. Därför är traditionella verktyg för affärsprocesshantering ofta otillräckliga när det gäller att hantera affärsarkitektur i ett mer övergripande och strategiskt perspektiv.

Ett exempel på detta kan ses i processkartor, som är vanliga i BPM. Trots deras användbarhet för att visualisera affärsprocesser är de inte universella eller standardiserade. Standards som BPMN (Business Process Model and Notation) eller UML (Unified Modeling Language) erbjuder inte funktioner för att skapa en processkarta, medan system som ARIS erbjuder processkartor och processlandskap, men dessa är ändå inte universella lösningar. Här uppstår en skillnad mellan affärsprocesshantering och affärsarkitektur, där BPM mer fokuserar på detaljerad processmodellering, medan affärsarkitektur tar ett mer övergripande perspektiv.

Det är viktigt att förstå att dessa två områden inte är ömsesidigt uteslutande utan snarare komplementära. Affärsprocessens detaljer behöver vara konsekventa med de element som anges i affärsarkitekturens modeller. I samma anda bör arkitekturens modellering vara förenlig med detaljerna i affärsprocesserna. En metod som bygger på ontologier och enterprise engineering (EE) visar att det från en modelleringssynvinkel inte finns något hinder för att inkludera affärsprocessens detaljer i affärsarkitekturen. Modeller för affärsprocesser, även på detaljnivå, är således en integrerad del av affärsarkitekturen.

BPM erbjuder procedurer för att identifiera och modellera affärsprocesser i detalj samt för att mäta deras prestanda, ofta utan att tillräcklig förståelse för detaljerna i de processerna är omöjlig. Det ger även bästa praxis som exempelvis APQC Process Classification Framework, kopplingar till balanserade styrkort och mognadsmodeller. Däremot lämnar BPM ofta själva analysen av de verkliga objekt som processerna arbetar med åt andra. Detta lämnar en lucka som andra modelleringsmetoder försöker fylla.

MMABP, eller metodiken för modellering och analys av affärsprocesser, ger ett svar på hur affärsarkitektur kan modelleras på ett sätt som både är effektivt och hanterbart. En ofta förekommande uppfattning är att affärsarkitekturens modeller måste vara komplexa och omfattande för att kunna tillämpas, vilket gör dem oöverkomliga för mindre problem. MMABP visar på motsatsen: en välstrukturerad metodik, med rätt verktyg, är återanvändbar och kan byggas ut gradvis, vilket gör att modellen kan fokusera på det som är relevant för det aktuella problemet utan att det krävs ett globalt företagsomfattande modell. MMABP undviker att konkurrera med befintliga standarder och syftar istället till att lyfta fram det väsentliga i den överflöd av diagram och element som de nuvarande modellerna och ramverken erbjuder.

MMABP är en metodik som kan stå på egna ben, inte som en sammanfattning av andra metoder. Den erbjuder grundläggande principer och bästa praxis för att fånga kärnan i affärsarkitekturen på ett sätt som är både fullständigt och konsekvent, samtidigt som det hålls minimalt i antal modeller och element. En central aspekt i MMABP är att det inte hindrar användningen av andra diagram och symboler som är relevanta enligt gällande standarder. Det är en flexibel metodik som är förenlig med andra ramverk som TOGAF och BPMN, vilket gör det möjligt för användaren att modellera affärsprocesser på ett sätt som är både konsekvent och kompatibelt med standarder och best practices.

MMABP anammar ontologisk modellering, som är ett kraftfullt verktyg för att fånga verkligheten på ett sätt som inte är möjligt genom enbart dataanalys. Ontologisk modellering är dock ofta för komplex för många analytiker, vilket leder till att denna metodik tenderar att undvikas i praktiken. MMABP tar en pragmatisk ansats och införlivar ontologiska begrepp i en mer lättanvänd modell som gör det möjligt att fånga affärsverkligheten utan att kräva en ontolog.

För att säkerställa att de olika modellerna för affärsarkitektur är konsekventa, specificerar MMABP en metamodel som definierar relationerna mellan modellerna och de konsistensregler som ska vägleda analytiker för att undvika potentiella inkonsekvenser. MMABP går inte att förstå isolerat – det refererar även till andra områden som affärsprocesshantering och implementering av affärsprocesser genom arbetsflöden.

Det finns många olika standarder och ramverk för modellering av affärsarkitektur. Dessa är vanligtvis designade som fristående standarder, men ofta hänvisar de till en metodologisk ram som ligger till grund för den affärsarkitektur som de fångar. Till exempel, ArchiMate är en fristående standard för företagets arkitekturmodellering, inklusive affärsarkitektur, men den hänvisar till TOGAF som sin filosofiska grund. På samma sätt listar TOGAF ArchiMate som en av de lämpliga standarderna för företagsarkitekturmodellering, men inte den enda.

Det är också viktigt att förstå att metoder som ARIS, som länge har varit ett ramverk för informationssystemens arkitektur, har utvecklats för att även omfatta hela företagets arkitektur. ARIS, med sina fem vyer (organisation, data, produkt/tjänst, funktion och kontroll), erbjuder ett multidimensionellt sätt att förstå och modellera verkligheten. Denna modell bryter ner komplexiteten i affärsarkitekturen och gör det möjligt att analysera den ur flera olika perspektiv.