Vad har en certifierad verksamhetsutvecklare som du inte har?

Att arbeta som verksamhetsutvecklare kan se väldigt olika ut, olika dagar i olika verksamheter. Rollen har många olika ”hattar” i sin garderob. För att nämna några: workshopledarens, förändringsledarens, tjänsteutvecklarens, processutvecklarens och inte minst kommunikatörens. Är det någon du saknar eller skulle vilja putsa upp?

Att utveckla sin kompetens kan ge både motivation och karriär en skön skjuts framåt. Detsamma gäller för verksamheten du verkar inom. Vår utbildning Certifierad verksamhetsutvecklare är för dig som vill driva och uppnå konkreta och hållbara förbättringar utan att tappa fokus på kunder och andra aktörer i omvärlden. 

För att kunna ta reda på om Certifierad verksamhetsutvecklare är rätt utbildning för dig så har vi spelat in ett par webbinarier: 

”Verksamhetsutvecklarens vardag och verktyg” är ett webbinarium från mars i år, där utbildningsledarna Lena Dohrnér och Johan Svärd presenterar utbildningens innehåll. Johnny Fyrman, Teamlead PMO på Södra och tidigare elev, deltar också. Han delar med sig av sina erfarenheter av att gå utbildningen, och hur det är att sedan nyttja sina nya kunskaper i den egna organisationer. 

I ”Panelsamtal:Vilken väg är rätt för mig?” deltar ansvariga för utbildningarna Certifierad Chefsarkitekt, Certifierad Verksamhetsutvecklare, Certifierad Verksamhetsarkitekt samt Certifierad IT-arkitekt Master. De diskuterar och svarar på frågor om vad som skiljer de olika utbildningarna och rollerna åt. 

”En bra blandning av teori och praktik. Jag har lärt mig hur jag ska ta mig framåt som verksamhetsutvecklare. Både hårt och mjukt, verktyg/metoder och en massa resonemang och övningar som tillsammans har förankrat det vi gått igenom, så att det går att använda i vardagen sen.”  – citat från tidigare deltagare Janet Ståhl.

Certifierad verksamhetsutvecklare startar 31 augusti. Programmets 12 utbildningsdagar är fördelade på sju tillfällen under hösten 2022. 

Skaffa några nya hattar och putsa upp några gamla. Boka din plats på utbildningen här.

Vi kompetensutvecklar människor i samarbete med DF Kompetens.

Informationsmodellering: Integrera text och grafik

En modell – informationsmodell eller annan modell – är inte komplett förrän den är gestaltad i både grafik och text. Och vi bör sträva efter att integrera texten och grafiken så långt det är möjligt.

Det vanliga är att en informationsmodell endast görs som ett ER-diagram. Så vanligt att många till och med sätter likhetstecken mellan informationsmodell och ER-diagram. Ibland kan diagrammet åtföljas av text vid sidan av. Men då ser man vanligen inte texten som en fullvärdig del av modellens gestaltning utan som en bifogad förklaring av modellen. Skillnaden kan tyckas subtil men är avgörande menar jag, för vår förståelse av vad en modell är.

En komplett modell bör vara gestaltad i både diagram och text

Jag menar att en informationsmodell bör vara gestaltad i både text och grafik. Det är sant att en bild säger mer än tusen ord. Men det är likafullt sant att en text säger mer än tusen bilder. Och ännu mera sant att med text och bild tillsammans så får vi en synergi som når ännu längre i tydlighet och klarhet. När vi behöver uttrycka oss både visuellt och verbalt, blir det inte bara tydligare utan vi kan även tänka klarare.

Modeller är våra centrala verktyg. Och hur vi gestaltar dem är avgörande för hur effektiva de blir, både som analys- och tankeverktyg i sig själva samt för att kommunicera det vi kommit fram till. Vi bör därför använda oss av alla till buds stående medel för att gestalta våra modeller. Då behöver vi både diagram och text, samt att vi låter diagram och text stödja varandra så mycket det bara går.

Diagram är för informationsmodeller först och främst alltid ett eller flera ER-diagram av något slag. Men också andra typer av diagram kan behövas, så som förekomstdiagram (instance diagrams) och tillståndsdiagram (state charts). Text innebär strukturerad text av olika slag.

Den amerikanske statistikern och grafikern Edward Tufte, som jag nämnt i tidigare artiklar, menar att detta är viktigt. De grafer som vi gör för att förmedla data, information eller kunskap, bör ha texter som är så tätt integrerade med själva grafen som det bara går. Bild och text ska samverka tätt.

Historien om förhållande mellan text och bild

Varför är vi så inställda på att separera text och bild? Det har nämligen inte alltid varit så. Det finns en historisk förklaring sägs det. Före den moderna tiden, före tryckkonsten, då man alltid skrev och ritade för hand var det vanligt att text och bild följdes åt på ett fullständigt integrerat sätt. Text och illustrationer löpte tillsammans på samma sidor i dokumenten.

Se exempel bild I och II nedan.

Bild I: Nicolaus Copernicus: Diagram som illustrerar den heliocentriska teorin om solsystemet, cirka 1520.
Bild II: Leonardo da Vinci: Penna-och-bläckstudier av mänskligt foster, cirka 1510.

När så tryckkonsten kom på 1500-talet blev det tekniskt omöjligt att integrera text och bild på det sättet. Boktryckare tryckte text med hjälp av typer, först i trä och sedan i bly. Bildsnidare och gravörer tryckte bilder med hjälp av träsnitt och graverade plåtar. Bokbindare band ihop det hela till böcker. Illustrationerna hamnade på det sättet för sig själva i slutet av bandet.

Integrera text och bild!

Idag är vi fria från den begränsningen som tryckerikonsten orsakade. Vi har nu teknik som ger oss alla möjligheter att kombinera text och illustrationer.

Men det finns en tröghet som låter föreställningen att vi ska hålla isär text och illustrationer leva kvar. I de modeller jag möter ser jag nästan alltid diagram för sig och text för sig.  I de lyckliga fall det finns text över huvud taget vill säga.

Men låt oss släppa den vanföreställningen och börja integrera text och bild.

Hur integrerar vi text och bild

Text och diagram ska samverka, vilket innebär att de behöver visas och hanteras tillsammans så gott det går.

Microsoft Word är ett utmärkt verktyg för att sätta samman text och bild till en helhet. Fast det fungerar bara för mindre diagram, som ryms på samma sida som åtföljande text.

I övrigt kan vi se till att ha förklarande texter i och i anslutning till våra diagram där så är lämpligt.

Exempel från informationsmodeller

Jag har i olika sammanhang strävat efter att integrera text och bild så mycket det går för att få till modeller som förmedlar mer kunskap och gör det på ett tydligare sätt. Jag visar i det följande några exempel från informationsmodeller som jag jobbat med i olika sammanhang. Jag vill visa hur man kan göra och vill också illustrera att det inte finns ett sätt utan vi måste vara kreativa och göra på olika sätt i olika sammanhang.

Bild III: Utsnitt av informationsmodell från bank: Förekomstdiagram med förklarande text. Modellen visar med exempel hur olika lokala avtalsstrukturer översätts till en global, för analys och rapportering.
Bild IV: Utsnitt av informationsmodell från försäkringsbolag: Förekomstdiagram med förklarande text. Förklarar med exempel de två olika typfallen av motorfordonsförsäkring.
Bild V: Utsnitt av informationsmodell från försäkringsbolag: ER-diagram med förklarande text. Förklarar hur försäkringsvillkor förekommer på olika nivåer i produkt- och avtalsstrukturen.
Bild VI: Utsnitt av informationsmodell från försäkringsbolag: ER-diagram med förklarande texter. Förklarar hur beloppen för skadeutbetalningar, premievolymer och försäkrade belopp rapporteras centralt.
Bild VII: Utsnitt av informationsmodell: ER-diagram med förklarande texter. Presenterar förslag på modell för bonushantering på en bank.
Bild VIII: Utsnitt av informationsmodell från bank: Beskrivning av möjliga värden för attributet som visar vilket tillstånd ett kundavtal befinner sig i. Hur tillstånden kan följa varandra över tid visas med ett tillståndsdiagram.
Bild IX: Utsnitt av informationsmodell från bank: Utsnitt av en scenariobeskrivning med text och åtföljande förekomstdiagram. Visar i en serie av händelser hur en dispyt om en betalningstransaktion hanteras.

Ett av många sätt för bättre modeller

Som sagt, för oss arkitekter är modeller av olika slag de centrala verktygen. Vårt jobb kokar ner till att analysera och beskriva verksamheter med hjälp av modeller av olika slag. Och att använda dessa modeller för att hjälpa och guida alla dessa som tillsammans utvecklar våra verksamheter.

Detta med att integrera text och bild är bara ett av många områden jag menar att vi behöver utveckla för att göra bättre modeller, de vill säga modeller som tjänar oss bättre i vårt arbete. Övriga idéer hittar du i de tidigare artiklarna jag skrivit, och mer kommer framöver.

/Peter Tallungs, IRM

Nu tar denna artikelserie ett sommaruppehåll. Nästa artikel publiceras i mitten av augusti. 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

Maximera innehållet – men snåla med bläcket!

Om vi ska göra riktigt bra modelldiagram bör vi behärska uttrycksmedlen. Grundläggande är hur vi dimensionerar linjer, typsnitt och färger.  Den kände amerikanske grafikern och statistikern Edward Tufte har skrivit en serie böcker om hur man använder grafik för att förmedla data, information och kunskap. Han förespråkar en minimalism i uttrycket.

Edward Tuftes idé om maximal information med minimal mängd bläck

Edward Tufte menar att varje uns bläck i en graf ska finnas där av en anledning. Om den inte tillför någon information ska den ovillkorligen tas bort.

Först och främst ska allt som bara är dekor bort. Sedan ska vi använda så tunna linjer som möjligt. Färg ska vi bara använda då den verkligen har betydelse, och då i så ljus nyans som möjligt. På så sätt finns det inget som skymmer och våra grafer blir tydligare. Vi nyttjar då de grafiska uttrycksmedlen effektivt och ändamålsenligt för att förmedla informationen.

Däremot då det gäller innehållet, det vill säga vilken information som förmedlas, förordar han motsatsen till minimalism. Vi ska kombinera så mycket kunskap som möjligt i en graf. Det är då en graf blir riktigt intressant. Alla riktigt intressanta grafer sammanför och kombinerar flera olika dimensioner.

Tufte har infört begreppet ”Data-Ink Ratio”, det vill säga en tänkt kvot mellan det bläck som verkligen förmedlar någon data i en graf och den totala mängden bläck som använts. Den kvoten ska hållas så hög som möjligt. Det innebär att vi ska anstränga oss att få in mer data, information och kunskap i våra grafer utan att använda mer bläck än vi behöver. Likaså ska vi försöka minska mängden bläck utan att förlora information.

En onödigt stor mängd bläck kan betyda onödigt tjocka linjer, för mycket svärta i linjerna, onödiga linjer eller detaljer som inte fyller någon funktion utöver att vara dekorativa. Det kan också betyda att vi använder färg där den inte tillför något som inte kan förmedlas på ett enklare sätt. Eller att vi använder en kraftig färg där en ljusare nyans skulle göra jobbet.

Edward Tuftes exempel

I sin första bok om informationsdesign, The Visual Display of Quantitative Information från 1983, exemplifierar Tufte detta med ett tänkt exempel.

Han utgår från ett stapeldiagram där han i fem steg tar bort grafiska element utan att minska datainnehållet.

Det första han gör är att ta bort onödiga stödlinjer i bakgrunden. Sedan tar han bort den blå bakgrundsfärgen som ju faktiskt inte tillför något. ”Chart-junk” (diagramskräp) är vad han kallar riktigt dåliga exempel på onödiga grafiska element. I nästa steg ryker ramlinjen på två sidor, den övre och den högra. Därefter ramlinjen på vänstra sidan, fast han ersätter på samma gång de horisontella stödlinjer han tog bort tidigare med horisontella slitsar i staplarna. Till sist tar han bort ramlinjen i underkant.
Det här kanske är ett lite väl extremt exempel, men illustrerar ändå hur vi kan ifrågasätta grafiska element och plocka bort dem när de inte tillför något.

Många av de mer avskräckande exempel på chart-junk har Tufte hittat från sammanhang då upphovspersonen inte har kunnat bärga sig från att leka med datorgrafiken. Här ser vi en karta med Nordmakedoniens regioner. Illustratören har använt olika blåa färger för landets regioner. Dessutom har hen tyckt det varit snitsigt med en färggradient i varje fält. Varken färgerna eller gradienterna tillför någon information över huvud taget.

Vad betyder det för oss

Hur kan vi tillämpa Tuftes tänk i de diagram vi designar: ER-diagram, förekomstdiagram, tillståndsdiagram, förmågekartor, processdiagram med mera?

Jag gör så här:

  • Linjer
    Jag ritar så tunna linjer jag kan, och byter svarta linjer mot mörkgrå när det är något jag vill hålla ur fokus. På så sätt spar jag den kraft som ligger i den svarta färgen till när den behövs, det vill säga när jag vill rikta fokus mot något särskilt element. Att rita tjocka svarta linjer i onödan är som att ständigt skrika. Vi utnyttjar då inte den möjlighet till dynamik vi har oss till buds.
  • Texter
    Jag fetmarkerar text endast då jag vill lyfta fram något som rubriker och liknande. Och de texter jag vill tona ner skriver jag i grått.
  • Färgade linjer och texter
    Jag spar färger till när de verkligen behövs. Färger är kraftfulla grafiska medel. Därför bör de användas med måtta och sparas till de tillfällen då de tillför något. Varje färg måste då ges en mening, någon egenskap man vill förmedla. I annat fall behövs den ju inte. Färger är en begränsad tillgång som betydelsebärare. Eftersom olika nyanser av samma färg inte tydligt kan skiljas från varandra återstår det inte så många kulörer som vi kan använda. För linjer och texter mot en ljus bakgrund fungerar endast kraftiga kulörer. Då har vi förutom svart och mörkgrått, endast blå, grön, röd och mörkgul att tillgå.
  • Färgade ytor
    Färgade ytor behöver man sällan, oftast tillför de inget. Men där man ska färglägga ytor bör man välja mycket ljusa färger, annars slår de emot en med alldeles för stark effekt.

Fortsättning följer

Jag kommer att berätta mer om Edward Tuftes idéer framöver och hur de kan hjälp oss att göra bättre modeller. Bland annat kommer jag berätta om vikten av att integrera text och grafik, samt om hur vi kan få riktigt intressanta modeller genom att sammanställa olika dimensioner i en och samma graf.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 23 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

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

Informationsmodellering: Om namngivning

Hur ska vi namnge alla de element i en informationsmodell som representerar verksamhetsbegrepp?

När vi tar fram en informationsmodell för en verksamhet eller en tjänst behöver vi besluta om namn för många olika saker. Det är inte bara entiteter, attribut och relationer som ska han namn utan också de specifika attributvärdena i det fall de utgör ett bestämt värdeförråd för något attribut. Alla dessa är verksamhetsbegrepp och bör ges korrekta och tydliga namn. Vad ska vi tänka på då? Vad är ett bra namn? Och hur gör vi med de namn som redan är etablerade på olika sätt i verksamheten, men kanske inte så lämpliga alla gånger?

Begrepp har namn och definition

Varje element i en informationsmodell, vare sig det är en entitet, ett attribut, en relation eller ett visst attributvärde, representerar en företeelse för vilket vi behöver ett namn.

Ibland handlar det om en helt ny företeelse i denna verksamhet men oftast om något som redan finns. Ett begrepp har två viktiga aspekter som bägge behöver uttryckas i naturligt språk. Dels behöver vi ta fram en korrekt och tydlig definition för att ringa in betydelsen, och dels behöver vi ett bra och tydligt namn.

Det kan till exempel vara att vi erbjuder våra kunder olika varor eller tjänster. Namnet vi bestämmer blir kanske ”Produkt”, och definitionen blir ”Det vi erbjuder våra kunder”.

Märk att det inte är själva namnet ”Produkt” som är begreppet i fråga utan det som namnet och definitionen står för. Namnet ”Produkt” är som ett handtag, en symbol eller ett tecken med vilket vi kan framkalla begreppet i våra hjärnor.

Om synonymer

Vi kan använda ett annat namn för samma begrepp (”Produkt”). Vi kan till exempel säga ”Vara”, ”Artikel” eller uttrycka oss på engelska och säga ”Product”, och ändå mena samma begrepp. Det kallas synonymer när ett och samma begrepp har flera namn. Det kan också finnas homonymer. Det är att ett och samma namn har flera betydelser.  

Vad är ett bra namn?

Ett bra namn ska vara korrekt, det vill säga så tydligt som möjligt peka på betydelsen hos det begrepp man vill använda namnet för. På sätt och vis fungerar det då som en liten definition i sig. Idealet är att man direkt förstår vad som menas och vad som inte menas. Åtminstone om man har lämplig förförståelse, som en allmän kunnighet om området i fråga. Namnet får inte ha en för bred betydelse och inte heller för snäv.

Vikten av bra namn

När vi sätter namn på detta sätt bygger vi de facto verksamhetens språk. Det är svårt att tänka sig en mer central och ansvarsfull uppgift som vi som modellerar kan ha. Med en korrekt och tydlig terminologi blir all kommunikation tydligare, i varje interaktion och integration. Risken för oklarhet och missförstånd minskar i varje punkt.

Men det finns också en annan minst lika tung aspekt som man kanske inte alltid tänker på. Vi använder språk inte bara för att kommunicera utan även för att tänka. Med en rik och tydlig vokabulär kan vi tänka klarare, både som individer och som grupp.

Råd för namn i informationsmodeller

Här följer ett antal saker att tänka på då vi bestämmer namn:

Förkorta inte

Jag anser att man i det längsta bör undvika förkortningar i de namn man sätter. Dels ökar det risken för misstolkning, och dels blir det en extra börda att hålla reda på alla förkortningar. Ty vi vill ju vara konsekventa så en term alltid förkortas på samma sätt överallt. Undantaget är några få mycket allmänna och etablerade förkortningar som ”SEK”, ”kg” etcetera.

Låt namnet uttrycka den fulla betydelsen

Om ett attribut heter ”Vikt” kan det förr eller senare bli osäkert i vilken viktenhet som avses.
Ändra till ”Vikt – kg”.

Använd verksamhetens språk

Det vill säga svenska i helsvenska verksamheter och engelska i verksamheter som ser sig som mer internationella. Det är ju verksamhetens språk vi normerar, inget annat.

Inom it-utveckling har det vuxit fram en informell standard att skriva namnen på programkonstrukter som moduler, klasser, metoder och variabler med mera samt även kommentarer på engelska. Därför tror ibland it-utvecklare att man ska skriva även verksamhetsbegrepp på engelska, även i det fall där verksamhetsspråket är svenska. Eftersom man vill vara konsekvent händer det också att engelskan fortplantar sig till andra sammanhang som rapporter med mera.

Därför ser man ibland amatörmässiga och ofta helt missvisande försök till engelsk översättning av svenska facktermer.

Jag menar att verksamhetstermer alltid ska vara på verksamhetens språk och det bör vara konsekvent överallt. Alltså även i programkod, databaser och filer, som ju är en integrerad del av verksamheten. 

Använd naturligt språk

Det innebär till exempel att man använder både versaler och gemener samt blanksteg.

Det förekommer annars att man i it-funktioner är påverkad av det skrivsätt som blivit standard i programkod på grund av att man där är begränsad till sammanskrivning av ord, så kallad ”Camel Casing”. Man skriver ”numberOfPieces” i stället för ”Number of pieces”. Men det finns alltså ingen anledning att tillämpa det skrivsättet utanför programkod.

Hur gör vi med redan etablerade men dåliga namn?

Det händer ofta att man sedan tidigare har namn i databaser och i system som är felaktiga och missvisande. Då kan det kännas som att vi i konsekvensens namn behöver fortsätta att använda de namnen. Namn har en tendens att bita sig fast väldigt hårt.

Men en dålig terminologi hämmar en verksamhets möjligheter framgent. Vår hållning måste vara att vi tar språk på allvar och att vi tar vårt ansvar. Vi kan inte bara fortsätta att propagera fel bara för att de en gång har uppstått. Vi behöver rätta till felen, även om det känns jobbigt för stunden. Vi behöver ju kontinuerligt vårda och utveckla verksamhetens terminologi.

Men om vi bara byter en term mot en annan, vet ingen vad vi menar med den nya termen. Förvirringen blir stor, man kanske tror att det är ett nytt begrepp, och inte ett nytt namn på ett befintligt begrepp.

Vi behöver hantera detta på ett ansvarsfullt sätt, det vill säga rätta till felaktigheter utan att ändringen skapar onödig förvirring. Det går till så här: I informationsmodellen anger vi det namn vi gemensamt kommit fram till är bäst, utan hänsyn till de misstag som har gjorts tidigare. Samtidigt anger vi i informationsmodellen det gamla etablerade namnet som en synonym som förekommer i verksamheten.

På så sätt får vi en spårbarhet från den äldre termen till den nyare. Våra informationsmodeller blir på så sätt på samma gång deskriptiv (beskriver befintligt språkbruk i verksamhet och it-system) och normerande (beskriver vad vi kommit fram till att det korrekta språket bör vara).

Exempel

Jag vill här visa exempel på hur det kan se ut i en informationsmodell. Detta är ett utsnitt från ett ER-diagram som visar en entitet med många attribut. I det följande beskriver jag de olika delarna av diagrammet.

  • Entitetens namn: ”Företagskonkurs – Statushändelse”
    Fetstil för att lyfta fram namnet, tydligt utskrivet och med versaler och gemener. Namnet är valt för att så tydligt som möjligt förmedla vad en förekomst av entiteten står för.
  • Källa för informationen: ”BLV (Daglig avisering via Bisnode)”
    Anger källan för informationen (BLV står för Bolagsverket). I detta fall hade vi många olika informationskällor och det var viktigt att lyfta fram dessa, därför rött typsnitt.
  • Entitetens definition: ”Händelsen att en företagskonkurs fått en ny status”.
    Försöker ge en så bra definition som möjligt för en förekomst av entiteten. Mörkgrått typsnitt för att tona ner uppgiften i förhållande till entitetens namn.
  • Grupprubriker för attribut: ”Identitet”, ”Typ av statushändelse” etc.
    Vi har strävat efter att ordna (sortera och gruppera) attributen i en ordning som känns naturlig och meningsfull. Detta är ett enkelt grepp för att öka modellens läsbarhet och begriplighet. Grupprubrikerna är mörkblå för att skilja ut dem från attributnamnen.
  • Attributnamn
    Vi har valt namn som försöker att ge en fullständig och tydlig betydelse.Logisk datatyp är med på många ställen som suffix. Vi har inte varit rädda för att skriva ut även långa namn och namn i flera led då det ökat tydligheten.
  • Teknisk datatyp och fältlängd: ”chr 1”, ”int”, ”dat” ”dat tid” etc.
    Skrivet i blått. Viktigt för att tolka data rätt.
  • Markering för obligatoriska attribut: ”obl”
    Behövs också för att tolka data rätt.
  • Fysiska fältnamn: ”PRIMARYKEY” ”KODFORDOMSTOLSOMUPPHAVTKONK” etc.
    Detta är vad attributen i fråga råkar heta i it-systemet, och som vi idag inte kan ändra. Detta är en typ av synonymer. Vi har använt ett grått typsnitt för att tona ner dessa i förhållande till de normerande attributnamnen.Det är viktigt att ha med fysiska namn för att få en spårbarhet till fysiskt data. Om vi inte har med dessa så blir det som att vår modell ”hänger i luften” utan koppling till en fysisk verklighet.

Användning av namnen i informationsmodellen

I de flesta sammanhang jag jobbat har vi på detta sätt använt informationsmodellen som en normering av den gemensamma terminologin i hela verksamheten. De namn vi satt är de som vi vill ska användas genomgående, som verksamhetens gemensamma språk. Det kommer dock att finnas synonymer alltjämt. Man kan inte bygga om alla rapporter och system bara för att vi har infört normerade begrepp.

Vi dokumenterar alla synonymer vi stöter på och i vilket sammanhang de förekommer. Men i allt nytt som görs kommer denna nya standardiserade terminologi att användas.

Namn i programkod, databaser och filer

Det är viktigt att detta normerade språk används i alla sammanhang. Många tror att man i programkod och liknande kan ha ”tekniska namn” som är annorlunda. Det är inte bra. Det ökar friktionen i kommunikationen. Jag menar att det är ett arv från den tiden då namn behövde vara korta och endast i versaler i programkod och databaser, av tekniska skäl. Så är inte fallet längre, i något sammanhang tror jag. Det man kan behöva göra det är en viss transkribering av namnen för de tekniska sammanhang där man inte har samma teckenuppsättning. Jag brukar då göra den transkriberingen redan i informationsmodellens textdel. 

Transkriberingsmetod

Den transkriberingsmetod vi då väljer bör vara den som gör minsta våld på namnen och har störst läsbarhet. Den metod vi har valt ofta är följande:

  • Ersätt Å, Ä med A, liksom å och ä med a.
  • Ersätt Ö med O, liksom ö med o
  • Ersätt blanksteg med understreck ”_”
  • Ersätt bindestreck med understreck ”_”  

”Konkurs avslutad – datum” blir då ”Konkurs_avslutad_datum”

Denna metod har en tradition inom databasdesign, vilket är en fördel.

Det finns dock en annan transkriberingsmetod som kommer från programvaruutveckling. Den kallas för ”Camel casing” eller mer anekdotiskt för ”Hungarian C”. Den består i att man använder versaler endast för att avdela mellan ord.

”Konkurs avslutad – datum” blir då ”konkursAvslutadDatum”.

Jag menar att den första metoden är att föredra och detta av tre skäl:

  1. Metoden gör inte onödigt våld på namnet. Läsbarheten är bästa möjliga. 
  2. Versalerna har samma funktion som före transkriberingen.
  3. Metoden har en tradition inom databasutveckling vilket ligger kulturellt och historiskt närmare informations- och databehandling än programvaruutveckling.  

Hur gör ni?

Vad sägs om detta? Hur gör ni i er verksamhet?

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 9 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