Hur förbereder man bäst inköp av en affärsprogramvara?

Ibland får vi frågan om bästa praxis när det gäller att köpa ett system. Många är intresserade av att höra hur andra företag går till väga. De flesta köper en affärsprogramvara 1-2 gånger under sitt liv, så det kan vara svårt att veta exakt vad man måste ta reda på och göra innan man fattar ett beslut. Ofta har vi också ett samtal med den person som har utsetts till projektledare för att hitta ett system, men som varken är den slutliga beslutsfattaren eller den som har det största behovet av systemet.

Därav detta blogginlägg som kommer att samla in tips och erfarenheter som vi har skaffat oss med tiden.

Naturligtvis finns det delade meningar om när man ska prata med ett företag i deras inköpsprocess. I stort sett kan man dela upp företagen i tre grupper:

• De som bara ska undersöka marknaden och inte har beslutat om de över huvud taget ska ha ett system.
• De som vet att de ska köpa ett nytt system, men som ännu inte har en deadline
• De som har ett fastställt slutdatum för att genomföra ett nytt system

Beroende på hur seriös man är när man letar efter ett nytt system är det naturligtvis skillnad på hur mycket man har förberett sig. Men man bör åtminstone tänka efter vad man egentligen är ute efter – annars är det svårt att få rätt hjälp.

Gör en kravspecifikation

Det är lämpligt att göra en kravspecifikation där man gör en lista över de krav man har på systemet. Beroende på i vilket stadium man är i inköpsprocessen kommer antalet detaljer att skilja sig åt. Men man gör sig själv en stor tjänst genom att precisera minimikraven för det nya systemet. Man ska kunna svara på frågan: ”Vilket är vårt övergripande mål med att genomföra ett nytt system, och vilka processer ska det kunna stödja?”.

Om man är i stadie 3 anser jag att företaget måste göra en intern workshop, där de olika intressenterna tillfrågas om vad de behöver i en lösning som är optimal för dem. Men här är det viktigt att hålla i minnet att projektledaren är med och definierar vad som är ”need to have” och ”nice to have” i förhållande till det övergripande syftet med lösningen. Om allt står som ”need to have” så blir det ofta svårt att hitta ett system. Man måste komma ihåg att alla system har sin specialitet, och såvida man inte ska implementera en jättestor SAP-lösning, bör man vara medveten om vilka krav man kan vara utan.

Genom att ha ett inledande internt möte så slipper man också få otrevliga överraskningar senare när man håller på att implementera det valda systemet. Det finns ingen som kan komma i efterhand och skylla på att projektledaren inte har tagit hänsyn till en specifik situation eftersom alla intressenter har bidragit till att definiera kravlistan.

Genom att ha en kravspecifikation garanterar man också att leverantören förstår vilka behoven är – i alla fall de som har beskrivits. Och om man lämnar över den till leverantören som svarar på den skriftligt så har bägge parter ett bra utgångsläge för en fortsatt dialog.

Det finns dock ingen uppmaning om hur lång en kravspecifikation ska vara. Vi har sett kravspecifikationer på allt från 1 sida till 30 sidor. Det är väldigt olika. Men ju mer exakt den är desto bättre blir förutsättningarna för att man fattar rätt beslut när det gäller val av leverantör. Det är också en fördel att kravspecifikationen är förhållandevis kort och först och främst fokuserar på ”Need to have”. När dessa punkter har skrivits ner kan man alltid göra en lista på ”nice to have”-punkterna.

För en dialog med olika leverantörer

Vi uppelever ofta att de som letar efter ett system mycket väl kan vara reserverade när det gäller att få en presentation av produkten. Många vill själva se sig om och få en känsla av om systemet klarar det som de är ute efter. Men om man vill hitta en mer komplex lösning än exempelvis Basecamp eller Harvest, så rekommenderar via en dialog om vilket behov som ska täckas – även om man är i stadie 1 och bara vill sondera marknaden för att få lite inspiration.

Vid en presentation har man en unik möjlighet att få igång en diskussion om vad man ska lägga vikt på i den önskade lösningen. Dessutom är det ofta tidsbesparande att få svar på sina frågor direkt i stället för att behöva leta efter svar på webbplatser och i offentliga demoversioner.

Man ska komma ihåg att många säljare också är goda rådgivare som har pratat med andra i liknande situationer, och därför kan de ofta berätta om bästa praxis. Vi upplever ofta att först när man börjar samtala kommer fler behov fram som man på företaget inte har tänkt på tidigare eftersom man inte kände till att det över huvud taget var möjligt att genomföra.

Om man fortfarande känner sig lite orolig inför den direkta kontakten med en säljare, erbjuder de flesta leverantörer en online demo, där det också finns videor introduktionswebbseminarier  antingen en gång i månaden eller var annan vecka, då leverantören ger en presentation för flera samtidigt. På detta sätt slipper man en dialog, men får ändå svar på många av de frågor man hade.

Utvärdering

När kravspecifikationen är färdig och man har fått en presentation av de olika systemen som valet står mellan så är det dags för en utvärdering.

Om man inte är överordnad beslutsfattare och det finns olika intressenter som har åsikter om systemet, så kan det kanske vara lämpligt att sitta ner tillsammans och presentera för- och nackdelar med de olika lösningarna. Finns det områden där man är osäker på om leverantören kan åtgärda detta eller inte, är det vår erfarenhet att det hjälper att ordna ett kort möte mellan den part som har störst kunskap inom ämnet och leverantören.

Det kan t.ex. vara en projektledare som har specifika frågor om ett projekt som börjar gå sämre eller ekonomiavdelningen som har frågor kring integrationsmöjligheter. Detta bidrar till att lugna ner dessa intressenter så de kan förlita sig på att systemet kan leva upp till deras behov. Det ska fortfarande ledas av projektledaren, som ska ha det överordnade målet i åtanke så att en enskild intressent inte plötsligt gör sin egen dagordning och leder ut projektet på ett sidospår.

En annan aspekt är också att man ofta har haft möten med flera leverantörer, och ju fler möten desto bättre vet man vad man vill ha. Ibland kan det komma nya krav på listan efter möte med t.ex. leverantör nr 3. Så innan man fattar ett beslut är det bra att höra med de två föregående leverantörerna och se om de också kan lösa dessa problem. Annars riskerar man om man väljer leverantör nr 1, att de inte kan lösa det eftersom de aldrig har hört talas om det kravet tidigare – eller omvänt att man tror de inte kan lösa det, även om man aldrig har pratat om de nya behoven.

Så vad gör man?

1. Gör en kravspecifikation
   1. Ta reda på vad som är ”need to have” och vad som är ”nice to have”
   2. Inkludera de olika intressenternas behov
   3. Var realistisk med att förmodligen kan inte alla behov tillgodoses exakt som man vill ha dem.
2. För en dialog med olika leverantörer
   1. Var inte rädd för att använda dem som rådgivare.
   2. Se till att få en presentation
   3. Ställ många frågor
3. Utvärdera de olika leverantörernas lösningar.
   1. Boka eventuellt ett möte där de olika interna intressenterna samt beslutsfattarna kan få svar på sina specifika frågor inom sina fackområden.
   2. Projektledaren måste ha det övergripande målet för upphandlingen av det nya systemet i åtanke
   3. Om nya krav har dykt upp under processens gång, se till att de skickas till alla leverantörer för att vara säker på att de kan lösa problemen, innan ett beslut fattas

Om förarbetet är bra gjort så är man väl rustad för att hitta den bästa lösning för företaget – och sannolikheten att grundläggande behov har försummats är mycket små.