Vi har kommit fram till plats 1 – 5 i v\u00e5r serie om den \u201dB\u00e4st f\u00f6rberedda kunden\u201d n\u00e4r det kommer till ett Aff\u00e4rssystemprojekt. I fyra delar har vi listat och rangordnat de 20 viktigaste faktorerna som kunden kan p\u00e5verka f\u00f6r att implementationsprojektet. Vi b\u00f6rjade bakl\u00e4nges med plats 20 och n\u00e4r vi nu \u00e4r framme p\u00e5 de \u00f6versta platserna, bygger den h\u00e4r rangordningen p\u00e5 HerbertNathan & Co erfarenheter efter att tillsammans med v\u00e5ra kunder genomf\u00f6rt \u00f6ver 400 aff\u00e4rssystemprojekt. Det \u00e4r sj\u00e4lvklart s\u00e5 att prioritering och rangordning kan se olika ut i det enskilda projektet beroende p\u00e5 projektets unika f\u00f6ruts\u00e4ttningar, men sammantaget har vi landat i denna rangordning:<\/p>\n
<\/p>\n
Kunden m\u00e5ste fr\u00e5n b\u00f6rjan inse att ansvaret f\u00f6r ett lyckade tester ligger i huvudsak p\u00e5 kunden sj\u00e4lv. Det finns en sj\u00e4lvklar g\u00e5ng och uppdelning d\u00e4r leverant\u00f6ren ansvarar f\u00f6r funktionstester och d\u00e4r kunden genomf\u00f6r acceptanstester av olika slag. Vi skiljer p\u00e5 systemtester (som b\u00f6r utf\u00f6ras av leverant\u00f6ren sj\u00e4lv som egenkontroll under implementeringen) och acceptanstest som \u00e5ligger kunden inf\u00f6r att godk\u00e4nna systemet.<\/p>\n
De vanligaste \u00e4r tester av processer, tester av integrationer och prestandatester. Leverant\u00f6ren erbjuder sig oftast att bist\u00e5 med mallar f\u00f6r testerna, men den springande punkten \u00e4r att det \u00e4r bara kunden och skall vara kunden som ansvarar f\u00f6r acceptanstester. Testerna kan bara genomf\u00f6ras med kunskap om de egna processerna och regelverk. H\u00e4r m\u00e5ste d\u00e4rf\u00f6r kunden avs\u00e4tta personal i tillr\u00e4cklig omfattning och personalen m\u00e5ste ocks\u00e5 vara s\u00e5 utbildad p\u00e5 systemet att testerna kan genomf\u00f6ras p\u00e5 ett effektivt s\u00e4tt.\u00a0\u00c4ven om kunden har det slutliga ansvaret f\u00f6r att genomf\u00f6ra testerna, hindrar det inte att leverant\u00f6ren \u00e4r med och \u00e4r aktiv som st\u00f6d under testerna. Tv\u00e4rtom \u00e4r detta oftast en f\u00f6ruts\u00e4ttning f\u00f6r att testerna skall kunna genomf\u00f6ras p\u00e5 ett rimligt s\u00e4tt och inom planerade tidsramar. Betydelsen av v\u00e4l genomarbetade testscenarion och testprotokoll f\u00f6r att ska struktur under arbetet skall inte underskattas<\/p>\n
<\/p>\n
F\u00f6r att p\u00e5 b\u00e4sta s\u00e4tt \u201ds\u00e4tta upp\u201d systemet, kr\u00e4vs det att personer med verksamhetskunskap tillsammans med applikationskonsulter fr\u00e5n leverant\u00f6ren deltar i den omfattning som kr\u00e4vs f\u00f6r att beskriva fl\u00f6den och testa fl\u00f6den s\u00e5 att det blir s\u00e5 v\u00e4l anpassat till kundensverksamhet som m\u00f6jligt. Detta omr\u00e5de h\u00f6r ihop med punkt 2 nedan och ibland ser vi att kunden anv\u00e4nder sig av s\u00e5 kallade referensgrupper. Det kan fungera men \u00e4nnu b\u00e4ttre \u00e4r att involvera verksamhetens resurser direkt in varje delprojekt s\u00e5 att man f\u00f6ljer och bidrar genom hela projektet med sin verksamhetskunskap. Process\u00e4gare och nyckelpersoner b\u00f6r medverka med en plan p\u00e5 att dessa personer ocks\u00e5 f\u00e5r ett l\u00e5ngsiktigt ansvar f\u00f6r utveckling av processerna \u00f6ver tid. Detta f\u00f6r att undvika att man fastnar i en stel l\u00f6sning och\/eller ett konsultberoende. En aktiv och utvecklande kund \u00e4r b\u00e4sta garantin f\u00f6r en l\u00e5ngsiktig och framtidss\u00e4ker l\u00f6sning.<\/p>\n
<\/p>\n
Ett implementationsprojekt av den storlek det inneb\u00e4r att implementera ett Aff\u00e4rssystem inneb\u00e4r en utmaning att genomf\u00f6ra vid sidan av ordinarie arbetsuppgifter. Det m\u00e5ste finnas utrymme att frig\u00f6ra ordinarie arbetsuppgifter till den personal som skall delta i projektet och detta g\u00e4ller s\u00e4rskilt de som skall arbeta mycket i projektet s\u00e5som kundens egna projektledare, l\u00f6sningsansvarig, testledare med flera.\u00a0\u00a0En enkel tumregel brukar vara att kunden m\u00e5ste minst s\u00e4tta till dubbelt s\u00e5 m\u00e5nga timmar som leverant\u00f6ren g\u00f6r och m\u00e5nga g\u00e5nger \u00e4nnu mer. Det kan vara v\u00e4rt att ta in extra arbetskraft f\u00f6r att utf\u00f6ra delar av de ordinarie arbetsuppgifterna. Det \u00e4r en investering som \u00e5terbetalar sig i ett b\u00e4ttre system och mer kompetent personal.<\/p>\n
N\u00e4r resurserna beh\u00f6vs som mest varierar \u00f6ver projektets genomf\u00f6rande och n\u00e5got f\u00f6renklat kan man s\u00e4ga att under faserna Design, Test och Driftsstart beh\u00f6vs det som mest resurser i projektet. Finns det m\u00f6jlighet och utrymme redan inf\u00f6r projektstart att ber\u00e4kna n\u00e4r dessa 3 aktiviteter intr\u00e4ffar under \u00e5ret, s\u00e5 kan ocks\u00e5 st\u00f6rre h\u00e4nsyn tas till semesterperioder, perioder med h\u00f6g arbetsbelastning i linjen p\u00e5 grund av kundbeteende och liknande interna p\u00e5verkande faktorer. De kunder som g\u00e5r igenom roller och resurser och faktiskt best\u00e4mmer deltagande i procent p\u00e5 individniv\u00e5 har st\u00f6rst m\u00f6jlighet att lyckas med resurstilldelning till projektet.<\/p>\n
<\/p>\n
Denna punkt tangerar den punkt som vi satt som nummer 1 i denna ranking. Det till\u00e4gg vi vill g\u00f6ra h\u00e4r \u00e4r att kunden skall st\u00e4lla krav p\u00e5 leverant\u00f6ren redan under designfasen att inte utg\u00e5 fr\u00e5n ett vitt papper utan att hela tiden jobba agilt och integrerat i systemet utifr\u00e5n de standardprocesser som finns tillg\u00e4ngliga i systemet. D\u00e5 blir det r\u00e4tt fokus fr\u00e5n b\u00f6rjan och man minskar risken f\u00f6r \u201d\u00f6nskelistor\u201d fr\u00e5n kunden om hur systemet borde s\u00e4ttas upp, snarare \u00e4n att se p\u00e5 hur systemet kan s\u00e4ttas upp utifr\u00e5n standard.\u00a0\u00a0F\u00f6r att detta skall fungera kr\u00e4vs ocks\u00e5 att leverant\u00f6ren \u201dv\u00e5gar st\u00e5 f\u00f6r en \u00e5sikt\u201d och inte slentrianm\u00e4ssigt k\u00f6per kundens \u00f6nskem\u00e5l. H\u00e4r noterar vi att det finns 2 risker;<\/p>\n
D\u00e5 ovanst\u00e5ende diskussioner och arbete sker ute i delprojekten, s\u00e5 \u00e4r det synnerligen viktigt att rollen L\u00f6sningsarktitekt \u00e4r involverad i dessa diskussioner. Projektet m\u00e5ste hitta formerna f\u00f6r detta f\u00f6r att undvika on\u00f6dig byr\u00e5krati men \u00e4nd\u00e5 ha kontroll p\u00e5 problemet som kan uppkomma h\u00e4r.<\/p>\n
<\/p>\n
Numera brukar kunden vara bra p\u00e5 att anv\u00e4nda de standardprocesser som finns i systemet fr\u00e5n b\u00f6rjan och inte med automatik kr\u00e4va specialanpassningar av standardsystemet. Det har tidigare varit vanligt och d\u00e5 ofta med motivet att \u201ddet \u00e4r s\u00e5 h\u00e4r vi arbetar i nuvarande system och d\u00e5 vill vi g\u00f6ra det i det nya ocks\u00e5\u201d. Vi ser allt oftare en mer nykter syn p\u00e5 detta nu och att man i dialog med leverant\u00f6ren kommer fram till att slutresultatet av en viss systemprocess blir lika bra som tidigare, bara att v\u00e4gen dit kan se lite annorlunda ut i det nya systemet.<\/p>\n
Samtidigt ser vi ofta att det finns n\u00e5gra processer eller funktioner i organisationen som beh\u00f6ver ett IT-st\u00f6d som inte standardsystemet som skall implementeras klarar av fullt ut. I det l\u00e4get kan det sj\u00e4lvklart vara motiverat att ge sig in p\u00e5 n\u00e5gon form av kundunik anpassning. D\u00e5 \u00e4r det dock synnerligen viktigt att ta h\u00f6jd f\u00f6r att b\u00e5de budget och tidplan med st\u00f6rsta sannolikhet kommer att spricka. Involvera Styrgruppen tidigt i diskussionen ha dess st\u00f6d f\u00f6r vilket v\u00e4gval projektet g\u00f6r. Med detta sagt, s\u00e5 fundera p\u00e5 vad som \u00e4r helt n\u00f6dv\u00e4ndig funktionalitet vid driftsstart och vad som kan v\u00e4nta till en fas 2 i projektet. Syns\u00e4ttet \u201datt b\u00f6rja g\u00e5 innan man f\u00f6rs\u00f6ker springa\u201d fungerar i detta sammanhang. Det kan ibland\/ofta vara r\u00e4tt strategi att b\u00f6rja i begr\u00e4nsad skala innan man drar i g\u00e5ng alla moduler och funktioner.<\/p>\n
Tidplanen i m\u00e5nga av de implementationsprojekt vi \u00e4r involverade i styrs delvis av att det gamla systemet skall fasas ut vid en viss tidpunkt som \u00e4r kopplat till avtal med nuvarande leverant\u00f6r. Genom att d\u00e5 s\u00e4kerst\u00e4lla nuvarande funktionalitet i dagens system, kan projektet hitta en miniminiv\u00e5 som absolut m\u00e5ste vara klar till driftsstart. Resterande kan sedan l\u00e4ggas ut under senare faser i projektet.<\/p>\n
<\/p>\n