HELENA LINDQVIST

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.