Artiklar

Hur får man på sikt nytta av sin investering i nytt affärssystem? (Nr 10/10)

Postad: 2022/01/21

Investering nytt affärssystem

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.

 


 

När är ett affärssystemsprojekt klart? (Nr 9/10)

Postad: 2021/12/09

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.

 


 

Hur går en framgångsrik implementation till? (Nr 8/10)

Postad: 2021/06/30

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? (Nr 7/10)

Postad: 2021/05/27

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? (Nr 6/10)

Postad: 2021/05/12

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? (Nr 5/10)

Postad: 2021/04/29

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 (nr 4/10)

Postad: 2021/04/06

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? (nr 3/10)

Postad: 2021/03/19

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 kravspecifikationen 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? (nr 2/10)

Postad: 2021/03/05

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:

  • Är det system man har idag ett system som stödjer de affärskritiska processerna på ett tillräckligt bra sätt eller finns det brister?
  • Supporteras det nuvarande systemet fortfarande av systemleverantören? Finns det annan kompetens på marknaden för att säkra upp förvaltning?
  • Utvecklas det nuvarande systemet fortfarande eller satsar leverantören på andra modernare system?
  • Hur ser själva leverantören ut? Ekonomisk utveckling? Närvaro i Sverige mm. Detta är viktigt eftersom det handlar om vilken hjälp man kan få i framtiden.
  • Hur ser den bakomliggande tekniken ut i det nuvarande systemet? Finns det risk att t ex serveroperativsystem, databas etc inte supporteras längre av t ex Microsoft?

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 du 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? (nr 1/10)

Postad: 2021/02/18

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.