Cookie alert.

Deze website maakt gebruik van cookies om de website te verbeteren.
Ga naar content
Zoek op onderwerpen, blogs, diensten etc.

DevOps: Budgetteren in een DevOps organisatie

Laat ik maar alvast beginnen met de conclusie: een goed budget wordt altijd overschreden. Dat kaLege portemonneen er maar uit zijn.

Als we op een DevOps manier aan het werk zijn gegaan, bepalen we zeer kort cyclisch wat we gaan doen. De backlog wordt continu aangevuld en afgehandeld. We kunnen bij wijze van spreken vandaag bepalen wat we morgen doen. En dat kan echt iets heel anders zijn dan wat we gisteren dachten. De wereld om ons heen staat niet stil, sterker nog: hij verandert steeds sneller. Het is steeds minder Af.

Budgetteren is voor helderzienden
Hoe gaat het budgetteren in veel organisaties? In de zomer van 2016 wordt aan de verschillende afdelingen gevraagd welke budgetten er nodig zijn voor 2017. Alle managers pakken hun glazen bol erbij en gaan eens nadenken over welke projecten en investeringen er in de periode tussen een half jaar en anderhalf jaar van nu gedaan moeten worden. Binnen het team wordt al langer gesproken over het inzetten van AvePoint tooling, dit zou onze Continuous Delivery straat een stuk beter maken en we kunnen nog sneller en beter opleveren. We hebben dus geld voor licenties nodig. En de teamsites zijn echt aan een update toe, dus laten we daar de nodige uren maar voor reserveren. Dan pakken we die teamsites in de eerste helft van 2017 op en implementeren we AvePoint in de tweede helft. We leveren ons gevraagde budget in en wachten af. Na twee maanden in een schimmig proces te hebben verkeerd komt het zo rond oktober terug. Iedereen moet iets inleveren, dus ons gevraagde budget krijgen we, minus 10%. Da’s mooi, dat gebeurt ieder jaar dus dit hadden we ingecalculeerd in ons budget. Dat is dus geregeld en dat is maar goed ook, want het vierde kwartaal breekt aan, we moeten de budgetten van 2016 nog opmaken. Doen we dat niet, dan zijn we het kwijt. Dan komt het namelijk ten goede aan iets onbelangrijks als het bedrijfsresultaat van de hele onderneming. Dat willen we blijkbaar niet, dus we verbranden de laatste restjes nog even. Niet zo gek dat het vrijwel overal in de laatste maanden van het jaar het drukst is.

Kortom: we verwachten ieder jaar dat we in staat zijn anderhalf jaar vooruit te kunnen kijken. En we houden elkaar voor de gek door in de budgetten voldoende buffer in te bouwen en wat we over hebben op te maken. Ten koste van de resultaten van de onderneming, maar dat is even niet ons probleem. Toch is het raar, wat we maken is immers nooit af. Hoe weten we dan in augustus 2016 wat we in november 2017 gaan doen? Het wordt nu eenmaal gevraagd en roepen we dus maar wat.

Van budgetteren moet je leren
Wat als we de vraag: hoeveel geld heb je in 2017 nodig nou eens zouden beantwoorden met dat wat we echt zeker weten? Dan vragen we dus veel te weinig. Maar we hebben het wel nodig. Gaat het om een DevOps team waar Office 365 wordt ontwikkeld en beheerd dan hebben we wat kosten voor tooling die we gebruiken en we weten zeker dan we een aantal mensen nodig hebben om onze kunsten te verrichten. We weten vrij zeker hoeveel beheerders we in ieder geval nodig hebben om de continuïteit te waarborgen en we weten ook dat we iets aan ontwikkeling moeten doen. Dat iets schatten we op basis van onze ervaring en we leren voortdurend. Die goede oude Deming Circle. Plan-Do-Check-Act. Niet meer, niet minder. Dit team noemen we maar het kernteam. En we hebben een partner die onze achtervang is: als er meer werk is dan het kernteam aankan, kunnen we snel opschalen (zie ook de blog Een Nooit Af organisatie). We hoeven dan alleen maar budget te regelen. Als we het echt nodig hebben dus, niet eerder.

Dan wordt het 2017 en gaan we aan de slag (nou ja, we gaan lekker door met waar we in december al mee bezig waren, maar een jaar overgang is nu eenmaal een magisch iets). Onderhoudscontracten voor de tooling worden keurig betaald en de medewerkers zitten op hun plek. De “vaste” externen hadden we in ons budget zitten, dus ook die facturen worden netjes betaald. Maar we hebben niets extra’s in ons budget. Tegenvallers en onverwachte extra werkzaamheden leiden direct tot een overschrijding van het budget. Maar is dit erg? Het zorgt er in ieder geval voor dat het team even goed nadenkt over de nut en noodzaak van de overschrijding. Het zal wel uitgelegd moeten worden. Bovendien kan het getoetst worden aan de laatste stand van zaken binnen de organisatie. Draaien we beter of slechter dan verwacht? Is er binnen de gehele organisatie wel ruimte voor budgetoverschrijdingen? Het zelfsturend team beschikt immers over alle informatie en kan dus zelf meedenken. En zal zelf de samenwerking met anderen moeten zoeken om tot de juiste keuze te komen. Het overschrijden van het budget hoeft dus helemaal niet slecht te zijn, het moet vooral logisch en goed voor de totale organisatie zijn. Dit vereist wel totale transparantie van iedereen. Als ergens iemand in de organisatie iemand stiekem buffers blijft inbouwen voor zichzelf, dan ondermijnt hij het vertrouwen in het systeem. Maar doordat iedereen ziet wat er gebeurt, is de kans ook groot dat dit vanzelf wordt gecorrigeerd.

Terug naar de conclusie: een goed budget wordt altijd overschreden. Beetje kort door de bocht, maar binnen budget blijven we eigenlijk nooit. Is dat wel het geval, dan is de kans groot dat er toch stiekem buffers in de budgetten zijn geslopen. En dat moeten we gauw afleren. Er is door deze manier van budgetteren wel degelijk een financiële buffer (als het goed is, ten minste), maar die bevindt zich op de plek waar hij hoort. Op organisatieniveau en niet versnipperd over de hele organisatie. Ik geef wel toe: het omgooien van de manier van budgetteren is voor veel organisaties geen eenvoudige klus. Je kunt op kleine schaal beginnen om ervaring op te doen en de beoordelen of het binnen jouw organisatie wel echt werkt. Spreek met een aantal managers af dat je op de bekende manier budgetteert. Vervolgens voeg je alle budgetten samen en verdeel je de budgetten waarvan je zeker weet dat je ze nodig hebt. Je houdt zo een centrale buffer over. Samen met je collega’s bespreek je gedurende het jaar de besteding van deze buffer. Je leert zo om samen te werken als het gaat om het maken van kosten. Je moet voortdurend met je collega’s overleggen wat het beste voor de organisatie is. En dat is niet altijd wat het beste voor jouw afdeling of team is. Ik ben ervan overtuigd dat je zult zien dat de kosten uiteindelijk lager uit zullen vallen. En je de middelen hebt besteed aan hele andere zaken dat je anderhalf jaar daarvoor had bedacht. Deel deze ervaringen met de hele organisatie en overtuig ze dat deze nieuwe manier de organisatie weer een stukje verder helpt.

Andere blogs over DevOps:
Wat komt er na SCRUM
DevOps: Als het toch nooit af is
DevOps: Een Nooit Af organisatie
DevOps: Ook management is Nooit Af
DevOps: Werkwijze van een DevOps team

Meer over DevOps, .Net

Blogpost / 9-9-2020

The perfect secure Azure Kubernetes Deployment (part 1)

Kubernetes is the most populair container orchestrator available
Blogpost / 6-3-2020

Waarom zou je je DevOps omgeving standaardiseren?

Met Azure DevOps wordt de veelgebruikte DevOps-methode gevangen in één centrale tool, waardoor alle onderdelen van de gehele ontwikkelstraat zijn samengevoegd. Lees in deze blog de voordelen en mogelijkheden.
Blogpost / 11-2-2016

DevOps: Werkwijze van een DevOps team

Als we alle rollen voor het ontwikkelen en beheren van een IT-oplossing bij elkaar brengen in een DevOps team, hoe komt dan de werkwijze eruit te zien?
Blogpost / 11-2-2016

DevOps: Werkwijze van een DevOps team

Als we alle rollen voor het ontwikkelen en beheren van een IT-oplossing bij elkaar brengen in een DevOps team, hoe komt dan de werkwijze eruit te zien?
Blogpost / 26-1-2016

DevOps: Ook management is Nooit Af

Een DevOps organisatie stelt andere eisen aan managers. Traditionele rollen verdwijnen of worden in het zelfsturende team belegd. Van Managers naar Leiders.
Blogpost / 19-1-2016

DevOps: Een Nooit Af organisatie

Hoe organiseer je een DevOps team? Waar moet dit team aan voldoen en hoe bemens je dat?
Blogpost / 12-1-2016

DevOps: Als het toch Nooit Af is

Wat als het resultaat nooit af is? Dan moeten we anders te werk gaan. Kleine aanpassingen in plaats van grote projecten. DevOps en Continuous Delivery dus.
Blogpost / 3-7-2013

Wortell ontwikkelt WPC deelnemers app voor Microsoft

Tijdens de Microsoft Worldwide Partner Conference kunnen deelnemers elkaar eenvoudiger vinden en bereiken via de 'Deelnemers app' die Wortell heeft ontwikkeld.