Innan ni köper affärssystem

Transkript

1 Innan ni köper affärssystem Läs hur ni bäst förbereder er innan ni köper ett affärssystem. Utnyttja mer än 10 års erfarenhet och undvik överraskningar med dessa goda råd från en aktör som själva producerar och implementerar programvara. I mer än 10 år har vi på TimeLog producerat och implementerat programvara åt mer än 500 kunder. Därför har vi massor av erfarenhet av att identifiera behov oavsett om det rör sig om ett nystartat enmansföretag eller större företag inom den privata och offentliga sektorn. Detta whitepaper är resultatet av all den kunskap vi har samlat på oss under årens lopp, som vi hoppas kan tjäna som inspiration för er som står inför situationen att behöva köpa ny programvara oavsett företagets storlek eller ståndpunkt i inköpsprocessen. 1

2 Hur man köper rätt program Det är först när ni vet vad ni vill ha, som det verkliga jobbet med kravspecifikationen börjar låt TimeLog hjälpa er att komma igång. 1 Introduktion Programvara är inte bara programvara När är deadline? Var i inköpsprocessen befinner ni er? 4 2 Gör en kravspecifikation Undvik överraskningar 5 3 För en dialog med olika leverantörer Se till att få en presentation tidigt i processen 6 4 Utvärdering 7 5 Processen steg för steg 8 6 Hundra frågor till din kravspecifikation Tidrapportering Hantering av utlägg Projekthantering Resursstyrning Fakturering udgåva Skriven av Sascha Skydsgaard TimeLog A/S Kungsgatan Stockholm Sverige Telefon Rapportering Organisationen Ytterligare aspekter TimeLog A/S Alla rättigheter förbehållna. info@timelog.se 2

3 1 Introduktion 1.1 Programvara är inte bara programvara 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. Syftet med detta whitepaper är därför att ge goda råd i denna process. Vi har varit involverade i tusentals säljprocesser och har därför sett att man har hanterat detta på olika sätt. Därför har vi samlat en hel del goda råd som bygger på vår erfarenhet, som vi hoppas kan hjälpa dig att hitta rätt system. 1.2 När är deadline? Vi möter företag på olika ställen i inköpsprocessen, och här skiljer det sig förstås i exakt var företaget befinner sig, i förhållande till de krav man ställer på ett framtida system. Men det är viktigt att vara realistisk, när det gäller ens deadline. Det är ovanligt att de företag vi möter når önskad deadline, eftersom man har underskattat hur lång tid inköpsprocessen verkligen tar såvida man inte har en resursperson vars främsta uppgift är att arbeta med inköp av programvara. Ofta är det en process som sker parallellt med alla andra dagliga sysslor, och tiden går snabbt när arbetet med kunderna gör att man får skjuta de interna arbetsuppgifterna på framtiden. Med bra förberedelser och realistiska avsikter går det att komma i mål till önskat datum. 3

4 Här är ett exempel på en realistisk tidsplan för ett företag med cirka 25 anställda: Månad 1 och 2: interna undersökningar av behov och krav, som mynnar ut i en kravspecifikation. Månad 3: Inbjudan till leverantörerna att besvara kravspecifikationen. Månad 4: Antalet leverantörer minskas ned och slutliga kontraktsförhandlingar genomförs. Månad 5: Implementering av det nya systemet. Månad 6: Nu har hela företaget börjat använda det nya systemet. Detta kan verka som ett långt tidsperspektiv, men vår erfarenhet visar, att det brukar ta längre tid än man tror att komma i mål med att implementera ett nytt system. 1.3 Var i inköpsprocessen befinner ni er? 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: 1. De som bara ska undersöka marknaden och inte har beslutat om de över huvud taget ska ha ett system. 2. De som vet att de ska köpa ett nytt system, men som ännu inte har en deadline. 3. 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. Oavsett var i processen du befinner dig, kan detta whitepaper hjälpa dig att formulera kraven för ditt nya programvarusystem. 4

5 2 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 stadium 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. 2.1 Undvik överraskningar 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. 5

6 En sak som vi ofta ser, är att kravspecifikationerna fokuserar på självklara krav, men inte tar med alla de små undantagen i de dagliga processerna. Ni gör er själva en stor tjänst om ni tar er tid att tänka på vilka administrativa saker, som ni stöter på då och då, men som också ska kunna hanteras lätt och smidigt. Det kan t.ex. vara: Kan man flytta tidrapporteringar utan att behöva kontakta medarbetaren? Finns det ett enkelt sätt att flytta uppgifter från en medarbetare som slutar? Kan man tidrapportera för medarbetare som är sjuka, utan att känna till deras inloggningsuppgifter? Vad händer om man ändrar timpriserna? Ändrar det också historiska data? Dessa exempel är inte något man upplever varje dag, men om man inte tar hänsyn till dessa scenarier i sin kravspecifikation eller undersökning, riskerar man att upptäcka det först när systemet är köpt och betalt eller implementerat. 3 För en dialog med olika leverantörer När ni sonderar terrängen, hittar ni säkert en favorit kanske för att det är en leverantör som har rekommenderats, eller för att ni gillar beskrivningarna på deras hemsida. Oavsett vad, så rekommenderar vi, att ni väljer ut minst 2 3 leverantörer, som ska besvara er kravspecifikation. På så sätt kan ni vara säkra på att ni fattar rätt beslut även om ni väljer favoriten, i slutändan. 3.1 Se till att få en presentation tidigt i processen Vi upplever 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 stadium 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. 6

7 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. 4 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. 7

8 5 Processen steg för steg 1. Gör en kravspecifikation Ta reda på vad som är need to have och vad som är nice to have. Inkludera de olika intressenternas behov. 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 Var inte rädd för att använda dem som rådgivare. Se till att få en presentation. Ställ många frågor. 3. Utvärdera de olika leverantörernas lösninger 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. Projektledaren måste ha det övergripande målet för upphandlingen av det nya systemet i åtanke. 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å. 6 Hundra frågor till din kravspecifikation För vissa kan det vara en svår uppgift att börja göra en kravspecifikation. Vi har därför listat många av de frågor man bör ställa sig för att ta reda på vilka behov det nya systemet som ett minimum måste uppfylla. Det finns många fler frågor än dessa det är endast fantasin som sätter gränser. Dessa frågor bygger naturligtvis på, våra erfarenheter inom TimeLog av säljprocessen vid inköp av nytt tidrapporterings- och projektstyrningsverktyg. 8

9 6.1 Tidrapportering 1 Vad vill ni förbättra i förhållande till nuvarande tidrapportering? 2 Vill ni rapportera all er tid (intern och extern) eller bara projekttid (extern)? 3 Behöver ni skriva kommentarer till era tidrapporter? 4 Gör era medarbetare många olika saker under dagens lopp eller arbetar de koncentrerat på ett projekt i flera timmar åt gången? 5 Ska era medarbetare kunna tidrapportera via smartphone? 6 Behöver ni kunna rapportera tid på andra mobiltelefoner än smartphones? 7 Vill ni rapportera tid i minuter (01:30) eller centiminuter (1,5)? 8 Använder era medarbetare Outlook och vill ha möjlighet att tidrapportera via Outlook? 9 Behöver ni kunna rapportera tid för andra medarbetare? 10 Behöver ni kunna flytta felaktiga tidrapporteringar mellan projekt? 11 Behöver ni kunna dela upp en tidrapportering i två olika rapporteringar? 12 Behöver ni göra tidrapporteringar offline? 13 Behöver ni en godkännandeprocess för rapportering av timmar? 14 Ska både projektledare och avdelningschefer godkänna timmar? 15 Stänger ni tidrapporteringen varje månad eller varje vecka? 16 Hur hanterar ni flextid? 17 Hur vill ni rapportera frånvaro? 18 Behöver ni styra semestrarna? 19 Vill ni stödja löneberäkningen för ert lönesystem? 20 Har ni kontraktsanställda för vilka ni ska beräkna flex? 21 Om svaret är ja vilka flexregler använder ni? 22 Finns det olika regler för olika grupper av medarbetare? 6.2 Hantering av utlägg 23 Behöver ni registrera inköp/utlägg? 24 Behöver ni hjälp att registrera reseräkningar? 25 Behöver ni registrera traktamenten? 26 Behöver ni registrera körningar? 27 Behöver ni rapportera i olika valutor? 28 Ska ni fakturera utlägg vidare till kunden? 29 Vill ni ha möjlighet att lägga på en avans på utläggen? 30 Har ni behov av ett godkännandeflöde för medarbetarnas utläggsregistreringar? 9

10 31 Behöver ni skilja mellan utlägg på företagskort/fakturor och medarbetarnas personliga utgifter? 32 Behöver ni importera/exportera inköp/utlägg mellan olika system? 6.3 Projekthantering 33 Vilka avtalsformer använder ni (förbrukad tid, fast pris, klippkort m.m.)? 34 Blandar ni någon gång olika avtalsformer i ett och samma projekt? 35 Har ni olika inköpspriser för olika medarbetare? 36 Har ni olika timpriser för olika medarbetare? 37 Har ni kundspecifika timpriser? 38 Reglerar ni timpriserna, till exempel årligen? 39 Använder ni olika timpriser på samma projekt? 40 Vid fastprisprojekt är ni intresserade av att se värdeberäkningen utifrån ett genomsnittligt timpris, eller hur mycket ni skulle kunna ha sålt projektet för utifrån förbrukad tid? 41 Hur budgeterar ni era projekt i dag? 42 Budgeterar ni både i timmar och i värde? 43 Har era medarbetare en personlig budget för sitt arbete? 44 Budgeterar ni på etappnivå eller bara på övergripande projektnivå? 45 Kan värdet/tiden på projektbudget och projektkontrakt vara olika? 46 Budgeterar ni era projekt i olika valutor? 47 Hur många etappnivåer använder ni i era mest komplexa projekt? 48 Vill ni fördela specifika resurser till era projekt eller ska alla kunna se alla projekt? 49 Vill ni kunna beräkna pågående arbete? 50 Är det viktigt att känna till upp- och nedgångar i projektfaktureringen? 51 Vill ni ha ett Gantt-kort på projektnivå? 52 Arbetar ni med milstolpar i era projekt? 53 Arbetar ni enligt principen ETC (Estimated Time to Complete)? 54 Behöver ni projektmallar, eftersom vissa projekt är likadana? 55 Har ni Microsoft Project och vill gärna kunna importera projektplaner in i systemet? 6.4 Resursstyrning 56 Har ni användning för en översikt för att kunna se hur belastade era medarbetare är? 57 Planerar medarbetarna sin tid på en daglig basis eller veckobasis? 58 Följer ni aktivt upp om personliga planer infrias? 59 Behöver ni ha överblick över semestrar/frånvaro i resursplanen? 10

11 60 Vill ni lägga till resurser baserat på kompetens? 61 Vill du se framtida förtjänstpotential utifrån dina planerade projekt? 62 Behöver ni se om ni har utrymme för fler projekt i framtiden? 63 Behöver ni lätt kunna flytta planerade uppgifter till andra resurser som är mindre belastade? 6.5 Fakturering 64 Fakturerar ni era kunder per projekt eller allt på en enda faktura? 65 Har någon av era kunder en fakturaadress som skiljer sig från besöksadressen? 66 Vill era kunder ha en detaljerad faktura eller en mycket enkel faktura? 67 Fakturerar ni i olika valutor? 68 Behöver ni fakturamallar på olika språk? 69 Behöver ni flera olika fakturamallar? 70 Gör ni någon gång upp- och nedjusteringar på fakturan? 71 Behöver ni göra registreringar icke-fakturerbara? 72 Har ni ett specifikt arbetsflöde för godkännande av fakturor och faktureringspotential? 73 Skickar ni fakturor till myndigheter? 74 Har ni överblick över planerade betalningar i framtiden? 75 Behöver ni flera fakturanummerserier? 6.6 Rapportering 76 Vilka nyckeltal arbetar ni med i dag? 77 Vilka medarbetarrapporter har ni användning av? 78 Vill ni kunna identifiera täckningsgraden per projekt/kund/medarbetare? 79 Vill ni kunna se medarbetarnas faktureringsgrad och extern %? 80 Vill ni kunna se en analys av vad ni har använt era resurser på? 81 Vill ni kunna se vilka kunder som har upptagit störst del av er tid och vilka som har varit mest lönsamma? 82 Vill ni kunna se vilka affärsområden som har upptagit störst del av er tid och vilka som har skapat högst värde? 83 Vill ni kunna se vilka projekt som har upptagit störst del av er tid och vilka som har varit mest lönsamma? 84 Vill ni jämföra era projektresultat oavsett projektens storlek? 85 Vill ni kunna rapportera på avdelnings- och teamnivå? 86 Om svaret är ja hur många nivåer har er avdelningsstruktur idag? 87 Arbetar ni med EU-projekt och har ni behov av EU-rapportering? 11

12 6.7 Organisationen 88 Vill ni dela in systemet i delar på flera nivåer? 89 Har ni internationella medarbetare eller kontor utomlands så ni har behov av att systemet finns på olika språk? 90 Har de internationella kontoren egna specifika tjänster, och behöver ni olika prislistor i olika valutor? 91 Använder ni er av bonus i er organisation om ja, vilket Key Performance Index beräknar ni bonusen ifrån? 6.8 Ytterligare aspekter 92 Behöver ni integration till andra system, t.ex. ekonomi eller lönesystem? 93 Behöver ni kunna få ut era data i Excel, Word, XML eller.txt? 94 Kan ni koda mot ett API själva eller behöver ni hjälp? 95 Har ni ett CRM-system redan, eller vill ni att säljavdelningen ska kunna styra sin pipeline i systemet? 96 Vill ni kunna segmentera er kunddatabas med era egna kriterier? 97 Stöder ni era kunder idag med ett helpdesk-system? 98 Vill ni dela informationen med era kunder via ett extranät? 99 Har ni behov av dokumenthantering via Office365, SharePoint, Dropbox osv.? 100 Vill ni ha en kopia av ert produktionssystem för att testa nya processer och funktioner? 12