Valg af regnskabssystem – en guide

Økonomisystem, regnskabssystem, ERP-system…

Kært barn har mange navne. Jeg har arbejdet med regnskabssystemer siden 1996 – dengang i forrige årtusind … før internetet. Dengang var der overraskende mange forskellige systemer – fra PC-Plus, Reflex og Revi2000 over Concorde C4/C5/XAL til Navision 3.56A (stadig en af mine favoritter… hvis bare DOS stadig var fedt). Og det er bare dem, vi brugte til bogføring hos Deloitte.

Fast-forward til 2016, hvor der er så mange at vælge mellem, at jeg mere eller mindre har mistet overblikket – jeg bidrager selv til Xena. Alle påstår de at have fundet den sølvkugle, som kan redde din virksomhed fra alt fra dårlige betalere til Skat. Så hvordan vælger man?

  1. Glem prisen (for nu)
  2. Start med hvorfor
  3. Spørg en ven
  4. Vælg en strategi
  5. Grovsortér og prøv
  6. Business as usual

1. Glem prisen (for nu)

Med så mange konkurrenter på området kan det være fristende, at lave en prissammenligning mellem alle produkterne og så fravælge de dyreste. Vent med det. Problemet med software er, at du meget sjældent kan vurdere om prisen er rimelig før du har brugt produktet i et halvt års tid. Regnskabsystemer varierer så meget i kompleksitet og kvalitet, at det er tæt på umuligt at vurdere det up-front.

2. Start med hvorfor

Hvilke udfordringer har din virksomhed? Hvor tjener du penge? Hvis du er en selvstændig kommunikationskonsulent har du væsentlig andre behov end hvis du seriefremstiller rengøringsmaskiner. Find de processer i din virksomhed, hvor du vinder mest ved at automatisere, for det er automatisering, et regnskabssystem skal hjælpe dig med. De bedste kandidater til automatisering er de områder, du/I er dårlige til eller som I ikke tjener penge på. Husk at det ikke altid er et system, der er løsningen – hvis det er bogholderiet, der er problemet, kan en deltidsansat bogholder eller et bogholderibureau nemt være bedre givet ud end et forkromet automatiseret helvede.

Så – hvad kan automatiseres? Hvis du kan tegne et flow-diagram over en proces, så kan den automatiseres. Hvis processen afhænger af en ansats humør og gamle venskaber, så kan den ikke. Tænk på regnskabssystemet som den checkliste, du mere eller mindre formelt udfylder når du gennemgår processen. Brug tiden på at finde ud af hvordan din virksomhed egentlig fungerer. Alle de områder, hvor du sukker dybt bare ved tanken – dér skal du sætte ind.

Hvad skal regnskabssystemet løse? Hvad vil du have svar på? Du kommer til at bruge rigtig meget energi på at putte data ind i systemet og hvis de data så ikke giver svar på dine spørgsmål, er du ligevidt, men har spildt en masse tid. Når du skifter eller investerer i et nyt økonomisystem, er det en gylden mulighed for at optimere din forretning. Skær de procedurer væk, som ikke giver (nok) værdi og indfør nye, der giver værdi.

3. Spørg en ven

Undersøg markedet for potentielle produkter – men gør det smart. Find virksomheder som minder om din – helst nogen, du ikke ligger i konkurrence med (de er som regel langt mere villige til at dele ud af deres erfaringer). Der findes et hav af ERFA-grupper, netværksgrupper og hjemmesider, hvor der er rigtig meget hjælp at hente. Steder som Amino er gode steder at starte. Vær kritisk; især ved ressourcerne på internettet – alle har en agenda.

4. Vælg en strategi

Groft sagt, har du 4 muligheder, hver med deres styrker og svagheder – de er sorteret efter hvor stor indflydelse, du har på deres funktionalitet fra mindst til mest:

  • Cloud
  • Hosted
  • Lokal installation
  • Hjemmestrik

En Cloud-løsning har du meget lidt kontrol over. Om du vælger Dinero, e-conomic eller Xena er i den sammenhæng ligegyldigt. Hvis de i morgen vælger at fjerne en funktionalitet, som du er afhængig af – tough luck. Til gengæld skal du ikke koncentrere dig om backup, drift, sikkerhed og vedligeholdelse af platformen (udover at sikre dig, at leverandøren gør det).

En hosted løsning giver dig mange af fordelene fra cloud-løsningen ved at du har en leverandør til at håndtere backup, drift og vedligeholdelse. Du har mere kontrol over funktionaliteten – de produkter der tilbyder hostede løsninger, har typisk større mulighed for tilpasninger af selve programmet – og der er større valgfrihed i forhold til opdateringer/opgraderinger.

Den lokale installation er den klassiske model. Produktet bliver installeret lokalt på din egen server/arbejdsstation og du har selv ansvaret for driften. Som med den hostede løsning er der typisk stor mulighed for at tilpasse produkterne.

Den hjemmestrikkede løsning er for dem, hvor der er brug for noget helt specifikt, som giver en konkurrencefordel. En god tommelfingerregel er, at med mindre du har fundet en helt ny måde at håndtere kunder på – eller har nogle fantastiske interne udviklingskompetencer… så lad være. Et regnskabssystem bliver generelt betragtet som noget af det vanskelligste at udvikle. Det betyder ikke, at du skal lade være med at hjemmestrikke systemer til specifikke processer – men lad være med at implementere finansbogholderiet selv.

De ovenstående modeller er hovedtyperne – der findes utallige hybrider. Det er et strategisk valg, hvilken du vælger – der er ikke noget rigtigt/forkert.

5. Grovsortér og prøv

Alt efter strategi og dine funktionalitetskrav har du højst sandsynligt reduceret feltet til 5-20 produkter, som kunne være interessante. Vælg 3 ud fra ren intuition og få en demonstration. Så vidt muligt, lad være med at introducere salgsleddet. Dan dig et indtryk af produktet – virker det “færdigt”? Hvis du støder på talrige fejl eller underlige brugerflade-kortslutninger, så forkast produktet – og vælg et nyt. Salgsleddets opgave er at overtale dig – ikke hjælpe dig. De ved godt, hvor skoen trykker (alle produkter har områder som er underprioriterede) og vil derfor prøve at underspille dem og slå på styrkerne (som ikke nødvendigvis passer sammen med dine vigtigste krav).

Understøtter produktet dine krav – prioritér i forhold til de vigtigste krav. Husk, at du ikke på nuværende tidspunkt kender produkterne til bunds – og acceptér at det kun er en foreløbig rangliste. Og vigtigst af alt – Exit-strategien: “Kan jeg få mine data ud igen, hvis jeg stopper med at bruge det?”.

6. Business as usual

Nu kommer forhandlingsfasen – det er ikke anderledes end at købe en bil*. Før købet har du kontrollen – efter købet… not-so-much.

* En bil er fyldt med langt mere elektronik end mekanik. En typisk high-end bil har konservativt anslået 100 mio. kodelinjer i den indbyggede software. Til sammenligning har Xena i skrivende stund ca. 80.000 linjer kode.

IT projekter der går galt

IT er på samme tid vanvittig simpelt og vanvittig komplekst. Vi ser hvert år både offentlige og private IT projekter, der går over budget, bliver forsinkede eller bliver skrottet helt. I mine øjne, er de tre vigtigste årsager:

Projektstørrelse

Forestil dig at du skal lave et program med een funktion – det skal kunne sende en mail. De fleste programmører vil kunne løse det på et par timer. Nu tilføjer vi en ekstra funktionalitet – journalisering af e-mails. Hver gang en e-mail sendes skal det gemmes for tid og evighed. Isoleret set vil denne funktionalitet også kunne gøres på et par timer, men vi skal også integrere den med e-mail funktionen. Den skal ændres til at tage højde for journalisering – så lad os sige det i alt tager fire timer for journaliseringsdelen. Nu kommer den tredje funktion – programmet skal kunne sende til en hel mailingliste. Igen, isoleret set et par timer – men integrationen skal nu ske til to andre funktioner. Mailinglistefunktionen vil nu tage i alt en 8-10 timer.

Mønsteret er, at kompleksiteten øges eksponentielt hver gang vi tilføjer en ny funktionalitet, fordi antallet af integrationer mellem funktioner stiger eksponentielt. Tidsforbruget stiger ligeledes eksponentielt og bliver stadig mere usikkert. Fælles for de største IT katastrofer er at kravspecifikationen indeholder 100-vis, hvis ikke 1000-vis af krav og funktioner, som alle skal være opfyldt på samme tid.

Vandfaldsmodellen

Rygmarvsreaktionen på 100-vis af krav, er at vi må bruge mere tid på at analysere problemet, så vi tager højde for alle de integrationer. Det er sådan man gør i andre ingeniør-discipliner. Skal du bygge en bro, så starter du med at tegne en skitse, lave en række beregninger, tilpasse skitsen efter det fundne, laver nye beregninger – når alt er beregnet, starter du med at bygge. Undervejs sørger du for at holde styr på forbrug af materialer og om dine forudsætninger holder stik og korrigerer dine beregninger, hvis det ikke er tilfældet. Vandfaldsmodellen: Analyse, design, implementation, opfølgning.

Det har man prøvet indenfor software siden 60’erne. Det går rigtig godt for små projekter, knap så godt for mellemstore projekter og helt katastrofalt for store projekter. Vandfaldsmodellen har nemlig en forudsætning – vi skal have et erfaringsgrundlag fra lignende opgaver og mere vigtigt, software involverer mennesker. En bro skal tage højde for vind, vejr, belastning og geologiske forhold – alt sammen noget du kan simulere på forhånd. Den skal ikke tage højde for, at en tilfældig bruger sidder på en langsom internetforbindelse på en virusbefængt maskine, som der lige er blevet spildt kaffe i.

Manglen på ansvar

Hvis man bygger en biltype, der konsekvent eksploderer efter 5-6.000 kilometers kørsel, bliver man ret hurtigt afskåret fra at lave biler. Hvis du som et af de 6 største revisionsfirmaer er medskyldig i regnskabssvindel, holder dit firma op med at eksistere (Læs: Enron og Arthur Andersen). Hvis man fejler med leverancen af et milliard projekt i det offentlige, bliver man indbudt til næste udbudsrunde.

Fordi størrelsen af IT projekterne bliver så enorme, er det ganske få firmaer, der overhovedet har mandskabet til at kunne udføre dem indenfor en overskuelig fremtid – og de fleste af dem har firmanavne på 3 bogstaver. Disse store firmaer har hver en omsætning på højde med adskillige kommuners samlede budget, og det gør det svært at statuere eksempler. Og ofte ligger problemet ligeså meget på kundens banehalvdel, så man bliver i al mindelighed enige om ikke at pege fingre… og således går de skyldige fri og kan fortsætte til næste katastrofe.

Hvad gør vi så ved det?

Vi skal lære at dele store projekter op i små dele – og så skal vi stå til ansvar for det vi bygger – både fra kunden og leverandørens side. Lave en havarikommision, så vi kan lære af de fejl, der sker. For der sker fejl – og i starten vil der ske mange fejl. Men hvis vi ikke gør noget, ender vi med 100% sandsynlighed nøjagtig hvor vi er nu.

IT-konsulenter – 3 tips

Du skal have lavet noget IT-sovs, men hvordan finder du en god IT-konsulent eller i det hele taget en god IT-leverandør? Her er mine erfaringer:

1. Gør din opgave overskuelig

Det lyder banalt, men gør dit hjemmearbejde. Hvad er det præcis du skal have lavet og hvordan passer det ind i dit eksisterende setup? Ja, hvad er dit eksisterende setup i det hele taget? Hvis du siger til din kommende leverandør: “Jeg skal bruge en hjemmeside, sådan lidt en mellemting mellem borger.dk og netflix.com – bare i pink”, så bliver du for det første ikke taget seriøst – og værre endnu; leverandøren har ikke en chance for at give et fornuftigt overslag.

Find det IT-folk kender som MVP – altså hvad er det absolut mindste du kan nøjes med. Hvis det er en hjemmeside, så dine kunder kan komme i kontakt med dig – så er statisk HTML helt fint og et fuldt CMS-system over-kill. Når du har gjort dit hjemmearbejde, så er det nemmere for leverandøren at give en reel pris og det er nemmere for dig at vurdere tilbuddet. Risikoen er også meget lav for både dig og leverandøren og I kan i samarbejde nemmere planlægge næste udvidelse.

2. Referencer, referencer og atter referencer

Hvad har de lavet før – og hvordan var de at samarbejde med? Det ved kun deres kunder. Vær opmærksom på, at alle firmaer kun lister success-historier på deres hjemmeside, så det er helt klart bedst, hvis du har nogen i dit netværk, der har erfaringer med dem.

Sørg for at finde referencer, som har fået lavet nogenlunde det samme, som det du skal have lavet. Det nytter ikke noget at leverandøren er god til at håndtere kæmpe kunder som DSB og du skal have lavet en visitkort hjemmeside.

3. Gør dig attraktiv som kunde

Gode IT-leverandører er ikke engangs-leverandører, de er samarbejdspartnere. Jo bedre de kender din virksomhed, jo bedre service kan de levere. Hvis de ved, at de kun bliver vurderet på pris, vil de handle derefter. Tommelfingerreglen siger at der er 3 grundlæggende kriterier: Lav pris, kvalitet og leveringshastighed. Til hver en tid kan du maksimalt få to af dem.

Igen, gør dit hjemmearbejde – hvad skal du have lavet indenfor de næste 3 år, som kunne være interessant for din leverandør? En sælger vil være villig til at give en skarp pris på første leverance, hvis han kan lugte et mersalg om 6 måneder. Men husk på følgende læresætning: “Glæden over den lave pris varer kortere end smerten over den lave kvalitet”. Leverandøren er en forretning – han skal tjene penge på dig. Accepter det. Vis at du villig til at betale for kvalitet – så får du på magisk vis kvalitet. Hvorfor? Leverandørens bedste folk bliver sat på opgaven, fordi du nu er en værdifuld kunde.

Konklusion

Der skal hjemmearbejde til for at finde gode IT-folk – og der er ikke nogen smutveje. IT er egentlig ikke væsentligt anderledes fra alt andet leverandørsamarbejde. Det skal vedligeholdes, passes og plejes – og ikke mindst måles. Og nej, jeg tænker ikke på BS og KPI‘er, men nærmere – leverer de til tiden? Er kvaliteten i orden første gang? Leverer de det aftalte? Kommer de med gode ideer? Lav dig en liste over de ting, der er vigtige for dig i leverandørsamarbejdet – og fortæl din leverandør det! Et samarbejde med en høj grad af gensidig tillid giver langt mere værdi end kontrakter kan.