Il balzo in avanti del software diventerà presto una malattia molto comune nelle aziende. Cambiare un software con un altro a causa di ogni piccola cosa, passare da una tecnologia all'altra, sperimentare un business dal vivo sta diventando la norma. Allo stesso tempo, in ufficio inizia una vera guerra civile: si forma un movimento di resistenza all'attuazione, i partigiani conducono un lavoro sovversivo contro il nuovo sistema, le spie promuovono un mondo nuovo e coraggioso con nuovi software, la gestione dall'auto blindata di il portale aziendale trasmette informazioni su pace, lavoro, KPI. Una rivoluzione di solito termina con un completo fallimento da una parte.
Sappiamo quasi tutto sull’implementazione, quindi proviamo a capire come trasformare una rivoluzione in un’evoluzione e rendere l’implementazione il più utile e indolore possibile. Bene, o almeno ti diremo in cosa potresti imbatterti nel processo.
Visualizzazione ideale dell'accettazione da parte dei dipendenti del nuovo software Fonte: Yandex.Images
I consulenti stranieri inizierebbero questo articolo in questo modo: “Se offri ai tuoi dipendenti un software di qualità che possa migliorare il loro lavoro, avere un impatto qualitativo sulle prestazioni, l’adozione di un nuovo programma o sistema avverrà in modo naturale”. Ma siamo in Russia, quindi la questione dei dipendenti sospettosi e bellicosi è molto rilevante. Una transizione naturale non funzionerà, nemmeno con un software minimo come un messenger aziendale o un softphone.
Da dove vengono le radici del problema?
Oggi ogni azienda ha uno zoo di software installato (prendiamo il caso generale, perché nelle aziende informatiche la quantità di software è doppia o tripla e i problemi di adattamento si sovrappongono parzialmente e sono molto specifici): sistemi di project management, CRM/ERP, client di posta elettronica, messaggistica istantanea, portale aziendale, ecc. E questo senza contare il fatto che ci sono aziende in cui anche il passaggio da browser a browser viene effettuato dall'intero team senza eccezioni (e ci sono anche team che sono completamente basati su Internet Explorer Edge). In generale, ci sono diverse situazioni per le quali il nostro articolo può essere utile:
- è in atto il processo di automazione primaria di un determinato gruppo di compiti: si sta implementando il primo CRM/ERP, si sta aprendo un portale aziendale, si sta installando un sistema per il supporto tecnico, ecc.;
- un software viene sostituito da un altro per qualche motivo: obsolescenza, nuovi requisiti, ridimensionamento, cambio di attività, ecc.;
- si stanno costruendo moduli del sistema esistente ai fini dello sviluppo e della crescita (ad esempio, un'azienda ha aperto la produzione e ha deciso di passare da su con la massima funzionalità);
- È in corso un importante aggiornamento dell'interfaccia e del software funzionale.
Naturalmente, i primi due casi sono molto più acuti e tipici nelle loro manifestazioni, prestate loro particolare attenzione.
Quindi, prima di iniziare a lavorare con il team (che già sospettava che presto ci sarebbero stati dei cambiamenti), cerca di capire quali sono i reali motivi per cambiare il software e se sei d'accordo che i cambiamenti siano così necessari.
- È difficile lavorare con il vecchio programma: è costoso, scomodo, non funzionale, non soddisfa più le tue esigenze, non è adatto alla tua scala, ecc. Questa è una necessità oggettiva.
- Il venditore ha smesso di supportare il sistema, oppure il supporto e le modifiche si sono trasformati in una serie infinita di approvazioni e sprechi di denaro. Se i tuoi costi sono aumentati in modo significativo e in futuro promettono di aumentare ancora di più, non c'è niente da aspettare, devi tagliare. Sì, anche un nuovo sistema costerà denaro, ma alla fine l'ottimizzazione costerà meno di tale supporto.
- La modifica del software è il capriccio di una persona o di un gruppo di dipendenti. Ad esempio, il CTO vuole un rollback e sta facendo pressioni per l'introduzione di un nuovo sistema più costoso, cosa che accade nelle grandi aziende. Un altro esempio: un project manager consiglia di cambiare Asana in Basecamp, quindi Basecamp in Jira e il complesso Jira in Wrike. Spesso l’unico motivo di tali migrazioni è mostrare il proprio lavoro intenso e mantenere la propria posizione. In tali casi, è necessario determinare il grado di necessità, i motivi e la giustificazione e, di regola, con una decisione volitiva di rifiutare i cambiamenti.
Stiamo parlando delle ragioni del passaggio da un software all'altro e non dell'automazione primaria, solo perché l'automazione è necessaria a priori. Se la tua azienda fa qualcosa manualmente e di routine ma potrebbe essere automatizzato, stai semplicemente sprecando tempo, denaro e, molto probabilmente, preziosi dati aziendali. Automatizzalo!
Come si può attraversare: il grande salto o la tigre accovacciata?
Nella pratica mondiale, ci sono tre strategie principali per passare a un nuovo software e adattarsi ad esso - e ci sembrano molto adatte, quindi non reinventiamo la ruota.
Big Bang
L'adozione con il metodo “Big Bang” è la transizione più difficile possibile, quando si fissa una data precisa e si effettua una migrazione brusca, disabilitando al 100% il vecchio software.
Pro
+ Tutti lavorano in un unico sistema, non è necessario sincronizzare i dati, i dipendenti non devono monitorare due interfacce contemporaneamente.
+ Semplicità per l'amministratore: una migrazione, un'attività, un supporto di sistema.
+ Tutti i possibili cambiamenti si verificano in un determinato momento e sono evidenti quasi immediatamente: non è necessario isolare cosa e in quale proporzione ha influenzato la produttività, la velocità di sviluppo, le vendite, ecc.
Contro
— Funziona con successo solo con software semplici: chat, portale aziendale, messaggistica istantanea. Anche la posta elettronica può già fallire, per non parlare dei sistemi di gestione dei progetti, CRM/ERP e altri sistemi seri.
— Una migrazione esplosiva da un grande sistema a un altro causerà inevitabilmente il caos.
La cosa più importante per questo tipo di transizione verso un nuovo ambiente lavorativo è la formazione.
Corsa parallela
L'adattamento parallelo al software è un metodo di transizione più morbido e universale, in cui viene fissato un periodo di tempo durante il quale entrambi i sistemi funzioneranno contemporaneamente.
Pro
+ Gli utenti hanno abbastanza tempo per abituarsi al nuovo software mentre lavorano rapidamente con quello vecchio, trovano paralleli e comprendono la nuova logica di interazione con l'interfaccia.
+ In caso di problemi improvvisi i dipendenti continuano a lavorare con il vecchio sistema.
+ La formazione degli utenti è meno rigorosa e generalmente più economica.
+ Non c'è praticamente alcuna reazione negativa da parte dei dipendenti: dopo tutto, non sono stati privati dei loro strumenti o modi di fare consueti (se l'automazione avviene per la prima volta).
Contro
— Problemi di amministrazione: supporto per entrambi i sistemi, sincronizzazione dei dati, gestione della sicurezza in due applicazioni contemporaneamente.
— Il processo di transizione si protrae all'infinito: i dipendenti si rendono conto che gli resta quasi un'eternità e possono estendere ancora un po' l'utilizzo dell'interfaccia familiare.
- Confusione dell'utente: le due interfacce creano confusione e causano errori operativi e di dati.
- Soldi. Paghi per entrambi i sistemi.
Adozione graduale
L'adattamento graduale è l'opzione più morbida per passare al nuovo software. La transizione viene eseguita in modo funzionale, entro determinati periodi di tempo e per dipartimento (ad esempio, dal 1 giugno aggiungiamo nuovi clienti solo al nuovo sistema CRM, dal 20 giugno effettuiamo transazioni nel nuovo sistema, fino al 1 agosto trasferiamo i calendari e casi, ed entro il 30 settembre completeremo la migrazione (è una descrizione molto approssimativa, ma generalmente chiara).
Pro
+ Transizione organizzata, carico distribuito tra amministratori ed esperti interni.
+ Apprendimento più ponderato e approfondito.
+ Non c'è resistenza al cambiamento, perché avviene nel modo più delicato possibile.
Contro - approssimativamente lo stesso di una transizione parallela.
Quindi ora, solo una transizione graduale?
Una domanda logica, sarai d'accordo. Perché avere qualche seccatura in più quando puoi stabilire un programma e agire secondo un piano chiaro? In realtà, non tutto è così semplice.
- Complessità del software: se parliamo di software complesso (ad esempio, ), allora l'adattamento di fase è più adatto. Se il software è semplice (messenger, portale aziendale), allora un modello adatto è quando si annuncia la data e si disattiva il vecchio software il giorno stabilito (se si è fortunati, i dipendenti avranno il tempo di estrarre tutte le informazioni di cui hanno bisogno) e se non conti sulla fortuna, devi fornire l'importazione automatica dei dati necessari dal vecchio sistema a quello nuovo, se tecnicamente possibile).
- Il grado di rischio per l’azienda: quanto più rischiosa è l’implementazione, tanto più lenta dovrebbe essere. D’altra parte, anche il ritardo è un rischio: ad esempio, stai passando da un sistema CRM a un altro e durante il periodo di transizione sei costretto a pagare per entrambi, aumentando così i costi e i costi di implementazione del nuovo sistema, che significa che il periodo di rimborso è prolungato.
- Numero di dipendenti: Big Bang non è sicuramente adatto se è necessario scalare e configurare molti profili utente. Sebbene ci siano casi in cui l'implementazione ultraveloce è un vantaggio per una grande azienda. Questa opzione potrebbe essere adatta per i sistemi utilizzati da molti dipendenti, ma potrebbe non presentare requisiti poiché non è prevista la personalizzazione. Ma ancora una volta, questo è un grande botto per gli utenti finali e un enorme lavoro passo dopo passo per lo stesso servizio IT (ad esempio, fatturazione o sistema di accesso).
- Caratteristiche dell'implementazione del software selezionato (revisione, ecc.). A volte l'implementazione avviene inizialmente per fasi, con la raccolta dei requisiti, il perfezionamento, la formazione, ecc. Per esempio, viene sempre implementato progressivamente e se qualcuno ti promette "implementazione e configurazione in 3 giorni o anche 3 ore" - ricorda questo articolo e ignora tali servizi: installazione ≠ implementazione.
Ancora una volta, anche conoscendo i parametri elencati, non è possibile intraprendere con certezza una strada o l'altra. Valuta il tuo ambiente aziendale: questo ti aiuterà a comprendere gli equilibri di potere e a determinare quale modello (o combinazione di alcuni dei loro elementi) è giusto per te.
Agenti d'influenza: rivoluzione o evoluzione
La prima cosa a cui dovresti prestare attenzione sono i dipendenti che saranno interessati dall'implementazione del nuovo software. In realtà, il problema che stiamo considerando ora è puramente un fattore umano, quindi non è possibile evitare di analizzare l'impatto sui dipendenti. Alcuni di essi li abbiamo già menzionati sopra.
- I leader aziendali determinano il modo in cui il nuovo software sarà generalmente accettato. E questo non è il luogo per discorsi promozionali e discorsi infuocati: è importante mostrare esattamente la necessità di cambiamento, trasmettere l'idea che si tratta semplicemente di scegliere uno strumento più interessante e conveniente, come sostituire un vecchio laptop. L’errore più grande del management in una situazione del genere è lavarsene le mani e ritirarsi: se il management non ha bisogno dell’automazione aziendale, perché dovrebbe interessare ai dipendenti? Essere nel processo.
- I capi dipartimento (responsabili di progetto) sono un anello intermedio che deve partecipare a tutti i processi, gestire l'insoddisfazione, mostrare volontà e lavorare nonostante ogni obiezione dei colleghi e condurre una formazione approfondita e di alta qualità.
- Servizio IT (o amministratori di sistema): a prima vista, questi sono i primi, i più adattabili e adattivi, ma... no. Spesso, soprattutto nelle piccole e medie imprese, gli amministratori di sistema si oppongono a qualsiasi modifica (potenziamento) dell'infrastruttura informatica, e ciò non è dovuto ad alcuna giustificazione tecnica, ma alla pigrizia e alla riluttanza al lavoro. Chi di noi non ha cercato modi per evitare di lavorare? Ma questo non va a discapito dell’intera azienda.
- Gli utenti finali, di regola, vogliono lavorare bene e comodamente da un lato e, come ogni persona vivente, hanno paura del cambiamento. L'argomentazione principale per loro è onesta e semplice: perché stiamo introducendo/modificando, quali sono i limiti del controllo, come verrà valutato il lavoro, cosa cambierà e quali sono i rischi (a proposito, tutti dovrebbero valutare i rischi - anche se siamo venditori , ma non ci impegniamo a dire che tutto vada sempre liscio: ci sono dei rischi in ogni processo all'interno di un'azienda).
- Le “autorità” all’interno dell’azienda sono partigiani che possono influenzare altri dipendenti. Questa non è necessariamente una persona con una posizione elevata o una vasta esperienza: nel caso di lavorare con il software, l '"autorità" potrebbe essere un saccente avanzato che, ad esempio, ha riletto Habr e inizierà a intimidire tutti su quanto tutto diventerà brutto. Potrebbe non avere nemmeno l'obiettivo di rovinare il processo di implementazione o di transizione - solo esibizionismo e spirito di resistenza - e i dipendenti gli crederanno. È necessario lavorare con tali dipendenti: spiegare, porre domande e, in casi particolarmente difficili, suggerire le conseguenze.
Esiste una ricetta universale per verificare se gli utenti hanno davvero paura di qualcosa o se soffrono di paranoie di gruppo guidate da un leader esperto. Chiedi loro le ragioni dell'insoddisfazione, delle preoccupazioni: se questa non è un'esperienza o un'opinione personale, gli argomenti inizieranno ad arrivare dopo 3-4 domande chiarificatrici.
Due fattori importanti per superare con successo il “movimento di resistenza”.
- Fornire formazione: fornitore e interna. Assicurati che i dipendenti capiscano davvero tutto, lo abbiano padroneggiato e, indipendentemente dal loro livello di formazione, siano pronti per iniziare a lavorare. Un attributo obbligatorio della formazione sono le istruzioni stampate ed elettroniche (regolamenti) e la documentazione più completa sul sistema (i fornitori che si rispettano la rilasciano insieme al software e la forniscono gratuitamente).
- Cerca sostenitori e scegli influencer. Gli esperti interni e gli early adopter sono il tuo sistema di supporto, educando e dissipando i dubbi. Di norma, i dipendenti stessi sono lieti di aiutare i colleghi e di presentarli al nuovo software. Il tuo compito è sollevarli temporaneamente dal lavoro o offrire loro un bonus decente per il loro nuovo carico di lavoro.
Che cosa dovrebbe prestare attenzione?
- A che punto sono i dipendenti interessati dai cambiamenti? (Relativamente parlando, se domani inventano un nuovo programma di contabilità, Dio non voglia che tu ficchi il naso nel reparto contabilità con donne sopra i 50 anni e suggerisca una transizione da 1C, non ne uscirai vivo).
- Quanto saranno influenzati i flussi di lavoro? Una cosa è cambiare il messenger in un'azienda di 100 persone, un'altra cosa è implementare un nuovo sistema CRM, che si basa sui processi chiave dell'azienda (e non si tratta solo delle vendite, ad esempio, nelle edizioni senior colpisce produzione, magazzino, marketing e top manager che, insieme al team, costruiranno processi aziendali automatizzati).
- È stata fornita formazione e a che livello?
L'unica transizione logica nel sistema di pensiero aziendale
Cosa salverà la transizione/implementazione del nuovo software?
Prima di dirti quali punti chiave ti aiuteranno a passare comodamente al nuovo software, attiriamo la tua attenzione su un punto. C'è qualcosa che sicuramente non dovrebbe essere fatto: non è necessario esercitare pressioni sui dipendenti e “motivarli” privandoli di bonus, sanzioni amministrative e disciplinari. Ciò non migliorerà il processo, ma peggiorerà l’atteggiamento dei dipendenti: se spingono, ci sarà controllo; Se ti obbligano significa che non rispettano i nostri interessi; Se lo impongono con la forza significa che non hanno fiducia in noi e nel nostro lavoro. Pertanto, facciamo tutto in modo disciplinato, chiaro, competente, ma senza pressioni o forzature inutili.
È necessario disporre di un piano d'azione dettagliato
Tutto il resto potrebbe non esistere, ma deve esserci un piano. Inoltre, il piano è adattabile, aggiornato, chiaro e inevitabile, allo stesso tempo accessibile alla discussione e trasparente per tutti i dipendenti interessati. È impossibile comunicare in modo direttivo che dalle 8:10 alle 16:00 c'è un'impresa e alle XNUMX:XNUMX c'è la guerra con l'Inghilterra, è importante vedere l'intero piano in prospettiva.
Il piano deve necessariamente riflettere le esigenze dei dipendenti che saranno gli utenti finali: in questo modo ogni dipendente saprà esattamente quale funzionalità desidera e in quale momento potrà utilizzarla. Allo stesso tempo, il piano di transizione o di attuazione non è una sorta di monolite immutabile; è necessario lasciare la possibilità di finalizzare il piano e di modificarne gli attributi (ma non sotto forma di un flusso infinito di modifiche e nuovi “desideri”) e non sotto forma di un costante spostamento delle scadenze).
Cosa dovrebbe essere nel piano?
- Le principali tappe fondamentali della transizione (fasi): cosa è necessario fare.
- Punti di transizione dettagliati per ciascuna fase: come dovrebbe essere eseguita.
- Punti chiave e relativa rendicontazione (riconciliazione delle ore): come verrà misurato ciò che è stato fatto e chi dovrebbe trovarsi al punto di controllo.
- Le persone responsabili sono persone a cui puoi rivolgerti e a cui puoi porre domande.
- Le scadenze rappresentano l'inizio e la fine di ogni fase e dell'intero processo nel suo complesso.
- Processi interessati: quali modifiche si verificheranno nei processi aziendali, cosa deve essere modificato durante l'implementazione/transizione.
- La valutazione finale è un insieme di indicatori, parametri o anche valutazioni soggettive che aiuteranno a valutare l'implementazione/transizione avvenuta.
- L'inizio dell'attività è la data esatta in cui l'intera azienda aderirà al processo automatizzato aggiornato e lavorerà nel nuovo sistema.
Ci siamo imbattuti in presentazioni di implementatori in cui la linea rossa è un consiglio: attuare con la forza, ignorare la reazione, non parlare con i dipendenti. Siamo contrari a questo approccio, ed ecco perché.
Guarda la foto sotto:
Un nuovo mouse, una nuova tastiera, un appartamento, un'auto e persino un lavoro sono eventi piacevoli e gioiosi, alcuni addirittura risultati. E l'utente va su Yandex per scoprire come abituarsi e adattarsi. Come entrare in un nuovo appartamento e capire che è tuo, aprire il rubinetto per la prima volta, bere il tè, andare a letto per la prima volta. Come mettersi al volante e fare amicizia con un'auto nuova, la tua, ma finora così aliena. Il nuovo software sul posto di lavoro non è diverso dalle situazioni descritte: il lavoro del dipendente non sarà più lo stesso. Pertanto, implementa, adatta, cresci con nuovi software efficaci. E questa è una situazione di cui possiamo dire: affrettatevi lentamente.
Fonte: habr.com