Artiklar

Att tänka på vid uppgradering av affärssystem

Postad: 2021/09/07

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?

Postad: 2021/06/30

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ärssystemimplemen-tationer 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 tester – tester – tester

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 att 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!

Vi återkommer efter sommaren med de avslutande två artiklarna som handlar 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?

Postad: 2021/05/27

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. I dessa fall är det bra att man anger en procentsats för hur viktigt t ex priset är i förhållande till funktionalitet och leverantören. Denna procentsats kan sedan med fördel multipliceras med de poäng som framkommer vid den matematiska 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å visar 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 kommer handla 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?

Postad: 2021/05/12

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.

Detta är en mycket viktig del. 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.

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

– Allmänna frågor om leverantören, tex historik, storlek, lönsamhet, antal anställda, antal utvecklare mm.

– Dessutom bör man här tydligt beskriva hur man ska svara på upphandlingsförfrågan och vilka delar som ingår. Exempel på innehåll kan vara:

– Anbudsförfrågan, dvs det allmänna dokumentet som beskrivs ovan.

– Frågor om det efterfrågade systemet, tex historik, antal kunder, övergripande teknik mm.

– Kravspecifikation inklusive hur man ska svara på den. Denna bör innehålla så kallade Ska- och Bör-krav för att tydligt markera för leverantörerna vad som är riktigt viktigt och vad som är mer av karaktären ”nice-to-have”.

– Sammanställning över kostnader där leverantörerna ska precisera hur man avser att ta betalt för systemet och, inte minst, för själva införandet.

– Referenser

– Man bör också ange i anbudsförfrågan hur ändringar och tillägg till anbudsförfrågan kommer att hanteras/administreras.

– En beskrivning av hur utvärderingen kommer att ske, vilka steg och om det kommer att göras någon vägning av tex pris, funktion, leveranstid etc.

– Slutligen bör man tydligt beskriva hur leverantörerna ska utforma sina anbud. Detta för att förenkla utvärderingen.

  • Kommersiella villkor

    Redan i anbudsförfrågan bör man specificera vilka kommersiella villkor man som ett minimum kommer att kräva i ett kommande avtal. Det kan tex röra sig om:

–  Avtalstid

– Uppsägningstid

– Handlingars inbördes förhållande, dvs i vilken ordning avtalets olika delar gäller i förhållande till varandra

– Regler för fakturering

– Betalningsvillkor

– Pris och hur det ska anges (fast pris, totalpris etc)

– Eventuell betalningsplan

– Leveransgodkännande och hur det ska ske

– Ansvarsfrågor

– Tvistelösning

 

Nästa artikel kommer att handla 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?

Postad: 2021/04/29

Nästan alla implementationer av affärssystem idag omfattas till viss del av 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å behöver man 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 en anpassning 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 så mycket som möjligt och i stället använda standardfunktionalitet och parametersättning så långt det går. I vissa 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 kan bli 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 kommer att handla 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, dvs On Premise (lokalt) eller Molnlösning

Postad: 2021/04/06

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 istä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 dessutom en 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 t ex amerikanska företag.

Vi ska här fokusera på affärssystem – 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 vara 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, men det ä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ö. 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.

 

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 men företaget har tillgång till dessa resurser och kan använda så mycket de vill vid varje tidpunkt.

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 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 tvekar att hoppa in i 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 tredjepartsleverantö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 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å ta reda på om den lösning man är intresserad av är en ”äkta” molnlösning. Vad menas då med det?

Många företag utger sig för att ha molntjänster, även om de inte är helt molnbaserade tjänster. 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 en ASP-tjänst eller någon annan traditionell form av distribution av applikation.

Erbjudandet av en äkta molnlösning är lite annorlunda. I detta fall så finns det bara en instans av programvaran (och därmed bara en databas) 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 eller konfigurera lokalt, tillgång till programvara och data sker endast via webb eller mobilapplikation. I en äkta molnlösning delar alla användare resurser, men du betalar bara för eget bruk.

 

Nästa artikel kommer att handla 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?

Postad: 2021/03/19

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 implementera ett affärssystem på ett bra sätt.

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

– tidrapportering
– utläggshantering
– resor och traktamenten
– projektredovisning och projektbudgetering
– huvudboksredovisning
– finansiell budgetering och prognos, uppföljning
– fakturering och kundreskontra
– EFH och leverantörsreskontraanläggningar
– ev ytterligare funktioner såsom abonnemang, inköp och lager mm

  • 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”. I vissa sammanhang talar man om ska-krav och bör-krav men det räcker inte. 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 dimensioner:
    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.

Nästa artikel kommer att handla 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?

Postad: 2021/03/05

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 istä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? Går det fortfarande att få support?
  • Utvecklas det nuvarande systemet fortfarande eller har leverantören bytt spår t ex mot Cloud?
  • Hur ser själva leverantören ut? Ekonomisk utveckling? Närvaro i Sverige mm. Detta är extremt 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. För konsultbolag är det verksamhetskritiskt att använda ett affärssystem som har fokus på projekt/uppdragsredovisning och tidrapportering. Man måste kunna fånga tiden på ett effektivt sätt för att kunna fakturera smidigt och lika viktigt är det att kunna följa uppdragen/projekten rent ekonomiskt. Dessutom måste redovisningen i systemet stödja termer såsom successiv vinstavräkning, upparbetade intäkter mm. Gör inte systemet det så är det nog läge att fundera på ett nytt system istä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?

Postad: 2021/02/18

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.
  • Stora rapporteringsproblem på grund av att information man vill följa helt enkelt inte finns i systemet.
  • I övrigt många manuella rutiner på grund av att befintligt system inte stödjer processer eller digitalisering.

Ovanpå detta händer det att man som bolag inte givit sitt affärssystem den tid och uppmärksamhet det behöver så man kan helt plötsligt sitta med ett system som inte längre supporteras av leverantören. Det kan vara ödesdigert eftersom det då i värsta fall kan sluta fungera då operativsystem etc kanske inte heller längre supporteras eller stöds.

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 dessa pandemitider.
  • Ä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.
  • 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 kan ”för mycket”, dvs det är för komplicerat och krångligt.

Många konsultbolag kan också ha hamnat i fel 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.