El salt del programari aviat es convertirà en una malaltia molt comuna a les empreses. Canviar un programari per un altre a causa de cada petita cosa, saltar de la tecnologia a la tecnologia, experimentar amb un negoci en directe s'està convertint en la norma. Al mateix temps, s'inicia una veritable guerra civil a l'oficina: es forma un moviment de resistència a la implementació, els partidaris estan duent a terme un treball subversiu contra el nou sistema, els espies estan promovent un nou món valent amb nou programari, gestió des del cotxe blindat de el portal corporatiu està emetent sobre pau, treball, KPIs. Una revolució acostuma a acabar amb un fracàs total d'un costat.
Sabem gairebé tot sobre la implementació, així que intentem esbrinar com convertir una revolució en una evolució i fer que la implementació sigui el més útil i indolora possible. Bé, o almenys us direm en què podríeu entrar en el procés.
Visualització ideal de l'acceptació dels empleats del nou programari Font - Yandex.Images
Els consultors estrangers començarien aquest article alguna cosa així: "Si ofereix als seus empleats un programari de qualitat que pot millorar el seu treball, tenir un impacte qualitatiu en el rendiment, l'adopció d'un nou programa o sistema es produirà de manera natural". Però som a Rússia, així que el tema dels empleats sospitosos i bel·ligerants és molt rellevant. Una transició natural no funcionarà, fins i tot amb un programari mínim, com ara un missatger corporatiu o un softphone.
D'on surten les potes del problema?
Avui en dia, cada empresa té tot un zoo de programari instal·lat (prendrem el cas general, perquè a les empreses TI la quantitat de programari és el doble o el triple, i els problemes d'adaptació se solapen parcialment i són molt específics): sistemes de gestió de projectes, CRM/ERP, clients de correu electrònic, missatgeria instantània, portal corporatiu, etc. I això sense comptar amb el fet que hi ha empreses en què fins i tot la transició de navegador a navegador la fa tot l'equip sense excepció (i també hi ha equips que es basen completament en Internet Explorer Edge). En general, hi ha diverses situacions per a les quals el nostre article pot ser útil:
- Hi ha un procés d'automatització primària d'algun grup de tasques: s'està implantant el primer CRM/ERP, s'obre un portal corporatiu, s'està instal·lant un sistema de suport tècnic, etc.;
- un programari és substituït per un altre per algun motiu: obsolescència, nous requisits, escalat, canvi d'activitat, etc.;
- s'estan construint mòduls del sistema existent amb finalitats de desenvolupament i creixement (per exemple, una empresa va obrir la producció i va decidir canviar de en amb la màxima funcionalitat);
- S'està duent a terme una important actualització de la interfície i del programari funcional.
Per descomptat, els dos primers casos són molt més aguts i típics en les seves manifestacions, presteu-hi especial atenció.
Per tant, abans de començar a treballar amb l'equip (que ja sospita que hi haurà canvis aviat), intenteu entendre quins són els motius reals per canviar el programari i si accepteu que els canvis siguin necessaris.
- El programa antic és difícil de treballar: és car, inconvenient, no funciona, ja no compleix els vostres requisits, no és adequat per a la vostra escala, etc. Aquesta és una necessitat objectiva.
- El venedor va deixar de donar suport al sistema, o el suport i les modificacions es van convertir en una sèrie interminable d'aprovacions i d'esgotament de diners. Si els vostres costos han augmentat significativament i en el futur prometen augmentar encara més, no hi ha res a esperar, cal reduir-los. Sí, un nou sistema també costarà diners, però al final l'optimització costarà menys que aquest suport.
- Canviar de programari és el caprici d'una persona o grup d'empleats. Per exemple, el CTO vol un retrocés i està pressionant per a la introducció d'un nou sistema més car, això passa a les grans empreses. Un altre exemple: un director de projecte defensa canviar Asana per Basecamp, després Basecamp per Jira i Jira complex per Wrike. Sovint, l'únic motiu d'aquestes migracions és mostrar la seva feina ocupada i mantenir la seva posició. En aquests casos, cal determinar el grau de necessitat, motius i justificació i, per regla general, per una decisió decidida de rebutjar els canvis.
Estem parlant dels motius de la transició d'un programari a un altre, i no de l'automatització primària, només perquè l'automatització és necessària a priori. Si la vostra empresa fa alguna cosa de manera manual i rutinària, però es pot automatitzar, simplement esteu perdent temps, diners i, molt probablement, dades valuoses de l'empresa. Automatitza-ho!
Com pots creuar: el gran salt o el tigre ajupit?
A la pràctica mundial, hi ha tres estratègies principals per canviar a programari nou i adaptar-s'hi, i ens semblen molt adequades, així que no reinventem la roda.
Big Bang
L'adopció mitjançant el mètode "Big Bang" és la transició més difícil possible, quan s'estableix una data exacta i es realitza una migració brusca, desactivant el programari antic al 100%.
Pros
+ Tothom treballa en un sol sistema, no cal sincronitzar dades, els empleats no necessiten supervisar dues interfícies alhora.
+ Simplicitat per a l'administrador: una migració, una tasca, un suport del sistema.
+ Tots els canvis possibles es produeixen en un moment determinat i es noten gairebé immediatament: no cal aïllar què i en quina proporció afecta la productivitat, la velocitat de desenvolupament, les vendes, etc.
Contres
— Funciona amb èxit només amb programari senzill: xats, portal corporatiu, missatgeria instantània. Fins i tot el correu electrònic ja pot fallar, per no parlar dels sistemes de gestió de projectes, CRM/ERP i altres sistemes seriosos.
— Una migració "explosiva" d'un gran sistema a un altre provocarà inevitablement el caos.
El més important per a aquest tipus de transició a un nou entorn laboral és la formació.
Carrera paral·lela
L'adaptació paral·lela al programari és un mètode de transició més suau i universal, en el qual s'estableix un període de temps durant el qual tots dos sistemes funcionaran simultàniament.
Pros
+ Els usuaris tenen prou temps per acostumar-se al nou programari mentre treballen ràpidament amb l'antic, trobar paral·lelismes i comprendre la nova lògica d'interacció amb la interfície.
+ En cas de problemes sobtats, els empleats continuen treballant en el sistema antic.
+ La formació dels usuaris és menys rigorosa i generalment més barata.
+ Pràcticament no hi ha cap reacció negativa per part dels empleats; al cap i a la fi, no se'ls va privar de les seves eines o manera de fer habituals (si l'automatització es produeix per primera vegada).
Contres
— Problemes d'administració: suport per a tots dos sistemes, sincronització de dades, gestió de la seguretat en dues aplicacions alhora.
— El procés de transició s'allarga sense parar: els empleats s'adonen que els queda gairebé una eternitat i poden ampliar una mica més l'ús de la interfície familiar.
- Confusió de l'usuari: les dues interfícies són confuses i causen errors operatius i de dades.
- Diners. Pagueu pels dos sistemes.
Adopció per fases
L'adaptació pas a pas és l'opció més suau per canviar a programari nou. La transició es realitza de manera funcional, dins de períodes de temps determinats i per departament (per exemple, a partir de l'1 de juny afegim nous clients només al nou sistema CRM, a partir del 20 de juny realitzem transaccions en el nou sistema, fins a l'1 d'agost transferim calendaris). i casos, i el 30 de setembre finalitzem la migració és una descripció molt aproximada, però generalment clara).
Pros
+ Transició organitzada, càrrega distribuïda entre administradors i experts interns.
+ Aprenentatge més reflexiu i en profunditat.
+ No hi ha resistència al canvi, perquè es produeix de la manera més suau possible.
Contres - aproximadament el mateix que per a una transició paral·lela.
Ara, només una transició gradual?
Una pregunta lògica, estaràs d'acord. Per què tenir una molèstia addicional quan podeu fer un calendari i actuar segons un pla clar? De fet, no tot és tan senzill.
- Complexitat del programari: si estem parlant de programari complex (per exemple, ), llavors l'adaptació de fase és més adequada. Si el programari és senzill (messenger, portal corporatiu), un model adequat és quan anuncieu la data i desactiveu el programari antic el dia assenyalat (si teniu sort, els empleats tindran temps per treure tota la informació que necessiten). , i si no compteu amb sort, haureu de proporcionar les dades necessàries d'importació automàtica del sistema antic al nou, si és tècnicament possible).
- El grau de risc per a l'empresa: com més arriscada sigui la implementació, més lenta hauria de ser. D'altra banda, l'endarreriment també és un risc: per exemple, estàs canviant d'un sistema CRM a un altre, i durant el període de transició estàs obligat a pagar per tots dos, augmentant així els costos i el cost de la implantació del nou sistema, que significa que el període d'amortització s'allarga.
- Nombre d'empleats: Big Bang definitivament no és adequat si necessiteu escalar i configurar molts perfils d'usuari. Encara que hi ha casos en què la implementació ultra ràpida és un benefici per a una gran empresa. Aquesta opció pot ser adequada per a sistemes que utilitzen molts empleats, però pot ser que no tinguin requisits perquè la personalització no està pensada. Però de nou, això és una gran explosió per als usuaris finals i un gran treball pas a pas per al mateix servei informàtic (per exemple, sistema de facturació o accés).
- Característiques de la implementació del programari seleccionat (revisió, etc.). De vegades, la implementació és inicialment etapa per etapa, amb recollida de requisits, perfeccionament, formació, etc. Per exemple, sempre s'implementa de manera progressiva, i si algú us promet "implementació i configuració en 3 dies o fins i tot 3 hores", recordeu aquest article i eviteu aquests serveis: instal·lació ≠ implementació.
De nou, fins i tot coneixent els paràmetres enumerats, no es pot prendre definitivament un camí o un altre. Avalueu el vostre entorn corporatiu: això us ajudarà a entendre l'equilibri de poder i a determinar quin model (o combinació d'alguns dels seus elements) és adequat per a vosaltres.
Agents d'influència: revolució o evolució
El primer que cal prestar atenció són els empleats que es veuran afectats per la implementació del nou programari. De fet, el problema que ens plantegem ara és un factor purament humà, per la qual cosa no es pot evitar analitzar l'impacte en els empleats. Ja n'hem esmentat alguns més amunt.
- Els líders de l'empresa determinen com s'acceptarà generalment el nou programari. I aquest no és el lloc per a discursos promocionals i discursos de foc: és important mostrar exactament la necessitat de canvis, per transmetre la idea que això només és triar una eina més fresca i còmoda, el mateix que substituir un ordinador portàtil antic. El major error de la direcció en una situació així és rentar-se les mans i retirar-se: si la direcció no necessita l'automatització de l'empresa, per què hauria d'interessar als empleats? Estar en el procés.
- Els caps de departament (caps de projecte) són un enllaç intermedi que ha de participar en tots els processos, gestionar la insatisfacció, mostrar voluntat i treballar amb totes les objeccions dels companys i realitzar una formació de gran qualitat i profunda.
- Servei informàtic (o administradors de sistemes): a primera vista, aquests són els vostres primers, els més adaptables i adaptables, però... no. Sovint, sobretot a les petites i mitjanes empreses, els administradors de sistemes s'oposen a qualsevol canvi (enfortiment) de la infraestructura informàtica, i això no es deu a cap justificació tècnica, sinó a la mandra i la reticència a treballar. Qui de nosaltres no ha buscat la manera d'evitar la feina? Però que això no sigui en detriment de tota l'empresa.
- Els usuaris finals, per regla general, volen treballar bé i còmodament d'una banda i, com qualsevol persona viva, tenen por del canvi. El principal argument per a ells és honest i senzill: per què introduïm/canviem, quins són els límits de control, com s'avaluarà el treball, què canviarà i quins són els riscos (per cert, tothom hauria d'avaluar els riscos - tot i que som venedors , però no ens comprometem a dir que tot va sempre bé: hi ha riscos en qualsevol procés dins d'un negoci).
- Les "autoritats" dins de l'empresa són partidaris que poden influir en altres empleats. No es tracta necessàriament d'una persona amb una posició elevada o una àmplia experiència: en el cas de treballar amb programari, l'"autoritat" pot ser un avançat que ho sap tot que, per exemple, hagi rellegit Habr i començarà a intimidar. tothom sobre el dolent que es tornarà tot. És possible que ni tan sols tingui l'objectiu d'arruïnar el procés d'implementació o de transició -només lluïment i l'esperit de resistència- i els empleats el creuran. Cal treballar amb aquests empleats: explicar, preguntar i, en casos especialment difícils, indicar les conseqüències.
Hi ha una recepta universal per comprovar si els usuaris realment tenen por d'alguna cosa o si tenen paranoia grupal liderada per un líder intel·ligent. Pregunteu-los sobre els motius de la insatisfacció, sobre les preocupacions; si aquesta no és una experiència o opinió personal, els arguments començaran a abocar després de 3-4 preguntes clarificadores.
Dos factors importants per superar amb èxit el "moviment de resistència".
- Proporcionar formació: proveïdor i interna. Assegureu-vos que els empleats ho entenguin realment tot, ho hagin dominat i, independentment del seu nivell de formació, estiguin preparats per començar a treballar. Un atribut obligatori de la formació són les instruccions impreses i electròniques (normatives) i la documentació més completa del sistema (els venedors que es respecten l'alliberen juntament amb el programari i la proporcionen gratuïtament).
- Busqueu seguidors i trieu influencers. Els experts interns i els primers usuaris són el vostre sistema de suport, tant per educar com per dissipar dubtes. Per regla general, els mateixos empleats estan encantats d'ajudar els seus col·legues i presentar-los el nou programari. La vostra tasca és alleujar-los temporalment de la seva feina o donar-los una bonificació decent per la seva nova càrrega de treball.
Què cal prestar atenció?
- Fins a quin punt estan els empleats afectats pels canvis? (En termes relatius, si demà s'inventen un nou programa de comptabilitat, Déu n'hi do que et fiquis el nas al departament de comptabilitat amb dones de més de 50 anys i et proposes una transició de l'1C, no en sortiràs viu).
- Quant es veuran afectats els fluxos de treball? Una cosa és canviar el missatger en una empresa de 100 persones, una altra és implementar un nou sistema CRM, que es basa en processos clau de l'empresa (i això no només són vendes, per exemple, en edicions sènior afecta la producció, el magatzem, el màrqueting i els alts directius que, juntament amb l'equip, construiran processos de negoci automatitzats).
- S'ha impartit formació i a quin nivell?
L'única transició lògica en el sistema de pensament corporatiu
Què estalviarà la transició/implementació de nou programari?
Abans de dir-vos quins punts clau us ajudaran a passar còmodament al programari nou, deixeu-nos cridar la vostra atenció sobre un punt. Hi ha una cosa que definitivament no s'hauria de fer: no cal pressionar els empleats i "motivar-los" privant-los de bonificacions, sancions administratives i disciplinàries. Això no millorarà el procés, però l'actitud dels empleats empitjorarà: si empenyen, hi haurà control; Si us obliguen, vol dir que no respecten els nostres interessos; Si ho imposen amb força, vol dir que no confien en nosaltres ni en la nostra feina. Per tant, ho fem tot de manera disciplinada, clara, competent, però sense pressions ni forçaments innecessaris.
Heu de tenir un pla d'acció detallat
Potser no existeix tota la resta, però hi ha d'haver un pla. A més, el pla és ajustable, actualitzat, clar i inevitable, alhora accessible per a la discussió i transparent per a tots els empleats interessats. És impossible comunicar de manera directiva que de 8 a 10 del matí hi ha una gesta, i a les 16:00 hi ha guerra amb Anglaterra; és important veure tot el pla en perspectiva.
El pla ha de reflectir necessàriament els requisits dels empleats que seran usuaris finals; d'aquesta manera, cada empleat sabrà exactament quina funció desitja i en quina hora la podrà utilitzar. Al mateix temps, el pla de transició o implementació no és una mena de monòlit immutable; cal deixar la possibilitat de finalitzar el pla i canviar-ne els atributs (però no en forma d'un corrent interminable d'edicions i nous "desitjos" i no en forma de canvi constant de terminis).
Què hauria d'haver al pla?
- Les principals fites de transició (etapes): què cal fer.
- Punts de transició detallats per a cada etapa: com s'ha de fer.
- Punts clau i informes sobre ells (conciliació d'hores): com es mesurarà el que s'ha fet i qui hauria d'estar al punt de control.
- Les persones responsables són persones a les quals pots recórrer i fer preguntes.
- Els terminis són l'inici i el final de cada etapa i de tot el procés en el seu conjunt.
- Processos afectats: quins canvis es produiran en els processos de negoci, què cal canviar juntament amb la implementació/transició.
- L'avaluació final és un conjunt d'indicadors, mètriques o fins i tot avaluacions subjectives que ajudaran a avaluar la implementació/transició que s'ha produït.
- L'inici de l'operació és la data exacta en què tota l'empresa s'incorporarà al procés automatitzat actualitzat i treballarà en el nou sistema.
Ens hem trobat amb presentacions d'implementadors en què la línia vermella és el consell: implementar per la força, ignorar la reacció, no parlar amb els empleats. Estem en contra d'aquest plantejament, i aquí teniu el perquè.
Mireu la imatge següent:
Un nou ratolí, un teclat nou, un apartament, un cotxe i fins i tot una feina són esdeveniments agradables i alegres, alguns d'ells fins i tot èxits. I l'usuari va a Yandex per saber com acostumar-s'hi i adaptar-s'hi. Com entrar a un apartament nou i entendre que és teu, obrir l'aixeta per primera vegada, beure te, anar al llit per primera vegada. Com posar-se al volant i fer amistat amb un cotxe nou, el teu, però fins ara aliè. El nou programari al lloc de treball no és diferent de les situacions descrites: la feina de l'empleat mai serà la mateixa. Per tant, implementar, adaptar, créixer amb un nou programari eficaç. I aquesta és una situació sobre la qual podem dir: afanya't a poc a poc.
Font: www.habr.com