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 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 verksamhetsregler?

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 student 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
  • 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
  • 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 som begrä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:

1. 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.

2. 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

22.06.09