Trångsynt systemdefinition leder till stora problem

Detta är en första artikel i en serie med inriktning på begreppet "system".

Om man slår upp en svensk dagstidning en alldeles vanlig veckodag möts man ofta av skrämmande rubriker. Med "kravingenjörsglasögonen" på näsan hittar man överskrifter som: "Dyrt IT-system knappt använt", "Böter på spårvagnen trots skickade sms", "Tågen stod stilla - igen"...

Vi är ett app-älskande folk i ett informationssamhälle som slår sig för bröstet och basunerar ut styrkan i våra systemsatsningar. För vi är ju bra på att bygga system, eller hur?

Ett flertal återkommande undersökningar (exempelvis den ofta omtalade CHAOS-rapporten från amerikanska företaget Standish Group, som intervjuat mer än 80 000 företag sedan 1994) visar entydigt att en av de viktigaste faktorerna för att ro i land ett IT-projekt, är att "involvera användarna". Men vad menas med det egentligen? Inom den agila projektstyrningsmodellen Scrum, realiserar man denna "användarinvolvering" genom införande av Sprintdemon i processen och rollen Product Owner som en surrogatroll (en roll som fungerar som representant för en mängd olika roller, personer och viljor...) med uppgiften att svara på frågor och säga JA eller NEJ till föreslagna lösningar.

Men det räcker inte att måla om och köpa nya designmöbler om huset är felkonstruerat med alla tre toaletterna på första våningen, och inga på de andra våningsplanen. Användbarhet och "snygga knappar" är meningslöst om det konstruerade Automatiska Systemet inte används överhuvudtaget eller brukas på ett kontraproduktivt sätt.

Det gäller att involvera användarna även i den konceptuella beskrivningen och representationen av verkligheten i den aktuella kontexten för att förstå och tydliggöra den framtida arbetssituationen där det införda automatiska systemen tillför mätbar nytta i den vardagliga och verkliga arbetsdomänen (the Area of Work).

Låt oss titta på några upplysande begrepp och definitioner delvis från IREB CPRE1, den internationella certifieringsutbildningen för kravingenjörer.

AS, Automatic System: det automatiska systemet är själva "datasystemet" som vi har uppgiften att bygga, förbättra eller ändra på något sätt. Eftersom begreppet "system" kan tolkas på många olika sätt, rekommenderar jag alla att försöka vara övertydlig. Problemen inom krav ligger ofta inom "mjuka områden", vi måste förstå de "mjuka systemets"2  drivkrafter, processer, scenarion etc.. och allt kommer INTE att inkorporeras i det automatiska systemet. Om vi exempelvis har en verksamhetsregel (Business Rule) som säger: "alla som arbetar på sjukhuskliniken skall ha nytvättade vita rockar", innebär det inte att vi måste realisera denna regel i en del av det automatiska systemet (även om det är en viktig del av AoW). Det skulle vara möjligt att realisera en automatisk kontroll även av de vita rockarna med olika RFID-taggar och låta det automatiska systemet styra någon typ av alarmfunktion om läkarens tag är separerad från läkarrockens tag. Men vem vill betala för det? Exemplet realiseras givetvis bättre av en manuell kontrollprocess, som efter ett tag kan bli ett "naturligt beteende" utan krav på att ens behöva kontrolleras eller styras av någon process- eller regeldokumentation.

Non-relevant context: icke-relevant kontext, är det som är utanför det vi bryr oss om när vi undersöker och utvecklar ett automatiskt system för en arbetsdomän.

Relevant context: relevant kontext, det som är "innanför", med andra ord, det vi bryr oss om. Ett nätverk av tankar och ideer som krävs för att man ska kunna förstå händelser och påståenden. Eftersom vi är speciellt intresserade av automatiska system, så är den relevanta kontexten oftast detsamma som det automatiska systemets kontext (automatic system context) dvs. allt som behövs för att vi ska förstå det automatiska systemet och VAD det ska göra, så att vi på bästa sätt kan representera den aktuella kravmängden och kravställa själva produkten eller tjänsten.

Boundary: gräns, är i en visuell representation, en linje som skiljer på det som är innanför och det som är utanför. Det finns flera gränslinjer i vår modell: gränsen för det automatiska systemet (automatic system boundary), det automatiska systemets kontextgräns (automatic system context boundary),och gränsen för arbetsdomänen (Area of Work boundary).

Grey-zone: "grå-zon", är området mellan dragningen av en specifik gränslinje vid två olika tidpunkter. Om exempelvis scopet ändras innebär det i praktiken att gränsen för det automatiska systemet (automatic system boundary) inte kan ritas exakt lika vid tidpunkterna t1 och t2. Mellanrummet (ytan) mellan de båda gränserna för det automatiska systemet vid t1 respektive t2 kallas därmed automatic system boundary grey-zone. På samma sätt finns det en Area of Work boundary grey-zone, och en automatic system context boundary grey-zone (eller bara context boundary grey-zone).

Att vara medveten om grey-zone som fenomen, innebär att man inser att ingenting är fixt och att allt ändras med tiden, oavsett om vi vill det eller inte.

Scope: avgränsning av det automatiska systemet (systemavgränsning), det som ligger innanför gränsen för det automatiska systemet (automatic system boundary) omfattar allt det som vi kan bygga och designa. Inom ett specifikt projekt kan man ofta tro att scopet är fixerat en gång för alla, för att senare inse att avgränsningen varit luddig, otydlig och "rört på sig" (scope creep). Det innebär att det automatiska systemet helt plötsligt förväntas utföra fler uppgifter som tidigare utfördes på annat sätt inom AoW, eller att AoW har utökats och det automatiska systemet skall stödja även den utvidgningen. Problemet ligger återigen i det faktum att man inte kan bygga ett bra automatiskt system utan att förstå arbetsdomänen och att tydligt visa på hur det automatiska systemet skall fungera i sitt sammanhang. Utan den kunskapen kommer scopet hela tiden vara en osäkerhetsfaktor.

AoW, the Area of Work: arbetsdomänen i vilken det införda automatiska systemen är tänkt att tillföra en tydlig mätbar och upplevd nytta. AoW omfattar allt som företaget gör, skapar, använder och förbrukar för att utföra det som företaget/organisationen har som mål och uppgift att förverkliga. Om AoW är en ortopedklinik, så omfattas även telefoner, handböcker, medicinsk utrustning, de anställda och deras kunskap, korridorsdiskussioner och möten, etc. Allt som krävs för att lösa inkommande "uppgifter" (external events), tillräckligt bra enligt organisationens mål och visioner. Det är denna miljö som det påtänkta automatiska system ska göra nytta, antingen genom att förenkla redan existerande aktiviteter eller genom att utöka AoW till att innefatta nya uppgifter och aktiviteter.

Jag tror att pudelns kärna (eller "djävulen i Mefistofeles gestalt") är att det finns en rädsla att adressera "mjuka frågor" i en given situation. Om man har blivit anställd att bygga "det hårda"; knacka kod, bygga och snickra på det automatiska systemet, då fortsätter man med det, gärna i avancerade verktyg och strukturer, vilket ger en falsk trygghet. Om man inte vet varför man gör det man gör och inte vet vart man ska, hjälper det inte att man låtsas att det inte regnar, förr eller senare blir man blöt ändå.

Tänk dig att du är anställd för att vara del i bygget av ett avancerat meddelandesystem. Teamet trimmar funktionerna och skapar högkvalitativa features som är både snabba och stabila, och man har utfört användarstudier för både färg och form.

Men i verkligheten så funkar en enkel post-it-lapp på datorskärmen eller på organisationens visuella översiktstavla, bättre. Både enklare, snabbare och upplevs "mer naturligt". Vi stöter ideligen på system som inte används eller som inte alls används så som det var tänkt: exempelvis den extremt dyra designerfåtöljen som ingen kan sitta bekvämt i, och som bara används som en plats för smutstvätt.

Att bygga automatiska system för systembyggandets egen skull är dumt.

Att bygga automatiska system för alla tänkbara processer i arbetsdomänen, bara för att man får betalt eller för att man själv "tycker det är kul", är nästan kriminellt!

Det är viktigt att skilja på ANSVAR och KOMPETENS. Kravrollen kan ha ett begränsat direkt ansvar men skall ha kompetens att röra sig och kommunicera över hela skalan. I den kompetensen ligger ett indirekt ansvar att "få det hela att konceptuellt hänga ihop", om det inte gör det då MÅSTE man försöka öppna ögonen på folk och skapa broar och kommunikativa representationer.

Ett automatiskt system som inte används och blir en naturlig del av arbetsdomänen, är ett dåligt system oavsett om det levererar alla listade funktioner enligt kravspecen.

Kravingenjörens kompetens måste således omfatta verksamhetsanalys och han/hon ska känna ett ansvar för det automatiska systemet, att det verkligen levererar den tänkta nyttan och svarar mot ett verkligt, explicit uttalat eller latent omedvetet, behov.

Kravrollen är alltså inte bara en "hatt", utan kravingenjören har även mantel.

En kravsuperhjälte

---

1. IREB CPRE = International Requirements Engineering Board Certified Professional for Requirements Engineering

2. Läs mer om "mjuka problem" inom området systemteori:

Peter M. Senge (1990) The Fifth Discipline - The Art & Practice of The Learning Organization.

Peter Checkland (1981) Systems Thinking, Systems Practice.

Peter Checkland, Jim Scholes (1990) Soft Systems Methodology in Action.

Peter Checkland, Jim Sue Holwell (1998) Information, Systems and Information Systems.

Peter Checkland, John Poulter (2006) Learning for Action.

Donella Meadows (2008) Thinking in Systems - A primer

Lars Skyttner (2006) General Systems Theory: Problems, Perspective, Practice

Gerald M. Weinberg (2001) An Introduction to General Systems Thinking.

Russell L. Ackoff (2010) Systems Thinking for Curious Managers

Ludwig von Bertalanffy (1976) General System theory: Foundations, Development, Applications.

Om författaren

Stefan Eekenulv är en passionerad seniorkonsult inom kravhantering och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten.