Informationsmodellering: Om verksamhetsregler

Verksamhetsregler har sin naturliga plats i informationsmodellen. Då beskriver man inte bara allt det som verksamheten hanterar utan också vilka regler som gäller för detta. På det sättet fångar man hela den operativa verksamhetslogiken.

Verksamhetsregler har sin naturliga plats i informationsmodellen. Då beskriver man inte bara allt det som verksamheten hanterar utan också vilka regler som gäller för detta. På det sättet fångar man hela den operativa verksamhetslogiken.

/Peter Tallungs, IRM, 2022-06-09

Verksamhetsregler styr hur en verksamhet ska fungerar dagligdags. Därmed kan man tro att verksamhetsregler hanteras på ett strukturerat sätt i våra verksamheter, att de dokumenteras, vårdas, hanteras och tillgängliggörs för de som behöver dem.

Men så är det knappast. Få organisationer har något sätt att hantera sina verksamhetsregler. Jag har aldrig sett någon kurs eller ramverk för verksamhetsarkitektur som haft någon praktisk genomförbar idé för detta.

I sammanhang där verksamhetsarkitektur behandlas undviker man ämnet. Man nämner kanske att verksamhetsregler är viktiga men går inte in på vad de är eller hur de kan hanteras.

Men låt oss ta tag i ämnet, här och nu! Vi börjar med att titta på vad verksamhetsregler är.

Vad är en verksamhetsregel?

För att du ska få en känsla för vad vi pratar om ges här några exempel på verksamhetsregler.

”Att en student är behörig innebär att studenten har en styrkt behörighet.”

”Endast behörig student får antas till kurs.”

”Endast registrerad student kan få betyg på kurs.”

”En kund måste registreras i kundregistret innan order relaterade till kunden kan skapas.”

”En kund som har order knuten till sig kan inte tas bort.”

”En kund tillåts inte att lägga ny order om kunden inte har en godkänd kredit.”

”En kund som lägger order för mer än 500 SEK får gratis frakt.

”En kund som lägger order under årets kampanj får 20 procents rabatt.”

Vad är verksamhetsregler? – Enkelt förklarat

Verksamhetsregler är de specifika regler som verksamheter ständigt tillämpar i sin operativa verksamhet. En del är mer eller mindre permanenta, andra är tillfälliga. Varje verksamhet har ett otal sådana regler, fast ofta slarvigt hanterade eller oskrivna eller dolda på olika ställen eller otydliga. Därför sker ofta missöden i den dagliga hanteringen.

Vad är verksamhetsregler? – Teori

Det finns gott om teori runt verksamhetsregler. Det var ett hett ämne inom verksamhetsutveckling under 00-talet, men verkar ha gått i stå i brist på exempel på praktisk tillämpning. De som skrev och pratade mycket om ämnet var ett gäng framträdande personer vars idéer gick under baneret ”The Business Rules Approach”. Mest kända var kanske Donald G. Ross och Barbara von Halle. Jag tycker de framförde vettiga saker, och jag följde dem noga. Det som var vettigt var dock endast teorin. Då det gällde hur man rent praktiskt skulle hantera verksamhetsregler var idéerna svagare.

Wikipedia ger följande beskrivning av verksamhetsregler, översatt till svenska av mig:

”Verksamhetsregler beskriver de operationer, definitioner och begränsningar som en organisation behöver tillämpa för att nå sina mål.

Till exempel kan en verksamhetsregel säga att en kreditkontroll inte behöver göras för en återkommande kund. Andra exempel är en lista på utvalda leverantörer eller leveransscheman.

Dessa regler används för att organisationen bättre ska uppnå sina mål, kommunicera mellan medarbetare och intressenter, kommunicera med tredje-parter, visa hur man fullföljer legala krav, opererar mer effektivt, automatiserar hantering, göra analyser med mera.

En definition som har använts är följande: En verksamhetregel är ett uttryck som definierar eller begränsar någon aspekt av verksamheten.”

Om själva namnet ”Verksamhetsregler”

På engelska heter det vi här talar om Business rules. Ofta översätts det till svenska med affärsregler. Men jag menar att det är en felaktig översättning som leder tanken fel. Business kan betyda två olika saker. Det kan betyda affär och det kan betyda verksamhet.

Verksamhet är allt en organisation, del av en organisation eller flera samverkande organisationer gör, stort som smått.

Affär däremot handlar bara om det mest grundläggande eller yttersta aspekterna hos verksamheten; För vilka finns vi till? Hur når vi dem? Vad gör vi för dem? Hur fortsätter vi att vara relevanta?
Många skulle säga att det handlar om pengar. Fast det är ju bara ett mått som används. Det finns viktigare aspekter av en affär. Man kan mycket väl prata om affär också i icke-kommersiella organisationer. En förening, kommun eller statligt verk behöver på samma sätt finnas till för några och vara relevant.

Så anledningen till att jag tycker att Business i många fall bör översättas till verksamhet och inte affär är att det är att det senare är ett specifikt begrepp som är avgränsat till de existentiella frågorna för en organisation.

Vad är inte verksamhetsregler?

Det finns en annan typ av regler som ibland förväxlas med verksamhetsregler men som bör benämnas och hanteras på ett annat sätt. Det är bestämmelser, styrande regler, policys, affärsbestämmelser med mera. Både sådana som påläggs verksamheter utifrån och sådana som organisationer tar fram själva.

Allt sådant hör hemma i strategisk ledning och ska inte hänföras till det som menas med verksamhetsregler som är mer direkt operativa. Verksamhetsregler är ett av de medel med vilka strategier är implementerade. Verksamhetsregler säger en organisation vad som går att göra i den detaljerade operativa hanteringen medans strategin fokuserar på organisationens inriktning på makronivå.

Man kan också uttrycka det på följande sätt: Strategi ger organisationen en riktning i vad den ska göra. Verksamhetsregler ger detaljerad styrning om exakt hur en strategi ska översättas till handling i en specifik situation.

Principer för hur vi ska hantera verksamhetsregler

Verksamhetsregler är viktiga för en verksamhet och behöver därför hanteras. Vad innebär hantering i detta fall? Nedan principer för detta togs fram av gänget bakom The Business Rules Approach.

Verksamhetsregler ska

  • vara nedskrivna och tydliggjorda.
  • uttryckas i naturligt språk.
  • utformas så de inte är bundna till specifika procedurer och arbetsflöden.
  • beskrivas diskret, icke-redundant och icke-procedurellt.
  • bygga på fakta, begrepp och termer.
  • vara åtkomliga för de som behöver dem.
  • Hanteras.

Typer av verksamhetsregler

En verksamhetregel ska formuleras så den blir atomär, vilket betyder att den ska vara på sådan detaljnivå att den inte kan brytas ner i fler detaljerade regler utan att information förloras.

Varje (atomär) verksamhetregel måste vara någon av följande typer:

  • Strukturregel (Structural assertion)
    Ett definierat begrepp eller redogörelse av fakta som uttrycker någon aspekt av någon struktur i verksamheten. Det omfattar både termer och fakta sammansatt av dessa termer.
  • Handlingsregel (Action assertion)
    En begränsning eller villkor sombegränsar eller styr en handling i verksamheten.
  • Härledd regel (Derivation)
    Ett uttryck för kunskap som är härledd från annan kunskap i verksamheten.

Verksamhetsregler i informationsmodellen

Grafen nedan visar hur jag menar att de olika typerna av verksamhetsregler uttrycks i en informationsmodell. Många av reglerna är sådana som vi uttrycker i själva strukturen. Andra regler behöver vi uttrycka i text. För handlingsregler och härledda regler blir textdelen av informationsmodellen särskilt viktig.

Informationsmodellen är platsen för alla verksamhetsregler

Jag menar att den struktur som bäst hanterar verksamhetsregler är informationsmodellen. Detta av två orsaker:

  • Verksamhetsregler är överlappande och tätt förknippade med det som informationsmodellen beskriver i övrigt
    Ty informationsmodellen beskriver inte information i första hand menar jag. Den beskriver de företeelse som verksamheten hanterar samt reglerna för detta, det vill säga strukturer, begränsningar med mera. Detta är en del av verksamhetsreglerna. Andra verksamhetsregler uttrycks i text, och de använder alla de begrepp som definieras i informationsmodellen. Därför är det svårt att separera verksamhetsreglerna från informationsmodellen.
  • Informationsmodellen ger en naturlig struktur för verksamhetsreglerna
    En rik informationsmodell är strukturerad i ämnesområden som i sin tur är indelade i ett avsnitt per entitet. Varje avsnitt för en entitet är sedan indelad i ett underavsnitt per attribut. En verksamhetsregel handlar alltid om en viss entitet eller attribut eller i vissa fall relationen mellan två entiteter eller attribut. Därmed har varje verksamhetsregel en naturlig plats i informationsmodellen. Till exempel finns då allt som gäller för kunder under avsnittet ”Kund”. Inte bara alla definierade begrepp och termer som har med kunder att göra och vilken information som hanteras och var den hanteras. Utan också alla de regler som gäller för hanteringen av kunder.

Informationsmodellen kan bli bärare av hela den operativa verksamhetslogiken

Jag menar att våra informationsmodeller på detta sätt kan bli bärare av hela den operativa verksamhetslogiken. Detta då en informationsmodell kan beskriver både allt det som verksamheten hanterar och vilka regler som gäller för denna.

Det som inte beskrivs av informationsmodellen är av vem och var hanteringen sker. Inte heller varför. Men detta är i sig inte heller del av den operativa verksamhetslogiken, utan snarare hur denna exekveras. Det har vi andra modeller för.

Men om informationsmodellen ska kunna bära hela denna operativa verksamhetslogik krävs det att vi gör på rätt sätt, både i hur vi bygger upp vår modell och hur vi arbetar med den i verksamheten.

Jag har varit med om det i olika verksamheter, så jag vet att det är praktiskt genomförbart och har sett den stora nyttan det ger. Hur man som informationsarkitekt kan driva detta är i själva verket det jag egentligen vill förmedla med hela den här artikelserien.

Men allt detta förutsätter att vi, förutom att vi blir bra på att fånga, formulera och hantera verksamhetsregler

  • gör rika informationsmodeller, det vill säga modeller som inte bara är ett ER-diagram utan integrerar text och bild, och bär mer kunskap än vanligt.
  • verkligen utvecklar och använder våra modeller i en kontinuerlig dialog tvärs över verksamhet och it.

Hur gör ni?

Hur hanterar ni verksamhetsregler i er verksamhet? Hur hanterar och förmedlar ni verksamhetslogiken? Hur fungerar det?

/Peter Tallungs

Nästa artikel i serien publicerar vi torsdag 16 juni. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Varför en industrimodell är en dålig idé

Varför inte en standardmodell i stället för en hemmasnickrad? Varför uppfinna hjulet på nytt? Är det inte bättre med en etablerad och beprövad standard? 

Det finns många generella standard-informationsmodeller för olika branscher, så kallade industrimodeller. De täcker alla upptänkliga aspekter av en bransch och finns för i stort sett alla branscher, till exempel transport-, telekom-, finans- och försäkringsbranschen. De är internationella och generella, och tänkta att kunna anpassas till de specifika behov man kan tänkas ha i sin egen organisation. Varför inte anamma en sådan modell för vår verksamhet i stället för att ta fram en egen?  

Lockelsen hos en industrimodell

I många organisationer har man sett det som en bra idé att införa en industrimodell. De fördelar man tänker sig är följande

  • Slipper besväret med att ta fram en själv
  • Får tillgång till all den kunskap och erfarenhet som finns inarbetad i modellen
  • Får kontrollerade och exakta begrepp
  • Det blir lättare att utbyta information med andra i branschen.
    (Förutsatt att modellen är accepterad av tillräckligt många.)

Ofta är man frustrerad över alla försök som gjorts med att få till gemensamma begrepp i organisationen. Då ser en redan färdig modell ut som en enkel lösning. Man påhejas av konsultföretag som har som affärsidé att erbjuda en industrimodell, och konsulter för att hjälpa till att implementera. Varför bygga något själv när det finns en färdig standard? Man förstår förstås att det ändå blir ett arbete med att anpassa sig till standarden och att man ibland även måste göra avsteg från själva standarden för sina egna specifika behov. Konsultföretagen brukar nämna att det brukar röra sig om runt tjugo procent egna anpassningar.

Allt verkar bra. Det känns tryggt att luta sig mot något etablerat. Därför har också många organisationer valt den vägen.

Det finns gott om misslyckanden

I själva verket är den vägen allt annat än trygg. Alla sådana satsningar jag känner till har misslyckats. I bästa fall har de runnit ut i sanden efter ett tag, då satsningen har tappat fart och inte visat sig ge den nytta man trodde. Ibland har satsningen ändå fortsatt, eftersom projekt har en tendens att bara fortsätta fastän de inte fungerar.

I många fall har industrimodellen då satt sin prägel på begreppen och språket i verksamheten. Men inte på ett bra sätt. Tvärtom har man då skadat organisationens möjlighet att få till en gemensam förståelse och ett gemensamt språk. Detta eftersom arbetet har varit mer inriktat på att matcha ihop företeelserna i domänen med modellen, än att verkligen skapa en förståelse av verksamheten.

Organisationen har då inte bara slösat pengar, kraft och tid samt missat möjligheter utan också hamnat i ett betydligt sämre läge än innan. Man har då förstört något av det viktigaste man har, de gemensamma begreppen och det gemensamma språket.

Ibland hör man förklaringen att de industrimodeller som finns än så länge är för dåliga, vilket inte är sant. Eller att de är för generella, vilket är sant, men den förklaringen missar ändå själva kärnproblemet. Jag vill nu försöka förklara varför hela tanken med att köpa in en industrimodell är en dålig idé.

Första skälet: Det är vägen som är mödan värd

Som jag beskrivit i min tidigare artikel, ”Om modeller på papper och modeller i huvudet”, så har modellen i sig inget värde så länge den inte representerar en gemensam förståelse. Det är modellering som skapar en gemensam förståelse och ett gemensamt språk. Det är detta som är det verkliga värdet. Det finns ingen smitväg förbi detta.

Modellen i sig är vilseledande och skadlig om den inte representerar en gemensam förståelse som är tillräckligt krispig och genomtänkt. Och det kan den bara bli genom att vi verksamhets- och it-kunniga arbetat fram den själva, tillsammans.

Det är förstås möjligt att använda en industrimodell som referens och inspiration, något att plocka begrepp, benämningar och mönster från när de passar vår förståelse av vår domän. Men det är något helt annat än att implementera industrimodellen som vår egen. Vi som modellerar har alltid olika källor för inspiration, det är inget nytt och det är inte det vi pratar om här.

När man inför en industrimodell för sin verksamhet brukar det gå till så här. Man försöker matcha ihop de företeelser och begrepp man hittar i den egna verksamheten, med begrepp och mönster i standardmodellen. Men man saknar då den djupa förståelse för de egna företeelserna som bara en modellering av den egna verksamheten kan ge. Matchningen blir ytlig, grov och skev.

Andra skälet: En modell har alltid en viss kontext

Det som ofta glöms bort är att en modell aldrig är universell. En modell är framtagen för ett visst sammanhang, det vi kallar för kontext. Kontext kan vara smalare eller bredare, utefter olika dimensioner. En modell för en viss verksamhet passar sällan en annan verksamhet trots att de är i samma bransch. Om man håller sig på en mycket generell nivå passar den förstås, men då är ju kontexten inte längre samma. Kontexten är då mer allmän, den som är gemensam för verksamheterna. Därmed kan man naturligtvis skapa en gemensam standard för en hel bransch. Men då avgränsar vi oss till just det som ska delas mellan organisationerna, det som är en delad kontext, inte hela deras respektive interna världsbild.

Vi kan förstås matcha ihop begrepp för två eller flera olika verksamheter, det gör vi ju ofta som informationsmodellerare. Det gör vi genom att först skaffa oss en djup förståelse för respektive verksamhet, det vill säga att vi först behöver modellera respektive verksamhets begreppsvärld och först därefter kan vi ta fram den gemensamma modellen.

En industrimodell är extremt generell, eftersom den ska passa alla varianter av verksamheter i branschen i fråga, i alla länder med olika lagstiftning, kultur och språk. Det blir ”one size fits all” eller snarare ”one size fits no one”.

Resultatet

Resultatet av en satsning på att implementera en industrimodell för sin verksamhet blir att hopmatchningen mellan de egna företeelserna och begreppen i industrimodellen blir slarvig och skev. Begreppen blir för vida eller smala. Namnen blir missvisande. Man har helt enkelt inte tillämpat det enda arbetssätt som kan skapa den gemensamma förståelsen. Med andra ord: man har inte modellerat. I min tidigare artikel ”Om modeller på papper och modeller i huvudet” förklarar jag vikten av att bygga gemensam förståelse i en verksamhet och ett gemensamt språk som speglar den förståelsen.

Detta gör att man, om man inte ger upp tidigare, får en begreppsvärld och ett språk som blir trubbigt, skevt och missvisande. Det blir motsatsen till vad man behöver uppnå. I stället för att bygga en gemensam förståelse och ett krispigt språk så fryser man förståelsen och förstör språket. Och det är något som skadar en verksamhet för lång tid, ofta decennier. Jag har sett verksamheter där man inte kan använda allmänna termer som ”transaction”, ”agreement” och ”service” eftersom de har låsts fast i alldeles för specifika och missvisande betydelser. Jag har sett det hända gång på gång.

Specifika standarder

Det betyder inte att standarder är en dålig idé rent allmänt. Utan standarder kan vi inte kommunicera effektivt mellan organisationer. Men då handlar det om specifika mycket smalare standarder för vissa typer av data. Till exempel hur en order ser ut inom en viss bransch, eller hur ekonomiska data rapporteras. Vanligen har de mognat fram under många år. Och det handlar då aldrig om hur en hel bransch fungerar, tvärs över alla företeelser som hanteras i de respektive verksamheterna.

Och en sådan standard ersätter aldrig vår interna modell. Den interna modellen är tvärtom en förutsättning för att vi ska kunna matcha våra egna data mot standarden.

Orsaken till övertron på industrimodeller

Jag tror att det finns flera samverkande orsaker till föreställningen att en industrimodell kan ersätta en egen modell:

  1. Fokusering på konkret synligt resultat
    En tendens att fokusera på det synliga yttre resultatet i ställe för på det vi verkligen vill ha. Man ser bara själva modellen som det viktiga, utan att förstå att den inte har något värde om den inte representerar en gemensam förståelse och ett gemensamt språk i verksamheten.
  2. Saknad förståelse av kontextens betydelse
    Man har inte har förstått att en modell alltid avser en viss kontext, det vill säga hela det sammanhang där den är giltig. Det kan vara en bred kontext, men ändå alltid en viss kontext. En modell för en hel bransch kan aldrig vara en modell för en specifik verksamhet. En modell kan inte passa överallt och ändå vara tillräckligt specifik i alla lägen.
  3. Oseriösa leverantörer
    Leverantörer säljer in industrimodeller som om det vore en beprövad och framgångsrik lösning. Leverantörernas säljare har dock inte den kunskap som krävs för att ge bra råd.
  4. Saknad förståelse hos it-ledningar
    It-ledningar har vanligen inte den förståelse för informationsmodellering som krävs för att rätt bedöma säljarnas utsagor.
  5. Akuta behov
    Man har ofta misslyckats med tidigare försök att skapa en gemensam modell, och behovet blir alltmer trängande.
  6. Invändningar framstår som flummiga
    Det är svårt att argumentera för vad modellering egentligen handlar om och hur den bör bedrivas. Det låter flummigt och svårt och det kräver erfarenhet och kunskap som man saknar. Det alternativet står sig slätt mot ett mer konkret alternativ, att bara köpa in något så är problemet snart löst.

Vad kan vi göra?

Vad kan vi göra åt det? Ja, vi som är verksamma i branschen, skriver och undervisar om modellering har uppenbarligen inte lyckats förmedla en förståelse av vad vi egentligen håller på med. Men det är aldrig för sent att göra rätt. Låt oss hjälpas åt. Det här är i mitt bidrag.

Har du varit med om att införa en industrimodell? Hur gick det? Har du andra erfarenheter? Kommentarer är välkomna.

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 1 april. Då handlar det om skillnaden mellan data och information.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.