Quando ho iniziato il mio percorso di imprenditore, si stava già parlando delle aziende-rete: quelle aziende che concentrano in se stesse esclusivamente il core-business e delegano a partnership, alleanze, forniture tutto il resto.
I motivi sono chiari: concentrarsi al massimo nel proprio core-business, ridurre in modo sostanziale i costi fissi, aumentare al massimo la flessibilità dell’azienda e la sua capacità di resistere agli urti del mercato.
Pur capendo in pieno le fondamenta dell’impostazione, una vocina interiore mi lasciava sempre scettico e sono sempre stato portato ad organizzare l’azienda e il lavoro. Cerco di spiegarmi.
Come ogni metodologia, si presta ad applicazioni sbagliate o estremizzazioni. Per poter creare un’azienda “a rete” é necessario che nell’azienda stessa tutte le competenze del business che tratta esistano, ad ottimo livello e siano in grado di lavorare in maniera estremamente efficace. Diversamente l’azienda:
- non é in grado di avere uno stile proprio riconoscibile;
- fatica a garantire continuità del proprio operato;
- rischia di vedere moltiplicarsi i costi di gestione nell’utilizzare partner, fornitori, consulenti terzi o delocalizzati per inefficienze di gestione.
Esempio. L’azienda ACME mi commissiona una applicazione web, lavoro che totalmente o in parte non sono in grado di svolgere. Accetto comunque il lavoro e mi trovo il meglio degli sviluppatori disponibili sul mercato al miglior prezzo: un bello staff di indiani.
I problemi da risolvere a questo punto sono una marea:
- devo gestire le comunicazione con qualche fuso orario di differenza, il che significa che può benissimo capitare che il clienta mi faccia richieste a cui non so rispondere prima di qualche ora… al massimo posso mettere sul piatto un po’ di fuffa da commerciale;
- non sono uno sviluppatore web e mi trovo a dover interpretare (senza averne in parte o del tutto gli strumenti cognitivi) le esigenze del mio cliente in specifiche che il mio staff di indiani siano in grado di capire (e devo sapare l’inglese tanto bene che le specifiche non siano fraintedibili);
- devo capire cosa mi presentano i miei sviluppatori come avanzamento lavori e saperlo spiegare al cliente in modo che possa capirlo; dopodiché si torna al punto 2. fino a completamento della commessa;
- durante l’avanzamento lavori devo saper dare ordine alle varie priorità (desideri del cliente e necessità degli sviluppatori) in modo coerente e avendo ben chiaro l’obiettivo finale del progetto (il che vuol dire grosso modo avere in mente l’appicazione web e il suo funzionamento almeno per sommi capi).
Questo processo, qualsiasi project leader potrebbe testimoniarlo, é già normalmente difficile con uno staff proprio, competente e affiatato. Semplicemente perché “il mondo del cliente” e “il mondo degli sviluppatori” é molto spesso ad anni luce di distanza.
Se a questi problemi di base aggiungiamo
- competenze generaliste e/o superficiali del proprio business aziendale,
- uno staff di persone che non ho mai visto, non conosco e con le quali non é facile comunicare
ci s’imbatte in un aumento esponenziale dei rischi che
- i tempi di consegna dell’appicazione web si dilatino all’infinito,
- (per mantenere i tempi) il prodotto non corrisponda alle esigenze del cliente,
- il prodotto corrisponda alle esigenze del cliente e sia stato consegnato nei tempi, ma sia sviluppato a toppe e con troppi compromessi.
Conclusione: molto probabilmente a conclusione e consegna del progetto, se sono stato veramente bravissimo, il cliente sarà abbastanza contento.
Chiaro é che se non lo sono stato (o non sono stati all’altezza sviluppatori mai visti ne conosciuti, con i quali non ho esperienza lavorativa precedente e che quindi ho preso a praticamente a scatola chiusa), il cliente mi avrà tolto il lavoro (nella peggiore delle ipotesi) o mi avrà fatto concludere ma sicuramente non mi commissionerà null’altro.
Continuiamo con l’esempio, facendo finta che a seguito della consegna del progetto il cliente sia normalmente soddisfatto del lavoro.
A questo punto devo sperarare che non ci si debba mettere le mani in un secondo momento. E più passa il tempo, più i rischi che le richieste di estensione del progetto possano creare problemi. Perché? Bhe, molto banalmente perché più passa il tempo più é difficile che riesca a ricostituire lo staff di persone che hanno lavorato inizialmente sul progetto.
Il problema non é così semplice come sembra perché:
- il nuovo staff di sviluppo deve mettere mano su codice che non conosce, scritto da altri, con lo stile di altri;
- io, non essendo uno sviluppatore, non conosco nel dettaglio il funziomento dell’applicazione quindi non sono in grado di trasferire le competenze necessarie al nuovo staff;
- quasi certamente c’é un overhead di efficienza da parte del nuovo staff che prima di cominciare a lavorare dovrà formarsi e capire l’applicazione esistente (tempo in più che dovrà essere pagato);
- inoltre il nuovo staff dovrà calarsi nel cliente per poterlo capire (attraverso me), cosa che il precedente staff aveva già fatto e probabilmente commetterà alcuni errori prima di imboccare la strada giusta (errori già occorsi nella precendente fase di lavoro e che il cliente si aspetta non occorano più).
Tradotto in spicci:
- se l’estensioni richieste dal cliente sono sufficientemente marginali, il lavoro sarà fattibile ma a maggiori costi (per tutti);
- più le estensioni diventano vaste, più aumenta il rischio di dover riscrivere l’applicazione ex-novo, cosa normalmente inaccettabile dal cliente se non a livello di costi sicuramente a livello operativo (tempi di consegna e impatto su organizzativo su quanto realizzato in precedenza).
Più passa il tempo, più é facile che si manifesti il disastro o che semplicemente il cliente si stufi: un’azienda che opera in questo modo é difficilissimo che riesca a fidelizzare un cliente.
Il panorama che dipingo può sembrare troppo nero. In realtà é la sintesi di quanto ho visto capitare in oltre nove anni di esperienza sul campo… e sinceramente ho visto anche peggio.
Inoltre quest’approccio non é neache poco diffuso. Queste sono le modalità delle aziende che sono maggiormente orientate alla vendita o con una logica di fruttamento imprenditoriale spudorato del mercato in cui si posizionano.
Le aziende non orientate alla vendita che operano in questo modo sono destinate a chiudere velocemente: se non si riesce a costituire un portafogli cliente (che é un asset fondamentale di ogni azienda) stabile, bisogna costantemente andare a caccia di nuovi clienti. Il che significa ingenti investimenti nelle vendite, non nel core business della propria azienda.
Le aziende che operano “a rete” sono spesso vuote perché: in realtà non hanno internamente le competenze per sviluppare completamente il proprio core business; perché non riescono a creare valore (intelletuale, di portafoglio clienti, etc) per se stesse, se non forse (a breve/medio termine) valore economico.
Chiaramente esistono svariate sfumature di grigio tra un’azienda totalmente autosufficiente (ma con forti spese fisse costanti) e un’azienta toalmente a rete (pochissime spese fisse ma quasi nessuna competenza interna).
Anche in questo caso l’eccellenza sta nel mezzo. Un’azienda che voglia operare tramite una rete di competenze esterne, deve:
- avere uno staff di livello e stabile in grado di soddisfare quasi completamente il core business dell’azienda per capacità ma non per volume di lavoro (che chiaramente deve essere maggiore di quanto non assolvibile dallo staff stesso);
- utilizzare per adempiere al maggior volume di lavoro e/o per competenze contigue al proprio core business partner e fornitori il più possibile fedeli, costanti e ragionevolmente “vicini”;
- dare l’impronta alla realizzazione dei progetti e mantenerne il controllo.
Ma anche in questo caso ho il sospetto che i margini che si possono gestire sono labili.
In ogni caso il volume di lavoro in eccesso non può crescere all’infinito (per esempio, 10 persone non ne possono gestire progetti che ne coinvolgono 500), quindi l’azienda deve periodicamente crescere (allo stabilizzarsi dei volumi di lavoro e/o delle richieste di competenze) per evitare di implodere su se stessa e rientrare nella prima casistica… ovvero dell’azienda che non sa fare il proprio lavoro e delega a terzi lo svolgimento.