Perché una software house può fallire anche quando sa costruire software

Uno dei problemi principali è stata la mancanza di una struttura decisionale realmente efficace.

I ruoli formali esistevano, ma non sempre corrispondevano ai poteri e alle responsabilità effettivamente esercitati. Le decisioni importanti non seguivano sempre un processo chiaro, documentato e condiviso tra i soci.

Con il tempo, questo ha portato a una situazione nella quale alcune persone si occupavano concretamente dell’operatività, mentre altre mantenevano ruoli societari senza contribuire in modo equivalente alla gestione.

Il risultato è stato un progressivo deterioramento della governance.

Quando i soci smettono di parlarsi in maniera efficace, ogni altro problema diventa più difficile da risolvere.

Le comunicazioni importanti diventano sporadiche, alcune richieste restano senza risposta e diverse questioni vengono trascinate per settimane o mesi. In una società piccola, questo è devastante.

Non servono cento dipendenti per avere problemi di governance: bastano poche persone che non riescono più a comunicare tra loro in modo chiaro e costante.

La parte amministrativa è diventata progressivamente più difficile da gestire. Mancava una visione semplice e condivisa della situazione economica: quali clienti fossero attivi, quali avessero crediti aperti, quali fossero i costi ricorrenti, quali servizi fossero davvero profittevoli e quale fosse il valore effettivo degli asset.

Questo rendeva difficile prendere decisioni razionali. Una società tecnologica può avere codice, clienti, domini, server e contratti, ma se nessuno riesce a quantificare correttamente questi elementi, diventa quasi impossibile capire quanto valga davvero l’attività.

La gestione finanziaria ha sofferto dello stesso problema. Crediti, costi e flussi finanziari non venivano sempre monitorati con la sistematicità necessaria.

Un errore tipico delle piccole aziende è confondere il fatturato con la sostenibilità economica:

• Un cliente che deve pagare non equivale a liquidità disponibile.
• Un contratto non equivale a margine.
• Un progetto che genera fatturato non necessariamente genera profitto.

Anche il portafoglio clienti ha contribuito alla situazione. Alcuni clienti pagavano in ritardo, altri richiedevano una quantità di assistenza sproporzionata rispetto al loro valore economico.

Il problema non era semplicemente che un cliente non pagasse. Spesso era il rapporto tra quanto il cliente produceva e quanto lavoro operativo richiedeva.

Per una software house piccola, un cliente da poche centinaia di euro all’anno può richiedere decine di ore di lavoro, assistenza, manutenzione e gestione delle urgenze. A quel punto, quello che sulla carta sembra un cliente diventa in realtà un costo.

La gestione dell’infrastruttura è stata un altro punto debole. Nel tempo si sono accumulati domini, hosting, VPS, database, applicazioni e configurazioni differenti, senza arrivare a una standardizzazione realmente efficace.

C’erano applicazioni non containerizzate, infrastrutture distribuite e sistemi che richiedevano manutenzione manuale. Questo rendeva difficile:

• Sapere esattamente dove fosse ogni applicazione.
• Effettuare backup affidabili.
• Trasferire rapidamente i servizi.
• Documentare l’infrastruttura.
• Ridurre i costi.
• Intervenire rapidamente in caso di problemi.

A un certo punto è diventato necessario razionalizzare l’infrastruttura e spostare parte dei servizi verso soluzioni più economiche. Il problema è che queste operazioni sono arrivate quando la situazione era già molto complessa.

Il problema non era necessariamente la capacità tecnica di sviluppare software. Il problema era l’assenza di una gestione tecnica strutturata.

Si lavorava spesso sui problemi quando emergevano, anziché costruire processi in grado di prevenirli. C’erano progetti, tecnologie, configurazioni e codice sviluppati in momenti diversi, senza standard sufficientemente rigidi per deployment, documentazione, backup, monitoraggio e manutenzione.

Il tecnico finiva quindi per diventare anche sistemista, DevOps, supporto clienti e, spesso, la persona che doveva ricordarsi come funzionasse ogni singolo servizio.

Questo modello può funzionare per qualche cliente. Non è scalabile.

Quando una società possiede domini, server, applicazioni, database, account, contratti e clienti, queste informazioni devono essere documentate. Altrimenti una parte importante del valore dell’azienda rimane nella testa delle persone.

Questo crea una dipendenza enorme dai singoli individui. Se una persona lascia la società o semplicemente non è disponibile, improvvisamente diventano difficili domande che dovrebbero avere una risposta immediata:

• Questo dominio dove punta?
• Questo cliente è ospitato su quale server?
• Chi ha accesso a questo account?
• Come viene effettuato il backup?
• Quale applicazione utilizza questo database?
• Quanto paga questo cliente?

La documentazione non è burocrazia superflua. È ciò che rende trasferibili, manutenibili e valutabili gli asset dell’azienda.

La comunicazione interna ed esterna può degradarsi in modo quasi invisibile: email senza risposta, messaggi persi, informazioni comunicate informalmente e decisioni mai formalizzate.

Il problema non è soltanto che le persone non si parlano. Senza comunicazione documentata, diventa impossibile stabilire:

• Chi ha deciso cosa.
• Quando è stata presa una decisione.
• Chi era responsabile.
• Quali informazioni fossero conosciute.
• Quali attività dovessero essere svolte.

A questo si collega la confusione tra lavoro operativo e responsabilità societarie. Quando manca una struttura organizzativa, subentra il principio: “qualcuno deve farlo”. E quel qualcuno finisce quasi sempre per essere la persona più disponibile o competente.

Questo crea responsabilità operative senza il corrispondente potere decisionale.

Nel corso della vita di una società vengono prese decisioni che, col senno di poi, possono rivelarsi economicamente o strategicamente poco sostenibili.

Una delle difficoltà è distinguere tra ciò che rappresenta davvero un asset e ciò che è semplicemente lavoro tecnico necessario per mantenere in piedi l’attività. Un portafoglio composto da domini, clienti, contratti, hosting e applicazioni ha un valore, ma quel valore deve essere analizzato correttamente.

Ridurre tutto a “quanto incassiamo di canoni” può ignorare il valore di clienti custom, software proprietario, manutenzione, infrastruttura e know-how.

Allo stesso tempo, hosting, servizi, domini e altri costi ricorrenti devono essere confrontati continuamente con i ricavi effettivamente prodotti. Quando questa analisi arriva tardi, razionalizzare l’infrastruttura diventa un intervento d’emergenza anziché una scelta strategica.

Guardando tutto insieme, questo è probabilmente il cuore della storia.

Non c’è stato un singolo problema che ha fatto fallire la società. C’è stata una concatenazione:

governance debole → comunicazione scarsa → amministrazione confusa → poca visibilità finanziaria → decisioni lente → problemi con clienti → infrastruttura difficile da gestire → sovraccarico operativo → ulteriore deterioramento dei rapporti.

Ogni problema rendeva più difficile risolvere quello successivo. E alla fine la società si è trovata in una situazione nella quale continuare l’attività non aveva più senso.

La liquidazione non rappresenta tanto la fine improvvisa di un’azienda, quanto il punto conclusivo di un processo iniziato molto prima.

Prima si deteriora la collaborazione. Poi la governance. Poi la gestione economica. Poi l’organizzazione operativa. Infine, diventa necessario prendere atto che non esistono più le condizioni per proseguire normalmente.

La lezione più importante è semplice: il prodotto può essere tecnicamente valido e la società può comunque fallire.

Puoi avere codice, clienti, competenze e idee valide, ma se mancano governance, contabilità, comunicazione, processi e controllo finanziario, stai costruendo qualcosa che funziona tecnicamente ma non regge come azienda.