I team operativi devono migliorare costantemente i processi di shop floor, mentre l’IT è responsabile della sicurezza e dell’integrazione. Una chiara ripartizione delle responsabilità tra governance IT e progettazione dei processi operativi può risolvere questa apparente tensione.
Le riunioni di Shop Floor come punto di partenza per il miglioramento continuo
In molte aziende industriali occorre conciliare due esigenze legittime: i team operativi vogliono adattare rapidamente i processi e migliorarli in modo continuo. Al tempo stesso, l’IT centrale è responsabile della sicurezza delle informazioni, dell’integrazione dei sistemi e della coerenza dell’architettura IT.
A questo si aggiunge spesso un problema di disponibilità delle risorse. Le migrazioni ERP, la sicurezza IT, le infrastrutture, l’integrazione dei sistemi e altre iniziative strategiche assorbono risorse IT considerevoli. Le richieste provenienti dalla produzione, dal lean management o dalle attività di miglioramento continuo competono per le stesse risorse e finiscono spesso in fondo a lunghe liste di priorità.
La causa, nella maggior parte dei casi, non è la scarsa disponibilità a collaborare, ma la diversità di responsabilità, priorità e ritmi di cambiamento.
A questo si aggiunge spesso un problema di disponibilità delle risorse. Le migrazioni ERP, la sicurezza IT, le infrastrutture, l’integrazione dei sistemi e altre iniziative strategiche assorbono risorse IT considerevoli. Le richieste provenienti dalla produzione, dal lean management o dalle attività di miglioramento continuo competono per le stesse risorse e finiscono spesso in fondo a lunghe liste di priorità.
La causa, nella maggior parte dei casi, non è la scarsa disponibilità a collaborare, ma la diversità di responsabilità, priorità e ritmi di cambiamento.
Quando il miglioramento continuo incontra le priorità IT
I processi di shop floor evolvono costantemente. Si aggiungono nuovi indicatori, si adattano le modalità di svolgimento delle riunioni, si perfezionano i percorsi di escalation e si introducono nuovi flussi di miglioramento continuo. È proprio su questi cambiamenti che si basa il miglioramento continuo.
Quando, però, questi adeguamenti devono seguire il tradizionale iter delle richieste IT, può crearsi un collo di bottiglia strutturale. Le modifiche devono essere definite nel dettaglio, ordinate per priorità e implementate tecnicamente. Per i team operativi questo significa tempi di attesa. Per l’IT, una moltitudine di piccole richieste operative comporta un ulteriore carico di lavoro.
Nella pratica, i team operativi ricorrono quindi spesso ad alternative pragmatiche. File Excel, elenchi locali o altri strumenti digitali consentono di agire rapidamente nell’immediato, ma nel lungo periodo generano nuovi problemi: le informazioni si disperdono tra strumenti diversi, si creano discontinuità nel flusso informativo e processi analoghi vengono gestiti in modo diverso nei vari reparti. Il coordinamento centrale e la standardizzazione diventano così sempre più difficili.
Il vero problema risiede quindi meno nella diversità delle esigenze che nell’attuale ripartizione delle responsabilità: finché anche piccoli adeguamenti dei processi dipendono dalle risorse IT, l’evoluzione digitale dei processi operativi rimane frenata dalla capacità disponibile e dalle priorità dell’IT.
Quando, però, questi adeguamenti devono seguire il tradizionale iter delle richieste IT, può crearsi un collo di bottiglia strutturale. Le modifiche devono essere definite nel dettaglio, ordinate per priorità e implementate tecnicamente. Per i team operativi questo significa tempi di attesa. Per l’IT, una moltitudine di piccole richieste operative comporta un ulteriore carico di lavoro.
Nella pratica, i team operativi ricorrono quindi spesso ad alternative pragmatiche. File Excel, elenchi locali o altri strumenti digitali consentono di agire rapidamente nell’immediato, ma nel lungo periodo generano nuovi problemi: le informazioni si disperdono tra strumenti diversi, si creano discontinuità nel flusso informativo e processi analoghi vengono gestiti in modo diverso nei vari reparti. Il coordinamento centrale e la standardizzazione diventano così sempre più difficili.
Il vero problema risiede quindi meno nella diversità delle esigenze che nell’attuale ripartizione delle responsabilità: finché anche piccoli adeguamenti dei processi dipendono dalle risorse IT, l’evoluzione digitale dei processi operativi rimane frenata dalla capacità disponibile e dalle priorità dell’IT.
Conciliare governance IT e autonomia nella progettazione dei processi operativi
Un possibile approccio consiste nel separare le responsabilità relative all’integrazione tecnica da quelle legate alla progettazione dei processi operativi.
L’IT è responsabile della base tecnologica. Queste comprendono, ad esempio, l’integrazione dei sistemi, l’accesso ai dati, le autorizzazioni, la sicurezza delle informazioni e le linee guida generali per l’architettura IT.
Nel rispetto di queste regole, gli esperti selezionati dei team operativi possono far evolvere autonomamente le proprie applicazioni operative. Le tecnologie no-code consentono, ad esempio, di adattare shop floor board, visualizzazioni degli indicatori, workflow, riunioni di shop floor e processi di miglioramento continuo, senza avviare un nuovo progetto software per ogni modifica.
Il punto fondamentale è questo: no-code non significa aggirare l’IT, ma consentire ai team operativi di apportare modifiche nel rispetto di regole e limiti tecnici e organizzativi chiaramente definiti. In questo modo è possibile conciliare governance IT e autonomia nella progettazione dei processi operativi.
L’IT è responsabile della base tecnologica. Queste comprendono, ad esempio, l’integrazione dei sistemi, l’accesso ai dati, le autorizzazioni, la sicurezza delle informazioni e le linee guida generali per l’architettura IT.
Nel rispetto di queste regole, gli esperti selezionati dei team operativi possono far evolvere autonomamente le proprie applicazioni operative. Le tecnologie no-code consentono, ad esempio, di adattare shop floor board, visualizzazioni degli indicatori, workflow, riunioni di shop floor e processi di miglioramento continuo, senza avviare un nuovo progetto software per ogni modifica.
Il punto fondamentale è questo: no-code non significa aggirare l’IT, ma consentire ai team operativi di apportare modifiche nel rispetto di regole e limiti tecnici e organizzativi chiaramente definiti. In questo modo è possibile conciliare governance IT e autonomia nella progettazione dei processi operativi.
Meno dipendenza dall’IT, più spazio per il miglioramento continuo
Questa ripartizione delle responsabilità riduce l’impegno necessario per il coordinamento e l’implementazione da entrambe le parti.
Anziché dover coordinare ogni richiesta di modifica tra team operativi, IT ed eventuali fornitori esterni, i key user possono apportare autonomamente molte modifiche ai processi.
L’IT può così concentrare maggiormente le proprie risorse sull’architettura, sull’integrazione, sulla sicurezza e sulle iniziative strategiche. I team operativi, a loro volta, possono rispondere a nuove esigenze senza dover attendere che si liberino risorse di sviluppo per ogni piccola modifica ai processi.
Questa capacità di adattamento è particolarmente importante per il miglioramento continuo, che raramente segue un modello di processo definito una volta per tutte. I processi vengono sperimentati, valutati e perfezionati gradualmente. Il software utilizzato deve accompagnare questa evoluzione, senza trasformare ogni modifica in un progetto IT a sé stante.
Anziché dover coordinare ogni richiesta di modifica tra team operativi, IT ed eventuali fornitori esterni, i key user possono apportare autonomamente molte modifiche ai processi.
L’IT può così concentrare maggiormente le proprie risorse sull’architettura, sull’integrazione, sulla sicurezza e sulle iniziative strategiche. I team operativi, a loro volta, possono rispondere a nuove esigenze senza dover attendere che si liberino risorse di sviluppo per ogni piccola modifica ai processi.
Questa capacità di adattamento è particolarmente importante per il miglioramento continuo, che raramente segue un modello di processo definito una volta per tutte. I processi vengono sperimentati, valutati e perfezionati gradualmente. Il software utilizzato deve accompagnare questa evoluzione, senza trasformare ogni modifica in un progetto IT a sé stante.
Come Visual Shop Floor supporta questo approccio
Visual Shop Floor segue questo principio. La piattaforma software combina dati e informazioni provenienti da sistemi diversi con un ambiente di lavoro configurabile in modo flessibile per i processi operativi.
I key user selezionati possono adattare, tra le altre cose, shop floor board, visualizzazioni degli indicatori, workflow, riunioni di shop floor e processi di miglioramento continuo alle esigenze della propria organizzazione. Allo stesso tempo, è possibile integrare sistemi e fonti di dati esistenti per creare una base informativa condivisa a supporto delle attività operative.
Visual Shop Floor favorisce così una chiara ripartizione delle responsabilità: l’IT definisce e gestisce le condizioni tecniche e di sicurezza, mentre i team operativi possono sviluppare e perfezionare autonomamente i propri processi nel rispetto di tali condizioni.
