Ho lavorato per 20 mesi in un’azienda retail storica della mia zona. Non cito i dettagli così ne posso parlare liberamente. Il mio ruolo era quello di coordinatore logistico: in pratica organizzavo e riorganizzavo il workflow aziendale partendo dalle questioni logistiche ed espandendo lo scope ai processi aziendali più in generale. Il bello di lavorare in un’azienda a gestione familiare è questo: che ti interfacci con tutte – letteralmente tutte – le funzioni aziendali. Direzione, consulenti di direzione, ufficio acquisti, ufficio amministrativo, consulenti marketing, commerciale estero, agenti di vendita, commessi storici che in realtà sono dei veri e propri internal solutions engineers, consulenti IT, clienti B2B e B2C.
Cos’ho imparato da questa esperienza. Che gli obiettivi di rinnovamento non bastano, a partire da una decisione sintetica bisogna anche saper calare top-down l’innovazione di processo, ed escalare bottom-up le idee di chi effettivamente porta avanti il lavoro di ogni giorno. In realtà nemmeno la mia ultima frase è vera, l’innovazione di processo non si cala dall’alto, quello che si fa è iniziare un progetto di change management che integra esperienza e cambiamento. La progettazione di un cambiamento non va solo decisa da un team di persone coinvolte, va prima discussa (testata) tra l’intero pool aziendale. Uso volutamente la parola pool, per indicare l’insieme di tutte le figure aziendali, nessuna esclusa, senza il bisogno di segmentare o compartimentalizzare le funzioni nominali delle persone. Questo non significa essere una democrazia, significa accettare il fatto che i cambiamenti non sono mai localizzati e circoscritti come sembrano, le interazioni inter-processo ci sono sempre. Basta pensare che in una software house strutturata il debugging è fatto da operatori specializzati: i processi – e i problemi – non sono mai completamente localizzati. Le aziende sono sistemi di sistemi, interagiscono in modi che a volte non sono espliciti e soltanto in fase di testing e di debugging si palesano. Va allenata questa modalità di approccio al problema, è facile da intuire ma per nulla banale da applicare nella realtà.
Prossimo punto delicato. La resistenza alla necessaria pressione evolutiva. Per ristrutturare un processo serve autorità, non in senso caratteriale, non leadership, intendo proprio potere decisionale sulla carta. Non si riesce a evolvere sistematicamente se il tempo va sprecato a convincere il capo del capo del capo che sarebbe il caso di fare una modifica al segmento di workflow. L’inerzia è reale, l’allineamento degli stakeholder ha un costo, in termini di tempo, di fatica e di attrito. Come consulente posso trovare ed enumerare i punti critici di un sistema, ma mai inizierei a lavorarci se non avessi il temporaneo potere decisionale per farlo. Anche perché resta sempre vero il fatto che esistono le istanze di staging ed esistono gli A/B test, non necessariamente serve intaccare l’attuale production per innovare. Lo spiego con un concetto devops. Se il mio pool di nodi Kubernetes ha una versione legacy in production e una versione che esce dallo staging e arriva alla fase di testing, posso programmare un load balancer in modo che inoltri le richieste in maniera da testare il nuovo agent gradualmente senza intaccare troppo i SLA impliciti.
Le PMI, in particolare le microimprese, hanno un altissimo potenziale, e spesso moltissima esperienza reale che non va buttata ma va incanalata in una rete di piping che necessita di essere costantemente adattata alla situazione. E questo è essenzialmente il mio lavoro.