Dalla mia prima esperienza imprenditoriale e fino ad ideato, la compilazione del budget è stata un’attività formativa e ricca di discussioni che mi ha portato a riflettere su molti aspetti del futuro lavoro dandomi una consapevolezza importante sul nostro mondo. Anche se, non nascondo, che per i primi anni abbia un po’ tirato a caso…
Cos’è il BUDGET?
Ma partiamo dall’inizio… Avete mai fatto un budget? Ed ancora, durante l’anno avete mai dato un occhio al vostro budget stilato con tanta fatica? Ed a fine anno avete mai verificato le assunzioni precedenti per preparare quello nuovo?
Vi siete mai chiesti a cosa serva veramente?
Per alcuni è uno strumento utile a definire aspettative. Che posso essere di lowerbound (non voglio incassare meno di) o di upperbound (non voglio spendere più di) rispetto alle attività che gravitano intorno al business.
Per altri è uno strumento di check-up definito dall’insieme di diversi parametri (come efficacia, adeguatezza ed efficienza) che fungono da indicatore alla buona riuscita della nostra impresa (commerciale).
Ma cosa succede se il nostro modello di business è fortemente vincolato al mercato e se questo mercato è, al tempo stesso, altamente volatile e dinamico?
In questo caso lo “strumento budget” inteso come pietra miliare scolpita e non più modificabile non basta più e bisogna farlo evolvere in qualcosa di più fluido e dinamico.
Il budget è l’obiettivo che ci prefissiamo di raggiungere tramite strategie operative portate avanti grazie a continue scelte tattiche.
Le pratiche di beyond budgeting introdotte nel 1998, e portate avanti da aziende che piccole non sono, puntano proprio a questo: ad avvicinare un processo iterativo e di continuo apprendimento a qualcosa che non lo è.
Una sorta di budget-do-measure-learn.
Diventa quindi essenziale non solo ridurre gli sprechi, dovuti ad una rigidità eccessiva del “vecchio” strumento, ma è essenziale avere e mantenere una visione a medio-lungo termine del perché si fanno determinati investimenti.
Beyond budgeting si può riassumere in 12 principi, 6 di leadership e 6 di gestione:
Principi che si possono, tranquillamente, riassumere in un concetto molto chiaro: non essere rigido, sii trasparente ed accetta il cambiamento.
Più o meno quello che tutte le pratiche Agili per la scrittura del software e quelle Lean per l’evoluzione del proprio business cercano di far capire alla maggior parte di noi.
DEBITO TECNICO
Se bazzicate il mondo del software dovreste sapere cos’è il concetto di debito tecnico, ovvero quanto stiamo “lasciando indietro” sul fronte della qualità per rispondere velocemente ad esigenze di mercato (o peggio del cliente).
La definizione ufficiale è quella di Ward Cunningham
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”[5]
— Ward Cunningham, 1992
A me però piace molto di più quella data un decennio prima da Lehman
“As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.”[4]
— Meir Manny Lehman, 1980
è particolarmente importante una parola: COMPLESSITA’.
La definizione di un budget per una azienda tecnologica è fortemente influenzato dalla complessità che quest’ultima deve, in qualche modo, gestire.
Uno strumento che ci può aiutare a comprendere cos’è, e come si gestisce la complessità è il framework Cynefin, qui di seguito perfettamente spiegato dal suo autore (Dave Snowden):
Se quindi è tutto così “complesso” come facciamo a stabilire un budget a prescindere? Magari relativo alla nostra prossima idea imprenditoriale?
DICOTOMIE
E quindi, nel caso di una software house (o di una qualsiasi azienda che basa il proprio core business su software realizzato in casa) come si può studiare un budget che permetta di gestire e mantenere un prodotto?
Innanzitutto bisogna ricordarsi che il software “scade”. A parte rare eccezioni come AS/400 che stanno facendo girare ancora qualche banca, con problematiche di trashware per recuperare hardware funzionanti, il software ha una bella data di scadenza stampata (e poi nascosta). Questa data dipende da molteplici fattori: l’ecosistema usato per svilupparlo, la qualità con cui è stato sviluppato, il numero di persone che ne conoscono il codice, le funzionalità o anche semplicemente il dominio in tutti i suoi aspetti.
Se fino a qualche anno fa il “sacro Graal” del ridurre il debito tecnico (e quindi mantenere il software fresco) era associato al “refactoring del codice” oggi questo paradigma (di trashware alternativo) non basta più. Non basta più perché bisogna pensare anche a fare refactoring dell’architettura, dell’infrastruttura, del modello di business e bisogna avere il coraggio (ogni tanto) di buttare via tutto e ripartire da capo perché le scelte tecnologicamente valide 5 anni fa non lo sono più oggi così come i domini in cui sono state applicate.
Ma come si può preventivare, a budget, una scelta di questo genere? Magari veicolata da cambiamenti (e riassestamenti) del mercato IT da noi non controllabili?
Uno strumento ci è dato dalla filosofia di polar management (che vede una sua applicazione, giusta o sbagliata che sia, nell’approccio bimodale di Gartner). In sostanza tenendo fissi due punti, polari e quindi opposti (ie. Mantenere VS Riscrivere) alterniamo le scelte strategiche e tattiche per soddisfarli al meglio entrambi. Una soluzione, molto probabilmente, sub-ottima ma che al tempo stesso ci permette, più velocemente, di accettare (ed abbracciare) il cambiamento del mercato o anche, semplicemente, apprendere quelle informazioni che non abbiamo ancora in mano.
Si parla quindi di “E ANCHE” e non di “OPPURE”.
Evolvere E ANCHE mantenere.
Questo in soldoni potrebbe significare per una azienda che ha un prodotto software di investire continuamente (ecco il termine vero da usare) nell’evoluzione del software intesa non solo come nuove features ma anche, e soprattutto, come sostituzione di strumenti obsoleti, di apprendimento di nuove tecniche o metodologie di lavoro, o nel personale (perché la gente cambia lavoro o va in pensione), di girare un po’ di utile in attività di r&d guardando un po’ più in la del proprio piccolo orticello, di fare decoupling dei servizi in modo da poterli sostituire in corso d’opera e senza interruzione nell’erogazione, etc, etc.
Insomma di usare lo strumento budget per regolare un processo di continua evoluzione dell’azienda, del modello di business e del software che lo rende profittevole.
Quindi, la prossima volta che stenderete un budget ricordatevi di prendere quello vecchio, confrontarlo con quanto avete fatto, di ripassare i vostri obiettivi a medio-lungo termine, di snellire alcune scelte e di essere pronti a reiterare questo lavoro, confrontarlo con quanto c’è intorno e di avere la consapevolezza che chi vive con il software non può permettersi il lusso di adagiarsi sui successi temporanei.