ARTIKLAR

Sundbom & Partners har under 16 års tid varit verksamma inom affärssystem- och ekonomitjänster, främst till andra konsultbolag. Under denna tid har vi mött hundratals konsultföretag och uppmärksammat den anmärkningsvärda bristen på en enhetlig definition av ett av branschens kanske mest centrala nyckeltal: debiteringsgraden.

Det slår oss ofta hur samtalen med våra kunder kan skifta mellan att ena stunden diskutera beläggningsgrad för att nästa stund prata om debiteringsgrad. Många använder dessutom debiteringsgraden som ett väsentligt mått i sina årsredovisningar. Är det då inte förvånande att det saknas en standardiserad definition, likt EBITDA, som alla känner till?

Om det inte finns någon fastställd standard, hur kan man då avgöra om till exempel en debiteringsgrad på 82% är bra eller dåligt?

Hur brukar debiteringsgraden beräknas?

En vanlig definition är att man dividerar all tid som fördelas på debiterbar verksamhet (tex uppdrag eller projekt) med den faktiska närvarotiden:

all tid som fördelas på debiterbar verksamhet
närvarotid

Det är inte ovanligt att lägga normaltid i stället för närvarotid i nämnaren eller att endast ta med tid som faktiskt kan faktureras i täljaren. Det är ju inte samma sak som all tid man lägger på debiterbar verksamhet. Vissa timmar går av olika anledningar inte alltid fakturera. Och hur blir det med restid, bör den inkluderas i täljaren?

Vad är rätt och vad är fel?

Om vi ytterligare komplicerar saken genom att börja prata om beläggningsgrad. Är det någon skillnad mellan debiteringsgrad och beläggningsgrad? Om vi jämför med hotellbranschen så är det ju normalt samma sak. Beläggningsgrad är hur många rum som är uthyrda i förhållande till det totala antalet rum och normalt sett debiteras gästerna för dessa. Tillgängligheten blir då totalt antal rum minus uthyrda rum.

Men inom konsultbranschen blir det genast lite mer komplicerat. Är beläggningsgrad här endast relaterat till debiterbar tid? Borde det inte vara samma som inom hotellbranschen, det vill säga att beläggningsgrad är den tid som inte är tillgänglig i förhållande till totalt möjlig tid. Finns det tid över så borde den ju vara tillgänglig – eller hur? Men hur blir det med de som jobbar internt? Är de tillgängliga? Fråga ekonomiavdelningen om de har tillgänglig tid… Normalt sett inte eftersom konsultbolag är experter på att minimera interntiden så mycket som möjligt.

Borde det då inte vara en ganska betydande skillnad på debiteringsgrad och beläggningsgrad?

Kanske borde konsultföretag i stället fokusera på att mäta hur stor del av den potentiellt debiterbara tiden som faktiskt genererar intäkter, vilket kunde kallas betalningsgrad. Detta skulle kunna bli ett tydligt och enhetligt nyckeltal för hela branschen, med liknande status, som till exempel EBITDA.

Anta att ett konsultbolag med 100 medarbetare, varav 10 inte är konsulter utan arbetar internt med sälj, administration, ledning etc. På en normalmånad har företaget ca 14,400 (90×160) timmar som rent teoretiskt, om alla jobbar heltid och ingen övertid, kan debiteras. Låt säga att det går att ta betalt för 12,000 timmar så har vi en betalningsgrad på 75% (12,000/16 000).

Och beläggningsgraden? Om vi resonerar som hotellbranschen och antar att personal inom försäljning, administration och ledning är upptagna med sina uppgifter är de ju inte tillgängliga. Då skulle beläggningsgraden vara 85% (13,600/16,000) – eller hur?

Debiteringsgraden skulle under dessa omständigheter vara densamma som betalningsgraden. Givetvis förutsatt att inga justeringar behövs på grund av kreditnotor eller att kunden av någon anledning inte betalat. I dessa fall minskar betalningsgraden medan debiteringsgraden förblir oförändrad på 75%.

Som du märker kan det här bli en ganska komplex diskussion. Vi på Sundbom & Partners menar att bristen på tydlighet när viktiga nyckeltal definieras kan vara ganska förödande när yttre betraktare ska avgöra ett konsultbolags prestationer.

Dessutom är det, som alltid, viktigt att även beakta andra nyckeltal. Inte bara EBITDA utan även täckningsbidrag, soliditet, likviditet, rörelsekapital och, kanske viktigast av allt, hur alla dessa utvecklas över tid.

Vad tycker du? Har du synpunkter eller vill diskutera ämnet vidare är du varmt välkommen att kontakta:

Per Sundbom – per.sundbom@sundbompartners.se – 070-590 81 30

Det går även bra att kontakta någon annan av oss, kontaktuppgifter hittar du här.

Under årens lopp tillkommer fler och fler rapporter i bolagets affärssystem. Varför blir det så? Och hur många av dessa rapporter är egentligen väsentliga för att följa upp bolagets mål?

Sundbom & Partners har jobbat länge med affärssystemlösningar. Enligt vår erfarenhet är den växande rapportfloran ett symtom på att bolaget inte har tillräckligt tydliga strategiska mål och styrningsprinciper. Rapporter byggs löpande upp för att svara på allehanda ad hoc-frågor och ska ofta svara på frågan ”varför når jag inte mitt resultat”. Orsaken till att målet inte nås är ofta beroende på ett flertal faktorer.

För att ha möjlighet att rensa i rapportmängden så måste man bygga ett bas-rapportpaket. Det ska alltid visa vart bolaget är på väg i relation till sina mål. Men det i sig räcker inte. Man måste också ha definierat dessa mål i form av nyckeltal, som måste vara förankrade i organisationen så att alla litar på att de är relevanta. Målet ska vara; Så länge våra nyckeltal pekar åt rätt håll är allt frid och fröjd!

Vi på Sundbom & Partners genomför ofta analyser ute hos våra kunder för att identifiera dessa nyckeltal och bygger sedan rapportpaket kopplat till dem. Ibland innebär det att vi även genomför en upphandling av BI-system för att optimera rapporteringen.

Om något av nyckeltalen som bolaget följer börjar vika åt fel håll behöver ledningen i förhand veta vilka åtgärder som ska vidtas. Vi behöver alltså förstå vad som är ett sunt beteende för att nå våra mål.

För att skapa det bas-rapportpaket som nämns ovan behöver bolaget:

• Ta reda på vilka bolagets framgångsfaktorer är.
• Ha koll på masterdata som ligger till underlag för nyckeltal och annan rapportering, oavsett från vilket system dessa data hämtas.
• Skapa relativa nyckeltal som alla kan lita på och där varje nyckeltal är kopplat till en framgångsfaktor. Mål ska sättas på varje nyckeltal.
  • Det är väsentligt att nyckeltal mäts på en organisatorisk- och kostnadsnivå som är påverkbar för chefer inom bolaget.
• Bygg ett rapportpaket som omfattar hela företaget och följer upp bolagets gemensamma mål. Tillåt olika divisioner/affärsområden ha unika nyckeltal för sin verksamhet (inom ramen för samma rapportpaket).
• Se till att data presenteras digitalt på ett tilltalande grafiskt sätt och är tillgänglig för så många som möjligt.

Naturligtvis kommer verksamheten ha behov av detaljerade rapporter över till exempel projekt-uppföljning, artikelförsäljning, kundbearbetning m.m. Men det är rapporter som med fördel redan finns i befintliga system. Även dessa rapporter bör vara standardiserade så långt som möjligt då man även längre ner i organisationen bör veta vad som är ett sunt beteende.

Så kom nu ihåg – när någon i organisationen frågar efter ytterligare rapporter. Ifrågasätt detta, ofta finns svaret redan i standardrapportpaketet, eller så är det en helt irrelevant data som efterfrågas. Är ni osäkra så kontakta någon av oss på Sundbom & Partners för att rådfråga.

Kontaktuppgifter hittar ni här.

Hur får man på sikt nytta av sin investering i nytt affärssystem? – Del 10 av 10 i artikelserien om ”Upphandling av affärssystem för konsultbolag”

Som vi skrev tidigare så kommer denna artikel handla om hur man skapar en långsiktig nytta av sin investering i nytt affärssystem. Vår erfarenhet säger att det handlar om effektiv och professionell förvaltning.

Det är sällan som företagets IT-avdelning har kunskap om förvaltning av ekonomisystemet utöver kommunikation, lagringsyta och backup. Ofta är det rena molnsystem och då är inte IT alls involverad i driften. I stället ligger ansvaret oftast hos ekonomiavdelningen där någon systemintresserad ekonom utses till ansvarig för förvaltningen av systemet.

Vad innefattar då ansvar för förvaltning av ett affärssystem?

Bland annat ingår följande uppgifter i arbetet:

• Tillse att det finns Super-users, dvs en person/ett team på företaget som bäst förstår systemets uppbyggnad och funktioner. I mindre organisationer är oftast super-user och förvaltningsansvarig samma person.
• Bygga upp en intern kompetens genom att anordna utbildningar och fortbildningar i systemet för olika personalgrupper.
• Bygga upp en intern supportorganisation så att alla medarbetare vet vem de ska vända sig till med frågor samt hur frågor ska eskaleras inom företaget.
• Löpande utveckla sin egen kompetens inom systemets olika funktioner.
• Löpande hålla sig uppdaterad om tillkommande funktioner i nya releaser.
• Införa nya funktioner i samband med uppdateringar eller uppgraderingar.
• Löpande konfigurera systemet efter förändringar i organisation, nya attestordningar, nya bolag mm.
• Ansvara för dialog och kravställande mot systemleverantören, tillse att gemensamma förvaltningsmöten hålls.
• Upphandla konsulter som kan stödja när intern resurs inte räcker till.
• Tillsätta resurser och projektledning i samband med uppgraderingar av systemet.
• Tillse att det finns en budget för underhåll, anpassningar och förbättringar av affärssystemet, samt följa upp kostnaderna.
• Sköta dialogen med intern IT avseende hårdvara, lagring, prestanda mm om det är ett on-premise system (Läs mer om olika driftsformer här).
• Utarbeta en förvaltningsplan där ovanstående punkter struktureras och framtida utvecklingsbehov identifieras och planeras in.

Dessa exempel är ändå bara en del av det övergripande ansvaret som en systemförvaltare har. Det är viktigt att den som får en sådan roll faktiskt får tid att arbeta med frågorna och kan frigöras från andra arbetsuppgifter. Beroende på vilket valt system och storlek på företaget kan detta ta allt från några dagar i månaden upp till heltid.

Ta hjälp av konsulter!

Många företag har en egen förvaltningsorganisation men långt ifrån alla. Om en sådan saknas måste man ofta ta in konsulter som bistår med allt från att upprätta en förvaltningsplan till att ansvara för hela den löpande förvaltningen av affärssystemet. Eller så väljer man att ta in konsulter för vissa delar, t ex i samband med en uppgradering. Har man gjort en investering av ett nytt affärssystem så gäller det även att investera i resurser som kan sköta om systemet.

Vi på Sundbom & Partners är specialister på förvaltning av affärssystem för företag som arbetar med tid och projekt, som IT-, Teknik- och kommunikationskonsulter. Våra huvudstyrkor ligger i att förvalta de affärssystem som man oftast använder av dessa branscher. Bland dessa finns Maconomy, Visma PX, Unit4 ERP (Agresso), IFS, Dynamics 365, Xledger, Rexor m.fl.

Vill du veta mer om våra systemförvaltningstjänster så kan du med fördel kontakta någon av oss på Sundbom & Partners som är experter på affärssystem för just konsultbolag. Kontaktinformation hittar du här.

Del 9 av 10 i artikelserien om ”Upphandling av affärssystem för konsultbolag” – När är ett affärssystemsprojekt klart?

Det korta svaret på den frågan är – Aldrig!

Systemleverantörerna har alltid en införandeplan, vilken i förenklad form brukar se ut så här:

1. Design av systemet.
2. Bygga in önskade funktioner i systemet.
3. Löpande tester, både systemtester och användartester.
4. Go-live och go-live stöd.
5. Överlämning till förvaltning.

Och det är den sista punkten som gör att projekten aldrig tar slut.

För att minimera arbetet med förvaltningen så måste man lägga ner mycket tid INNAN projektet startar. Det vill säga redan vid kravspecen som vi pratat om i avsnittet ”Hur tar man fram en bra kravspecifikation” som du hittar i samma artikelserie. En förutsättning för att få en effektiv förvaltning av systemet är att ni valt rätt system för er verksamhet. Både för dagens och morgondagens behov. Därför krävs det att ni gjort hemläxan och ställt korrekta krav.

Under implementationen behöver ni sedan lägga ner mycket tid tillsammans med systemleverantören på att designa systemet. Både så att den ursprungliga uppsättningen stödjer dagens behov och att kodstruktur och prestanda räcker till för de ev. förändringar i verksamheten som ni ser i framtiden.

Vår erfarenhet är att systemleverantörer ofta underskattar den tid designfasen tar. Man ska inte vara rädd för att öka budgeten i tidiga skeden. Om man slarvar sig igenom denna fas riskerar man sen att få ett system som kommer behöva anpassas och justeras en hel del under resans gång. Anpassningar som görs efter go-live innebär ofta att även fungerande flöden måste anpassas och att tid och kostnader skenar.

Övriga delar av implementationen baserar sig till fullo på designfasen. Systemleverantören konfigurerar systemet baserat på detta, och kunden testar att allt fungerar som förväntat. Då är det av största vikt att de som testar är engagerade och ställer krav när något inte fungerar som tänkt.

Hur bygger man då upp en effektiv systemförvaltning?

Många operativa system i verksamheten förvaltas av olika grupper av systemanvändare där IT ofta har en stark roll. Men IT-avdelningens kompetens och engagemang i affärssystemet är ofta blygsam.

Därför är det vanligt att ekonomichefen blir systemägare för affärssystemet och att engagemanget ute i organisationen är ganska svalt. Det är inte så konstigt då de flesta användare bara ser en liten del av systemet varje dag.

Förvaltningen blir ofta en intern angelägenhet på ekonomiavdelningen. Hur man ska jobba med förvaltningen för att nå en långsiktig nytta av sitt affärssystem kommer vi till i nästa artikel i serien, som dessutom blir den sista.

Vill du veta mer om vår upphandlingstjänst så kan du med fördel kontakta någon av oss på Sundbom & Partners som är experter på affärssystem för just konsultbolag. Kontaktinformation hittar du här. Det går även bra att fylla i kontaktformuläret längst ner här på sidan så kontaktar vi dig.

För att ert affärssystem ska fungera och leverantören ska kunna underhålla det så krävs det att systemet löpande uppgraderas. Systemleverantörerna supporterar oftast bara två versioner bakåt i tiden. Det betyder att uppgradering behöver ske minst vartannat år för att man ska känna sig säker på att få den support och det stöd man betalar för.

Ladda ner hela artikeln som pdf här!

I samband med uppgraderingen får man på köpet alla förbättringar och utvecklingar som gjorts i systemet. Leverantören bygger löpande in de funktioner som användarna efterfrågat i tidigare versioner. Det händer också mycket med automatiseringar och effektiviseringar i varje ny version. Om man själv deltar i användargrupper mm som kravställare så har man möjlighet att kunna vara med och påverka ny funktionalitet i framtida versioner.

En uppgradering av affärssystemet kan skilja sig beroende på vilken teknik som systemet är byggt på. Har man ett äkta SaaS (System as a Service) ska detta skötas automatiskt och som kund behöver man egentligen inte tänka på det alls. De flesta bolag har dock inte det, utan har i stället antingen en hybridlösning eller ett on-premise system som driftas på egen hand. Då är det betydligt mer jobb kring en uppgradering. Här beskriver vi lite hur man kan arbeta med uppgradering i olika systemtyper.

Äkta SaaS

Ett äkta SaaS är ett system som leverantören driftar, underhåller och uppgraderar. För att leverantörerna ska kunna ansvara för funktionen så tillåts sällan några kundunika anpassningar. Exempel på ett sådana system är till exempel Visma.net eller Fortnox.

Även när man har ett äkta SaaS-system så finns det anledning att testa alla funktioner inför en uppgradering, framför allt de integrationer man har. Det händer också att vissa funktioner försvinner eller förändras i en uppgraderad version. Äkta SaaS-system uppgraderas/uppdateras löpande, ofta månadsvis eller kvartalsvis. I normalfallet så uppgraderas först en testmiljö, där ni som kund förväntas testa era viktigaste flöden samt nya funktioner för att säkerställa att allt fungerar när den nya versionen läggs på. I de flesta fall kan kunden med egen personal hantera uppgraderingarna av SaaS-system.

Hybridlösningar

Vid en hybridlösning driftar systemleverantören er miljö och ansvarar för uppgraderingar. Men ni har en egen databas eller så delar ni en databas med ett fåtal andra kunder. Systemleverantören gör uppgraderingen av grundsystemet som en del av serviceåtagandet som man betalar för. Det är leverantören som styr när uppgradering ska ske och ni som kund får anpassa er efter deras tidplan. Tex är Maconomy DFME en så kallad Hybridlösning.

Dessa uppgraderingar kräver i många fall mer omfattande tester då man ofta i dessa system har byggt in kundunika funktioner och anpassningar.

On-premise

Ett on-premise system är ett affärssystem som man själv driftar på egna servrar, eller så kan man lägga ut driften på en driftspartner.

Man beslutar själv när uppgradering av ett on-premise system ska ske. Då behöver man anlita systemleverantören eller en partner som kan utföra den tekniska uppgraderingen av databaser mm samt lägga på den nya versionen av programvaran.

Vid uppgradering av on-premise-lösningar, och till stor del när det gäller hybridlösningar, så är det viktigt att man som kund tar ett stort ansvar för att systemet ska fungera så som man förväntar sig efter uppgraderingen.

Uppgradering är ofta ett tidskrävande projekt

Uppgraderingen måste ses som ett internt projekt, och ska planeras in med både timmar och pengar. Tid måste avsättas, i första hand inom ekonomi och IT-avdelningarna. Någon måste ta projektledarrollen för uppgraderingsprojektet, finns den resursen internt? Eller måste ni ta hjälp av en konsult med vana av denna typ av projekt för att samordna, administrera och sköta kontakten med systemleverantören?

Dessa punkter kan vara bra att tänka på innan uppgraderingen:

• Läs igenom dokumentationen om vad som ska uppgraderas från leverantören.
• Under vilken period (datum) sker uppgraderingen, hur passar det in med övrig verksamhet?
• Går datumet att påverka om det inte passar?
• Hur lång är testperioden?
• Vilket datum ska nya versionen gå live?
• Samordna mellan avdelningar i organisationen, oftast IT och Ekonomi.

Det är viktigt att inte glömma bort användarna i systemet. Hur påverkas deras användning, både före, under och efter en uppgradering? Vad behöver kommuniceras och krävs det någon ytterligare utbildning för användarna? Allt detta ska planeras in och förberedas i ett tidigt skede. Det kan vara en bra idé att ta fram eller uppdatera lathundar om det är förändringar i till exempel projekt, tidrapportering eller uppföljning som påverkar användarna.

Glöm inte heller att vara ”i fas” med den nya versionen. Ibland har bolagen fullt upp med att testa och säkerställa att befintlig funktion och anpassningar/integrationer fungerar som de ska att man glömmer att uppgraderingen kan innebära nya och mer effektiva arbetssätt. Det kan ha tillkommit möjligheter som inte fanns tidigare och chans att få nya effektiva rutiner på plats. Frigör man inte tid för att förstå och utbilda personalen inom dessa nyheter får man kanske inte full effekt av uppgraderingen.

Testa, testa, testa!

Bland det viktigaste och mest tidskrävande i projektet är att testa systemet i samband med uppgraderingen. En bra testperiod minimerar fel som kan uppstå efter att nya versionen gått live och påverkar den dagliga verksamheten i form av tid, pengar och badwill i verksamheten.

Att tänka på i samband med testning:

• Resurser – Vem/vilka ska testa?
• Tid – Under hur lång tid pågår testen?
• Bokning i kalender – Avsätt tid.
• Vilka funktioner, integrationer, rapporter mm ska testas?
• Dokumentation – Dokumentera de fel som uppstår.
• Hur sker kommunikationen med leverantören angående testresultat?

Vi rekommenderar att ta fram en genomtänkt testplan över vilka funktioner som ska testas. I testplanen bör alla funktioner som används i organisationen finnas med. Det inkluderar egna kundanpassningar, anpassade rapporter, externa kopplingar och integrationer, och hur de nya funktionerna fungerar i systemet. Om man har en bra testplan och dokumenterar sina tester så kan man bocka av att alla funktioner är testade. Om det sedan uppstår ett fel i live-versionen så går det att påvisa om samma fel fanns med redan i testversionen. Detta underlättar för alla parter.

Avslutningsvis så kan vi konstatera att en större uppgradering alltid innebär mycket arbete för organisationen. Men med en bra planering, en strukturerad process och där tillräckligt med tid frigörs för involverade resurser så brukar dessa projekt bli lyckade.

Har ni frågor eller står ni kanske inför en kommande uppgradering av ert affärssystem? Välkommen att kontakta någon av oss, kontaktuppgifter hittar ni här.

Hur går en framgångsrik implementation till? – Del 8 av 10 i artikelserien om ”Upphandling av affärssystem för konsultbolag”

När man väl har upphandlat sitt nya affärssystem är det dags för implementation, dvs införandet av det nya systemet. Att införa att nytt affärssystem är inget som går att slarva sig igenom. Inom konsultbolag är en affärssystemimplementation något som påverkar hela företaget till skillnad från att införa ett nytt ekonomisystem på ett tillverkande bolag. Alla kommer att påverkas på ett eller annat sätt och då innebär ett misslyckat införande att det kan bli mycket smärtsamt och dyrt. Tyvärr så resulterar många affärssystemimplementationer i förseningar och fördyringar men det finns vissa knep för att undvika detta:

Rätt projektmodell

De allra flesta systemleverantörer har normalt sett en modell för hur just deras system ska införas på bästa sätt. Enklast är så klart att utgå från denna modell men en del, framför allt större, kunder jobbar enligt egna bestämda projektmodeller. Vår rekommendation är att alltid utgå från leverantörens modell då den brukar vara väl beprövad.

Rätt implementationsteam

A och O för en lyckad implementation är att tillsätta rätt- och tillräckliga resurser – det gäller både personal och pengar. Viktigast är att den som står som ansvarig har erfarenhet av att driva denna typ av projekt och har mandat/budget för att nyttja interna resurser och kunna driva igenom projektet. Många företag gör misstaget att plocka en person ur den ordinarie organisationen för att leda projektet. Någon som kanske helt saknar erfarenhet från den här typen av projekt och som dessutom inte kommer kunna få någon avlastning från ordinarie arbetsuppgifter. I stället är det starkt rekommenderat att hyra in en extern projektledare. Oftast behöver man också öka bemanningen på ekonomiavdelningen för att täcka upp för den tid som går åt till att arbeta i projektet. Det finns inte tid för att både sköta sina egna arbetsuppgifter och arbeta med implementationsprojektet. Det lönar sig i stort sett alltid att bemanna upp ekonomiavdelningen under projektet.

Rätt inställning till förändring

”Människan är aldrig så stark som när det gäller att motverka förändring” sa en gammal chef till mig. Så sant!
Ett nytt affärssystem innebär stora möjligheter till förbättring/förändring. Man ska inte missa detta tillfälle att förbättra sin verksamhet. I implementationsteamet måste det därför finnas medlemmar som har rätt inställning till och kan fatta beslut om förändringar. Oftast handlar det om att effektivisera processer, till exempel faktureringsprocessen, tidrapporteringsprocessen etc. Det måste också finnas en förändringsvilja ända upp i företagsledningen. Om man inte tar tillvara på dessa möjligheter finns det en risk för att det nya affärssystemet endast leder till att man fortsätter att jobba som tidigare, alltså fortsätter att göra fel fast på ett nytt sätt.

Rätt anpassningar

I möjligaste mån bör man undvika alltför många anpassningar av ett standardiserat affärssystem. Kan man anpassa verksamheten till systemet utan stora uppoffringar är det sannolikt bättre än att börja anpassa systemet. Alla anpassningar kräver underhåll och är kostsamma i längden. De moderna s.k. ”multi tenant” molnsystemen är ofta inte heller gjorda för att anpassas alltför mycket eftersom alla kunder ska köra samma kärnsystem för att underlätta vid uppgraderingar mm.

Rätt integrationsplan

Ofta har man ett flertal kringsystem som ska integreras mot det nya affärssystemet, det kan vara CRM, Budgetsystem, Datalager, Koncernrapportering och unika verksamhetssystem av alla slag. Varje sådan integration måste planeras i samråd med det systemets förvaltningsgrupper och systemleverantörerna. Detta kan vara både en tidstjuv och en stor kostnadspost som inte alltid är känd innan man bestämt sig för ett system. Se till att alla inblandade system är representerade och att tid sätts av tillsammans med leverantörerna/förvaltningsgrupperna – ofta involverar dessa integrationer externa konsulter som måste avropas i tid och planeras in.

Rätt historik

En viktig del i implementationen är också att se till att icke relevant information inte migreras in i det nya systemet. Det är ett ypperligt tillfälle till att ”tvätta” data och minska datamängderna. Denna del av projektet kan vara omfattande och måste kartläggas på ett tidigt stadium i projektet och kan faktiskt delvis genomföras i ett mycket tidigt skede.

Rätt testarbete

Man brukar säga att man inte kan testa för mycket. Det är helt riktigt. När man tycker att man testat färdigt så är det läge att testa en omgång till. Man upptäcker alltid något som kan förbättras. Både funktioner och processer i systemet måste testas. Testcase måste upprättas och testprotokoll måste tas fram. Återtestning efter rättningar måste genomföras. Allt detta tar tid och kräver resurser. Här kan man med fördel ta in en konsult med erfarenhet av systemet för att leda testerna.

Rätt utbildning

Ett av de säkraste sätten att öka sannolikheten till ett lyckat projekt är att se till att alla slutanvändare får relevant utbildning. Alla som ska tidrapportera måste få veta hur man gör det i det nya systemet etc. Missar men det får man säkerligen höra att det gamla systemet var bättre. Många kunder låter leverantören utbilda ”utbildare” – ”train the trainer”. Dessa blir ofta superusers i slutänden. Hela organisationen måste få relevant utbildning. Allt ifrån företagsledningen, som behöver veta hur man attesterar och får fram bra rapporter till den enskilde konsulten som behöver veta hur hen tidrapporterar och rapporterar resor och utlägg. Vi rekommenderar att man tar fram egna manualer, eller ännu hellre spelar in filmer över de vanligaste uppgifterna som medarbetare förväntas göra, t ex rapportera tid och fakturera.

Rätt information

Eftersom ett nytt affärssystem påverkar hela organisationen i ett konsultbolag är det synnerligen viktigt att alla i organisationen får information om vad som händer. Vi brukar kalla det intern marknadsföring. Det finns inga affärsystemsprojekt som går exakt som man planerar vilket innebär att man måste informera hela tiden om vad som händer. Förståelsen för förseningar och annat strul ökar dramatiskt med relevant och öppen information. Säger man från början att det kommer bli en tid av prövningar kommer organisationen ha större förståelse.

Följer man råden ovan så ökar definitivt sannolikheten för ett lyckat införande!

De avslutande två artiklarna i denna serie kommer handla om när ett affärssystemsprojekt är klart och om hur man får nytta på sikt av sin investering.

Vill du veta mer om vår upphandlingstjänst så kan du med fördel kontakta någon av oss på Sundbom & Partners som är experter på affärssystem för just konsultbolag.

Kontaktinformation hittar du här.

Hur utvärderar man anbud/offerter? – Del 7 av 10 i artikelserien om ”Upphandling av affärssystem för konsultbolag”

En utmaning i samband med systemupphandlingar är hur man ska utvärdera de inkomna anbuden/offerterna. Hur vet man att man får svar på det man frågar om? Hur ska man veta att leverantören har förstått vad som ska levereras? Går det att jämföra priser och TCO (Total Cost of Ownership)?

För att kunna genomföra en vettig utvärdering krävs att man följt våra tidigare rekommendationer, dvs att man tagit fram en bra och tydlig kravspecifikation och att man tagit fram ett komplett och tydligt upphandlingsunderlag. Finns inte detta så är det mycket svårt att utvärdera. Man måste kunna ”nollställa” anbuden, dvs de måste vara jämförbara så att man inte jämför ”äpplen” och ”päron”.

Här är några bra tips på hur man utvärderar:

1. Ett bra sätt att jobba på är att man, så långt det är möjligt, poängsätter krav och önskemål baserade på hur viktiga de är för verksamheten. Här kan man med fördel använda Excel eller liknande verktyg så att man kan räkna på poäng med automatik. När man sedan börjar själva utvärderingen ser man helt enkelt hur många poäng respektive leverantör/system får vid denna mer matematiska utvärdering. Vi rekommenderar också att man alltid arbetar med så kallade ”ska-” och ”bör-” krav där ska-kraven är sådant som måste uppfyllas för att man ska komma vidare i processen. Men denna del av utvärdering kan inte ensamt ligga till grund för ett beslut.

2. Man måste komplettera med att analysera hur leverantörerna svarat upp mot kraven. I vissa fall svarar man att man klarar kravet men att det krävs en anpassning. Hur ska man tolka det? Har man eller har man inte? Till samtliga krav måste man därför ge utrymme för leverantörerna att svara i text. Denna del av utvärderingen kräver att läsaren har vana av att läsa förklaringar från affärssystemleverantörer eftersom det i vissa fall kan vara svårt att förstå vad de menar annars.

3. I vissa fall vill företaget som ska upphandla systemet även att utvärderingen ska ske utifrån några huvudparametrar. T ex är det vanligt att man, speciellt i offentliga upphandlingar anser att priset är det viktigaste. I andra sammanhang värderar man kanske höga poäng på funktionalitet eller att kraven på själva leverantören och dess leverans- och utvecklingskapacitet uppfylls. Inför en upphandling måste man som kund bestämma hur man ska vikta pris mot kvalitet på system och leverantör, det hjälper mycket i samband med utvärderingen.

4. En mycket viktig del i utvärderingen är så klart demonstrationer av systemen. Lämpligast är att bjuda in de två eller tre leverantörer som fått den högsta matematiska utvärderingsratingen. Under förutsättning att de också svarat tillfredsställande på de mer beskrivande delarna i anbudsförfrågan samt att prisindikationen visar på en acceptabel nivå. Själva demonstrationerna ska också styras relativt hårt så att leverantörerna visar det som är intressant – inte det som de själva vill visa eftersom de då pekar på de styrkor de har, oaktat vad det aktuella företaget har behov av.

Vi brukar arbeta med färdiga körscheman som leverantörerna får i god tid innan demonstrationen så att de har en rimlig tid på sig att förbereda sig. Dessutom använder vi ibland protokoll för att kunna betygsätta leverantören utifrån vilken känsla företagets representanter får under demonstrationen. Hur väl stämmer systemet med vad man vill ha rent funktionellt? Hur känns användarvänligheten? Har leverantören förstått vad som efterfrågas? Hur intresserade och engagerade verkar leverantörens representanter? Det kan vara stor skillnad på olika leverantörer. En del är ”hungriga” medan andra verkar ”ointresserade” så det är en viktig parameter. Vilken typ av leverantör vill man ha framöver?

5. Slutligen är det sådant som pris, avtal och vilja som avgör. Vad får man för pengarna? Matchar priset prestandan/funktionaliteten? Är leverantören förhandlingsbenägen? Betänk att man ska ha en relation under många år framöver och det första avtalet kanske avspeglar hur just denna leverantör gör affärer även framgent. Är just ni en intressant kund för leverantören?

Nästa artikel handlar om hur en framgångsrik implementation går till.

Vill du veta mer om vår upphandlingstjänst så kan du med fördel kontakta någon av oss på Sundbom & Partners som är experter på affärssystem för just konsultbolag. Kontaktinformation hittar du här.

Hur skriver man ett bra upphandlingsunderlag? – Del 6 av 10 i artikelserien om ”Upphandling av affärssystem för konsultbolag”

Bland det viktigaste i samband med en upphandling av ett affärssystem är själva upphandlingsunderlaget, dvs det man skickar till de leverantörer man vill ha anbud/offerter ifrån. Ofta finns det stora brister i upphandlingsunderlaget och då blir själva upphandlingen sällan bra. Finns det för många oklarheter i underlaget får man också otydliga anbud/offerter.

Vad ska då ett bra upphandlingsunderlag innehålla?

Nedan följer ett upplägg som vi inom Sundbom & Partners har tillämpat i många upphandlingar.

Inledning

med övergripande beskrivning av upphandlingen med syfte, mål, sekretess etc.

Beskrivning av företaget som ska upphandla 

Den ska innehålla verksamhetsbeskrivning, organisationsmodell och nuvarande IT-system. Den ska också inkludera en planerad målbild, vad man vill förändra/förbättra, huvudsakliga behov och krav på ett nytt system mm.

Den syftar till att ge offererande leverantörer en övergripande bild samt förståelse för vad företaget vill åstadkomma med upphandlingen. Här kan man även med fördel lägga in kvalitativa och kvantitativa mål med ett nytt affärssystem.

Om det är så att företagets olika organisatoriska delar har skilda behov och krav så bör det beskrivas i detta avsnitt. Allt för att ge en så klar bild som möjligt över målbilden.

Själva kravspecifikationen

Kravspecifikationen är den viktigaste bilagan, och en självklar del av upphandlingsunderlaget. Den har ni läst om i en tidigare artikel i serien.

Annan viktig information för upphandlingen

Tex antal juridiska personer, antal användare, roller som kan påverka licensiering etc. Specificera även vilka väsentliga delar av ett affärssystem som ska offereras, tex om EFH ska ingå, eller om CRM-funktionalitet ska ingå osv.

Upphandlingsform och anbudsinstruktioner

I detta avsnitt bör man specificera hur upphandlingen kommer att ske med avseende på tidsplan inklusive viktiga datum (senaste anbudsdatum, anbudets giltighet och eventuell sista dag för frågor, när anbudspresentationer och demonstrationer ska genomföras, när utvärdering ska ske, när slutförhandling ska ske och när avtal planeras att skrivas). Den ska också inkludera formalia kring anbudet, adress dit anbudet ska skickas, kontaktpersoner mm.

Nästa artikel handlar om hur man utvärderar anbud och offerter.

Vill du veta mer om vår upphandlingstjänst så kan du med fördel kontakta någon av oss på Sundbom & Partners som är experter på affärssystem för just konsultbolag. Kontaktinformation hittar du här.

Hur ska man se på det här med integrationer och anpassningar? – Del 5 av 10 i artikelserien om ”Upphandling av affärssystem för konsultbolag”

Nästan alla implementationer av affärssystem idag kräver integrationer eller anpassningar. Åtminstone gäller det för lite större verksamheter och sällan stöter vi på verksamheter som klarar sig med ett system för allt.

Affärssystem är bra på mycket men inte allt, vilket leder till att företag måste ta till andra lösningar eller göra anpassningar i de standardsystem man inför. Men hur bra är det egentligen och vad bör man tänka på?

Definitioner

Med integration menar vi att flera olika fristående system kopplas ihop för att fungera tillsammans. Det kan t ex röra sig om att ett CRM-system, ett resursplaneringsverktyg, ett lönesystem, ett BI-system eller liknande ska kopplas ihop med affärssystemet.

Med kundanpassning menar vi att man inom ramen för affärssystemet gör en anpassning av funktionaliteten genom programmering eller justeringar i databasen för att uppnå vissa kundspecifika önskemål. Det kan röra sig om allt ifrån hela extra moduler till små fältförändringar.

I samband med att man upphandlar ett nytt affärssystem är det viktigt att utreda hur de olika systemkandidaterna kan hantera integrationer och anpassningar. En del system har bra integrationsmöjligheter via så kallade API:er.  API är ett protokoll för att skicka och ta emot data som kan vara strukturerat på olika sätt (XML, Json) i olika system. Många system har standardintegrationer till andra system ex. från ett ERP-system till en e-fakturaleverantör.

Om man har två system som inte är förberedda på att prata med varandra så rekommenderar vi en integrationsmotor för att hämta/skicka och konvertera data mellan systemen.

Det finns färdiga integrationsmotorer från olika leverantörer men man kan också skriva individuella script som löser integrationen mellan två API:er eller mellan ett API och en filintegration.

Viktigt att tänka på vid upphandling

Det man kan vara helt säker på i de allra flesta fallen är att ett införande av ett affärssystem kommer att innehålla ett visst mått av integration. Då är det viktigt att undersöka vilka möjligheter affärssystemet har och se till så att upphandlingen även omfattar uppgifter från berörda leverantörer. Man behöver ta reda på vad dessa integrationer kommer att innebära, både kostnadsmässigt, underhållsmässigt och tidsmässigt i samband med implementationen. Annars kan detta komma som obehagliga överraskningar i projektet.  Dock ska sägas att tekniker för integration har utvecklats mycket genom åren och det är normalt sett idag betydligt enklare att integrera system med varandra än för några år sedan. Men det är ändå en viktig fråga att ta hänsyn till när man upphandlar ett affärssystem.

Samma sak gäller för kundanpassningar. Vilka möjligheter har systemen för att hantera anpassningar? Vad händer till exempel vid en uppgradering av affärssystemet? Hur hanteras anpassningarna då? Vem har ansvaret för att de fungerar efter en uppgradering? Har det tilltänkta systemet inbyggda verktyg för anpassningar? Vissa system är mer gjorda för denna flexibilitet än andra. För konsultbolag finns system som är byggda för just konsultverksamhet och då behövs ett minimum av anpassningar. Men dessa system är oftast inte lika flexibla som andra, mindre branschinriktade system.

En grundregel måste ändå vara att minimera antalet anpassningar och i stället använda standardfunktionalitet och parametersättning så långt det går. I många fall kanske det till och med är bättre att ändra interna rutiner och arbetssätt till förmån för standardfunktionerna i det tilltänkta systemet.

Men det kan också vara så att om man bedriver en verksamhet som man vet kommer att förändras över tid och man dessutom har unika behov. I ett sådant fall kan flexibilitet och anpassningsmöjlighet i ett system vara avgörande vid valet av system.

Det är därför viktigt att man, i samband med upphandlingen, går igenom sina affärskritiska processer och ställer dem i relation till standardfunktionalitet kontra flexibilitet i de system man utvärderar. Kanske man får göra avkall på vissa krav för att i stället slippa hantera mängder av anpassningar som på sikt ska underhållas och vidareutvecklas. Det blir dyrt i längden och det måste ställas emot den nyttan anpassningen gör för verksamheten. Å andra sidan kan ett system som inte tillåter anpassningar vara begränsande över tid.

Nästa artikel handlar om hur man skriver ett bra upphandlingsunderlag.

Vill du veta mer om vår upphandlingstjänst så kan du med fördel kontakta någon av oss på Sundbom & Partners som är experter på affärssystem för just konsultbolag. Kontaktinformation hittar du här.

För- och nackdelar med olika driftslösningar/tekniker – Del 4 av 10 i artikelserien om ”Upphandling av affärssystem för konsultbolag”

De flesta företag lagrar en del av sin data på egna servrar eller på servar driftade av en IT- partner och en del data lagras i så kallade molnlösningar. Vi ser en tydlig trend där företag lägger en allt större del av sin lagrade data i molnet och det blir alltmer ovanligt med egen drift av servar och annan IT-miljö.

Detta avspeglas också i själva applikationerna/programvarorna som i allt större utsträckning blir molnbaserade lösningar som man hyr i stället för att som tidigare köpa en nyttjanderätt.

On Premise kontra Moln

Anledningar till att molnlösningarna har vuxit i popularitet är att dessa erbjuder en större flexibilitet för företag, man betalar bara för den lagringskapacitet man använder och de personer som för tillfället nyttjar programvaror. Man slipper större investeringar i hård- och mjukvara som belastar likviditeten och får oftast en mer driftsäker miljö.

Samtidigt så finns risker med molnlösningar. Om bolaget har all data inom egna väggar så kan de själva påverka säkerhet och kapacitet. Brandväggar kan byggas upp och man kan säkerställa att GDPR följs fullt ut, vilket är ett problem om data lagras på servrar som ägs av till exempel amerikanska företag.

Vi ska här fokusera på affärssystemet – ska vi ha det i molnet eller lokalt?

Lokal programvara (On-premise) – Egen drift

Oavsett om ett företag placerar sina applikationer i molnet eller om det beslutar att hålla dem lokalt kommer datasäkerhet alltid att vara av största vikt.

Lokal programvara kräver att ett företag köper en licens/nyttjanderätt till programvaran för att använda den. Eftersom programvaran och transaktionsdata finns på egen server har man själv ansvar för säkerhet och backup mm. Det kan kännas som en tryggare lösning än att köpa en molntjänst men kräver en noggrann förvaltning av IT-miljön.

Nackdelen med lokala miljöer är att kostnader förknippade med att hantera och underhålla lösningen kan vara väsentligt högre än vid en molnbaserad lösning. En lokal installation kräver intern hård- och mjukvara för servrar, backuplösning, programvarulicenser, integrationsfunktioner och IT-anställda till hands för att stödja och hantera potentiella problem som kan uppstå.

Lokal programvara (On-premise) – Extern drift

I stället för att drifta sin egen licensierade programvara är det vanligt att man låter en IT-driftspartner tillse att servrar och programvara tillgängliggörs för medarbetarna. Man slipper ansvaret för driften men betalar å andra sidan ett ganska högt pris vilket är absolut motiverat om företaget bara har ett fåtal applikationer som ska driftas.

 Molnlösning (Cloud)

En molnlösning skiljer sig från lokal programvara genom att en systemleverantör ansvarar för allt i en molnmiljö. Många driftar sina system på ett lokalt datacenter, men ibland ligger både system och data hos amerikanska jättar som Azure, AWS eller Google. Detta gör det möjligt för företag att betala efter behov och effektivt skala upp eller ner beroende på den totala användningen, användarkraven och ett företags tillväxt.

Det finns inga kapitalkostnader, data säkerhetskopieras regelbundet och företaget behöver bara betala för aktiva användare. För de organisationer som planerar för en expansion globalt är en molnlösning ännu mer tilltalande.

Molnlösningar går oftast snabbare att implementera då mycket är förkonfigurerat samtidigt som de inte är lika flexibla som en egen installation. Dock är inte alla så kallade molnlösningar av denna moderna typ, utan snarare en variant där leverantören driftar en traditionell lösning, men tar betalt i form av hyra.

Viktiga skillnader mellan lokalt och moln

Som beskrivs ovan finns det ett antal grundläggande skillnader mellan en lokal och en molnmiljö. Vilken väg som är rätt för ditt företag beror helt på dina behov och vad du letar efter i en lösning.

Drift

Lokal: Ett företag är själv eller via en driftspartner ansvarigt för att underhålla lösningen och alla dess relaterade processer inklusive löpande uppgraderingar av systemet.

Moln: Vid en molnlösning är det systemleverantören som tar ansvar för hela driften och underhållet. Kunden har tillgång till systemet via internet och kan normalt sett använda så mycket de vill vid varje tidpunkt, med vissa begränsningar vid hybridlösningar.

Kostnader

Lokal: För företag som har programvara lokalt ansvarar de för de löpande kostnaderna för serverhårdvara, strömförbrukning, resurser, programvarulicenser, uppgraderingar, anpassningar etc.

Moln: Företag som väljer att använda en molnlösning behöver bara betala för de resurser de använder, där support- och underhållskostnader samt uppgraderingar ingår, priset justeras normalt sett upp eller ner beroende på hur mycket som konsumeras.

Kontroll

Lokal: I en lokal miljö behåller företagen all sin data och har full kontroll över vad som händer med det, på gott och ont. Företag i högt reglerade industrier med extra integritetsproblem är ofta tveksamma till molnet framför allt på grund av detta.

Moln: I en molnlösning är frågan om äganderätt till data en som många företag – och leverantörer för den delen, har kämpat med. Data och krypteringsnycklar finns hos din leverantör, så om det händer något oväntat och det är stillestånd kanske du inte kan komma åt den informationen. Dessutom får du problem med tillgång till din data om du säger upp tjänsten. Det kan också vara svårt att bygga integrationer då all data kanske inte är åtkomlig via erbjudna API:er.

Säkerhet

Lokal: Företag som har extra känslig information, t.ex. statliga och bankbranscher, måste ha en viss nivå av säkerhet och integritet som en lokal miljö erbjuder. Trots molnets löfte om säkerhet är detta det främsta problemet för många branscher, så en lokal miljö, trots några av dess nackdelar och prislapp, kan bedömas vara mer säker.

Moln: Säkerhetsproblem är fortfarande den främsta barriären för molnlösningar. Det har skett många publicerade molnöverträdelser och IT-avdelningar runt om i världen är oroliga. Från personliga uppgifter från anställda som inloggningsuppgifter till förlust av immateriell egendom är säkerhetshoten verkliga. GDPR-frågan har också aktualiserats då privacy shield inte längre garanterar utbyte av personuppgifter mellan EU/USA.

Äkta moln – vad är det?

Om man är intresserad av ett s.k. molnbaserat affärssystem, vilket de flesta är idag, måste man också förstå att det finns olika typer av moln. Vad menas då med det?

Många företag utger sig för att ha molntjänster, även om de inte är helt molnbaserade. Flera leverantörer av affärssystem i Sverige erbjuder en molnlösning enligt definitionen att de har en hyrestjänst, dock inte som en äkta molntjänst utan som någon annan traditionell form av distribution av applikation, t ex via ett fjärrskrivbord.

Erbjudandet av en äkta molnlösning är lite annorlunda. I detta fall så finns det bara en instans av programvaran som delas utav alla kunder som använder programvaran. Eftersom flera företag delar på samma infrastruktur och programvara så beskrivs den äkta molnlösningen ofta som ”multiklientklösning.” Det finns inget att installera lokalt, tillgång till programvara och data sker endast via webb eller mobilapplikation. I en äkta molnlösning delar alla användare på system, datalagring mm, men du betalar bara för eget bruk.

Nästa artikel handlar om hur ska man kan se på det här med integrationer och anpassningar.

Vill du veta mer om vår upphandlingstjänst så kan du med fördel kontakta någon av oss på Sundbom & Partners som är experter på affärssystem för just konsultbolag. Kontaktinformation hittar du här.

Hur tar man fram en bra kravspecifikation? – Del 3 av 10 i artikelserien om ”Upphandling av affärssystem för konsultbolag”

Ett av de mest kritiska momenten när man ska upphandla ett nytt affärssystem är framtagandet av en kravspecifikation. Det är den som lägger grunden för det framtida systemet. Utan en bra kravspecifikation blir det svårt att hitta rätt system och införa det effektivt.

Hur gör man då när man ska ta fram en bra kravspecifikation? Följande punktlista beskriver de moment vi inom Sundbom & Partners tillämpar när vi hjälper våra upphandlingskunder:

• Definition:

  I detta moment går man igenom syftet samt vilka mål man vill uppnå med ett eventuellt byte av affärssystem. Budget, processer, koppling till affärsplan, tidsplan mm gås igenom. Tillsammans med kunden brukar vi bilda en projektgrupp som blir arbetsgruppen i den fortsatta processen, samt en styrgrupp som är den beslutande instansen i projektet.

• Behovsinventering/prioritering:

  Detta moment omfattar fokuserade workshops med valda delar av verksamheten. Lämpligtvis med ekonomi/ledning och operativ leveransverksamhet för att fånga upp de unika behov som finns inom organisationen. Vid behov genomförs workshops eller intervjuer med ytterligare intressenter inom verksamheten.

• Kravspecifikation:

  Denna aktivitet syftar till att ta fram själva kravspecifikationen som är en detaljerad specifikation över både funktionella och tekniska krav. Specifikationen kommer att omfatta krav inom alla de områden som systemet förväntas stödja, t ex:

• • Tid-, rese och utläggsrapportering
  • Projektredovisning, resursplanering och projektbudgetering
  • Finansiell budget, prognos och uppföljning
  • Effektiv fakturering och enkel kundreskontrahantering
  • Elektroniskt leveratörfakturaflöde
  • Smidiga betalösningar
  • Ibland även abonnemang, inköp, lager osv

• Prioritering

  Alla de krav som framkommer bör också prioriteras beroende på hur viktiga de egentligen är för verksamheten. Vissa krav kan vara mer ”nice-to-have” medan andra är ”must-have”. Alla krav viktas också beroende på hur väsentliga de är för verksamheten och vi poängsätter därefter anbuden baserat på leverantörens svar och demo av systemet, det ger oss en så objektiv bild som möjligt över systemets kvalitet.

• Andra värden:

  När man tar fram en kravspecifikation för användning i en upphandling får man inte glömma att även ställa krav på:

• • Leverantören i sig av typen ekonomi, historik, resurstillgång mm. Det är trots allt en relation man kommer att ha under många år framöver.
  • Teknik, dvs vilka tekniska krav man har från sin IT-verksamhet. Det kan finnas en IT-strategi att ta hänsyn till. Tekniken kan skilja sig mycket mellan olika affärssystem beroende på molnteknik, on-premise mm.
  • Juridik, dvs man kan redan i en kravspecifikation ställa krav på vilka juridiska grundkrav man ställer på leverantören, t ex betalplaner, betalningsvillkor, garantier, avtalstider, GDPR mm. Att ha med det från början i sin kravställning kan underlätta senare förhandling.

Kommande artikel handlar om för- och nackdelar med olika tekniska lösningar för affärssystem, t ex on-premise, cloud etc.

Vill du veta mer om vår upphandlingstjänst så kan du med fördel kontakta någon av oss på Sundbom & Partners som är experter på affärssystem för just konsultbolag. Kontaktinformation hittar du här.

Uppgradera sitt affärssystem eller investera i ett nytt? – Del 2 av 10 i artikelserien om ”Upphandling av affärssystem för konsultbolag”

De flesta lite större konsultbolag har säkert vid ett flertal tillfällen ställts inför dilemmat att bestämma om man ska uppgradera sitt befintliga affärssystem eller investera i ett nytt system.

En uppgradering av ett affärssystem kan ibland vara ett ganska kostsamt projekt, speciellt om man ligger kvar i ett system som bygger på lite äldre teknik. Man ställer sig då frågan – är det verkligen värt att ta den kostnaden? Borde man inte i stället satsa pengarna på att förnya sig och investera i ett modernare system där uppgraderingar i framtiden kanske inte är så kostsamma samt att gränssnitten är modernare?

Tyvärr är det många som byter system helt i onödan och ibland till något som fungerar betydligt sämre. För att kunna fatta ett bra beslut behöver man fundera över följande:

Om en uppgradering innebär att ovanstående frågeställningar till stor del undanröjs kan det definitivt vara vits att uppgradera istället för att investera i ett nytt system.

En uppgradering är i de allra flesta fall, trots att prislappen kan te sig stor, betydligt mer kostnadseffektiv än att byta system.

Det viktigaste att fundera över är den första frågeställningen ovan. För konsultbolag är det verksamhetskritiskt att använda ett affärssystem som har fokus på projekt/uppdragsredovisning och tidrapportering. Man måste ha möjlighet att fånga tiden på ett effektivt sätt för att kunna fakturera smidigt. Lika viktigt är det att kunna följa uppdragen/projekten rent ekonomiskt. Dessutom måste redovisningen i systemet stödja bolagets nuvarande och kommande redovisningsprinciper, IFRS-regelverk, successiv vinstavräkning, upparbetade intäkter mm. Gör inte systemet det så är det nog läge att fundera på ett nytt system i stället för att uppgradera.

Ett systembyte innebär att man börjar helt från början med kravställning etc och det tar längre tid än vad man tror från början. Men om ovanstående frågeställningar helt eller delvis inte löses med en uppgradering har man inte mycket val – då är det bara att kavla upp ärmarna och se till att ta fram ett så bra underlag för en upphandling som möjligt.

Det berättar vi vidare om i nästa artikel i denna serie.

Om du känner igen dig i några av frågeställningarna ovan så är det nog dags att göra någonting. Då kan du med fördel kontakta någon på Sundbom & Partners som är experter på affärssystem för just konsultbolag. Kontaktinformation hittar du här.

När vet ett konsultbolag att det är dags att byta ut sitt affärssystem? – Del 1 av 10 i artikelserien om ”Upphandling av affärssystem för konsultbolag”

Konsultbolag verkar nästan alltid i en mycket föränderlig värld. Branschen karaktäriseras ofta av uppköp, omfattande expansioner, avknoppningar, internationalisering etc. Dessa förändringar ställer höga krav på affärssystemens flexibilitet. Inte alla system motsvarar dessa krav och då kan det börja gnissla lite.

Förutom uppenbara tecken på att det är dags att byta system såsom bristande funktionalitet, för få dimensioner etc så är detta tecken som tyder på att det är dags att se över sitt system:

• Mängder av manuella bokningar för att hantera mellanhavanden mellan bolagen i en koncern.
• Svårigheter att hantera flera valutor.
• Manuella bokningar av intäkter mellan bokföringsperioder.
• Problem att tidrapportera i, och följa upp koncerngemensamma projekt.
• Vid en blandad projekt- och produktverksamhet – svårigheter att följa projekten medan produkterna går alldeles utmärkt att följa, eller vice versa.
• Stora rapporteringsproblem på grund av att information man vill följa helt enkelt inte finns i systemet, eller kräver komplexa externa rapportverktyg för att filtrera fram.
• I övrigt många manuella rutiner på grund av att befintligt system inte stödjer processer eller digitalisering.
• Utöver detta så finns risk att att systemet helt enkelt inte längre supporteras och underhålls av systemleverantören, eller att det kräver operativsystem som inte supporteras av t ex Microsoft.

Fler mänskliga faktorer som också kan vara tecken på att det är dags att göra något:

• Organisationen får problem med att inrapportera på grund av gamla gränssnitt som man inte vill arbeta med. Idag ställer man ofta krav på mobila gränssnitt, speciellt i organisationer där medarbetarna inte sitter på ett gemensamt kontor.
• Är man ett teknikintensivt företag kan gamla system med gamla gränssnitt upplevas som negativt från medarbetarna utifrån ett arbetsgivarperspektiv. Man vill helt enkelt inte jobba på ett ”gammalmodigt” företag eller i ett ”fult” system.
• Ett system som fått alltför mycket intern kritik av någon anledning kan i sig vara en anledning till ett byte eftersom det brukar vara mycket svårt att vända en sådan allmän syn på systemet.
• Dessutom kan det vara så att det system man en gång investerat i faktiskt är för komplicerat och krångligt, dagens behov kanske inte kräver ett komplext system. Många konsultbolag kan också ha hamnat i ett system som inte är gjort för ett konsultbolag. Det kanske har fokus på produkter och inte projekt/uppdrag. I det läget kan det vara idé att byta, antingen till ett enklare eller till ett som är gjort för branschen.

Känner du igen dig i några av dessa påstående så kan det nog vara dags att fundera över detta. Då kan du med fördel kontakta någon på Sundbom & Partners som är experter på affärssystem för just konsultbolag. Kontaktinformation hittar du här.