Darbuotojai nenori naujos programinės įrangos – ar jie turėtų sekti pavyzdžiu ar laikytis savo linijos?

Programinės įrangos šuolis netrukus taps labai dažna įmonių liga. Vienos programinės įrangos keitimas kita dėl kiekvienos smulkmenos, peršokimas nuo technologijų prie technologijų, eksperimentavimas su gyvu verslu tampa norma. Tuo pat metu biure prasideda tikras pilietinis karas: formuojasi pasipriešinimo įgyvendinimui sąjūdis, partizanai vykdo ardomąjį darbą prieš naująją sistemą, šnipai propaguoja narsų naują pasaulį su nauja programine įranga, valdymu iš šarvuočio. įmonių portalas transliuoja apie taiką, darbą, KPI. Revoliucija dažniausiai baigiasi visiška nesėkme vienoje pusėje.

Mes žinome beveik viską apie įgyvendinimą, todėl pabandykime išsiaiškinti, kaip revoliuciją paversti evoliucija ir padaryti įgyvendinimą kuo naudingesnį ir neskausmingesnį. Na, arba bent jau mes jums pasakysime, į ką galite patekti šiame procese.

Ideali darbuotojų priėmimo naujai programinei įrangai vizualizacija Šaltinis – Yandex.Images

Užsienio konsultantai šį straipsnį pradėtų maždaug taip: „Jei pasiūlysite savo darbuotojams kokybišką programinę įrangą, kuri gali pagerinti jų darbą, turėti kokybinį poveikį našumui, naujos programos ar sistemos priėmimas įvyks natūraliai“. Bet mes esame Rusijoje, todėl įtartinų ir karingų darbuotojų klausimas labai aktualus. Natūralus perėjimas neveiks net naudojant minimalią programinę įrangą, tokią kaip įmonės pasiuntinys ar programinis telefonas.

Iš kur kyla problemos kojos?

Šiandien kiekvienoje įmonėje įdiegtas visas zoologijos sodas programinės įrangos (imkime bendrą atvejį, nes IT įmonėse programinės įrangos kiekis yra dvigubas ar trigubas, o adaptacijos problemos iš dalies persidengia ir yra labai specifinės): projektų valdymo sistemos, CRM/ERP, pašto klientai, momentiniai pasiuntiniai, įmonių portalas ir kt. Ir tai neskaičiuojant to, kad yra įmonių, kuriose net perėjimą iš naršyklės į naršyklę atlieka visa komanda be išimties (o taip pat yra komandų, kurios yra visiškai pagrįstos Internet Explorer Edge). Apskritai, yra keletas situacijų, kurioms mūsų straipsnis gali būti naudingas:

• Vyksta kai kurių užduočių grupių pirminio automatizavimo procesas: diegiamas pirmasis CRM/ERP, atidaromas įmonės portalas, diegiama techninio palaikymo sistema ir kt.;
• viena programinė įranga dėl tam tikrų priežasčių pakeičiama kita: pasenimas, nauji reikalavimai, mastelio keitimas, veiklos pasikeitimas ir pan.;
• plėtros ir augimo tikslais kuriami esamos sistemos moduliai (pavyzdžiui, įmonė atidarė gamybą ir nusprendė pereiti nuo RegionSoft CRM profesionalas apie RegionSoft CRM Enterprise Plus su maksimaliu funkcionalumu);
• Vyksta didelis sąsajos ir funkcinės programinės įrangos atnaujinimas.

Žinoma, pirmieji du atvejai yra daug aštresni ir tipiškesni savo apraiškomis, jiems atkreipkite ypatingą dėmesį.

Taigi, prieš pradėdami dirbti su komanda (kurie jau įtarė, kad netrukus bus pasikeitimų), pabandykite suprasti, kokios yra tikrosios programinės įrangos keitimo priežastys ir ar sutinkate, kad pakeitimai tokie reikalingi.

• Su sena programa sunku dirbti: ji brangi, nepatogi, neveikianti, nebeatitinka Jūsų reikalavimų, netinka Jūsų masteliams ir pan. Tai yra objektyvi būtinybė.
• Pardavėjas nustojo palaikyti sistemą arba palaikymas ir modifikacijos virto begaline patvirtinimų ir pinigų išeikvojimu. Jeigu jūsų išlaidos gerokai išaugo, o ateityje žada dar didėti, nėra ko laukti, reikia mažinti. Taip, nauja sistema taip pat kainuos, bet galiausiai optimizavimas kainuos pigiau nei toks palaikymas.
• Programinės įrangos keitimas yra vieno žmogaus ar darbuotojų grupės užgaida. Pavyzdžiui, CTO nori atšaukti ir užsiima naujos, brangesnės sistemos įvedimu – taip nutinka didelėse įmonėse. Kitas pavyzdys: projekto vadovas pasisako už Asana pakeitimą į Basecamp, tada Basecamp į Jira ir kompleksinį Jira į Wrike. Dažnai vienintelis tokių migracijų motyvas yra parodyti savo užimtą darbą ir išlaikyti savo pareigas. Tokiais atvejais būtina nustatyti būtinumo laipsnį, motyvus ir pateisinimą ir, kaip taisyklė, stiprios valios sprendimu atsisakyti pakeitimų.

Kalbame apie perėjimo nuo vienos programinės įrangos prie kitos priežastis, o ne apie pirminį automatizavimą – tik todėl, kad automatizavimas yra a priori būtinas. Jei jūsų įmonė kažką daro rankiniu būdu ir reguliariai, bet gali būti automatizuota, jūs tiesiog eikvojate laiką, pinigus ir, greičiausiai, vertingus įmonės duomenis. Automatizuokite!

Kaip tu gali kirsti: didysis šuolis ar tupintis tigras?

Pasaulinėje praktikoje yra trys pagrindinės strategijos, kaip pereiti prie naujos programinės įrangos ir prie jos prisitaikyti – ir jos mums atrodo labai tinkamos, todėl neišradinėkime dviračio iš naujo.

Didžiojo sprogimo

Priėmimas naudojant „Didžiojo sprogimo“ metodą yra sunkiausias įmanomas perėjimas, kai nustatote tikslią datą ir atliekate staigų perkėlimą, išjungiant seną programinę įrangą 100%.

Argumentai "už"

+ Visi dirba vienoje sistemoje, nereikia sinchronizuoti duomenų, darbuotojams nereikia stebėti dviejų sąsajų vienu metu.
+ Paprastumas administratoriui – viena migracija, viena užduotis, vienas sistemos palaikymas.
+ Visi galimi pokyčiai įvyksta vienu momentu ir yra pastebimi beveik iš karto – nereikia išskirti, kas ir kokia dalimi paveikė produktyvumą, plėtros greitį, pardavimus ir pan.

Trūkumai

— Sėkmingai veikia tik su paprasta programine įranga: pokalbiais, įmonės portalu, momentiniais pasiuntiniais. Net elektroninis paštas jau gali sugesti, jau nekalbant apie projektų valdymo sistemas, CRM/ERP ir kitas rimtas sistemas.
— „Sprogioji“ migracija iš didelės sistemos į kitą neišvengiamai sukels chaosą.

Svarbiausia tokio tipo perėjimui į naują darbo aplinką yra mokymai.

Lygiagretus bėgimas

Lygiagretus pritaikymas programinei įrangai yra švelnesnis ir universalesnis perėjimo būdas, kai nustatomas laikotarpis, per kurį abi sistemos veiks vienu metu.

Argumentai "už"

+ Vartotojai turi pakankamai laiko priprasti prie naujos programinės įrangos, greitai dirbdami su senąja, rasti paralelių ir suprasti naują sąveikos su sąsaja logiką.
+ Iškilus staigioms problemoms, darbuotojai toliau dirba pagal seną sistemą.
+ Vartotojų mokymas yra ne toks griežtas ir paprastai pigesnis.
+ Praktiškai nėra neigiamos darbuotojų reakcijos – juk iš jų nebuvo atimti įprasti įrankiai ar darbo būdas (jeigu automatizavimas įvyksta pirmą kartą).

Trūkumai

— Administravimo problemos: abiejų sistemų palaikymas, duomenų sinchronizavimas, saugos valdymas dviejose programose vienu metu.
— Perėjimo procesas tęsiasi be galo – darbuotojai supranta, kad jiems liko beveik amžinybė, ir jie gali dar šiek tiek pratęsti pažįstamos sąsajos naudojimą.
– Vartotojo painiavos – dvi sąsajos yra painios ir sukelia veikimo ir duomenų klaidas.
- Pinigai. Jūs mokate už abi sistemas.

Laipsniškas įvaikinimas

Žingsnis po žingsnio pritaikymas yra švelniausia galimybė pereiti prie naujos programinės įrangos. Perėjimas vykdomas funkcionaliai, nustatytais laikotarpiais ir pagal padalinius (pvz., nuo birželio 1 d. naujus klientus įtraukiame tik į naują CRM sistemą, nuo birželio 20 d. atliekame operacijas naujoje sistemoje, iki rugpjūčio 1 d. perkeliame kalendorius ir atvejai, o iki rugsėjo 30 d. užbaigsime migraciją yra labai apytikslis apibūdinimas, bet apskritai aiškus).

Argumentai "už"

+ Organizuotas perėjimas, paskirstyta apkrova tarp administratorių ir vidinių ekspertų.
+ Daugiau apgalvoto ir išsamesnio mokymosi.
+ Nėra pasipriešinimo pokyčiams, nes jie vyksta kuo švelniau.

Trūkumai - maždaug toks pat kaip lygiagrečiam perėjimui.

Taigi dabar tik laipsniškas perėjimas?

Logiškas klausimas, sutiksite. Kam turėti papildomų rūpesčių, kai galite sudaryti tvarkaraštį ir veikti pagal aiškų planą? Tiesą sakant, ne viskas taip paprasta.

• Programinės įrangos sudėtingumas: jei kalbame apie sudėtingą programinę įrangą (pvz. CRM sistema), tada fazės pritaikymas yra tinkamesnis. Jei programinė įranga paprasta (messenger, įmonės portalas), tuomet tinkamas modelis, kai paskelbiate datą ir paskirtą dieną išjungiate senąją programinę įrangą (jei pasiseks, darbuotojai turės laiko ištraukti visą jiems reikalingą informaciją , o jei nesitikite sėkmės, tuomet, jei techniškai įmanoma, turite pateikti automatizuotą reikiamų duomenų importą iš senosios sistemos į naująją).
• Įmonės rizikos laipsnis: kuo rizikingesnis įgyvendinimas, tuo jis turėtų būti lėtesnis. Kita vertus, delsimas taip pat yra rizika: pavyzdžiui, pereinate nuo vienos CRM sistemos prie kitos, o pereinamuoju laikotarpiu esate priversti mokėti už abi, todėl padidėja naujos sistemos diegimo sąnaudos ir sąnaudos, reiškia, kad atsipirkimo laikotarpis pratęsiamas.
• Darbuotojų skaičius: Didysis sprogimas tikrai netinka, jei reikia keisti ir konfigūruoti daug vartotojų profilių. Nors pasitaiko atvejų, kai itin greitas įgyvendinimas yra į naudą didelei įmonei. Ši parinktis gali būti tinkama sistemoms, kurias naudoja daugelis darbuotojų, bet gali neturėti reikalavimų, nes pritaikyti neketinama. Bet vėlgi, tai yra didelis sprogimas galutiniams vartotojams ir didžiulis žingsnis po žingsnio darbas tai pačiai IT paslaugai (pavyzdžiui, atsiskaitymo ar prieigos sistemai).
• Pasirinktos programinės įrangos diegimo ypatybės (revizija ir kt.). Kartais įgyvendinimas iš pradžių vyksta etapais – su reikalavimų rinkimu, tobulėjimu, mokymu ir pan. Pavyzdžiui, CRM sistema jis visada įgyvendinamas palaipsniui, o jei kas nors žada „įdiegti ir konfigūruoti per 3 dienas ar net 3 valandas“ - prisiminkite šį straipsnį ir apeikite tokias paslaugas: diegimas ≠ diegimas.

Vėlgi, net žinant išvardintus parametrus, negalima neabejotinai eiti vienu ar kitu keliu. Įvertinkite savo įmonės aplinką – tai padės suprasti jėgų pusiausvyrą ir nuspręsti, kuris modelis (arba kai kurių jų elementų derinys) jums tinka.

Įtakos agentai: revoliucija arba evoliucija

Pirmas dalykas, į kurį turėtumėte atkreipti dėmesį, yra darbuotojai, kuriuos paveiks naujos programinės įrangos diegimas. Tiesą sakant, problema, kurią dabar svarstome, yra grynai žmogiškasis veiksnys, todėl negalima išvengti poveikio darbuotojams analizės. Kai kuriuos iš jų jau minėjome aukščiau.

• Įmonės vadovai nustato, kaip nauja programinė įranga bus visuotinai priimta. Ir čia ne vieta reklaminėms kalboms ir ugningoms kalboms – svarbu tiksliai parodyti pokyčių poreikį, perteikti mintį, kad tai tik šaunesnio ir patogesnio įrankio pasirinkimas, tas pats, kas pakeisti seną nešiojamąjį kompiuterį. Didžiausia vadovybės klaida tokioje situacijoje – nusiplauti rankas ir atsitraukti: jeigu vadovybei nereikia įmonės automatizavimo, kodėl tai turėtų dominti darbuotojus? Būkite procese.
• Skyrių vadovai (projektų vadovai) – tai tarpinė grandis, kuri turi dalyvauti visuose procesuose, valdyti nepasitenkinimą, rodyti valią ir dirbti per kiekvieną kolegų prieštaravimą, kokybiškai ir nuodugniai atlikti mokymus.
• IT paslauga (arba sistemos administratoriai) – iš pirmo žvilgsnio tai jūsų ankstyvieji paukščiai, labiausiai prisitaikantys ir prisitaikantys, bet... ne. Dažnai, ypač mažose ir vidutinėse įmonėse, sistemų administratoriai priešinasi bet kokiems IT infrastruktūros pokyčiams (stiprinimui), ir tai vyksta ne dėl kokio nors techninio pagrindimo, o dėl tingumo ir nenoro dirbti. Kas iš mūsų neieškojo būdų, kaip išvengti darbo? Bet tegul tai nepakenks visai įmonei.
• Galutiniai vartotojai, kaip taisyklė, nori dirbti gerai ir patogiai, viena vertus, ir, kaip ir bet kuris gyvas žmogus, bijo pokyčių. Pagrindinis argumentas jiems – sąžiningas ir paprastas: kodėl įvedame/keičiame, kokios yra kontrolės ribos, kaip bus vertinamas darbas, kas keisis ir kokios rizikos (beje, kiekvienas turėtų įvertinti rizikas) nors esame pardavėjai CRM sistemos, tačiau neįsipareigojame sakyti, kad viskas visada vyksta sklandžiai: bet kuriame verslo procese yra rizika).
• Įmonės „autoritetai“ yra partizanai, galintys daryti įtaką kitiems darbuotojams. Tai nebūtinai turi aukštas pareigas ar didelę patirtį turintis asmuo – dirbant su programine įranga „autoritetas“ gali būti pažengęs išmanantis žmogus, kuris, pavyzdžiui, dar kartą perskaitė Habrą ir pradės gąsdinti. visi apie tai, kaip viskas bus blogai. Jis gali net neturėti tikslo sužlugdyti įgyvendinimo ar perėjimo proceso – tik demonstravimas ir pasipriešinimo dvasia – ir darbuotojai juo patikės. Su tokiais darbuotojais reikia dirbti: paaiškinti, klausinėti, o ypač sunkiais atvejais užsiminti apie pasekmes.

Yra universalus receptas, kaip patikrinti, ar vartotojai tikrai ko nors bijo, ar jiems nepatiria grupinė paranoja, kuriai vadovauja sumanus vadovas. Paklauskite jų apie nepasitenkinimo priežastis, apie nerimą – jei tai nėra asmeninė patirtis ar nuomonė, ginčai prasidės po 3-4 patikslinančių klausimų.

Du svarbūs veiksniai norint sėkmingai įveikti „pasipriešinimo judėjimą“.

1. Suteikite mokymus: tiekėjo ir vidaus. Įsitikinkite, kad darbuotojai tikrai viską supranta, yra įvaldę ir, nepaisant savo pasirengimo lygio, yra pasirengę pradėti dirbti. Privalomas mokymo atributas yra spausdintos ir elektroninės instrukcijos (reglamentai) ir pati išsamiausia sistemos dokumentacija (save gerbiantys pardavėjai išleidžia kartu su programine įranga ir pateikia nemokamai).
2. Ieškokite rėmėjų ir rinkitės influencerius. Vidiniai ekspertai ir ankstyvieji naudotojai yra jūsų pagalbos sistema, kuri ugdo ir išsklaido abejones. Paprastai patys darbuotojai mielai padeda savo kolegoms ir supažindina juos su nauja programine įranga. Jūsų užduotis yra laikinai atleisti juos nuo darbo arba suteikti jiems tinkamą priedą už naują darbo krūvį.

Ką reikia atkreipti dėmesį?

1. Kiek pažengę darbuotojai yra paveikti pokyčių? (Santykinai kalbant, jei rytoj sugalvos naują buhalterinę programą, neduok Dieve kišti nosį į buhalteriją su moterimis virš 50 metų ir pasiūlyti pereiti nuo 1C, gyvas neišeisi).
2. Kiek tai turės įtakos darbo eigai? Vienas dalykas yra pakeisti pasiuntinį 100 žmonių įmonėje, kitas dalykas yra įdiegti naują CRM sistemą, kuri paremta pagrindiniais įmonės procesais (ir tai ne tik pardavimai, pvz. RegionSoft CRM diegimas vyresniuose leidimuose tai liečia gamybą, sandėlį, rinkodarą ir aukščiausius vadovus, kurie kartu su komanda kurs automatizuotus verslo procesus).
3. Ar buvo rengiami mokymai ir kokiu lygiu?

Vienintelis logiškas perėjimas korporatyvinio mąstymo sistemoje

Kas išgelbės naujos programinės įrangos perėjimą/diegimą?

Prieš pasakydami, kokie pagrindiniai punktai padės patogiai pereiti prie naujos programinės įrangos, atkreipkime jūsų dėmesį į vieną dalyką. Yra kažkas, ko tikrai nereikėtų daryti – nereikia daryti spaudimo darbuotojams ir jų „motyvuoti“ atimant priedus, administracines ir drausmines nuobaudas. Proceso tai nepagerins, bet pablogės darbuotojų požiūris: jei pastūmės, tada bus kontrolė; Jei jie jus verčia, tai reiškia, kad jie negerbia mūsų interesų; Jei jie tai primeta prievarta, vadinasi, jie nepasitiki mumis ir mūsų darbu. Todėl viską darome drausmingai, aiškiai, kompetentingai, bet be spaudimo ir bereikalingo prievartavimo.

Turite turėti išsamų veiksmų planą

Viso kito gali ir nebūti, bet planas turi būti. Be to, planas yra koreguojamas, atnaujinamas, aiškus ir neišvengiamas, tuo pačiu prieinamas aptarimui ir skaidrus visiems suinteresuotiems darbuotojams. Neįmanoma direktyviai perteikti, kad nuo 8 iki 10 ryto vyksta žygdarbis, o 16:00 karas su Anglija, svarbu pamatyti visą planą perspektyvoje.

Planas būtinai turi atspindėti darbuotojų, kurie bus galutiniai vartotojai, reikalavimus – taip kiekvienas darbuotojas tiksliai žinos, kokia pageidaujama funkcija ir kuriuo metu galės ja naudotis. Tuo pačiu metu perėjimo ar įgyvendinimo planas nėra kažkoks nekintantis monolitas, būtina palikti galimybę užbaigti planą ir pakeisti jo atributus (bet ne begalinio pakeitimų srauto ir naujų „norų“ pavidalu). o ne nuolatinio terminų keitimo forma).  

Kas turėtų būti plane?

1. Pagrindiniai perėjimo etapai (etapai) – ką reikia padaryti.
2. Išsamūs perėjimo taškai kiekvienam etapui – kaip tai turėtų būti padaryta.
3. Pagrindiniai taškai ir jų atsiskaitymas (valandų sutikrinimas) – kaip bus matuojama kas buvo atlikta ir kas turi būti kontrolės punkte.
4. Atsakingi žmonės yra žmonės, į kuriuos galite kreiptis ir užduoti klausimus.
5. Terminai yra kiekvieno etapo ir viso proceso pradžia ir pabaiga.
6. Paveikti procesai – kokie pokyčiai įvyks verslo procesuose, ką reikia keisti kartu su diegimu/perėjimu.
7. Galutinis įvertinimas – tai rodiklių, metrikų ar net subjektyvių vertinimų rinkinys, padėsiantis įvertinti įvykusį įgyvendinimą/perėjimą.
8. Veiklos pradžia yra tiksli data, kada visa įmonė prisijungs prie atnaujinto automatizuoto proceso ir dirbs naujoje sistemoje.

Esame susidūrę su įgyvendintojų pristatymais, kuriuose raudona linija yra patarimas: įgyvendinkite per jėgą, nekreipkite dėmesio į reakciją, nekalbėkite su darbuotojais. Esame prieš šį požiūrį ir štai kodėl.

Pažiūrėkite į paveikslėlį žemiau:

Nauja pelė, nauja klaviatūra, butas, mašina ir net darbas – malonūs, džiaugsmingi įvykiai, kai kurie net pasiekimai. O vartotojas eina į „Yandex“, kad sužinotų, kaip prie to priprasti ir prisitaikyti. Kaip įeiti į naują butą ir suprasti, kad jis tavo, pirmą kartą atsukti čiaupą, išgerti arbatos, pirmą kartą eiti miegoti. Kaip sėsti prie vairo ir susidraugauti su nauju automobiliu, tavo, bet kol kas svetima. Nauja programinė įranga darbo vietoje niekuo nesiskiria nuo aprašytų situacijų: darbuotojo darbas niekada nebus toks pat. Todėl diegkite, pritaikykite, augkite naudodami naują efektyvią programinę įrangą. Ir tai yra situacija, apie kurią galime pasakyti: paskubėk lėtai.

Šaltinis: www.habr.com