Programaro-salto baldaŭ fariĝos tre ofta malsano de kompanioj. Ŝanĝi unu programaron por alia pro ĉiu eta afero, salti de teknologio al teknologio, eksperimenti kun viva komerco fariĝas la normo. Samtempe komenciĝas vera enlanda milito en la oficejo: formiĝas movado de rezisto al efektivigo, partizanoj faras subfosan laboron kontraŭ la nova sistemo, spionoj antaŭenigas kuraĝan novan mondon per nova programaro, administrado de la kirasa aŭtomobilo de la kompania portalo elsendas pri paco, laboro, KPIoj. Revolucio kutime finiĝas per kompleta fiasko unuflanke.
Ni scias preskaŭ ĉion pri efektivigo, do ni provu eltrovi kiel transformi revolucion en evoluon kaj fari efektivigon kiel eble plej utila kaj sendolora. Nu, aŭ almenaŭ ni diros al vi, kion vi povus eniri en la procezo.
Ideala bildigo de dungita akcepto de nova programaro Fonto - Yandex.Bildoj
Eksterlandaj konsultistoj komencus ĉi tiun artikolon kiel ĉi tion: "Se vi proponas al viaj dungitoj kvalitan programaron, kiu povas plibonigi ilian laboron, havi kvalitan efikon sur efikeco, la adopto de nova programo aŭ sistemo okazos nature." Sed ni estas en Rusio, do tre gravas la afero de suspektindaj kaj militemaj dungitoj. Natura transiro ne funkcios, eĉ kun minimuma programaro kiel kompania mesaĝisto aŭ softtelefono.
De kie venas la kruroj de la problemo?
Hodiaŭ, ĉiu firmao havas tutan zoon de programaro instalita (ni prenas la ĝeneralan kazon, ĉar en IT-kompanioj la kvanto de programaro estas duobla aŭ triobla, kaj adaptproblemoj interkovras parte kaj estas tre specifaj): projekt-administradsistemoj, CRM/ERP, retpoŝtaj klientoj, tujmesaĝiloj, kompania portalo ktp. Kaj ĉi tio ne kalkulas, ke ekzistas kompanioj, en kiuj eĉ la transiro de retumilo al retumilo estas farata de la tuta teamo senescepte (kaj ankaŭ ekzistas teamoj tute bazitaj sur Internet Explorer Edge). Ĝenerale, ekzistas pluraj situacioj por kiuj nia artikolo povas esti utila:
- Estas procezo de primara aŭtomatigo de iu grupo de taskoj: la unua CRM/ERP estas efektivigita, kompania portalo malfermiĝas, sistemo por teknika subteno estas instalita, ktp.;
- unu programaro estas anstataŭigita per alia ial: malnoviĝo, novaj postuloj, skalo, ŝanĝo de agado ktp.;
- moduloj de la ekzistanta sistemo estas konstruataj por disvolvado kaj kresko (ekzemple, firmao malfermis produktadon kaj decidis ŝanĝi de sur kun maksimuma funkcieco);
- Grava interfaco kaj funkcia programaro ĝisdatigo okazas.
Kompreneble, la unuaj du kazoj estas multe pli akraj kaj tipaj en siaj manifestiĝoj, aparte atentu ilin.
Do, antaŭ ol vi komencas labori kun la teamo (kiu jam suspektis, ke baldaŭ okazos ŝanĝoj), provu kompreni, kiuj estas la veraj kialoj por ŝanĝi la programaron kaj ĉu vi konsentas, ke la ŝanĝoj tiom necesas.
- La malnova programo estas malfacile laborebla: ĝi estas multekosta, maloportuna, nefunkcia, ne plu plenumas viajn postulojn, ne taŭgas por via skalo ktp. Ĉi tio estas objektiva neceso.
- La vendisto ĉesis subteni la sistemon, aŭ subteno kaj modifoj fariĝis senfina serio de aproboj kaj mono drenado. Se viaj kostoj signife pliiĝis, kaj en la estonteco ili promesas pligrandigi eĉ pli, estas nenio por atendi, vi devas tranĉi. Jes, nova sistemo ankaŭ kostos monon, sed finfine optimumigo kostos malpli ol tia subteno.
- Ŝanĝi programaron estas la kaprico de unu persono aŭ grupo de dungitoj. Ekzemple, la CTO volas retrovigon kaj celvarbas por la enkonduko de nova, pli multekosta sistemo - tio okazas en grandaj kompanioj. Alia ekzemplo: projektestro rekomendas ŝanĝi Asana al Basecamp, tiam Basecamp al Jira, kaj kompleksa Jira al Wrike. Ofte la sola motivo por tiaj migradoj estas montri sian okupatan laboron kaj konservi sian pozicion. En tiaj kazoj, necesas determini la gradon de neceso, motivoj kaj pravigo kaj, kiel regulo, per fortvola decido rifuzi ŝanĝojn.
Ni parolas pri la kialoj de la transiro de unu programaro al alia, kaj ne pri primara aŭtomatigo - nur ĉar aŭtomatigo estas apriore necesa. Se via firmao faras ion mane kaj rutine sed povus esti aŭtomatigita, vi simple malŝparas tempon, monon kaj, plej verŝajne, valorajn kompaniojn. Aŭtomatigu ĝin!
Kiel vi povas transiri: la granda salto aŭ la kaŭranta tigro?
En la monda praktiko ekzistas tri ĉefaj strategioj por ŝanĝi al nova programaro kaj adaptiĝi al ĝi - kaj ili ŝajnas al ni tre taŭgaj, do ni ne reinventu la radon.
Praeksplodo
Adopto per la metodo "Big Bang" estas la plej malfacila ebla transiro, kiam vi fiksas precizan daton kaj efektivigas akran migradon, malŝaltante la malnovan programaron 100%.
Puloj
+ Ĉiuj laboras en unu sistemo, ne necesas sinkronigi datumojn, dungitoj ne bezonas monitori du interfacojn samtempe.
+ Simpleco por la administranto - unu migrado, unu tasko, unu sistema subteno.
+ Ĉiuj eblaj ŝanĝoj okazas en unu momento kaj estas videblaj preskaŭ tuj - ne necesas izoli kio kaj en kiu proporcio influis produktivecon, rapidecon de disvolviĝo, vendon ktp.
Miksoj
— Funkcias sukcese nur per simpla programaro: babilejoj, kompania portalo, tujmesaĝiloj. Eĉ retpoŝto jam povas malsukcesi, sen mencii projekt-administradsistemojn, CRM/ERP kaj aliajn seriozajn sistemojn.
— Eksploda migrado de granda sistemo al alia neeviteble kaŭzos kaoson.
La plej grava afero por ĉi tiu tipo de transiro al nova labormedio estas trejnado.
Paralela Kurado
Paralela adaptado al softvaro estas pli milda kaj pli universala metodo de transiro, en kiu tempoperiodo estas fiksita dum kiu ambaŭ sistemoj funkcios samtempe.
Puloj
+ Uzantoj havas sufiĉe da tempo por alkutimiĝi al la nova programaro dum rapide laboras en la malnova, trovi paralelojn kaj kompreni la novan logikon de interago kun la interfaco.
+ En kazo de subitaj problemoj, dungitoj daŭre laboras en la malnova sistemo.
+ Trejnado de uzantoj estas malpli rigora kaj ĝenerale pli malmultekosta.
+ Preskaŭ ne ekzistas negativa reago de dungitoj - ja ili ne estis senigitaj de siaj kutimaj iloj aŭ maniero de fari aferojn (se aŭtomatigo okazas la unuan fojon).
Miksoj
— Problemoj pri administrado: subteno por ambaŭ sistemoj, sinkronigado de datumoj, administrado de sekureco en du aplikaĵoj samtempe.
— La transira procezo etendiĝas senfine - dungitoj rimarkas, ke al ili restas preskaŭ eterneco, kaj ili povas iomete plilongigi la uzon de la konata interfaco.
- Konfuzo de uzantoj - La du interfacoj estas konfuzaj kaj kaŭzas operaciajn kaj datumajn erarojn.
- Mono. Vi pagas por ambaŭ sistemoj.
Etapa Adopto
Paŝo-post-paŝa adapto estas la plej mola opcio por ŝanĝi al nova programaro. La transiro efektiviĝas funkcie, en difinitaj tempodaŭroj kaj laŭ fako (ekzemple, de la 1-a de junio ni aldonas novajn klientojn nur al la nova CRM-sistemo, de la 20-a de junio ni faras transakciojn en la nova sistemo, ĝis la 1-a de aŭgusto ni transdonas kalendarojn). kaj kazoj, kaj ĝis la 30-a de septembro ni kompletigas migradon estas tre malglata priskribo, sed ĝenerale klara).
Puloj
+ Organizita transiro, distribuita ŝarĝo inter administrantoj kaj internaj fakuloj.
+ Pli pripensema kaj profunda lernado.
+ Ne ekzistas rezisto al ŝanĝo, ĉar ĝi okazas kiel eble plej milde.
Miksoj - proksimume sama kiel por paralela transiro.
Do nun, nur laŭgrada transiro?
Logika demando, vi konsentos. Kial akiri iom da plia ĝeno kiam vi povas fari horaron kaj agi laŭ klara plano? Fakte, ne ĉio estas tiel simpla.
- Komplekseco de programaro: se ni parolas pri kompleksa programaro (ekzemple, ), tiam faza adapto estas pli taŭga. Se la programaro estas simpla (mesaĝilo, kompania portalo), tiam taŭga modelo estas kiam vi anoncas la daton kaj malŝaltas la malnovan programaron en la difinita tago (se vi bonŝancas, dungitoj havos tempon por eltiri ĉiujn informojn, kiujn ili bezonas. , kaj se vi ne kalkulas je bonŝanco, tiam vi devas provizi aŭtomatajn importajn necesajn datumojn de la malnova sistemo al la nova, se teknike eblas).
- La grado de risko por la kompanio: ju pli riska la efektivigo, des pli malrapida ĝi devus esti. Aliflanke, prokrasto ankaŭ estas risko: ekzemple, vi ŝanĝas de unu CRM-sistemo al alia, kaj dum la transira periodo vi estas devigita pagi por ambaŭ, tiel pliigante la kostojn kaj kostojn de efektivigo de la nova sistemo, kiu signifas, ke la repago periodo estas plilongigita.
- Nombro da dungitoj: Big Bang certe ne taŭgas, se vi bezonas grimpi kaj agordi multajn uzantprofilojn. Kvankam estas kazoj kiam ultra-rapida efektivigo estas avantaĝo por granda kompanio. Ĉi tiu opcio eble taŭgas por sistemoj uzataj de multaj dungitoj, sed eble ne havas postulojn ĉar personigo ne estas celita. Sed denove, ĉi tio estas granda eksplodo por finaj uzantoj kaj grandega paŝo post paŝo por la sama IT-servo (ekzemple, faktura aŭ alirsistemo).
- Trajtoj de la efektivigo de la elektita programaro (revizio, ktp.). Foje la efektivigo estas komence etapo - kun postulkolekto, rafinado, trejnado, ktp. Ekzemple, ĝi ĉiam efektiviĝas laŭgrade, kaj se iu promesas al vi "efektivigon kaj agordon en 3 tagoj aŭ eĉ 3 horoj" - memoru ĉi tiun artikolon kaj preteriru tiajn servojn: instalado ≠ efektivigo.
Denove, eĉ konante la listigitajn parametrojn, oni nepre ne povas preni unu vojon aŭ alian. Taksi vian kompanian medion - ĉi tio helpos vin ambaŭ kompreni la ekvilibron de potenco kaj determini kiu modelo (aŭ kombinaĵo de kelkaj el iliaj elementoj) taŭgas por vi.
Agentoj de influo: revolucio aŭ evoluo
La unua afero, kiun vi devas atenti, estas la dungitoj, kiuj estos tuŝitaj de la efektivigo de nova programaro. Fakte, la problemo, kiun ni konsideras nun, estas nur homa faktoro, do analizi la efikon al dungitoj ne povas esti evitita. Ni jam menciis kelkajn el ili supre.
- Firmaaj gvidantoj determinas kiel la nova programaro estos ĝenerale akceptita. Kaj ĉi tio ne estas la loko por reklamaj paroladoj kaj fajraj paroladoj - gravas montri ĝuste la bezonon de ŝanĝo, transdoni la ideon, ke ĉi tio nur elektas pli malvarmetan kaj pli oportunan ilon, same kiel anstataŭi malnovan tekkomputilon. La plej granda eraro de administrado en tia situacio estas lavi siajn manojn kaj retiriĝi: se administrado ne bezonas firmaan aŭtomatigon, kial ĝi interesu dungitojn? Estu en la procezo.
- Sekciestroj (projektestroj) estas meza ligo, kiu devas partopreni en ĉiuj procezoj, administri malkontenton, montri volon kaj labori tra ĉiu obĵeto de kolegoj, kaj fari altkvalitan kaj profundan trejnadon.
- IT-servo (aŭ sistemadministrantoj) - unuavide, ĉi tiuj estas viaj fruaj birdoj, la plej adapteblaj kaj adapteblaj, sed... ne. Ofte, precipe en malgrandaj kaj mezgrandaj entreprenoj, sistemadministrantoj kontraŭas ajnajn ŝanĝojn (plifortigon) de la IT-infrastrukturo, kaj tio estas ne pro ia teknika pravigo, sed pro maldiligento kaj malemo labori. Kiu el ni ne serĉis manierojn eviti laboron? Sed ĉi tio ne damaĝu la tutan kompanion.
- Finaj uzantoj, kiel regulo, volas labori bone kaj oportune unuflanke kaj, kiel ĉiuj vivantaj homoj, timas ŝanĝon. La ĉefa argumento por ili estas honesta kaj simpla: kial ni enkondukas/ŝanĝas, kiuj estas la limoj de kontrolo, kiel la laboro estos taksita, kio ŝanĝiĝos kaj kiuj estas la riskoj (cetere, ĉiuj devus taksi la riskojn - kvankam ni estas vendistoj , sed ni ne entreprenas diri, ke ĉio ĉiam iras glate: ekzistas riskoj en iu ajn procezo ene de komerco).
- "Aŭtoritatoj" ene de la firmao estas partizanoj, kiuj povas influi aliajn dungitojn. Ĉi tio ne nepre estas persono kun alta pozicio aŭ ampleksa sperto - en la kazo de laboro kun programaro, la "aŭtoritato" povas esti altnivela scianto, kiu, ekzemple, relegis Habr kaj komencos timigi. ĉiuj pri kiom malbona ĉio fariĝos. Eble li eĉ ne havas celon ruinigi la efektivigon aŭ transiran procezon - nur elmontron kaj la spiriton de rezisto - kaj dungitoj kredos lin. Vi devas labori kun tiaj dungitoj: klarigi, pridubi, kaj en speciale malfacilaj kazoj, aludo pri la sekvoj.
Estas universala recepto por kontroli ĉu uzantoj vere timas ion aŭ ĉu ili havas grupan paranojon gviditan de saĝa gvidanto. Demandu ilin pri la kialoj de malkontento, pri zorgoj - se ĉi tio ne estas persona sperto aŭ opinio, argumentoj komencos enflui post 3-4 klarigantaj demandoj.
Du gravaj faktoroj por sukcese venki la "rezistan movadon".
- Provizu trejnadon: vendisto kaj interna. Certiĝu, ke dungitoj vere komprenas ĉion, regas ĝin kaj, sendepende de sia nivelo de trejnado, estas pretaj komenci labori. Deviga atributo de trejnado estas presitaj kaj elektronikaj instrukcioj (regularoj) kaj la plej kompleta dokumentaro pri la sistemo (merespektaj vendistoj liberigas ĝin kune kun la programaro kaj provizas ĝin senpage).
- Serĉu subtenantojn kaj elektu influantojn. Internaj spertuloj kaj fruaj adoptantoj estas via subtena sistemo, kaj edukante kaj forigante dubojn. Ĝenerale, dungitoj mem ĝojas helpi siajn kolegojn kaj konigi ilin al novaj programoj. Via tasko estas provizore malpezigi ilin de ilia laboro aŭ doni al ili decan gratifikon por ilia nova laborkvanto.
Kion vi bezonas atenti?
- Kiom progresintaj estas la dungitoj trafitaj de la ŝanĝoj? (Relative parolante, se morgaŭ ili inventos novan kontadan programon, Dio malpermesu vin enŝovi la nazon en la kontada fako kun sinjorinoj pli ol 50-jaraj kaj sugestu transiron de 1C, vi ne eliros viva).
- Kiom laborfluoj estos tuŝitaj? Unu afero estas ŝanĝi la mesaĝiston en kompanio de 100 homoj, alia afero estas efektivigi novan CRM-sistemon, kiu baziĝas sur ŝlosilaj procezoj en la kompanio (kaj ĉi tio ne estas nur vendoj, ekzemple, en altrangaj eldonoj ĝi influas produktadon, stokejon, merkatadon kaj ĉefmanaĝerojn kiuj, kune kun la teamo, konstruos aŭtomatigitajn komercajn procezojn).
- Ĉu trejnado estis provizita kaj je kiu nivelo?
La sola logika transiro en la sistemo de kompania pensado
Kio ŝparos la transiron/efektivigon de nova programaro?
Antaŭ ol ni diros al vi, kiaj ŝlosilaj punktoj helpos vin komforte moviĝi al nova programaro, ni atentigu vian atenton pri unu punkto. Estas io, kio certe ne devus esti farita - ne necesas premi dungitojn kaj "motivi" ilin senigante ilin de gratifikoj, administraj kaj disciplinaj sankcioj. Ĉi tio ne plibonigos la procezon, sed la sinteno de la dungitoj plimalboniĝos: se ili premas, tiam estos kontrolo; Se ili devigas vin, tio signifas, ke ili ne respektas nian intereson; Se ili perforte trudas ĝin, tio signifas, ke ili ne fidas nin kaj nian laboron. Tial ni faras ĉion en disciplinita, klara, kompetenta maniero, sed sen premo aŭ nenecesa trudado.
Vi devas havi detalan agadplanon
Ĉio alia eble ne ekzistas, sed devas esti plano. Krome, la plano estas alĝustigebla, ĝisdatigita, klara kaj neevitebla, samtempe alirebla por diskuto kaj travidebla por ĉiuj interesitaj dungitoj. Estas neeble direkte komuniki, ke de la 8-a ĝis la 10-a estas heroaĵo, kaj je 16:00 estas milito kun Anglio; gravas vidi la tutan planon en perspektivo.
La plano devas nepre reflekti la postulojn de dungitoj, kiuj estos finaj uzantoj - tiamaniere ĉiu dungito scios precize kian deziratan funkcion kaj je kioma tempo li povos uzi ĝin. Samtempe, la transiro aŭ efektiviga plano ne estas ia neŝanĝebla monolito; necesas forlasi la eblecon fini la planon kaj ŝanĝi ĝiajn atributojn (sed ne en la formo de senfina fluo de redaktoj kaj novaj "deziraĵoj" kaj ne en la formo de konstanta ŝanĝo en templimoj).
Kio devus esti en la plano?
- La ĉefaj transiraj mejloŝtonoj (etapoj) - kio devas esti farita.
- Detalaj transirpunktoj por ĉiu etapo - kiel ĝi devus esti farita.
- Ŝlosilpunktoj kaj raportado pri ili (repaciĝo de horoj) - kiel tio, kio estis farita, estos mezurita kaj kiu devus esti ĉe la kontrolpunkto.
- Respondecaj homoj estas homoj al kiuj vi povas turni sin kaj demandi demandojn.
- Limdatoj estas la komenco kaj fino de ĉiu etapo kaj la tuta procezo kiel tutaĵo.
- Trafitaj procezoj - kiaj ŝanĝoj okazos en komercaj procezoj, kio devas esti ŝanĝita kune kun la efektivigo/transiro.
- La fina takso estas aro de indikiloj, metrikoj aŭ eĉ subjektivaj taksoj, kiuj helpos taksi la efektivigon/transiron kiu okazis.
- La komenco de operacio estas la ĝusta dato, kiam la tuta kompanio aliĝos al la ĝisdatigita aŭtomata procezo kaj laboros en la nova sistemo.
Ni renkontis prezentojn de efektivigantoj, en kiuj la ruĝa linio estas konsilo: efektivigi perforte, ignori la reagon, ne paroli kun dungitoj. Ni estas kontraŭ ĉi tiu aliro, kaj jen kial.
Rigardu la bildon sube:
Nova muso, nova klavaro, apartamento, aŭtomobilo, kaj eĉ laboro estas agrablaj, ĝojaj eventoj, kelkaj el ili estas eĉ atingoj. Kaj la uzanto iras al Yandex por ekscii kiel alkutimiĝi al ĝi kaj adaptiĝi. Kiel eniri novan apartamenton kaj kompreni, ke ĝi estas via, unuafoje enŝaltu la kranon, trinku teon, enlitiĝi la unuan fojon. Kiel amikiĝi malantaŭ la stirado kaj amikiĝi kun nova aŭto, via, sed ĝis nun tiel fremda. Nova programaro en la laborejo ne diferencas de la priskribitaj situacioj: la laboro de la dungito neniam estos la sama. Sekve, efektivigu, adaptu, kresku per nova efika programaro. Kaj jen situacio, pri kiu ni povas diri: rapidu malrapide.
fonto: www.habr.com