Tarkvarahüppest saab peagi ettevõtete väga levinud haigus. Iga pisiasja tõttu ühe tarkvara vahetamine teise vastu, tehnoloogialt tehnoloogiale hüppamine, elava äriga eksperimenteerimine on saamas normiks. Samal ajal algab kontoris tõeline kodusõda: moodustub vastupanuliikumine rakendamisele, partisanid teevad õõnestavat tööd uue süsteemi vastu, spioonid propageerivad uue tarkvaraga vaprat uut maailma, juhtimine soomusautost. korporatiivportaal edastab rahu, töö ja KPI-de teemasid. Revolutsioon lõpeb tavaliselt ühel pool täieliku ebaõnnestumisega.
Me teame rakendamisest peaaegu kõike, seega proovime välja mõelda, kuidas muuta revolutsioon evolutsiooniks ja muuta juurutamine võimalikult kasulikuks ja valutuks. Noh, või vähemalt me ütleme teile, millesse võite selle protsessi käigus sattuda.
Ideaalne visualiseerimine töötajate aktsepteerimisest uue tarkvaraga.Allikas - Yandex.Images
Väliskonsultandid alustaksid seda artiklit umbes nii: "Kui pakute oma töötajatele kvaliteetset tarkvara, mis võib parandada nende tööd ja avaldada kvalitatiivset mõju tulemuslikkusele, toimub uue programmi või süsteemi kasutuselevõtt loomulikult." Aga me oleme Venemaal, seega on kahtlaste ja sõjakate töötajate teema väga aktuaalne. Loomulik üleminek ei tööta isegi minimaalse tarkvaraga, nagu ettevõtte messenger või softphone.
Kust tulevad probleemi jalad?
Tänapäeval on igas ettevõttes installeeritud terve loomaaed tarkvara (võtame üldjuhtumi, sest IT-ettevõtetes on tarkvara hulk kahe- või kolmekordne ning kohanemisprobleemid kattuvad osaliselt ja on väga spetsiifilised): projektijuhtimissüsteemid, CRM/ERP, e-posti kliendid, kiirsõnumid, ettevõtte portaal jne. Ja see ei arvesta seda, et on ettevõtteid, kus isegi brauserist brauserile üleminekut viib läbi eranditult kogu meeskond (ja on ka meeskondi, mis põhinevad täielikult Internet Explorer Edge'il). Üldiselt võib meie artikkel olla kasulik mitmes olukorras:
- Toimub mõne ülesannete rühma esmase automatiseerimise protsess: juurutatakse esimene CRM/ERP, avatakse ettevõtte portaal, paigaldatakse tehnilise toe süsteem jne;
- üks tarkvara asendub millegipärast teisega: vananemine, uued nõuded, skaleerimine, tegevuse muutus jne;
- arenemise ja kasvu eesmärgil ehitatakse üles olemasoleva süsteemi mooduleid (näiteks avas ettevõte tootmise ja otsustas üle minna edasi maksimaalse funktsionaalsusega);
- Toimub suur liidese ja funktsionaalse tarkvara uuendus.
Muidugi on kaks esimest juhtumit oma ilmingutes palju teravamad ja tüüpilisemad, pöörake neile erilist tähelepanu.
Seega proovi enne meeskonnaga (kes juba kahtlustanud, et peagi toimuvad muudatused) koostööd alustad, mis on tarkvara muutmise tegelikud põhjused ja kas oled nõus, et muudatused on nii vajalikud.
- Vana programmiga on raske töötada: see on kallis, ebamugav, mittefunktsionaalne, ei vasta enam teie nõuetele, ei sobi teie skaalale jne. See on objektiivne vajadus.
- Müüja lõpetas süsteemi toetamise või tugi ja muudatused muutusid lõputuks heakskiidu ja raha äravooluks. Kui teie kulud on oluliselt kasvanud ja tulevikus lubavad need veelgi suureneda, pole midagi oodata, peate kärpima. Jah, uus süsteem maksab ka raha, kuid lõppkokkuvõttes maksab optimeerimine vähem kui selline tugi.
- Tarkvara muutmine on ühe inimese või töötajate rühma kapriis. Näiteks CTO soovib tagasipööramist ja teeb lobitööd uue kallima süsteemi juurutamiseks – seda juhtub suurtes ettevõtetes. Teine näide: projektijuht pooldab Asana muutmist Basecampiks, seejärel Basecampi Jiraks ja kompleksse Jira muutmist Wrike'iks. Sageli on selliste rände ainsaks motiiviks oma hõivatud töö näitamine ja oma positsiooni säilitamine. Sellistel juhtudel on vaja kindlaks määrata vajalikkuse aste, motiivid ja põhjendatus ning reeglina tugeva tahtega muudatustest keelduda.
Me räägime ühelt tarkvaralt teisele ülemineku põhjustest, mitte esmasest automatiseerimisest – ainult seetõttu, et automatiseerimine on a priori vajalik. Kui teie ettevõte teeb midagi käsitsi ja rutiinselt, kuid seda saab automatiseerida, raiskate lihtsalt aega, raha ja tõenäoliselt väärtuslikke ettevõtte andmeid. Automatiseerige see!
Kuidas ületada: suur hüpe või kükitav tiiger?
Maailmapraktikas on uuele tarkvarale üleminekuks ja sellega kohanemiseks kolm peamist strateegiat – ja need tunduvad meile väga sobivad, nii et ärgem leiutagem jalgratast uuesti.
Big Bang
„Suure Paugu” meetodil kasutuselevõtt on kõige raskem võimalik üleminek, kui määrate täpse kuupäeva ja viite läbi järsu migratsiooni, keelates vana tarkvara 100%.
Plusse
+ Kõik töötavad ühes süsteemis, pole vaja andmeid sünkroniseerida, töötajatel pole vaja kahte liidest korraga jälgida.
+ Lihtsus administraatori jaoks – üks migratsioon, üks ülesanne, üks süsteemitugi.
+ Kõik võimalikud muutused toimuvad ühel ajahetkel ja on märgatavad peaaegu kohe – pole vaja eraldada, mis ja mis proportsioonis mõjutas tootlikkust, arenduskiirust, müüki jne.
Miinused
— Töötab edukalt ainult lihtsa tarkvaraga: vestlused, ettevõtte portaal, kiirsõnumitoojad. Isegi e-post võib juba ebaõnnestuda, rääkimata projektijuhtimissüsteemidest, CRM/ERP-st ja muudest tõsistest süsteemidest.
— Plahvatuslik ränne suurest süsteemist teise tekitab paratamatult kaose.
Sellise uude töökeskkonda ülemineku puhul on kõige olulisem koolitus.
Paralleeljooks
Paralleelne kohandamine tarkvaraga on pehmem ja universaalsem üleminekumeetod, mille puhul määratakse ajavahemik, mille jooksul mõlemad süsteemid töötavad samaaegselt.
Plusse
+ Kasutajatel on piisavalt aega uue tarkvaraga harjumiseks, samas kiiresti vanas töötades, paralleelide leidmiseks ja liidesega suhtlemise uue loogika mõistmiseks.
+ Ootamatute probleemide korral jätkavad töötajad tööd vanas süsteemis.
+ Kasutajakoolitus on vähem range ja üldiselt odavam.
+ Töötajatelt praktiliselt puudub negatiivne reaktsioon - ju ei võetud neilt ära tavalisi tööriistu ega asjade tegemise viisi (kui automatiseerimine toimub esimest korda).
Miinused
— Haldusprobleemid: mõlema süsteemi tugi, andmete sünkroonimine, turvahaldus kahes rakenduses korraga.
— Üleminekuprotsess venib lõputult – töötajad mõistavad, et neil on jäänud peaaegu igavik ja nad saavad tuttava liidese kasutusaega veel veidi pikendada.
- Kasutaja segadus – need kaks liidest on segased ja põhjustavad töö- ja andmevigu.
- Raha. Maksate mõlema süsteemi eest.
Järkjärguline lapsendamine
Samm-sammuline kohandamine on pehmeim võimalus uuele tarkvarale üleminekuks. Üleminek toimub funktsionaalselt, kindlaksmääratud ajavahemike jooksul ja osakondade kaupa (näiteks alates 1. juunist lisame uusi kliente ainult uude CRM süsteemi, alates 20. juunist teostame tehinguid uues süsteemis, kuni 1. augustini kanname üle kalendrid ja juhtudel ning 30. septembriks lõpetame migratsiooni on väga umbkaudne kirjeldus, kuid üldiselt selge).
Plusse
+ Organiseeritud üleminek, jaotatud koormus administraatorite ja siseekspertide vahel.
+ Rohkem läbimõeldud ja süvendatud õppimist.
+ Muutusele vastupanu pole, sest see toimub võimalikult õrnalt.
Miinused - ligikaudu sama, mis paralleelse ülemineku puhul.
Nii et nüüd lihtsalt järkjärguline üleminek?
Loogiline küsimus, nõustute. Miks on vaja täiendavat tüli, kui saate teha ajakava ja tegutseda selge plaani järgi? Tegelikult pole kõik nii lihtne.
- Tarkvara keerukus: kui me räägime keerulisest tarkvarast (näiteks ), siis on sobivam faasi kohandamine. Kui tarkvara on lihtne (messenger, ettevõtte portaal), siis sobib mudel, kui teatate kuupäeva ja keelate vana tarkvara määratud päeval (kui veab, on töötajatel aega kogu vajalik teave välja tõmmata , ja kui te ei looda õnnele, peate võimaluse korral esitama vajalikud andmed vanast süsteemist uude automaatselt importima).
- Riskiaste ettevõtte jaoks: mida riskantsem on juurutamine, seda aeglasem see peaks olema. Teisest küljest on risk ka viivitus: näiteks lähete ühelt CRM-süsteemilt teisele üle ja olete üleminekuperioodil sunnitud maksma mõlema eest, suurendades sellega uue süsteemi juurutamise kulusid ja kulu, mis tähendab, et tasuvusaeg pikeneb.
- Töötajate arv: Big Bang ei sobi kindlasti, kui on vaja skaleerida ja seadistada paljusid kasutajaprofiile. Kuigi on juhtumeid, kus ülikiire juurutamine on suurele ettevõttele kasuks. See valik võib sobida süsteemidele, mida kasutavad paljud töötajad, kuid neil ei pruugi olla nõudeid, kuna kohandamine pole ette nähtud. Aga see on jällegi suur pauk lõppkasutajatele ja tohutu samm-sammult töö sama IT-teenuse (näiteks arveldus- või juurdepääsusüsteemi) jaoks.
- Valitud tarkvara juurutamise tunnused (redaktsioon jne). Mõnikord toimub juurutamine esialgu etapiviisiliselt – koos nõuete kogumise, täpsustamise, koolitusega jne. Näiteks, seda rakendatakse alati järk-järgult ja kui keegi lubab teile "rakendamine ja konfigureerimine 3 päeva või isegi 3 tunni jooksul" - pidage seda artiklit meeles ja jätke sellistest teenustest mööda: installimine ≠ juurutamine.
Jällegi, isegi teades loetletud parameetreid, ei saa kindlasti ühte või teist teed minna. Hinnake oma ettevõtte keskkonda – see aitab teil nii jõudude vahekorda mõista kui ka otsustada, milline mudel (või mõne selle elemendi kombinatsioon) teile sobib.
Mõjuagendid: revolutsioon või evolutsioon
Esimene asi, millele peaksite tähelepanu pöörama, on töötajad, keda uue tarkvara juurutamine mõjutab. Tegelikult on probleem, mida me praegu kaalume, puhtalt inimfaktor, seega ei saa vältida töötajatele avalduva mõju analüüsimist. Oleme mõnda neist eespool juba maininud.
- Ettevõtte juhid määravad, kuidas uus tarkvara üldiselt aktsepteeritakse. Ja see ei ole koht reklaamkõnedeks ja tulihingelisteks kõnedeks – oluline on täpselt näidata muutuste vajadust, anda edasi mõte, et see on lihtsalt lahedama ja mugavama tööriista valimine, sama mis vana sülearvuti väljavahetamine. Juhtkonna suurim viga sellises olukorras on käte pesemine ja enda tagasitõmbumine: kui juhtkond ei vaja ettevõtte automatiseerimist, siis miks peaks see töötajatele huvi pakkuma? Ole protsessis.
- Osakonnajuhatajad (projektijuhid) on vahelüli, kes peab osalema kõikides protsessides, juhtima rahulolematust, näitama üles tahet ja töötama läbi iga kolleegide vastulause ning läbi viima kvaliteetset ja põhjalikku koolitust.
- IT-teenus (või süsteemiadministraatorid) – esmapilgul on need teie varajased, kõige kohanemisvõimelisemad ja kohanemisvõimelisemad, aga... ei. Sageli seisavad süsteemiadministraatorid eriti väikese ja keskmise suurusega ettevõtetes vastu igasugustele IT-taristu muudatustele (tugevdamisele) ja see ei tulene mitte mingist tehnilisest põhjendusest, vaid laiskusest ja soovimatusest töötada. Kes meist poleks otsinud võimalusi töö tegemisest hoidumiseks? Kuid see ei tohi olla kogu ettevõtte kahjuks.
- Lõpptarbijad tahavad reeglina ühest küljest hästi ja mugavalt töötada ning kardavad nagu iga elav inimene muutusi. Peamine argument nende jaoks on aus ja lihtne: miks me juurutame/muutame, millised on kontrolli piirid, kuidas tööd hinnatakse, mis muutub ja millised on riskid (muide, riske peaks hindama igaüks kuigi me oleme müüjad , kuid me ei kohusta väitma, et kõik läheb alati ladusalt: igas ettevõttesiseses protsessis on riske).
- Ettevõttesisesed "autoriteedid" on parteilised, kes saavad mõjutada teisi töötajaid. See ei pruugi olla kõrge ametikoha või suurte kogemustega inimene - tarkvaraga töötamise puhul võib "autoriteediks" olla edasijõudnud teadja, kes on näiteks Habri uuesti läbi lugenud ja hakkab hirmutama. kõik sellest, kui halvaks kõik läheb. Tal ei pruugi olla isegi eesmärki rikkuda juurutus- või üleminekuprotsessi – lihtsalt eputamine ja vastupanuvaim – ning töötajad usuvad teda. Peate selliste töötajatega koostööd tegema: selgitama, küsima ja eriti rasketel juhtudel vihjama tagajärgedele.
On olemas universaalne retsept, kuidas kontrollida, kas kasutajad tõesti kardavad midagi või on neil grupiparanoia, mida juhib nutikas juht. Küsige neilt rahulolematuse põhjuste, murede kohta – kui see pole isiklik kogemus või arvamus, hakkavad vaidlused peale 3-4 täpsustava küsimuse peale tulema.
Kaks olulist tegurit “vastupanuliikumise” edukaks ületamiseks.
- Pakkuge koolitust: müüja ja sisemine. Veendu, et töötajad tõesti kõigest aru saavad, valdavad ja olenemata väljaõppe tasemest on valmis tööle asuma. Koolituse kohustuslik atribuut on trükitud ja elektroonilised juhised (eeskirjad) ning süsteemi kõige täielikum dokumentatsioon (enesest lugupidavad müüjad vabastavad selle koos tarkvaraga ja pakuvad tasuta).
- Otsige toetajaid ja valige mõjutajad. Siseeksperdid ja varajased kasutajad on teie tugisüsteem, mis nii harib kui hajutab kahtlusi. Reeglina on töötajatel endil hea meel oma kolleege aidata ja uut tarkvara tutvustada. Sinu ülesanne on nad ajutiselt töölt vabastada või anda neile uue töökoormuse eest korralik lisatasu.
Mida peate tähelepanu pöörama?
- Kui edasijõudnud on muudatused töötajaid? (Suhteliselt öeldes, kui homme leiutavad uue raamatupidamisprogrammi, siis hoidku jumal üle 50-aastaste daamidega oma nina raamatupidamisse pista ja 1C-st üleminekut soovitada, siis elusalt välja ei tule).
- Kui palju see töövooge mõjutab? Üks asi on sõnumitoojat vahetada 100-liikmelises ettevõttes, teine asi on juurutada uus CRM-süsteem, mis põhineb ettevõtte võtmeprotsessidel (ja see pole näiteks ainult müük, vanemates väljaannetes mõjutab see tootmist, ladu, turundust ja tippjuhte, kes koos meeskonnaga ehitavad automatiseeritud äriprotsesse).
- Koolitus toimus ja mis tasemel?
Ainus loogiline üleminek ettevõtte mõtlemise süsteemis
Mis päästab uue tarkvara ülemineku/juurutamise?
Enne kui räägime teile, millised põhipunktid aitavad teil mugavalt uuele tarkvarale üle minna, juhime teie tähelepanu ühele punktile. Midagi kindlasti ei tohiks teha - pole vaja töötajaid survestada ja neid "motiveerida" preemiatest, haldus- ja distsiplinaarkaristustest ilmajätmisega. See ei tee protsessi paremaks, aga töötajate suhtumine halveneb: kui surutakse, siis on kontroll; Kui nad sind sunnivad, tähendab see, et nad ei austa meie huve; Kui nad seda jõuga peale suruvad, tähendab see, et nad ei usalda meid ja meie tööd. Seetõttu teeme kõike distsiplineeritult, selgelt, pädevalt, kuid ilma surve ja tarbetu sundimiseta.
Teil peab olema üksikasjalik tegevuskava
Kõike muud ei pruugi olla, aga plaan peab olema. Pealegi on plaan kohandatav, ajakohastatud, selge ja vältimatu, samal ajal arutlemiseks kättesaadav ja läbipaistev kõigile huvitatud töötajatele. Direktiivselt ei saa kommunikeerida, et kell 8-10 on vägitegu ja kell 16:00 sõda Inglismaaga, oluline on näha kogu plaani perspektiivis.
Plaan peab tingimata kajastama nende töötajate nõudmisi, kellest saavad lõppkasutajad – nii saab iga töötaja täpselt teada, millist funktsiooni ja mis ajal ta soovib kasutada. Samas ei ole ülemineku- või teostusplaan mingi muutumatu monoliit, tuleb jätta võimalus plaani lõplikuks vormistamiseks ja selle atribuutide muutmiseks (kuid mitte lõputu toimetamiste ja uute “soovide” kujul) ja mitte tähtaegade pideva nihutamise näol).
Mis peaks plaanis olema?
- Peamised ülemineku verstapostid (etapid) - mida tuleb teha.
- Iga etapi üksikasjalikud üleminekupunktid – kuidas seda teha.
- Võtmepunktid ja nende kohta aruandlus (tundide vastavusseviimine) - kuidas tehtut mõõdetakse ja kes peaks kontrollpunktis olema.
- Vastutustundlikud inimesed on inimesed, kelle poole saate pöörduda ja kellelt küsimusi esitada.
- Tähtajad on iga etapi ja kogu protsessi kui terviku algus ja lõpp.
- Mõjutatud protsessid – millised muutused toimuvad äriprotsessides, mida on vaja muuta koos juurutamise/üleminekuga.
- Lõplik hinnang on näitajate, mõõdikute või isegi subjektiivsete hinnangute kogum, mis aitab hinnata toimunud rakendamist/üleminekut.
- Tegutsemise algus on täpne kuupäev, mil kogu ettevõte liitub uuenenud automatiseeritud protsessiga ja töötab uues süsteemis.
Oleme kohanud rakendajate esitlusi, milles punane joon on nõuanne: rakenda jõuga, ignoreeri reaktsiooni, ära räägi töötajatega. Oleme selle lähenemisviisi vastu ja siin on põhjus.
Vaata allolevat pilti:
Uus hiir, uus klaviatuur, korter, auto ja isegi töö on meeldivad, rõõmsad sündmused, mõned neist on isegi saavutused. Ja kasutaja läheb Yandexi, et uurida, kuidas sellega harjuda ja kohaneda. Kuidas siseneda uude korterisse ja mõista, et see on sinu, keera kraan esimest korda lahti, joo teed, mine esimest korda magama. Kuidas rooli istuda ja uue autoga sõbruneda, sinu, aga seni võõras. Uus tarkvara töökohal ei erine kirjeldatud olukordadest: töötaja töö ei ole kunagi endine. Seetõttu rakendage, kohandage, kasvage koos uue tõhusa tarkvaraga. Ja see on olukord, mille kohta võime öelda: kiirustage aeglaselt.
Allikas: www.habr.com