Inför ett byte av affärssystem
Kravhantering och förstudier är inget nytt inom IT-branschen men det är först på senare år som det har renodlats till ett eget kompetensområde med modeller och verktyg.
I branschtidningar går det att läsa om företag och organisationers affärssystemsprojekt som överskrider budget med miljoner och med undermålig funktionalitet. Med bakgrund till erfarenheter som dessa så börjar både leverantörer av anpassade IT-system och beställare inse vikten av att utveckla sättet man jobbar på för att samla in och formulera krav som är mätbara och riktiga.
Varför kravhantering?”Har vi annullerat orderrader så är det väl självklart att de inte skall synas på våra orderbekräftelser till vår kund, vi har ju tagit bort dom!” uttryckte en säljare efter att ha upptäckt att annullerade orderrader syntes på utskriften av en orderbekräftelse till sin kund. ”Det är mycket bra att kunderna ser att vilka av deras orderrader som vi har annullerat och kanske ersatt med andra produkter på orderbekräftelsen, kunderna uppskattar verkligen denna tydlighet från vår sida!” reagerade en annan säljare på ett annat företag. Samma funktion men den upplevs som fel av en användare och rätt av en annan användare. Vem har då rätt och vem har fel? Båda har givetvis rätt därför att en funktion kan behöva fungera annorlunda för två olika företag beroende på deras verksamhet och målsättning. För det första företaget hade alltså standardfunktionen behövts konfigureras annorlunda. Detta behovs identifieras och konfigureras innan systemet går i drift men för de båda företagen i exemplet är det kanske så självklart att det inte är ett krav de uttrycker förrän funktionen används på riktigt. Hur leverantören och kunden tillsammans i ett IT-projekt identifierar och planerar för alla krav kallas för kravhantering. |
När en organisation står inför att införa ett system eller genomföra förändringar i ett befintligt system så är det en investering. För att kunna ta ett investeringsbeslut så är det vanligt att kravinsamlingen sker i ett separat projekt som skall generera ett kravdokument som sedan är underlag för beslut om att gå vidare med själva utvecklingsprojektet. Det finns många benämningar på ett sådant ”projekt innan projektet” men det vanligaste och mest etablerade är förstudie.
Tre viktiga erfarenheter
För att en förstudie skall generera ett underlag som faktiskt speglar verksamheten och användarnas krav på ett system är det en rad moment som är viktiga för att nå målet. Vi kommer att följa ett riktigt case och hur förstudien hanterades i varje moment.
1. Identifiera huvudsakliga affärsprocesser och organisatoriska funktioner skall stödjas av IT-systemet eller förändringsprojektet.
Det första man som kund bör göra är att specificera vilka rutiner eller affärsprocesser man vill förändra och få bättre systemstöd i. Utifrån detta så planeras arbetsmöten för att sedan i detalj identifiera kraven och systemförändringarna. Kunden kände att de ville utveckla sin inköpsprocess och att de idag utförde alldeles för mycket manuellt arbete.
Kunden tog kontakt med oss för att se över de områden de skulle kunna förbättra med bättre systemstöd. Vi inledde arbetet med att definiera att de områden där de önskade bättre systemstöd var: leveransbevakning mot leverantör, beställningsförslag.
2. Arbeta med väl strukturerade möten.
Alla har nog varit med om dåliga möten utan agenda och där beslut och åtgärder fortfarande hänger i luften när mötet är slut och inget vettigt protokoll eller rutin för att alla deltagare skall läsa och godkänna protokollen. Eftersom mycket av kravinsamling sker i just möten så är det viktigt för den som initierar mötet att skapa så bra förutsättningar som möjligt för att mötet skall bli bra. Detta innebär att i god tid sammanställa en agenda som alla inbjudna kan ta till sig, att miljön på mötet är sådan att alla inbjudna vågar tycka till, att alla identifierade aktiviteter och beslut dokumenteras och godkänns.
Då vi identifierade tre huvudsaklig processer att behandla så planerades initialt tre arbetsmöten. Ett per process. På mötena med kunden så beslutades det att konsulten från Sundit skulle vara mötesledare. Till mötet så bjöds två inköpare in som hade god kunskap om verksamheten och dess behov. Inköpschefen var inte med på mötet då man bedömde att det inköparna skulle kunna diskutera sina behov mer fritt utan chefen med på mötet. Konsulten från Sundit strukturerade mötet på det sättet att inköparna skulle gå igenom en steg-för-steg beskrivning av hur man jobbade i sin leveransbevakningsprocess. Inköparna fick till uppgift att inför mötet förbereda en sådan presentation och dessutom ge exempel på olika delar i processen där man trodde sig kunna arbeta bättre.
Under mötet identifierades att det ett arbetsmoment som tog mycket tid och som gav lägre servicenivå mot kunderna var att inköparna manuellt såg till att uppdatera leveransdatum på sina kundorders när leverantörerna rapporterade leveransförseningar eller bekräftade leveransdatum. Då företagets verksamhet var sådan att det var mycket affärskritiskt att kunna ge kunderna så riktiga leveransdatum som möjligt. Konsulten från Sundit berättade att det finns möjlighet att ta emot orderbekräftelser och leveransdatumuppdateringar elektroniskt från många leverantörer. Deltagarna på mötet resonerade sig fram till att om det var möjligt att läsa in leveransdatumuppdateringar från leverantörerna och det i sin tur även kunde uppdatera leveransdatum till kunderna så skulle det öka servicegraden mot kunder och ge företaget en konkurrensfördel mot sina konkurrenter.
3. Försök att vara så konkret som möjligt.
Det vara svårt att bara prata om vilka funktioner man vill ha i ett system och hur de skall fungera. Det kan bli för abstrakt. Därför kan man i en förstudieprocess arbeta med ”prototyping” där en grov prototyp av systemet tas fram. T.ex. som bilder i Powerpoint. Under mötet med användarna så utgår man från prototypen och simulerar ett arbetsflöde för att identifiera funktioner som behövs utvecklas och eventuella fallgropar.
Då inköparna hade svårt att se framför sig hur det nya flödet skulle se ut så planerade ytterligare ett möte in där konsulten från Sundit skulle med hjälp av exempelbilder visa hur det nya flödet med elektronisk inläsning av datumbekräftelser från leverantör skulle se ut. Konsulten från Sundit förberedde exempel med bilder på hur inköpsorder skulle se ut innan och efter datumuppdateringen från leverantören anlände och vidare hur datumen på kundordern uppdaterades. Inköparna fick då ytterligare förståelse för hur lösningen skulle se ut när den realiserades i systemet och kunde ge ytterligare synpunkter som de inte hade tänkt på under arbetsmötet.
Sammanfattning
Kravhantering är ett område som vuxit i betydelse för att genomföra ett lyckat IT projekt. Det ger så många positiva effekter att det bör hanteras med respekt och av en projektledare med kompetens i kravinsamling. En väl genomförd kravinsamling ger:
- Ett bra beslutsunderlag för organisationen med en möjlig investeringsbudget.
- En genomtänkt och förankrat process stöd för införandet av systemet.
- Ett bra testunderlag inför driftsättningen.
Låt inte snålheten bedra visheten utan genomför en kravinsamling innan ert nästa IT projekt.