Van offerte tot betaling
In veel kleine bedrijven is een project versnipperd over veel software: sales maakt de offerte, de projectmanager beheert het project, inkoop zoekt leveranciers, de boekhouding boekt de kosten, en finance stuurt uiteindelijk de factuur en jaagt de betaling na. Maar waar de eigenaar echt om geeft, is het hele verhaal: wat hebben we geoffreerd, wat heeft het echt gekost, hebben we geleverd wat we beloofden, hoeveel hebben we gefactureerd en hoeveel geld hebben we uiteindelijk geïnd.
In veel kleine bedrijven is een project versnipperd over veel stukjes software.
Sales werkt aan de Quotation.
De projectmanager beheert het Project.
Inkoop zoekt Suppliers.
De boekhouding boekt de Expenses.
En uiteindelijk stuurt Finance de Invoice en jaagt de betaling na.
Iedereen ziet maar een deel van hetzelfde klantproject.
Maar waar de eigenaar echt om geeft, is het hele verhaal:
Hoeveel hebben we geoffreerd?
Hoeveel heeft het echt gekost?
Hebben we geleverd wat we beloofden?
Hoeveel hebben we gefactureerd?
Hoeveel geld hebben we uiteindelijk geïnd?
Dus bij het ontwerpen van Snappy PM wilden we deze dingen vanaf het begin met elkaar verbinden.
Een project begint met de eisen van de klant.
Requirements worden geleidelijk een Scope.
De Scope wordt uiteindelijk een Quotation.
Pas nadat de klant de Quotation heeft geaccepteerd, weten we echt:
Wat hebben we beloofd te leveren, en voor hoeveel?
Dan gaat het project de Implementation of Manufacturing in.
Materialen, inkopen, arbeid en andere Expenses beginnen plaats te vinden.
Dit zijn niet langer alleen kosten die verspreid in het financiële systeem liggen.
Ze horen bij dit Project.
En zo kunnen we gaandeweg zien:
Quoted Revenue
Cost to Date
Work in Progress
Expected Margin
Dan vindt de Delivery plaats.
En uiteindelijk gaan we naar het Closing:
Invoice → Payment → Settlement → Close.
Op dit moment zouden Accounting en Project Management geen twee totaal verschillende werelden meer moeten zijn.
Want voor de eigenaar waren ze altijd al één en hetzelfde.
Een project van AED 200.000 kostte uiteindelijk AED 130.000.
Waarom waren die 130.000 hoger dan begroot?
Was het materiaal?
Arbeid?
Een Scope Change?
Installation?
De antwoorden op deze vragen zouden niet moeten wachten tot de accountant maanden later een P&L produceert.
Ze zouden geleidelijk zichtbaar moeten worden terwijl het project loopt.
Dit is ook een heel belangrijke richting in hoe we Snappy PM ontwerpen:
Project Management zou uiteindelijk de cijfers in de boekhouding moeten verklaren.
En de boekhouding zou omgekeerd de Project Manager moeten vertellen:
wat er echt op het project is gebeurd.
Een Quotation is geen geïsoleerde PDF.
Een Purchase is geen geïsoleerde Expense.
En een Invoice is geen factuur die plotseling verschijnt nadat het project is afgelopen.
Het zijn allemaal verschillende registraties die hetzelfde commerciële proces heeft achtergelaten.
Alleen door deze registraties te verbinden, kunnen we de vraag beantwoorden waar een eigenaar echt om geeft:
Hebben we op dit project echt geld verdiend?
En belangrijker nog:
Waarom?
SnapLedger, your life easier.
Project Management zou uiteindelijk de cijfers in de boekhouding moeten verklaren. Een offerte is geen geïsoleerde PDF, een inkoop is geen geïsoleerde kostenpost, en een factuur is geen rekening die plotseling verschijnt nadat het project is afgelopen — het zijn verschillende registraties van hetzelfde commerciële proces. Ze verbinden is wat het antwoord geeft: hebben we op dit project echt geld verdiend, en waarom?
Kun je van je laatst afgeronde project vandaag direct geoffreerde omzet, werkelijke kosten, gefactureerd bedrag en geïnd geld naast elkaar leggen? Zo niet, waar leeft elk van die cijfers op dit moment?
Quotation → Delivery → Invoice → Cash. Eén commercieel proces, één doorlopende registratie.
Ontvang het Founder Diary + regelgevingsupdates voor jouw land
Een e-mail wanneer Richard een nieuw bericht publiceert, en de regelgevingsupdates die ertoe doen waar je woont. Gratis, altijd op te zeggen.