Facturen van uw ICT leverancier: 6 aanbevelingen

facturenAls de opdrachtgever nalaat om vóóraf duidelijke afspraken te maken met zijn leverancier over de indeling van kostendragers en kostensoorten van de factuur, krijgt de leverancier in feite de vrijheid om op een manier te factureren die hem het beste uitkomt. 

 


Het gebeurt regelmatig dat opdrachtgevers schrikken van de hoge en vaak onduidelijke facturen die zij maandelijks krijgen van hun ICT leverancier. Waar gaat het mis en wat kun je er aan doen?

Inleiding

Een veel gehoorde klacht bij opdrachtgevers is de onduidelijkheid en de hoogte over de facturen die zij krijgen van hun ICT leverancier. Vaak kan geen verband worden gelegd tussen een eventuele opdracht die gegeven zou zijn en de specificaties op de factuur. Of pas na lang puzzelen en doorvragen bij de leverancier. Ongeacht of het nu gaat om reguliere activiteiten of eventuele meerwerk. 

Te weinig maakt een opdrachtgever in dit geval gebruik van de stelregel “wie betaalt, die bepaalt”. Het omgekeerde lijkt echter eerder het geval: “wie int, die verzint”. Dit laatste slaat dan vooral op de vorm van de facturen.

Het geeft veel opdrachtgevers, zowel in het MKB als in de grootzakelijke markt, een weinig comfortabel gevoel. De vraag is echter, wat kun je hier aan doen?

 

Analyse

Om deze vraag te kunnen beantwoorden, is het zinvol om een korte analyse te maken over hoe deze situatie kan zijn ontstaan. 

Om te beginnen, moet er een onderscheid gemaakt worden tussen twee belangrijke stadia in de relatie met uw leverancier:

  1. facturering tijdens een ontwikkelings- of implementatie traject. Veelal éénmalig en dus projectgebonden activiteiten;
  2. facturering van het beheer en onderhoud van een ICT omgeving. Vaak gebaseerd op een overeenkomst van dienstverlening en extra activiteiten in het kader van onderhoud.

In de volgende paragrafen zal elk stadium kort worden belicht. 

 

Projectgebonden activiteiten

Tijdens een project vinden veel activiteiten plaats die sterk kunnen variëren in tijd en omvang. Maar ook in samenstelling van de middelen die worden ingezet of aangeschaft. 

De belangrijkste kostensoorten die bij de inzet van de middelen kunnen worden onderscheiden zijn over het algemeen onder te verdelen in:

  1. de inzet van eigen medewerkers of die van een externe leverancier;
  2. de aanschaf van materialen en/of apparatuur;
  3. om de zaak te completeren is er nog een post overig: hieronder vallen alle niet eerdere genoemde kosten. 

Voor de duidelijkheid is het belangrijk dat deze kostensoorten gehangen kunnen worden aan bepaalde projectactiviteiten: de kostendragers. Hier gaat het vaak mis als het gaat om onduidelijke facturen. 

Menig project wordt gestart zonder dat er een heldere en voor alle partijen aanvaardbare opsplitsing is gemaakt in projectactiviteiten. Het gaat in dat geval met name om de afspraken tussen de opdrachtgever en de projectmanager, verantwoordelijk voor het project. 

De ruggengraat van elk project is een goed gedefinieerde Work Breakdown Structure (WBS). Een WBS is niets anders dan een hiërarchische opsplitsing van het project in activiteiten volgens een bepaald patroon. Het kent over het algemeen een aantal niveaus. Er zitten nogal wat voordelen aan een goed gedefinieerde WBS. Om er enkele te noemen:
  1. een betere mogelijkheid om gebruik te maken van het systeem van 'checks and balances' en de mogelijkheid van contra-expertise;
  2. een betere controle op vóóraf gedefinieerde werkzaamheden met de mogelijkheid van inzoomen;
  3. een betere verdeling van het projectbudget over de verschillende onderdelen bij de start van het project;
  4. een betere mogelijkheid om het werk te delegeren in afgebakende delen;
  5. een betere inschatting van benodigde budget voor het betreffende onderdeel;
  6. een betere risico inschatting en beheersing;
  7. een betere mogelijkheid voor ‘what - if’ scenario's;
  8. een betere communicatie tussen betrokkenen.

Hoewel een WBS de ruggengraat van elk project is, krijgt dit onderdeel merkwaardig genoeg amper aandacht in de literatuur over projectmanagement. Een grote valkuil is echter dat, als een WBS al wordt opgesteld, deze wordt gedefinieerd door de opdrachtnemer of projectmanager. Vaak is het dan een WBS die gedefinieerd is vanuit hún perspectief en sluit niet aan op de belevingswereld van de opdrachtgever. De laatste laat hier een duidelijke kans liggen. Zeker als je bedenkt dat een WBS ook de basis is voor het bepalen van de de kostendragers, en dus voor de budgettering en facturering. Met de projectmanager worden namelijk per WBS activiteit (is altijd het laagste niveau) afspraken gemaakt over wie er ingezet gaat worden, tegen welk tarief en wat het beschikbare budget is per leverancier. 

Een opdrachtgever kan én moet nu van zijn leverancier eisen dat elke gefactureerd bedrag gekoppeld is aan de betreffende WBS activiteit.  Maar ook per maand en per activiteit is getotaliseerd. Vaak wordt dit gedelegeerd naar de projectmanager. Op zich niets mis mee, maar maak in dat geval goede afspraken over het tijdig melden van een tekort op het beschikbare budget. Om vervolgens gezamenlijk te kijken wat de gewenste oplossing is. 

In de praktijk blijkt dat een opdrachtgever onvoldoende gebruik maakt van genoemde mogelijkheden. In dat geval kun je er vanuit gaan dat de aandacht op dit punt bij alle betrokken verslapt en er facturen gestuurd worden die voor een opdrachtgever volstrekt onleesbaar zijn. Als deze weg eenmaal is ingeslagen, is het moeilijk om dit terug te draaien. Het kost dan vaak onevenredig veel tijd en energie om de facturen alsnog in de gewenste vorm te krijgen.

 

Beheer en onderhoud van een ICT omgeving

Het stadium van het beheer en onderhoud is een wezenlijk andere dan dat van een project. Hier geldt een totaal andere dynamiek qua aansturing van deze activiteiten. 

Nadat een ICT systeem is opgeleverd komt het in beheer bij een ICT leverancier. Dit kan een interne ICT afdeling zijn, maar ook een externe leverancier. In  deze context gaan wij uit van het laatste.  Belangrijk bij de oplevering van een ICT systeem is het volgende:

  1. bij de oplevering wordt er een lijst opgesteld met aanvullende eisen en wensen die op korte termijn alsnog gerealiseerd moeten worden maar een goede werking van het systeem niet in de weg staan. Deze lijst met aanpassingen wordt opgedeeld in één of meerdere kostendragers en behoord  gekoppeld te zijn aan een budget (bij voorkeur per onderdeel);
  2. er wordt een overeenkomst van dienstverlening opgesteld over de manier waarop het beheer wordt uitgevoerd, tegen welk niveau en tegen welke kosten. Een dergelijke overeenkomst wordt vaak een Service Level Agreement (SLA) genoemd. Zeker in het geval van een externe leverancier heeft dit de vorm van een contract. In een SLA wordt vaak gebruik gemaakt van toetsbare prestatie indicatoren die aan een aantal eisen moeten voldoen zoals validiteit, eenduidigheid, meetbaarheid en vergelijkbaarheid. Zij vormen in principe de kostendragers en vormen als zodanig de basis voor de budgettering en de facturering. 
Zowel de lijst met gewenste aanpassingen als de SLA zijn de basis voor een overzichtelijke, maandelijkse facturering van de uitgevoerde werkzaamheden. De facturering moet één op één aansluiten bij de afspraken in een SLA. Een SLA specificeert ook welke werkzaamheden tot service moeten worden gerekend, en welke werkzaamheden daar niet toe behoren. Deze laatste kunnen dan op basis van een aparte offerte worden aangeboden, geaccepteerd en betaald.  Dat betekent dat, als er een vast maandelijks bedrag is afgesproken voor het beheer voor een afgesproken ICT omgeving, je dit moet terugvinden op de factuur. Het is niet de bedoeling dat er voor service een factuur komt met bijvoorbeeld de tijd die is besteed aan het oplossen van incidenten en met de bijbehorende kosten. Of welke componenten zijn vervangen om een probleemloze werking van het ICT systeem te garanderen, eveneens met bijbehorende kosten. Dit behoort immers tot de service (vooropgesteld dat deze service onderdeel is van de afspraken over het beheer in de SLA en tegen een vaste prijs). Het is uiteraard niet de bedoeling dat de opdrachtgever zelf met zijn rekenmachine aan de slag moet om na te gaan of het totaal bedrag overeenkomt met het vooraf afgesproken vaste bedrag. Maar het komt helaas nog te vaak voor in de praktijk. Vaak is dit een kwestie van het verslappen van de aandacht van opdrachtgever na het ondertekenen van de SLA. Hij richt zich weer op zijn normale managementtaken en gaat er vanuit dat het verder goed komt. Een leverancier factureert vaak op de manier zoals hij gewend is en voor hem het gemakkelijkste is. Hij wil niet graag geconfronteerd worden met klanten die elk hun eigen eisen stellen voor wat betreft de manier van factureren. Maar dat leidt vaak tot SLA’s die gesteld zijn in termen die voor de opdrachtgever betekenisloos zijn, zoals gemiddelde tijd nodig om een fout te herstellen (mean time to repair bugs). Dat zou een opdrachtgever nooit moeten accepteren. De SLA hoort de opdrachtgever te garanderen wat de maximale tijd is dat het systeem niet kan worden gebruikt. Ook bij het opstellen van SLA moet de opdrachtgever dus alert zijn.

Naast de reguliere beheerstaken, is er de post onderhoud: het doen van kleine of grote aanpassingen aan het systeem op verzoek van de opdrachtgever of zijn vertegenwoordigers. Ook hier geldt dat elk gefactureerd bedrag gekoppeld moet zijn aan een vóóraf afgesproken opdracht. Met een heldere specificatie. Eveneens weer een belangrijke kostendrager. 

Voor kleine aanpassingen die snel gedaan moeten worden, blijkt deze manier van uitvoeren nog wel eens lastig. In dat geval kunnen er afspraken gemaakt worden over maandelijks te besteden onderhoudsbudgetten waarover achteraf verantwoording over wordt afgelegd. Ook dan moet de opdrachtgever de wijze van verantwoorden en factureren vóóraf goedkeuren.

Overigens moet de facturering los gezien worden van de reguliere rapportages over het beheer: in dit voorbeeld het oplossen van incidenten. In een apart rapport wordt een opdrachtgever geïnformeerd over het aantal incidenten, de gemiddelde oplostijd, etc. 

 

Wijze van factureren

In alle gevallen is het belangrijk dat er duidelijke afspraken worden gemaakt over de wijze van facturering. Ruwweg zijn de volgende twee manieren te onderscheiden:

  1. facturering op basis van nacalculatie. In dit geval is koppeling aan projectactiviteiten of beheersactiviteiten een voorwaarde. Evenals de afspraken over het maandelijks beschikbare budget hiervoor;
  2. facturering op basis van een vaste prijs (‘fixed price’ contracten). Ook in dit geval blijft een koppeling met uit te voeren en afgesproken activiteiten een voorwaarde. De hoogte van de deelbetalingen worden dan vaak gekoppeld aan de voortgang van een activiteit, aan een vooraf afgesproken percentage of aan termijnbetalingen. 

 

Conclusie

Het voorkomen van een ondoorzichtige en onduidelijke facturering heeft de opdrachtgever zelf in de hand. Als de opdrachtgever nalaat om vóóraf duidelijke afspraken te maken met zijn leverancier over de indeling van kostendragers en kostensoorten van de factuur, krijgt de leverancier in feite de vrijheid om op een manier te factureren die hem het beste uitkomt. Een opdrachtgever zou ook op dit punt een meer bedrijfsmatige benadering moeten nastreven. Een benadering waar een opdrachtgever in principe vertrouwd mee zou moeten zijn. 

De ICT leverancier daarentegen zou zich meer moeten verplaatsen in de rol van de opdrachtgever en, op eigen initiatief, met facturen komen die gebaseerd zijn op gemaakte afspraken en aansluiten bij de belevingswereld van de opdrachtgever.

 

Zes aanbevelingen

De zes aanbevelingen zijn:

  1. Maak als vast onderdeel van de inkoopvoorwaarden dat de leverancier verplicht is te factureren op een door de opdrachtgever aangegeven manier. Maar ook over de indexering van de tarieven en prijzen.
  2. Ga uit van het principe “wie betaalt, die bepaalt”  en breng dat ook daadwerkelijk in de praktijk. Te vaak voelt een opdrachtgever zich, overigens ten onrechte, onzeker naar zijn leverancier toe. 
  3. Maak gebruik van een heldere structuur van projectactiviteiten met daaraan gekoppelde budgetten en inzetten. Laat dit de basis zijn van de facturering. Controle is dan ook beter te delegeren naar anderen.
  4. Maak bij het opstellen van een SLA gebruik van goed gedefinieerde prestatie indicatoren en daaraan gekoppelde betalingen. De facturen zullen hiermee in overstemming dienen te zijn.
  5. Laat de aandacht niet verslappen. Ook als het goed gaat is het zaak op regelmatige momenten met de juiste vertegenwoordiger van uw leverancier te overleggen over de voortgang, de geleverde prestaties en de bijbehorende facturen. Laat merken dat u, als opdrachtgever, er bovenop zit. 
  6. Uitgaande van een goede koppeling van kostensoorten, kostendragers, budgetten en facturering, kan de bewaking van de facturering gedelegeerd worden naar een eigen contractmanager. Hij of zij rapporteert vervolgens op basis van ‘management by exception’ aan de opdrachtgever