<\/a><\/noindex><\/p>\nSi era convinto di essere un genio e decise di trovare una nicchia nella sua azienda. Questa nicchia doveva essere speciale, non occupata da nessuno. E voleva che l'azienda stessa volesse pagare denaro a una persona in questa nicchia, senza dover ingannare nessuno o architettare qualcosa. Doveva essere oggettivo: una persona in questa posizione doveva guadagnare molto.<\/p>\n
Le ricerche non durarono a lungo. Nella societ\u00e0 in cui lavorava questo ragazzo, c'era una nicchia completamente libera, che si poteva definire \"organizzazione dei processi aziendali\". In ogni azienda ci sono tantissimi problemi. C'\u00e8 sempre qualcosa che non funziona e non c'\u00e8 nessuno che venga a sistemare i processi aziendali. Cos\u00ec, decise di mettersi alla prova come esperto in grado di aiutare il proprietario a risolvere i suoi problemi.<\/p>\n
Al momento lavorava in azienda da sei mesi e riceveva una retribuzione media sul mercato. Non aveva nulla da perdere, soprattutto perch\u00e9 avrebbe potuto trovare lo stesso lavoro in una settimana. In sintesi, questo ragazzo pens\u00f2 che non sarebbe successo nulla di terribile se per caso tutto fosse andato male e lo avessero licenziato.<\/p>\n
Si \u00e8 fatto coraggio ed \u00e8 andato dal proprietario. Gli ha proposto di migliorare il processo pi\u00f9 problematico che esisteva in azienda. A quel tempo si trattava della gestione del magazzino. Oggi chi lavora in questa azienda prova persino imbarazzo a ricordare quei problemi, ma le inventarizzazioni trimestrali mostrano discrepanze tra il sistema contabile e le giacenze reali di decine di punti percentuali. Sia in valore che in quantit\u00e0, e in numero di posizioni. Era un disastro. L'azienda aveva correttamente le giacenze nel sistema contabile solo quattro volte all'anno \u2013 il giorno dopo l'inventario. Questo processo \u00e8 quello che il nostro ragazzo ha iniziato a sistemare.<\/p>\n
Il ragazzo ha concordato con il proprietario di ridurre le discrepanze nei risultati degli inventari della met\u00e0. Inoltre, il proprietario non aveva molto da perdere, perch\u00e9 prima del nostro eroe avevano gi\u00e0 tentato di sistemare le cose diversi dipendenti, e in generale il compito era considerato quasi impossibile. Tutto ci\u00f2 ha acceso molto interesse, perch\u00e9 se tutto fosse andato a buon fine, il tizio sarebbe automaticamente diventato una persona capace di mettere ordine e risolvere compiti irrisolvibili.<\/p>\n
Cos\u00ec, si trov\u00f2 di fronte all'obiettivo: ridurre nel corso dell'anno le discrepanze nei risultati degli inventari di 2 volte. All'inizio del progetto non sapeva come ottenere questo, ma capiva che la gestione del magazzino \u00e8 una cosa semplice, quindi in qualche modo sarebbe riuscito a fare qualcosa di utile. Tanto pi\u00f9 che ridurre le discrepanze da decine di punti percentuali a una decina di punti percentuali non dovrebbe essere cos\u00ec difficile. Tutti coloro che lavorano nel campo della consulenza o attivit\u00e0 simili sanno che la maggior parte dei problemi di processo pu\u00f2 essere risolta con azioni piuttosto semplici.<\/p>\n
Da gennaio a maggio si \u00e8 preparato, ha automatizzato un po' di cose, ha riscritto il processo di contabilit\u00e0 di magazzino, ha cambiato i flussi di lavoro di magazzinieri, contabili e ha completamente ristrutturato il sistema, senza mostrare e raccontare nulla a nessuno. A maggio ha distribuito a tutti nuove istruzioni e dopo il primo inventario dell'anno \u00e8 iniziata una nuova vita \u2013 lavoro secondo le sue regole. Per vedere i risultati, in seguito l'azienda ha iniziato a effettuare inventari pi\u00f9 frequentemente \u2013 ogni due mesi. I primi risultati sono stati positivi e entro la fine dell'anno le deviazioni dei risultati dell'inventario sono scese a frazioni di un percento.<\/p>\n
Il successo \u00e8 stato colossale, ma non si credeva nella sua stabilit\u00e0. Lo stesso ragazzo dubitava che il risultato sarebbe rimasto tale se si fosse allontanato e avesse smesso di osservare il processo. Tuttavia, il risultato c'era e il ragazzo ha ottenuto tutto ci\u00f2 su cui si era accordato con il proprietario. Poi, dopo alcuni anni, la stabilit\u00e0 del risultato \u00e8 stata confermata: per diversi anni le deviazioni sono rimaste entro l'1%.<\/p>\n
Allora ha deciso di ripetere l'esperimento e ha proposto al proprietario di perfezionare un altro processo problematico \u2013 l'approvvigionamento. C'erano carenze che non permettevano di spedire i volumi che i nostri clienti volevano. Si sono accordati che entro un anno le carenze si sarebbero ridotte della met\u00e0 e che il ragazzo avrebbe anche portato a termine 10-15 progetti legati a 1C, ovvero all'automazione di vari processi aziendali e altre sciocchezze.<\/p>\n
Nel secondo anno il tutto \u00e8 stato nuovamente portato a termine con successo, le carenze sono calate di pi\u00f9 di 2 volte e tutti i progetti IT sono stati conclusi con successo.<\/p>\n
Poich\u00e9 lo stipendio soddisfaceva gi\u00e0 pienamente tutte le richieste di quel ragazzo, per i prossimi due anni, ha deciso di stabilizzarsi un po', calmarsi e godersi un posto accogliente e caldo che aveva creato lui stesso.<\/p>\n
Cosa rappresentava? Formalmente, era il direttore IT. Ma capire chi fosse realmente \u00e8 complicato. Infondo, di cosa si occupa un direttore IT? Di solito amministra l'infrastruttura IT, gestisce gli amministratori di sistema, implementa il sistema ERP e partecipa alle riunioni del consiglio di amministrazione.<\/p>\n
E questo tizio aveva come una delle sue principali responsabilit\u00e0 la partecipazione ai processi di cambiamento, e principalmente \u2014 la generazione e l'avvio di questi processi, la ricerca e proposta di soluzioni, l'applicazione di nuove metodologie di gestione, la valutazione delle modifiche proposta, l'analisi dell'efficacia di altre funzioni e divisioni, e infine \u2014 la partecipazione diretta allo sviluppo strategico dell'azienda, fino alla stesura autonoma del piano strategico dell'intera compagnia.<\/p>\n
Gli \u00e8 stato dato carta bianca. Poteva partecipare a qualsiasi riunione a cui prima non aveva accesso. Si sedeva l\u00ec con un taccuino, scriveva qualcosa o semplicemente ascoltava. Parlava raramente. Poi ha cominciato a giocare col telefono \u2014 sosteneva che cos\u00ec la memoria associativa funzionava meglio.<\/p>\n
In riunione raramente dava qualcosa di utile. Usciva, rifletteva, poi riceveva una lettera \u2014 o con critiche, o con opinioni, o con proposte, o con la descrizione di soluzioni che aveva gi\u00e0 applicato.<\/p>\n
Ma pi\u00f9 spesso organizzava lui stesso le riunioni. Trovava un problema, pensava a opzioni di soluzione, identificava le parti interessate e portava tutti in sala riunioni. E l\u00ec \u2014 come sapeva fare. Convinceva, motivava, dimostrava, litigava, otteneva. <\/p>\n
Ufficialmente era considerato la terza persona in azienda, dopo il proprietario e il direttore. Naturalmente, era estremamente fastidioso per tutti i \"volti dell'azienda\", a partire dal numero 4. Soprattutto per i suoi jeans strappati e le t-shirt colorate, e ancora \u2014 per il tempo del proprietario.<\/p>\n
Il proprietario gli dedicava 1 ora al giorno. Ogni giorno. Parlavano, discutevano di problemi, soluzioni, nuovi affari, direzioni di sviluppo, indicatori ed efficienza, sviluppo personale, libri, e semplicemente \u2014 della vita.<\/p>\n
Ma questo ragazzo era strano. Sembrerebbe \u2014 siedi e goditi, la vita \u00e8 andata bene. Ma no. Ha deciso di riflettere.<\/p>\n
Gli \u00e8 venuto in mente: perch\u00e9 a lui \u00e8 riuscito, mentre agli altri no? Anche il proprietario lo spronava: diceva che voleva che anche gli altri riuscissero a mettere ordine, perch\u00e9 ci sono molti manager, che di solito si occupano della gestione operativa e della pianificazione strategica, ma praticamente nessuno si occupa di cambiamenti sistematici nei propri processi. Nella loro descrizione del lavoro, pu\u00f2 darsi che sia scritto che devono accelerare il proprio processo, aumentarne l'efficacia, ma di fatto nessuno se ne occupa. Perch\u00e9? Anche a quel ragazzo \u00e8 venuta curiosit\u00e0, e ha deciso di parlare con tutti quei manager.<\/p>\n
\u00c8 andato dal vice direttore per la qualit\u00e0 e ha proposto di implementare i diagrammi di controllo di Shewhart, affinch\u00e9 i prodotti fossero migliori di quelli giapponesi. Ma si \u00e8 rivelato che il collega non sapeva cosa fossero i diagrammi di controllo di Shewhart, cosa fosse la gestione statistica dei processi, e aveva sentito solo di sfuggita parlare dell'applicazione del ciclo di Deming nella gestione della qualit\u00e0. Va bene...<\/p>\n
\u00c8 andato da un altro vice direttore e ha proposto di introdurre il controllo. Ma anche qui non ha trovato supporto. Poco dopo ha appreso della gestione delle frontiere (boundary management) e ha proposto a tutti i vice direttori di implementare la parte sistematica di questa metodica per migliorare i processi. Ma per quanto ci ha parlato, nessuno sembrava interessato a capire di cosa si trattasse. Forse non era interessante per loro o troppo complicato. In effetti, nessuno ha compreso.<\/p>\n
In sintesi, ha raccontato tutto ci\u00f2 che sapeva e applicava in azienda. Ma nessuno lo ha compreso davvero. E fino ad ora non capiscono perch\u00e9, ad esempio, sia stato possibile correggere la contabilit\u00e0 di magazzino, cosa c\u2019entri il controllo e la gestione delle frontiere.<\/p>\n
Alla fine, \u00e8 arrivato ai suoi programmatori \u2013 il team era composto da 3 persone. Ha parlato di gestione delle frontiere, del controllo, della gestione della qualit\u00e0, di agile e scrum\u2026 E con sorpresa, hanno capito tutto e hanno persino potuto discutere con lui, comprese le complessit\u00e0 tecniche e metodologiche. Hanno capito perch\u00e9 i progetti di magazzino e di approvvigionamento erano riusciti. E l\u00ec il ragazzo ha avuto un\u2019illuminazione: in realt\u00e0, il mondo sar\u00e0 salvato dai programmatori.<\/p>\n
Ha capito che i programmatori sono gli unici in grado di comprendere a fondo e con i dettagli necessari i processi aziendali.<\/p>\n
Perch\u00e9 proprio loro? In realt\u00e0, non ha mai trovato una risposta definitiva. Ha solo formulato alcune allusioni tese.<\/p>\n
In primo luogo, i programmatori conoscono le aree tematiche del business, e per di pi\u00f9, le conoscono meglio di chiunque altro nella compagnia.<\/p>\n
Inoltre, i programmatori capiscono realmente cosa sia un algoritmo di processo. Questo \u00e8 importante perch\u00e9 i processi aziendali sono algoritmi, e gli elementi al loro interno possono essere semplicemente non allineati. Ad esempio, nel processo di approvvigionamento su cui lavorava il ragazzo, il primo passo \u00e8 la redazione del piano annuale degli acquisti, mentre il secondo \u00e8 l'acquisto quotidiano. Questi passaggi sono collegati da un legame diretto, quindi si presume che secondo questo algoritmo le persone debbano lavorare: redigere il piano annuale degli acquisti e immediatamente eseguire l'ordine. Il piano annuale degli acquisti viene redatto una volta all'anno, mentre l'ordine pu\u00f2 arrivare fino a 50 volte al giorno. Qui finisce l'algoritmo e bisogna lavorare su di esso. In effetti, ha ragionato, per i programmatori conoscere gli algoritmi \u00e8 un vantaggio competitivo, poich\u00e9 chiunque altro che non li conosce semplicemente non comprende come dovrebbe funzionare il processo aziendale e come possa essere rappresentato.<\/p>\n
Un altro vantaggio dei programmatori, secondo il ragazzo, \u00e8 che hanno abbastanza tempo libero. Tutti comprendiamo come un programmatore possa impiegare tre volte il tempo necessario su un compito, e poche persone se ne accorgeranno. Questo, ancora una volta, \u00e8 un vantaggio competitivo, perch\u00e9 per mettere in ordine un processo aziendale \u00e8 necessario avere molto tempo libero: pensare, osservare, studiare e provare.<\/p>\n
La maggior parte dei manager, secondo il ragazzo, non ha questo tempo libero e ne \u00e8 fiera. Anche se in realt\u00e0 significa che una persona non pu\u00f2 diventare efficiente, perch\u00e9 non ha tempo per migliorare la propria efficienza: un circolo vizioso. Nella nostra cultura \u00e8 di moda essere occupati, quindi tutto rimane immobile. E per noi, programmatori, questo \u00e8 un vantaggio. Possiamo trovare tempo libero e riflettere su tutto.<\/p>\n
I programmatori, raccontava, possono cambiare rapidamente un sistema informativo. Non \u00e8 applicabile a tutte le aziende, ma ovunque abbia lavorato, era possibile apportare qualsiasi modifica si desiderasse. Soprattutto se non riguardava il lavoro di nessun altro. Ad esempio, poteva avviare un sistema che misura segretamente le azioni degli utenti e poi utilizzare queste informazioni per analizzare l'efficacia del lavoro della contabilit\u00e0 e monitorare i costi di gestione della contabilit\u00e0.<\/p>\n
E infine, ci\u00f2 che ho ricordato dalle sue parole \u00e8 che i programmatori hanno accesso a un'enorme quantit\u00e0 di informazioni, poich\u00e9 hanno accesso amministrativo al sistema. Pertanto possono utilizzare queste informazioni nella loro analisi. Nessun altro in una normale fabbrica ha accesso a tale risorsa.<\/p>\n
E poi se ne and\u00f2. Durante il periodo di preavviso di due settimane, lo abbiamo costretto a condividere la sua esperienza, perch\u00e9 volevamo continuare il lavoro che svolgeva. E la sua posizione stava diventando vacante.<\/p>\n
Per alcuni giorni lo abbiamo fatto sedere su una sedia, accendevamo la telecamera e registravamo i suoi monologhi. Gli chiedevamo di parlare di tutti i progetti completati, dei metodi, degli approcci, dei successi e dei fallimenti, delle cause e degli effetti, dei profili dei dirigenti, ecc. Non lo limitavamo troppo, poich\u00e9 non sapevamo cosa avesse in mente. <\/p>\n
Nei monologhi, c'era ovviamente soprattutto spazzatura e risate \u2014 era di ottimo umore, poich\u00e9 stava lasciando un paesino per San Pietroburgo. E dove andare a lavorare a San Pietroburgo? In Gazprom, ovviamente.<\/p>\n
Ma ci sono state alcune informazioni utili che siamo riusciti a estrarre dai suoi monologhi. Vi racconter\u00f2 ci\u00f2 che ricordo.<\/p>\n
Quindi, i consigli di quel ragazzo. A chi vorr\u00e0 provare a sistemare le cose nei processi aziendali.<\/p>\n
Per fare un lavoro del genere, prima di tutto, \u00e8 necessario avere un certo livello di 'indifferenza'. Non bisogna avere paura di perdere il lavoro, non aver paura di rischiare, non aver paura dei conflitti con i colleghi. Lui ci riusciva facilmente, perch\u00e9 ha iniziato il suo percorso dopo aver lavorato in azienda solo sei mesi e non ha avuto il tempo di entrare in contatto con nessuno, n\u00e9 intendeva farlo. Comprendeva che le persone vengono e vanno, e per lui erano importanti i propri risultati e la loro valutazione da parte del proprietario dell'azienda. Se i colleghi lo trattavano bene o male, a lui importava poco in quel momento.<\/p>\n
Il secondo punto \u00e8 che, per svolgere efficacemente questo lavoro, purtroppo, bisogna imparare. Ma non imparare attraverso un MBA, corsi o istituti, bens\u00ec in modo autonomo. Ad esempio, nel suo primo progetto sul magazzino, ha agito istintivamente, non sapeva nulla, solo che cosa fosse la \"gestione della qualit\u00e0\".<\/p>\n
Quando ha iniziato a leggere la letteratura riguardo ai metodi di aumento dell'efficienza, ha scoperto le tecnologie che applicava. Il ragazzo le applicava in modo istintivo, ma si \u00e8 reso conto che non erano una sua invenzione, era tutto gi\u00e0 stato scritto da tempo. Tuttavia, ha perso tempo, molto di pi\u00f9 rispetto a se avesse letto subito il libro giusto. Qui \u00e8 importante capire che quando si studia una metodologia specifica, nessuna di esse, nemmeno la pi\u00f9 avanzata, risolver\u00e0 completamente tutti i problemi del processo aziendale.<\/p>\n
Il secondo punto \u00e8 che pi\u00f9 metodologie si conoscono, meglio \u00e8. Ad esempio, nell'antico Giappone viveva Miyamoto Musashi, uno dei pi\u00f9 noti schermidori, autore dello stile delle due spade. Ha studiato in qualche scuola con un maestro, poi ha viaggiato per il Giappone, combattendo contro vari avversari. Se un avversario era pi\u00f9 forte, il viaggio si interrompeva per un po' e Musashi diventava allievo. Cos\u00ec, in pochi anni, acquisiva competenze in varie pratiche di diversi maestri e formava la propria scuola, aggiungendo qualcosa di suo. Alla fine, ha raggiunto una maestria unica. Qui \u00e8 lo stesso.<\/p>\n
Certo, si pu\u00f2 agire come consulenti aziendali. In generale, sono ottimi ragazzi. Ma, di solito, arrivano per implementare qualche metodologia, e non quella necessaria per l'azienda. Anche noi abbiamo avuto situazioni tristi: nessuno sa come risolvere il problema e nessuno vuole pensare a come farlo. Iniziamo a cercare in internet oppure chiamiamo un consulente, e gli chiediamo cosa possa aiutarci. Il consulente riflette e dice che bisogna implementare la teoria dei vincoli. Gli paghiamo per la raccomandazione, spendiamo per l'implementazione, ma il risultato \u00e8 zero.<\/p>\n
Perch\u00e9 succede cos\u00ec? Perch\u00e9 il consulente ha detto di implementare un certo sistema, e tutti hanno acconsentito. Benissimo, ma una metodologia non risolve tutti i problemi nemmeno di un singolo processo aziendale, specialmente se non coincidono le condizioni di partenza \u2014 le nostre e quelle richieste per l'implementazione della metodologia.<\/p>\n
Nella pratica che il ragazzo consiglia, bisogna prendere il meglio e implementare il meglio. Non prendere i metodi nella loro interezza, ma cogliere le loro caratteristiche chiave, peculiarit\u00e0 e pratiche. E la cosa pi\u00f9 importante \u00e8 capire l'essenza.<\/p>\n
Prendiamo, diceva lui, ad esempio Scrum o Agile. Nelle sue dissertazioni, il ragazzo ha ripetuto molte volte che non tutti comprendono appieno l'essenza di Scrum. Anche lui ha letto il libro di Jeff Sutherland, che ad alcuni sembra una 'lettura leggera'. A lui \u00e8 sembrato una lettura profonda, perch\u00e9 uno dei principi fondamentali di Scrum \u00e8 la gestione della qualit\u00e0, di cui si parla esplicitamente nel libro.<\/p>\n
L\u00ec si parla della Toyota Production, di come Jeff Sutherland ha presentato Scrum in Giappone, di quanto si sia radicato l\u00ec e di quanto fosse vicino alla loro filosofia. E Sutherland ha parlato dell'importanza del ruolo del Scrum Master, del ciclo di Deming. Il ruolo dello Scrum Master \u00e8 quello di accelerare costantemente il processo. Tutto il resto che c'\u00e8 in Scrum \u2014 consegne per fasi, soddisfazione del cliente, un elenco chiaro delle attivit\u00e0 per il periodo dello sprint \u2014 \u00e8 importante, ma tutto deve procedere sempre pi\u00f9 velocemente. La velocit\u00e0 del lavoro deve aumentare continuamente nelle unit\u00e0 in cui viene misurata.<\/p>\n
Forse, qui il problema \u00e8 nella traduzione, perch\u00e9 da noi il libro \u00e8 stato tradotto come 'Scrum - un metodo rivoluzionario di gestione dei progetti', ma se traduciamo letteralmente il titolo inglese, diventa: 'Scrum - il doppio in met\u00e0 tempo', quindi anche nel titolo c'\u00e8 un riferimento alla velocit\u00e0, come funzione chiave di Scrum.<\/p>\n
Quando questo ragazzo ha implementato Scrum, nella prima settimana la velocit\u00e0 \u00e8 raddoppiata senza particolari cambiamenti. Ha trovato punti per modificare, ha adattato Scrum a s\u00e9 stesso, in modo che funzionasse molto pi\u00f9 velocemente. L'unica cosa, come si legge su Internet, \u00e8 che si sono trovati di fronte alla questione: 'Abbiamo raddoppiato la velocit\u00e0, rimane da capire cosa fare con tale velocit\u00e0?'. Tuttavia, questa \u00e8 un'altra area completamente diversa...<\/p>\n
Inoltre, ha personalmente consigliato diverse metodologie. Le ha definite fondamentali e fondamentali.<\/p>\n
La prima \u00e8 il boundary management.<\/p>\n
Viene insegnato a \"Skolkovo\", altre pubblicazioni e materiali, secondo quanto afferma il ragazzo, non ci sono. \u00c8 riuscito a partecipare a una lezione di un professore di Harvard, che predica il boundary management, e ha anche letto alcuni articoli del Harvard Business Review sui lavori di Eric Trist. <\/p>\n
Il boundary management tratta di come saper vedere e lavorare con i confini. I confini sono ovunque: tra dipartimenti, tra diversi tipi di lavoro, tra funzioni, tra lavoro operativo e analitico. La conoscenza del boundary management non rivela verit\u00e0 pi\u00f9 elevate, ma permette di vedere la realt\u00e0 sotto una luce diversa, attraverso la lente dei confini. E, di conseguenza, di gestirli: stabilendoli dove necessario e rimuovendoli dove ostacolano.<\/p>\n
Ma pi\u00f9 spesso il ragazzo ha parlato di controlling. Aveva davvero una fissa per questo argomento.<\/p>\n
Il controlling, in breve, \u00e8 la gestione basata sui numeri. Qui, ha detto, \u00e8 importante ogni parte della definizione: sia \"gestione\", sia \"basata su\", sia \"numeri\".<\/p>\n
Da noi, ha affermato, siamo messi male con tutti e tre gli elementi del controlling. Specialmente considerando che sono strettamente interconnessi tra di loro e con altre parti del sistema aziendale.<\/p>\n
La prima cosa che non va sono i numeri. Ce ne sono pochi e sono di bassa qualit\u00e0.<\/p>\n
Una parte significativa dei numeri la traevamo allora dal sistema informativo 1C. Ebbene, la qualit\u00e0 dei numeri in 1C, come sosteneva, \u00e8 inaccettabile. Almeno per via della possibilit\u00e0 di modificare i dati retroattivamente.<\/p>\n
\u00c8 chiaro che non \u00e8 colpa degli sviluppatori di 1C, che tengono conto solo delle esigenze del mercato e della mentalit\u00e0 della contabilit\u00e0 domestica. Ma per gli scopi del controlling, i principi di lavoro di 1C con i dati dovrebbero essere modificati, a livello dell'impresa specifica.<\/p>\n
In seguito, i numeri provenienti da 1C, secondo le sue parole, subiscono un'elaborazione semiautomatica, utilizzando Excel, ad esempio. Tale lavorazione non aggiunge qualit\u00e0 ai dati, n\u00e9 tempestivit\u00e0.<\/p>\n
Alla fine, un qualche responsabile rivede il report finale, per evitare di inviare al dirigente numeri errati. Di conseguenza, i numeri arrivano al destinatario in modo bello, controllato, ma molto in ritardo. Di solito \u2014 dopo la fine del periodo (mese, settimana, ecc.).<\/p>\n
E qui, diceva, tutto \u00e8 molto semplice. Se i numeri di gennaio ti arrivano a febbraio, allora non puoi pi\u00f9 gestire le attivit\u00e0 di gennaio. Perch\u00e9 gennaio \u00e8 gi\u00e0 finito.<\/p>\n
E se i numeri si basano sulla contabilit\u00e0 e l'azienda \u00e8 una comune, con dichiarazioni IVA trimestrali, allora il suo dirigente riceve numeri relativamente adeguati una volta al trimestre.<\/p>\n
Dopo \u00e8 chiaro. Ricevete i numeri una volta al mese: avete la possibilit\u00e0 di gestire in base ai numeri (cio\u00e8 mettere in atto il controllo) 12 volte all'anno. Praticate la rendicontazione trimestrale: gestite 4 volte all'anno. Inoltre, un bonus: rendicontazione annuale. Possibilit\u00e0 di gestire ancora una volta.<\/p>\n
Nel resto del tempo, la gestione, di norma, avviene alla cieca.<\/p>\n
Quando (e se) i numeri finalmente compaiono, scatta il secondo problema: come gestire in base ai numeri? Su questo punto delle sue riflessioni non sono riuscito a concordare.<\/p>\n
Il ragazzo sosteneva che se prima il dirigente non aveva numeri, la loro apparizione provocher\u00e0 un effetto wow. Guarder\u00e0 e girer\u00e0 i numeri in tutti i modi, chiamer\u00e0 le persone e chieder\u00e0 spiegazioni e indagini. Giocando con i numeri, facendo delle analisi e promettendo minacciosamente a tutti i dipendenti che 'adesso non vi lascer\u00f2 in pace', il dirigente si calmer\u00e0 rapidamente e lascer\u00e0 perdere. Non utilizzer\u00e0 pi\u00f9 lo strumento. E i problemi rimarranno.<\/p>\n
Questo accade, diceva, a causa della mancanza di competenze del dirigente. Soprattutto nel controllo. Il dirigente semplicemente non sa cosa fare con questi numeri. Cosa con<\/b>fare - sa, cosa fare - no. Fare - \u00e8 ci\u00f2 di cui si \u00e8 scritto sopra (litigare, giocare). Fare - \u00e8 un processo aziendale quotidiano.<\/p>\n
Sosteneva che tutto era molto semplice: il numero deve diventare parte del processo aziendale. Nel processo aziendale deve essere chiaro: chi, cosa e quando deve fare in caso di deviazione del numero dalla norma (qualsiasi variante - sopra i confini, sotto i confini, uscita dal corridoio, presenza di tendenze, mancato rispetto del quantile, ecc.)<\/p>\n
Ecco che ha delineato il dilemma cruciale: il numero c'\u00e8, deve diventare parte del sistema aziendale per migliorare l'efficacia della gestione, ma... questo non accade. Perch\u00e9?<\/p>\n
Perch\u00e9 il dirigente russo non ceder\u00e0 un pezzo del suo potere al concorrente.<\/p>\n
I concorrenti del dirigente russo - un processo aziendale di qualit\u00e0 e funzionante, una motivazione reciproca ben ponderata e una corretta automazione - purtroppo, lasceranno il dirigente senza lavoro.<\/p>\n
Qualcosa di assurdo, ammettetelo? Soprattutto riguardo ai leader. Va bene, vi ho raccontato, decidete voi.<\/p>\n
Un po' meno, ma comunque troppo secondo me, ha parlato di Scrum.<\/p>\n
Assolutamente, ha detto di leggere e provare Scrum nella pratica. Se, dice, avete letto ma non provato, considerate di non sapere. \u00c8 meglio leggere un libro, ad esempio di Sutherland, piuttosto che articoli e vari guide (che stronzate?) su Internet.<\/p>\n
Scrum, ha detto, si comprende solo attraverso la pratica, e con misurazioni obbligatorie del volume di lavoro svolto. Provate personalmente i due ruoli pi\u00f9 importanti: il Product Owner e il Scrum Master.<\/p>\n
\u00c8 particolarmente importante, secondo il ragazzo, vivere nella pratica il ruolo di Scrum Master, quando sarete in grado di aumentare il numero di task completati in uno sprint, senza aumentare risorse e costi dello sprint.<\/p>\n
E in cima alla sua lista c'era il TOC (Teoria dei Vincoli).<\/p>\n
Questi, secondo il ragazzo, sono principi fondamentali per aumentare l'efficienza, applicabili praticamente in qualsiasi area, in qualsiasi processo aziendale e sistema aziendale nel suo complesso.<\/p>\n
Quando ha scoperto che non conoscevamo il TOC, ha smesso di raccontare. Ha solo aggiunto che non ci avrebbe privati del piacere di leggere i libri di Eliyahu Goldratt. Ha dato una raccomandazione simile a quella di Scrum: leggete e provate. Tipo, a qualunque posizione vi troviate, qualunque lavoro svolgiate, troverete spazio per migliorare l'efficienza con i metodi del TOC.<\/p>\n
Poi, sembra che il suo bagaglio di metodologie sia esaurito, e ha detto: mescolate i principi per creare soluzioni pratiche in situazioni specifiche.<\/p>\n
Questa, dice, \u00e8 la raccomandazione principale, la chiave del successo. Comprendete i principi, l'essenza, e create soluzioni applicative uniche: processi aziendali e sistemi aziendali.<\/p>\n
Poi si sforzava di ricordare una citazione, alla fine ha dovuto cercare su Internet. Si \u00e8 scoperto che la citazione era tratta dall'articolo \"Standing on the Shoulders of Giants\" di Eliyahu Goldratt:<\/p>\n
\u00abC'\u00e8 una differenza tra soluzioni applicative (applicazioni) e concetti fondamentali su cui si basano queste soluzioni. I concetti sono generali, le soluzioni applicative sono un'adattamento dei concetti a un ambiente specifico. Come abbiamo gi\u00e0 visto, tale adattamento non \u00e8 semplice e rende necessaria la sviluppazione di determinati elementi della soluzione. Dobbiamo ricordare che una soluzione applicativa \u00e8 basata su ipotesi di partenza (a volte nascoste) relative a un ambiente specifico. Non dobbiamo aspettarci che questa soluzione applicativa funzioni in un ambiente per il quale le ipotesi di partenza non sono valide\u00bb.<\/p>\n
Ha detto che il lavoro di un programmatore e quello di un \u00abmiglioratore di processi aziendali\u00bb sono molto simili. E se ne \u00e8 andato.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0418\u0441\u0442\u043e\u0440\u0438\u044f \u0440\u0435\u0430\u043b\u044c\u043d\u0430\u044f, \u044f \u0432\u0441\u0435 \u0432\u0438\u0434\u0435\u043b \u0441\u0432\u043e\u0438\u043c\u0438 \u0433\u043b\u0430\u0437\u0430\u043c\u0438. \u041d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u043e\u0434\u0438\u043d \u043f\u0430\u0440\u0435\u043d\u044c, \u043a\u0430\u043a \u0438 \u043c\u043d\u043e\u0433\u0438\u0435 \u0438\u0437 \u0432\u0430\u0441, \u0440\u0430\u0431\u043e\u0442\u0430\u043b \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u043c. \u041d\u0430 \u0432\u0441\u044f\u043a\u0438\u0439 \u0441\u043b\u0443\u0447\u0430\u0439 \u043d\u0430\u043f\u0438\u0448\u0443 \u0442\u0430\u043a: \u00ab\u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u043c\u00bb. \u041f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043e\u043d \u0431\u044b\u043b 1\u0421\u043d\u0438\u043a\u043e\u043c, \u043d\u0430 \u0444\u0438\u043a\u0441\u0435, \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438. \u0414\u043e \u044d\u0442\u043e\u0433\u043e \u043e\u043d \u043f\u0440\u043e\u0431\u043e\u0432\u0430\u043b \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u2013 4 \u0433\u043e\u0434\u0430 \u0432\u043e \u0444\u0440\u0430\u043d\u0447\u0435 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u043c, \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0443\u043c\u0435\u043b \u0437\u0430\u043a\u0440\u044b\u0432\u0430\u0442\u044c \u043f\u043e 200 \u0447\u0430\u0441\u043e\u0432, \u043e\u0434\u043d\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e \u043f\u043e\u043b\u0443\u0447\u0430\u044f \u043f\u0440\u043e\u0446\u0435\u043d\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-54335","post","type-post","status-publish","format-standard","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t