ARTIKLAR

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

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

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

Definitioner

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

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

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

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

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

Viktigt att tänka på vid upphandling

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

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

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

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

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

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

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

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

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

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

On Premise kontra Moln

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

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

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

Lokal programvara (On-premise) – Egen drift

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

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

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

Lokal programvara (On-premise) – Extern drift

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

 Molnlösning (Cloud)

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

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

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

Viktiga skillnader mellan lokalt och moln

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

Drift

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

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

Kostnader

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

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

Kontroll

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

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

Säkerhet

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

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

Äkta moln – vad är det?

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

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

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

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

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

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

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

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

• Definition:

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

• Behovsinventering/prioritering:

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

• Kravspecifikation:

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

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

• Prioritering

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

• Andra värden:

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

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

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

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

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

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

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

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

• Ä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 igen dig i några av frågeställningarna ovan så är det nog dags att göra någonting. Då kan du med fördel kontakta någon på Sundbom & Partners som är experter på affärssystem för just konsultbolag. Kontaktinformation hittar du här.

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

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

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

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

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

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

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