Shpërthimi i softuerit së shpejti do të bëhet një sëmundje shumë e zakonshme e kompanive. Ndryshimi i një softueri me një tjetër për shkak të çdo gjëje të vogël, kalimi nga teknologjia në teknologji, eksperimentimi me një biznes të drejtpërdrejtë po bëhet normë. Në të njëjtën kohë, në zyrë fillon një luftë e vërtetë civile: formohet një lëvizje e rezistencës ndaj zbatimit, partizanët po kryejnë punë subversive kundër sistemit të ri, spiunët po promovojnë një botë të re të guximshme me softuer të ri, menaxhim nga makina e blinduar e portali i korporatës po transmeton për paqen, punën, KPI. Një revolucion zakonisht përfundon me dështim të plotë nga njëra anë.
Ne dimë pothuajse gjithçka rreth zbatimit, kështu që le të përpiqemi të kuptojmë se si ta kthejmë një revolucion në një evolucion dhe ta bëjmë zbatimin sa më të dobishëm dhe pa dhimbje. Epo, ose të paktën ne do t'ju tregojmë se çfarë mund të futeni në këtë proces.
Vizualizimi ideal i pranimit të softuerit të ri nga punonjësit - Yandex.Images
Konsulentët e huaj do ta fillonin këtë artikull diçka si kjo: "Nëse punonjësve tuaj u ofroni softuer cilësor që mund të përmirësojë punën e tyre, të ketë një ndikim cilësor në performancë, miratimi i një programi ose sistemi të ri do të ndodhë natyrshëm." Por ne jemi në Rusi, kështu që çështja e punonjësve të dyshimtë dhe luftarakë është shumë e rëndësishme. Një tranzicion i natyrshëm nuk do të funksionojë, madje edhe me një softuer minimal, siç është një mesazher i korporatës ose telefon i butë.
Nga vijnë këmbët e problemit?
Sot, çdo kompani ka të instaluar një kopsht zoologjik të tërë softuerësh (marrim rastin e përgjithshëm, sepse në kompanitë e IT sasia e softuerit është dyfish ose trefish dhe problemet e përshtatjes mbivendosen pjesërisht dhe janë shumë specifike): sistemet e menaxhimit të projekteve, CRM/ERP, klientët e postës elektronike, lajmëtarët e çastit, portalet e korporatave, etj. Dhe kjo nuk llogarit faktin se ka kompani në të cilat edhe kalimi nga shfletuesi në shfletues kryhet nga i gjithë ekipi pa përjashtim (dhe ka edhe ekipe që bazohen plotësisht në Internet Explorer Edge). Në përgjithësi, ka disa situata për të cilat artikulli ynë mund të jetë i dobishëm:
- Ekziston një proces i automatizimit primar të disa grupeve të detyrave: po zbatohet CRM/ERP i parë, po hapet një portal korporativ, po instalohet një sistem për mbështetje teknike, etj.;
- një softuer zëvendësohet nga një tjetër për disa arsye: vjetërsimi, kërkesat e reja, shkallëzimi, ndryshimi i aktivitetit, etj.;
- modulet e sistemit ekzistues po ndërtohen për qëllime zhvillimi dhe rritjeje (për shembull, një kompani hapi prodhimin dhe vendosi të kalojë nga mbi me funksionalitet maksimal);
- Një ndërfaqe e madhe dhe përditësim funksional i softuerit po ndodh.
Sigurisht, dy rastet e para janë shumë më akute dhe tipike në manifestimet e tyre, kushtojini vëmendje të veçantë atyre.
Pra, përpara se të filloni të punoni me ekipin (të cilët tashmë kanë dyshuar se së shpejti do të ketë ndryshime), përpiquni të kuptoni se cilat janë arsyet e vërteta për ndryshimin e softuerit dhe nëse jeni dakord që ndryshimet janë kaq të nevojshme.
- Programi i vjetër është i vështirë për t'u punuar: është i shtrenjtë, i papërshtatshëm, jofunksional, nuk i plotëson më kërkesat tuaja, nuk është i përshtatshëm për shkallën tuaj, etj. Kjo është një domosdoshmëri objektive.
- Shitësi ndaloi së mbështeturi sistemin, ose mbështetja dhe modifikimet u kthyen në një seri të pafundme miratimesh dhe shterim parash. Nëse kostot tuaja janë rritur ndjeshëm, dhe në të ardhmen ato premtojnë të rriten edhe më shumë, nuk ka asgjë për të pritur, duhet të shkurtoni. Po, një sistem i ri do të kushtojë gjithashtu para, por në fund optimizimi do të kushtojë më pak se një mbështetje e tillë.
- Ndryshimi i softuerit është teka e një personi ose grupi punonjësish. Për shembull, CTO dëshiron një rikthim dhe po lobon për futjen e një sistemi të ri, më të shtrenjtë - kjo ndodh në kompanitë e mëdha. Një shembull tjetër: një menaxher projekti mbron ndryshimin e Asana në Basecamp, pastaj Basecamp në Jira dhe komplekse Jira në Wrike. Shpesh motivi i vetëm për migrime të tilla është të tregojnë punën e tyre të zënë dhe të ruajnë pozicionin e tyre. Në raste të tilla, është e nevojshme të përcaktohet shkalla e domosdoshmërisë, motiveve dhe justifikimit dhe, si rregull, me një vendim me dëshirë të fortë për të refuzuar ndryshimet.
Ne po flasim për arsyet e kalimit nga një softuer në tjetrin, dhe jo për automatizimin parësor - vetëm sepse automatizimi është apriori i nevojshëm. Nëse kompania juaj bën diçka manualisht dhe në mënyrë rutinore, por mund të automatizohet, thjesht po humbisni kohë, para dhe, ka shumë të ngjarë, të dhëna të vlefshme të kompanisë. Automatizoni atë!
Si mund të kaloni: kërcimin e madh apo tigrin e ulur?
Në praktikën botërore, ekzistojnë tre strategji kryesore për kalimin në softuer të ri dhe përshtatjen me të - dhe ato na duken shumë të përshtatshme, kështu që le të mos e rishpikim timonin.
Big Bang
Adoptimi duke përdorur metodën "Big Bang" është tranzicioni më i vështirë i mundshëm, kur vendosni një datë të saktë dhe kryeni një migrim të mprehtë, duke çaktivizuar 100% softuerin e vjetër.
Rekuizitë
+ Të gjithë punojnë në një sistem, nuk ka nevojë të sinkronizohen të dhënat, punonjësit nuk kanë nevojë të monitorojnë dy ndërfaqe njëherësh.
+ Thjeshtësia për administratorin - një migrim, një detyrë, një mbështetje e sistemit.
+ Të gjitha ndryshimet e mundshme ndodhin në një moment në kohë dhe vërehen pothuajse menjëherë - nuk ka nevojë të izolohet se çfarë dhe në çfarë proporcioni ka ndikuar në produktivitetin, shpejtësinë e zhvillimit, shitjet, etj.
Cons
— Punon me sukses vetëm me softuer të thjeshtë: biseda, portal korporativ, lajmëtarë të menjëhershëm. Edhe emaili tashmë mund të dështojë, për të mos përmendur sistemet e menaxhimit të projektit, CRM/ERP dhe sisteme të tjera serioze.
— Një migrim “shpërthyes” nga një sistem i madh në një tjetër do të shkaktojë në mënyrë të pashmangshme kaos.
Gjëja më e rëndësishme për këtë lloj kalimi në një mjedis të ri pune është trajnimi.
Vrapim paralel
Përshtatja paralele me softuerin është një metodë më e butë dhe më universale e tranzicionit, në të cilën caktohet një periudhë kohore gjatë së cilës të dy sistemet do të funksionojnë njëkohësisht.
Rekuizitë
+ Përdoruesit kanë kohë të mjaftueshme për t'u mësuar me softuerin e ri ndërsa punojnë shpejt në atë të vjetër, për të gjetur paralele dhe për të kuptuar logjikën e re të ndërveprimit me ndërfaqen.
+ Në rast problemesh të papritura, punonjësit vazhdojnë të punojnë në sistemin e vjetër.
+ Trajnimi i përdoruesve është më pak rigoroz dhe përgjithësisht më i lirë.
+ Praktikisht nuk ka asnjë reagim negativ nga punonjësit - në fund të fundit, ata nuk u privuan nga mjetet e tyre të zakonshme ose mënyra e të bërit të gjërave (nëse automatizimi ndodh për herë të parë).
Cons
— Problemet e administrimit: mbështetje për të dy sistemet, sinkronizimi i të dhënave, menaxhimi i sigurisë në dy aplikacione njëherësh.
— Procesi i tranzicionit shtrihet pafundësisht - punonjësit kuptojnë se u ka mbetur pothuajse një përjetësi dhe mund të zgjerojnë pak më shumë përdorimin e ndërfaqes së njohur.
- Konfuzioni i përdoruesit - Dy ndërfaqet janë konfuze dhe shkaktojnë gabime operacionale dhe të dhënash.
- Paratë. Ju paguani për të dy sistemet.
Adoptimi me faza
Përshtatja hap pas hapi është opsioni më i butë për kalimin në softuer të ri. Tranzicioni kryhet funksionalisht, brenda periudhave të caktuara kohore dhe sipas departamentit (për shembull, nga 1 qershori ne shtojmë klientë të rinj vetëm në sistemin e ri CRM, nga 20 qershor kryejmë transaksione në sistemin e ri, deri më 1 gusht transferojmë kalendarët dhe rastet, dhe deri më 30 shtator ne përfundojmë migrimin është një përshkrim shumë i përafërt, por përgjithësisht i qartë).
Rekuizitë
+ Tranzicion i organizuar, ngarkesa e shpërndarë midis administratorëve dhe ekspertëve të brendshëm.
+ Mësimi më i zhytur në mendime dhe i thelluar.
+ Nuk ka rezistencë ndaj ndryshimit, sepse ai ndodh sa më butësisht të jetë e mundur.
Cons - afërsisht e njëjtë si për një tranzicion paralel.
Pra, tani, vetëm një tranzicion gradual?
Një pyetje logjike, do të jeni dakord. Pse të keni ndonjë sherr shtesë kur mund të bëni një orar dhe të veproni sipas një plani të qartë? Në fakt, jo gjithçka është kaq e thjeshtë.
- Kompleksiteti i softuerit: nëse po flasim për softuer kompleks (për shembull, ), atëherë përshtatja e fazës është më e përshtatshme. Nëse softueri është i thjeshtë (messenger, portal i korporatës), atëherë një model i përshtatshëm është kur shpallni datën dhe çaktivizoni softuerin e vjetër në ditën e caktuar (nëse jeni me fat, punonjësit do të kenë kohë të nxjerrin të gjithë informacionin që u nevojitet , dhe nëse nuk mbështeteni në fat, atëherë duhet të siguroni të dhënat e nevojshme të importimit të automatizuar nga sistemi i vjetër në atë të ri, nëse është teknikisht e mundur).
- Shkalla e rrezikut për kompaninë: sa më i rrezikshëm të jetë zbatimi, aq më i ngadalshëm duhet të jetë. Nga ana tjetër, vonesa është gjithashtu një rrezik: për shembull, ju po kaloni nga një sistem CRM në tjetrin dhe gjatë periudhës së tranzicionit jeni të detyruar të paguani për të dy, duke rritur kështu kostot dhe koston e zbatimit të sistemit të ri, i cili do të thotë se periudha e shlyerjes është zgjatur.
- Numri i punonjësve: Big Bang nuk është definitivisht i përshtatshëm nëse keni nevojë të shkallëzoni dhe konfiguroni shumë profile të përdoruesve. Edhe pse ka raste kur zbatimi ultra i shpejtë është një përfitim për një kompani të madhe. Ky opsion mund të jetë i përshtatshëm për sistemet që përdoren nga shumë punonjës, por mund të mos ketë kërkesa sepse personalizimi nuk synohet. Por përsëri, kjo është një zhurmë e madhe për përdoruesit përfundimtarë dhe një punë e madhe hap pas hapi për të njëjtin shërbim IT (për shembull, sistemi i faturimit ose i aksesit).
- Karakteristikat e zbatimit të softuerit të zgjedhur (rishikim, etj.). Ndonjëherë zbatimi është fillimisht hap pas hapi - me mbledhjen e kërkesave, përsosjen, trajnimin, etj. Për shembull, ai zbatohet gjithmonë në mënyrë progresive, dhe nëse dikush ju premton "zbatim dhe konfigurim në 3 ditë apo edhe 3 orë" - mbani mend këtë artikull dhe anashkaloni shërbime të tilla: instalimi ≠ zbatimi.
Përsëri, edhe duke ditur parametrat e listuar, nuk mund të merrni patjetër një rrugë apo një tjetër. Vlerësoni mjedisin tuaj të korporatës - kjo do t'ju ndihmojë të kuptoni ekuilibrin e fuqisë dhe të përcaktoni se cili model (ose kombinim i disa prej elementeve të tyre) është i duhuri për ju.
Agjentët e ndikimit: revolucion ose evolucion
Gjëja e parë që duhet t'i kushtoni vëmendje janë punonjësit që do të preken nga zbatimi i softuerit të ri. Në fakt, problemi që po shqyrtojmë tani është thjesht një faktor njerëzor, ndaj analizimi i ndikimit tek punonjësit nuk mund të shmanget. Disa prej tyre i kemi përmendur më lart.
- Drejtuesit e kompanisë përcaktojnë se si do të pranohet përgjithësisht softueri i ri. Dhe ky nuk është vendi për fjalime promovuese dhe fjalime të zjarrta - është e rëndësishme të tregohet saktësisht nevoja për ndryshim, për të përcjellë idenë se kjo është thjesht zgjedhja e një mjeti më të freskët dhe më të përshtatshëm, njësoj si zëvendësimi i një laptopi të vjetër. Gabimi më i madh i menaxhmentit në një situatë të tillë është të lajë duart dhe të tërhiqet: nëse menaxhmenti nuk ka nevojë për automatizimin e kompanisë, pse duhet të jetë me interes për punonjësit? Jini në proces.
- Drejtuesit e departamenteve (menaxherët e projektit) janë një hallkë e ndërmjetme që duhet të marrë pjesë në të gjitha proceset, të menaxhojë pakënaqësinë, të tregojë vullnet dhe të punojë për çdo kundërshtim të kolegëve dhe të kryejë trajnime cilësore dhe të thelluara.
- Shërbimi IT (ose administratorët e sistemit) - në shikim të parë, këta janë zogjtë tuaj të hershëm, më të përshtatshmit dhe më të adaptueshëm, por... jo. Shpesh, sidomos në kompanitë e vogla dhe të mesme, administratorët e sistemit kundërshtojnë çdo ndryshim (forcim) të infrastrukturës së IT-së dhe kjo nuk vjen nga ndonjë justifikim teknik, por nga dembelizmi dhe ngurrimi për të punuar. Kush prej nesh nuk ka kërkuar mënyra për të shmangur punën? Por kjo le të mos jetë në dëm të të gjithë kompanisë.
- Përdoruesit përfundimtarë, si rregull, duan të punojnë mirë dhe me lehtësi nga njëra anë dhe, si çdo njeri i gjallë, kanë frikë nga ndryshimi. Argumenti kryesor për ta është i sinqertë dhe i thjeshtë: pse po prezantojmë/ndryshojmë, cilët janë kufijtë e kontrollit, si do të vlerësohet puna, çfarë do të ndryshojë dhe cilat janë rreziqet (meqë ra fjala, të gjithë duhet të vlerësojnë rreziqet - edhe pse jemi shitës , por nuk marrim përsipër të themi se gjithçka shkon gjithmonë mirë: ka rreziqe në çdo proces brenda një biznesi).
- “Autoritetet” brenda kompanisë janë partizanë që mund të ndikojnë tek punonjësit e tjerë. Ky nuk është domosdoshmërisht një person me një pozicion të lartë ose përvojë të gjerë - në rastin e punës me softuer, "autoriteti" mund të jetë një njohës i avancuar i cili, për shembull, ka rilexuar Habrin dhe do të fillojë të frikësojë të gjithë se sa e keqe do të bëhet gjithçka. Ai mund të mos ketë as një synim për të prishur procesin e zbatimit ose të tranzicionit - thjesht shfaqje dhe frymën e rezistencës - dhe punonjësit do ta besojnë atë. Ju duhet të punoni me punonjës të tillë: shpjegoni, pyesni dhe në raste veçanërisht të vështira, jepni aluzion për pasojat.
Ekziston një recetë universale për të kontrolluar nëse përdoruesit kanë vërtet frikë nga diçka ose nëse kanë paranojë grupore të udhëhequr nga një udhëheqës i zgjuar. Pyetini ata për arsyet e pakënaqësisë, për shqetësimet - nëse kjo nuk është një përvojë apo mendim personal, argumentet do të fillojnë të derdhen pas 3-4 pyetjeve sqaruese.
Dy faktorë të rëndësishëm për kapërcimin me sukses të “lëvizjes së rezistencës”.
- Ofroni trajnime: shitës dhe të brendshëm. Sigurohuni që punonjësit të kuptojnë vërtet gjithçka, ta kenë zotëruar atë dhe, pavarësisht nga niveli i tyre i trajnimit, të jenë gati të fillojnë punën. Një atribut i detyrueshëm i trajnimit janë udhëzimet e shtypura dhe elektronike (rregulloret) dhe dokumentacioni më i plotë në sistem (shitësit që respektojnë veten e lëshojnë atë së bashku me softuerin dhe e ofrojnë falas).
- Kërkoni mbështetës dhe zgjidhni influencues. Ekspertët e brendshëm dhe adoptuesit e hershëm janë sistemi juaj i mbështetjes, duke edukuar dhe larguar dyshimet. Si rregull, vetë punonjësit janë të kënaqur të ndihmojnë kolegët e tyre dhe t'i prezantojnë ata me softuer të ri. Detyra juaj është t'i lironi përkohësisht nga puna ose t'u jepni atyre një bonus të mirë për ngarkesën e re të punës.
Çfarë duhet t'i kushtoni vëmendje?
- Sa të avancuar janë punonjësit të prekur nga ndryshimet? (Relativisht, nëse nesër ata shpikin një program të ri të kontabilitetit, Zoti ju ruajt të futni hundën në departamentin e kontabilitetit me zonjat mbi 50 vjeç dhe të sugjeroni një kalim nga 1C, nuk do të dilni gjallë).
- Sa do të ndikohen rrjedhat e punës? Është një gjë të ndryshosh mesazherin në një kompani prej 100 personash, tjetër gjë është të zbatosh një sistem të ri CRM, i cili bazohet në proceset kryesore në kompani (dhe kjo nuk është vetëm shitje, për shembull, në edicionet më të larta ajo prek prodhimin, magazinë, marketingun dhe menaxherët kryesorë të cilët së bashku me ekipin do të ndërtojnë procese të automatizuara biznesi).
- A u ofrua trajnime dhe në çfarë niveli?
I vetmi tranzicion logjik në sistemin e të menduarit të korporatës
Çfarë do ta shpëtojë tranzicionin/zbatimin e softuerit të ri?
Përpara se t'ju tregojmë se cilat pika kyçe do t'ju ndihmojnë të kaloni me lehtësi në softuer të ri, le të tërheqim vëmendjen tuaj në një pikë. Ka diçka që definitivisht nuk duhet bërë - nuk ka nevojë të ushtroni presion mbi punonjësit dhe t'i “motivoni” ata duke i privuar nga shpërblimet, sanksionet administrative dhe disiplinore. Kjo nuk do ta përmirësojë procesin, por qëndrimi i punonjësve do të përkeqësohet: nëse shtyjnë, atëherë do të ketë kontroll; Nëse të detyrojnë, do të thotë se nuk e respektojnë interesin tonë; Nëse e imponojnë me forcë, do të thotë se nuk na besojnë ne dhe punën tonë. Prandaj, ne bëjmë gjithçka në mënyrë të disiplinuar, të qartë, kompetente, por pa presione apo detyrime të panevojshme.
Duhet të keni një plan veprimi të detajuar
Çdo gjë tjetër mund të mos ekzistojë, por duhet të ketë një plan. Për më tepër, plani është i rregullueshëm, i përditësuar, i qartë dhe i pashmangshëm, në të njëjtën kohë i aksesueshëm për diskutim dhe transparent për të gjithë punonjësit e interesuar. Është e pamundur të komunikosh në mënyrë direkte se nga ora 8 e mëngjesit deri në 10 të mëngjesit ka një feat, dhe në orën 16:00 ka luftë me Anglinë, është e rëndësishme të shihet i gjithë plani në perspektivë.
Plani duhet domosdoshmërisht të pasqyrojë kërkesat e punonjësve që do të jenë përdorues të fundit - në këtë mënyrë çdo punonjës do të dijë saktësisht se çfarë veçorie të dëshiruar dhe në çfarë kohe do të jetë në gjendje ta përdorë atë. Në të njëjtën kohë, plani i tranzicionit ose zbatimi nuk është një lloj monolit i pandryshueshëm, është e nevojshme të lihet mundësia e finalizimit të planit dhe ndryshimit të atributeve të tij (por jo në formën e një rryme të pafund modifikimesh dhe "dëshirash" të reja; dhe jo në formën e një zhvendosjeje të vazhdueshme të afateve).
Çfarë duhet të jetë në plan?
- Pikat kryesore të tranzicionit (fazat) - çfarë duhet bërë.
- Pikat e detajuara të tranzicionit për secilën fazë - si duhet bërë.
- Pikat kyçe dhe raportimi për to (barazimi i orëve) - si do të matet ajo që është bërë dhe kush duhet të jetë në pikën e kontrollit.
- Njerëzit përgjegjës janë njerëz të cilëve mund t'u drejtoheni dhe të bëni pyetje.
- Afatet janë fillimi dhe fundi i çdo faze dhe i gjithë procesit në tërësi.
- Proceset e prekura - çfarë ndryshimesh do të ndodhin në proceset e biznesit, çfarë duhet të ndryshohet së bashku me zbatimin/tranzicionin.
- Vlerësimi përfundimtar është një grup treguesish, metrikash apo edhe vlerësimesh subjektive që do të ndihmojnë në vlerësimin e zbatimit/tranzicionit që ka ndodhur.
- Fillimi i funksionimit është data e saktë kur e gjithë kompania do t'i bashkohet procesit të përditësuar të automatizuar dhe do të punojë në sistemin e ri.
Kemi hasur në prezantime të zbatuesve në të cilat vija e kuqe është këshilla: zbato me forcë, shpërfill reagimin, mos fol me punonjësit. Ne jemi kundër kësaj qasjeje, dhe ja pse.
Shikoni foton më poshtë:
Një mi i ri, një tastierë e re, një apartament, një makinë, madje edhe një punë janë ngjarje të këndshme, të gëzueshme, disa prej tyre madje janë arritje. Dhe përdoruesi shkon në Yandex për të zbuluar se si të mësohet me të dhe të përshtatet. Si të hyni në një apartament të ri dhe të kuptoni se është i juaji, hapni rubinetin për herë të parë, pini çaj, shkoni në shtrat për herë të parë. Si të hipni pas timonit dhe të bëni miq me një makinë të re, tuajën, por deri tani kaq të huaj. Softueri i ri në vendin e punës nuk ndryshon nga situatat e përshkruara: puna e punonjësit nuk do të jetë kurrë e njëjtë. Prandaj, zbatoni, përshtatni, rriteni me softuer të ri efektiv. Dhe kjo është një situatë për të cilën mund të themi: nxitoni ngadalë.
Burimi: www.habr.com