Hvorfor CFO alltid er sist ut å vite at et prosjekt gikk over budsjett (og hvordan endre det)

Det er andre uke i måneden. Månedsmøtet står på kalenderen torsdag. Tirsdag begynner prosjektrapportene å komme inn. En av dem — det store industri-oppgraderingsprosjektet som har gått siden januar — ligger 1,8 millioner over budsjett. Prosjektlederen har visst om det i to uker. Kommersiell leder har visst i rundt ti dager. Når CFO åpner presentasjonen torsdag morgen, er overskridelsen allerede historie.

Samtalen som følger er forutsigbar. Hvorfor så vi ikke dette komme? Når skjedde det? Hva har vi forpliktet oss til som ikke lar seg trekke tilbake? Og under disse spørsmålene, det stillere ett: hvordan endte økonomi opp som den siste til å få vite om en kostnad som økonomi nå er ansvarlig for å forklare? Enten tittelen er CFO, økonomisjef eller daglig leder med budsjettansvar — mønsteret er det samme.

Dette er ikke et spørsmål om rapporteringsfrekvens. Det er ikke at prosjektleder glemte å flagge. Det er et strukturelt problem med når økonomisystemene i det hele tatt registrerer kostnaden — og inntil den strukturen endres, vil økonomisjefen fortsette å få vite om forpliktelser flere uker etter at virksomheten har inngått dem.

Synlighetsgapet, målt i uker

Her er det som faktisk skjer mellom at en kostnad bestemmes og at finans ser den. Et prosjektteam identifiserer et behov. De oppretter en innkjøpsordre. Bestillingen godkjennes — kanskje av prosjektleder, kanskje av kommersiell leder, kanskje opp en kjede avhengig av beløpet. Når den er godkjent, er virksomheten forpliktet. Leverandøren har fått autorisasjon til å levere, og pengene er kontraktsfestet skyldig når fakturaen kommer.

Den godkjenningen skjer i et system — et innkjøpsverktøy, en delt mappe, en e-posttråd, iblant en prosjektstyringsplattform. Forpliktelsen ligger der. Den ligger ikke i økonomisystemet.

Uker går. Leverandøren leverer. Så fakturerer. Fakturaen kommer inn i leverandørreskontroen, blir kodet, matchet, godkjent for betaling, og lander til slutt i regnskapssystemet. Det er øyeblikket økonomi for første gang ser kostnaden.

Fra forpliktelse til registrering i regnskapet er det typiske gapet tre til åtte uker. På et prosjekt av noe kompleksitet, med flere leverandører og overlappende leveranser, bygger gapet seg opp. Når månedsslutt kjører, ser finans på et regnskap som gjenspeiler beslutninger tatt i forrige måned, eller måneden før, eller i noen tilfeller forrige kvartal.

CFO er ikke sist ut å få vite fordi folk skjuler ting. Hen er sist ut å få vite fordi systemene som produserer økonomioversikten først begynner å registrere kostnaden etter at forpliktelsen allerede er gjort.

Alle oppstrøms har ferskere informasjon. Finans har den eldste.

Hvorfor standardverktøy ikke løser dette

De intuitive svarene på dette problemet feiler alle av samme underliggende grunn — de retter seg mot presentasjonen, ikke tidspunktet.

Ingen av disse treffer det strukturelle problemet: kostnaden må fanges i det øyeblikket forpliktelsen gjøres, ikke når fakturaen kommer, og den fangsten må skje i et system den økonomiansvarlige kan se uten å måtte spørre noen.

Hva synlighet av innkjøpsordrer egentlig betyr

Begrepet innkjøpsordre-synlighet blir ofte redusert til en rapporteringsfunksjon — «kan jeg se mine åpne bestillinger i et dashboard?» Det er den overfladiske versjonen. Den dypere versjonen er dette: kan den som har ansvar for virksomhetens kontantstrøm se hver forpliktede kostnad i det øyeblikket den ble forpliktet, med kontekst på hvilket prosjekt den treffer, hvilken budsjettlinje den trekker fra, og hvordan den står mot budsjettet for det prosjektet?

De fleste virksomheter svarer «litt» på det spørsmålet. De kan se bestillinger som er godkjent, som regel i et innkjøpsverktøy eller en delt mappe. De kan se forbruk som har truffet regnskapet. Det de ikke kan se, er koblingen mellom disse to — den forpliktede kostnaden som er godkjent, men ikke fakturert ennå, aggregert mot prosjektbudsjetter, synlig for økonomi i samme oversikt som alt annet.

Den manglende koblingen er der CFOs synlighetsgap ligger. Ikke i rapportlaget. Ikke i dashboardene. I datamodellen som behandler godkjenning av bestilling som en innkjøpshendelse, ikke en økonomisk hendelse.

I det øyeblikket en bestilling godkjennes, er pengene så godt som brukt. Virksomheten kan trekke tilbake en forespørsel. Den kan sjelden trekke tilbake en forpliktelse. Regnskapet vet bare ikke om det ennå.

Den strukturelle løsningen er å behandle bestillingsgodkjenningen på samme måte som virksomheten allerede behandler mottatt faktura: som øyeblikket kostnaden blir reell. Fra det øyeblikket skal kostnaden vises mot prosjektbudsjettet, mot kontantstrømprognosen, mot forpliktelses-totalen — ikke som prognose, men som faktum. Den er forpliktet. Den kommer til å skje. Fakturaen er en formalitet.

Hva økonomisjefen faktisk kan se — tre versjoner av samme virksomhet

For å gjøre gapet konkret, se for deg tre versjoner av samme virksomhet som kjører samme prosjekt.

Versjon A — kun regnskapssystem

CFOs oversikt oppdateres når fakturaene lander i regnskapet. Når en overskridelse er synlig i månedsrapporten, ble kostnadene forpliktet tre til åtte uker tidligere. Prosjektteamet har gått videre. Enhver korrigerende handling — redusert omfang, pressing tilbake på endringer — er nå opprydding, ikke forebygging. CFO forklarer overskridelsen i styrerapporten.

Versjon B — manuell loggføring ved siden av regnskapet

CFO har bedt prosjektlederne loggføre forpliktelser i et regneark fortløpende. Noen gjør det, noen ikke. Loggen er som regel oppdatert innen en uke på velstyrte prosjekter, og innen en måned på de andre. CFO kan få et estimat hvis noen samler loggene, men det holder ikke for å kjøre en kontantstrømprognose på det. Månedsrapporteringen er fortsatt regnskapsdrevet. Synlighet på overskridelser bedres marginalt.

Tre versjoner av samme virksomhet. Den eneste strukturelle forskjellen er når forpliktelsen treffer et system finans kan se.

Hvorfor dette betyr mer for prosjektbaserte virksomheter

I en produktbasert virksomhet er kostnadene relativt forutsigbare: varelager, lønn, faste kostnader, kjente leverandøravtaler. Gapet mellom forpliktelse og fakturering betyr mindre fordi det underliggende kostnadsgrunnlaget ikke varierer stort fra måned til måned.

Prosjektbaserte virksomheter — bygg og anlegg, ingeniørkonsulenter, maritim installasjon, event, energi-infrastruktur — er annerledes på tre spesifikke måter:

• Høy frekvens av forpliktelser. Kostnader bestemmes i sanntid av dem som gjør jobben, ofte uten at finans er med i bildet
• Høy variasjon. Hvert prosjekt er forskjellig; omfanget utvikler seg, endringer avtales på byggeplass, underentreprenører hentes inn midt i prosjektet
• Høye konsekvenser. Én underestimering på én underentreprise kan ta et helt prosjekt fra lønnsomt til tap — det finnes ingen lageromløp eller salgsmiks som fanger det opp

Hvis finans ser en dårlig forpliktelse seks uker etter at den er inngått, finnes det ingen vei tilbake. Og likevel opererer de fleste prosjektvirksomhetene akkurat slik — fordi verktøyene finans bruker er bygd for produktvirksomheter. Regnskapssystemer registrerer kostnad når den blir fakturert. ERP-systemer registrerer forpliktelse, men først etter en tung implementering. Innkjøpsverktøy fanger bestillinger, men snakker ikke prosjektkostnadskontroll flytende. Mellom disse tre kategoriene faller det spesifikke behovet til en prosjektbasert CFO — sanntids synlighet av forpliktelser, kartlagt mot prosjektbudsjetter, uten en ERP-implementering i millionklassen — gjennom gapet.

Hva som må endres (og i hvilken rekkefølge)

Hvis målet er å lukke synlighetsgapet uten å bygge om hele økonomistakken, er rekkefølgen viktig.

1 · Bestem hvor forpliktet kostnad skal bo

Før noe kjøpes, må finans og operasjonell drift bli enige om hvor det autoritative registeret for forpliktet kostnad ligger. Er det regnskapssystemet, er du låst til faktura-timing. Er det en delt logg, er du låst til manuell inntasting. Er det et dedikert innkjøpsstyringssystem som holder budsjetter og forpliktelser sammen, har du en sjanse. Denne beslutningen avgjør alt nedstrøms.

2 · Flytt bestillingsgodkjenninger inn i det systemet

Når systemet er valgt, må hver bestillingsgodkjenning skje inne i det. Dette er den tyngste atferdsendringen — prosjektlederne er vant til å godkjenne på e-post, Slack eller muntlig. Overgangen krever en kortsiktig påtvingning og et system som ikke gjør godkjenningen vanskeligere enn dagens metode. Gevinsten — sanntids forpliktelsesdata — kommer bare hvis dette steget holder. Delvis adopsjon gir et dårligere resultat enn ingen endring, fordi dataen ser komplett ut, men ikke er det.

3 · Bygg kontantstrømprognosen fra forpliktede data

Når forpliktelser fanges ved godkjenning, endrer kontantstrømprognoser form. I stedet for å prognostisere utbetalinger fra datoer for mottatt faktura, prognostiserer du fra forpliktede kostnader pluss leveringstider pluss betalingsbetingelser. Prognosen gjenspeiler det virksomheten faktisk har forpliktet seg til, ikke det reskontroene allerede har behandlet.

Hva CFO ser etterpå

Når denne endringen har satt seg, flytter månedsmøtet seg på to spesifikke måter.

For det første: overskridelser slutter å være overraskelser. Når et prosjekt er over budsjett, har finans fulgt forpliktelsene mot grensen i uker. Samtalen er ikke «når skjedde dette?» — den er «vi flagget dette for tre uker siden, her er det vi bestemte å gjøre, her er hvor det landet».

For det andre: kontantstrømprognosen blir noe virksomheten kan planlegge rundt. Hvis forpliktede kostnader er synlige etter hvert som de godkjennes, gjenspeiler prognosen for utbetalinger de neste 60 dagene faktiske forpliktelser, ikke en ekstrapolering fra siste måneds forbruk. Arbeidskapital-beslutninger tas på reell data. Covenant-samtaler med långivere blir enklere. Finansteamet slutter å være en etterslepsindikator og blir en nå-tilstands-indikator.

CFO er ikke lenger sist ut å få vite — ikke fordi hen stiller flere spørsmål, men fordi dataen kommer i forpliktelsesøyeblikket, før noen trenger å spørre.

Hvorfor dette er vanskeligere enn det ser ut (og hvorfor det er verdt det)

Det vanskeligste med å lukke dette gapet er ikke verktøyet. Det er å overbevise de operasjonelle om at det er verdt deres tid å flytte bestillingsgodkjenninger inn i et sentralt system. Fra prosjektleders perspektiv fungerer dagens prosess — prosjektet får underentreprenørene sine, materialene dukker opp, leveransene skjer. Synlighetsgapet er finans sitt problem, ikke drifts problem.

Motargumentet som faktisk når fram til prosjektlederne er dette: overskridelsene som er pinlige for finans, er også pinlige for prosjektlederne. Når et prosjekt går 15 prosent over budsjett, bærer prosjektleder det også. Overskridelsen de ikke så komme, er også den som lander på medarbeidersamtalen, på neste prosjekts budsjett, og på troverdigheten i det kommersielle teamets øyne. Å fange forpliktelser ved godkjenning er like mye et sikkerhetsnett for prosjektleder som et synlighetsverktøy for CFO.

Rammet slik blir endringen noe de operasjonelle vil ha, ikke noe finans påtvinger. Verktøyet støtter en praksis begge sider har nytte av. CFOs synlighet er en bieffekt av å gi prosjektteamet en bedre måte å se egne forpliktelser mot eget budsjett.

Ingenting av dette krever et ERP. Ingenting av dette krever måneder med innføring. Det krever at virksomheten blir enige om hvor forpliktet kostnad skal bo, flytter bestillingsgodkjenninger dit, og lar dataen flyte derfra inn i rapportene finans allerede kjører.

CFO slutter å være sist ut å få vite. Ikke fordi de ble mer pågående på rapporteringskrav. Fordi datamodellen endelig gjenspeiler når forpliktelser faktisk skjer.