Fiwe presenterar – en artikelserie om implementering av MDM-lösningar i moderniseringsprojekt
Vid modernisering av affärssystem stöter vi ofta på komplexa utmaningar som berör allt från datakvalitet och förändringshantering till resursallokering. Hos Fiwe Systems & Consulting har vi samlat ovärderliga insikter genom våra projekt av att aktivt engagera verksamheten, effektivisera förändringsprocesser och optimera användningen av MDM-verktyg för att maximalt stärka datakvaliteten.
Vår djupgående artikelserie, baserad på en mängd intervjuer, utforskar de mest värdefulla lärdomarna från våra senaste projekt. Vi delar med oss av både framgångar och utmaningar, för att ge dig en unik inblick i hur MDM kan revolutionera ditt företags datahantering och framförallt ur perspektivet att genomföra ett affärssystemsbyte eller uppgradering. Se till att prenumerera på vår mailinglista för att få direkt tillgång till varje nytt avsnitt i denna upplysande serie.
Del 3 – Förvänta förändringar
Förändringar i ett projekt är i inget ovanligt, inte heller i MDM-projekt. Även ni utsattes för förändringar inom ramen för ditt senaste projekt Peter. Kan du berätta mer om det?
Ja, det stämmer. Förändring är dessutom ett ganska brett begrepp. Man pratar om förändring av kraven och scopet, men även förändringar som rör förutsättningarna runt projektet. Det kan handla om vilka deltagare man har med sig in i projektteamet och hur de behöver omsättas eller ersättas. Andra typer av förändringar är de som sker i omvärlden eller i andra projekt och domäner som påverkar det egna projektet.
Beställarorganisationen sitter inledningsvis med en första behovsbild av vad man tänker sig att man skall åstadkomma och som skall omsättas till krav. Men ju längre projektet fortgår så blir fler inblandade och intresserade av det vi gör i MDM-projektet och vilken data som vi kan leverera. Det här har gjort att fler delar av organisationen vill vara med på resan och ta del av den kvalitetssäkrade datan som vi kan leverera.
Det där låter ju mer som begreppet “Scope Creep”. Är det vi talar om här?
Ja, på ett sätt är det så – utifrån att det blir fler konsumenter av datan. Men det är ju samma data vi levererar och från MDM-systemets sida spelar det ingen större roll om det är 1, 10 eller 100 prenumererande system. Från MDM:s synvinkel så är det mer fråga om en kö med ett fördefinierat format som är oberoende av hur många som läser den. Det som mest skulle hamna under begreppet “Scope Creep” är snarare utökade diskussioner och förklaringar kring vad datan är för något och hur den effektivast kan konsumeras, och såklart, mer tid och resurser går åt till att göra detta för 10 prenumeranter jämfört med 1.
Hur ställer sig beställarledet till det här?
Det accepterats full ut. Det här är ju egentligen bara en tidigareläggning för de som ändå skulle kommit med på resan, men som var planerat för lägre fram i tiden. Ju fler som kopplar sig mot MDM-lösningen och använder datan, desto bättre är det för verksamheten eftersom man då snabbare närmar sig en samsyn kring data och entiteter.
Parallellt har vi ett pågående ERP-projekt med kopplingar till vårt projekt som vi försöker hantera på bästa sätt. När vi startade så hade ERP-projektet redan hållit på i ett halvår och det fanns redan en formulerad kravbild för det projektet som vi fick ta del av. I takt med att de kom djupare in i sin kravbild så förändrades kraven även för vårt projekt.
Var dessa förändringar förväntade och planerade, eller skapade det nya utmaningar för er?
Ja definitivt skapades nya utmaningar, men man kan ju inte heller bestämt säga att “nej, det här går vi inte med på, detta var inte med i ursprungskraven”. Det skulle inte hjälpa någon. De nya och förändrade kraven speglade ju trots allt verkligheten och behoven bättre än vad de ursprungliga gjorde. Vi jobbar dessutom utifrån agila metodiker vilket ger möjligheten att inom 3 veckor relativt smärtfritt kunde styra om riktningen mot de nya kraven.
Agila projekt klarar av hur stora och många förändringar som helst. Hur hanterade ni det i det här projektet?
Från början planerade vi och estimerade insatsen för att sätta MDM på plats för 3 domäner. Vi tog bland annat höjd för datamodellering, sätta upp datakvalitetsregler, konfigurera användarinterface för Data Stewards etc. Vi la även in en löpande post för att kunna hantera oförutsedda händelser och förändringar. Detta gav oss “luft” för att hantera nya krav till en viss nivå allteftersom de uppkom. Och som nämndes tidigare, så löpte iterationerna under 3 veckor och därav var ju inte heller mer än 3 veckor i stöten fast planerade. Därför gick det också smidigt att justera för förändringarna.
Det innebär väl att ni estimerade “luft”? Om det skulle visa sig att den avsatta tiden för “luft” inte skulle behövas, skulle det inte innebära en risk att projektplanen blev missvisande?
Jo, det är sant, men erfarenhetsmässigt och i de flesta moderniseringsprojekt så kommer många insikter upp till ytan först efter att projektet varit igång ett tag. Vart och ett av dem riskerar påverka kravbilden. Det är också därför man oftast väljer agila projektmetodiker – just för dess effektiva verktyg för att hantera förändring.
Hur kom ni fram till hur stor andel av projekttiden som skulle avsättas för “luft”?
Jo, det är ca 20% av hela projekttiden faktiskt. Det är mer eller mindre en faktor som vi nästan alltid använder. Det gör vi utifrån tidigare erfarenheter från likvärdiga projekt.
Att ha posten “luft” med i planen ställer väl en hel del krav på uppföljning. Hur hanterades det?
Vi har löpande styrgruppsmöte, minst 1 gång per månad, ibland ännu oftare. Vid dessa redovisas hur mycket av budgeten vi använt. Om några förändringsbeslut tagits som påverkar budgeten på något sätt så lyfter vi det. Slutligen säkerställer vi att vi får accept på utökning eller förändringar av budgeten från styrgruppen.
Men med ökad budget, så är det väl utöver “luft”-planeringen? Vad för typ av förändringar handlade det då om?
Mycket riktigt. Det är viktigt att ha en tydlig avgränsning för vad som kvalificerar en förändring för “luft”-delen och inte. I det här fallet var det större poster som mer eller mindre skulle kunna utgöra ett helt separat delprojekt. T.ex. uppkom i somras en fråga om det skulle skapas en egen central databas för miljödata. Detta var inte del av MDM-scopet och skulle kunna innebära ganska stora avsteg från planen. Därför drog vi slutsatsen att detta först behövde utredas djupare, och det var den utredningen som vi äskade extra tid för. Ett annat exempel är frågan om var nykund skulle skapas, ett nytt önskemål som tillkommit var att det skulle skötas i MDM. Även detta låg utanför scoopet och behövde hanteras som ett tillägg.
Nu finns alla artiklar
tillgängliga om MDM-lösningar i
moderniseringsprojekt.
Läs mer här!
Vill du veta mer om hur vi kan hjälpa dig?
”Det är viktigt att ha tydliga och väldefinierade processer och verktyg för att hantera förändringar – och det har vi! ”
Har förändringarna varit så stora att det påverkat tidplanen i större omfattning?
Ja, det har det. Vi hade en ursprungsplan att vara klara före sommaren, sen kom information från ERP-projektet om att de kommer vara klara med sina delar först under hösten. Och såklart, vårt projekt innefattar även en komplett integration med ERP. Därför blev vi helt enkelt tvingade att skjuta på tidsplanen.
Med andra ord så har det aldrig varit förändringar av kravbilden som orsakat justeringar av projektets tidsplan?
Det stämmer. Dessa har alla kunnat hanteras inom ramen för den “luft” vi lagt in i projektet. Det har oftast handlat om saker som gjort att vi behövt prioritera annorlunda under en period, men aldrig något som orsakat förseningar eller revision av budgeten.
Vad har varit den mest svårhanterade förändringen ni råkat ut för i projektet?
Det som ställde till det en hel del för oss var förändringar av roadmapen för utrullning av olika regioner. Det har gjorts ganska stora förändringar av vilka regioner som det faktiskt skall rullas ut först.
Varför är det ett stort problem, det är väl samma MDM, samma typ av data som rullas ut oavsett vilken region går igång först?
Sant, men det är helt andra människor inblandade, i många fall från andra länder och med andra affärskulturer. Beslut som var helt tydliga, klara och implementerade för t.ex. Norden kanske inte får accept över huvud taget i Sydeuropa. Sådant ställer såklart till det för planen. Saker man gjort utifrån en region får inte kastas, det skall ju användas, men först senare, för att istället ta nytag och skapa en utrullning utifrån en till stora delar förändrad kravbild. För att lösa en sådan situation är det viktigt att ha tydliga och väldefinierade processer och verktyg för att hantera förändring – och det har vi!
Artikelförfattare:
Business Analyst på Fiwe
Bosse har sedan mitten av 90-talet arbetet med en stor variation av systemintegrationer och inom en lång rad branscher. Med sin långa erfarenhet från både systemutveckling såväl som projektledning och kravanalys har han skapat sig förmågan att engagera sig och kunna bidra i de allra flesta IT-relaterade uppdrag och projekt
