A szoftveres ugrás hamarosan a cégek igen gyakori betegsége lesz. Egyik szoftvert a másikra cserélni minden apróság miatt, a technológiáról a technológiára ugrálni, az élő üzlettel való kísérletezés szokássá válik. Ezzel párhuzamosan igazi polgárháború veszi kezdetét az irodában: megalakul a végrehajtással szembeni ellenállás mozgalom, a partizánok felforgató munkát végeznek az új rendszer ellen, a kémek új szoftverekkel hirdetik a bátor új világot, a vezetés a páncélautóból. a vállalati portál a békéről, a munkáról, a KPI-kről sugároz. A forradalom általában az egyik oldalon teljes kudarccal végződik.
Szinte mindent tudunk a megvalósításról, ezért próbáljuk meg kitalálni, hogyan lehet egy forradalmat evolúcióvá változtatni, és a megvalósítást a lehető leghasznosabbá és fájdalommentessé tenni. Nos, vagy legalább eláruljuk, mibe keveredhet a folyamat során.
Ideális megjelenítés az alkalmazottak új szoftverek elfogadásáról Forrás - Yandex.Images
Külföldi tanácsadók ezt a cikket a következőképpen kezdenék: „Ha minőségi szoftvert kínál az alkalmazottainak, amelyek javíthatják munkájukat, minőségi hatással vannak a teljesítményre, akkor egy új program vagy rendszer bevezetése magától értetődik.” De Oroszországban vagyunk, így a gyanús és harcias alkalmazottak kérdése nagyon aktuális. A természetes átmenet nem fog működni, még minimális szoftverrel sem, például vállalati üzenetküldővel vagy szoftveres telefonnal.
Honnan ered a probléma lába?
Ma már minden cégnél egy egész állatkertnyi szoftver van telepítve (az általános esetet vesszük, mert az informatikai cégeknél a szoftver mennyisége kétszeres vagy háromszoros, az adaptációs problémák pedig részben átfedik egymást és nagyon specifikusak): projektmenedzsment rendszerek, CRM/ERP, e-mail kliensek, azonnali üzenetküldők, vállalati portál stb. És ez nem számít bele, hogy vannak olyan cégek, amelyeknél még a böngészőről böngészőre való átállást is kivétel nélkül a teljes csapat végzi (és vannak teljesen Internet Explorer Edge-re épülő csapatok is). Általánosságban elmondható, hogy számos olyan helyzet van, amelyekben cikkünk hasznos lehet:
- egy bizonyos feladatcsoport elsődleges automatizálásának folyamata zajlik: az első CRM/ERP bevezetése, vállalati portál nyílik, műszaki támogatási rendszer telepítése stb.;
- az egyik szoftvert valamilyen okból kicserélik egy másikra: elavulás, új követelmények, méretezés, tevékenységváltás stb.;
- a meglévő rendszer moduljait építik fel fejlesztési és növekedési célokra (például egy cég termelést nyitott és úgy döntött, hogy on maximális funkcionalitással);
- Jelentős felület- és funkcionális szoftverfrissítés zajlik.
Természetesen az első két eset sokkal kiélezettebb és jellemzőbb a megnyilvánulásaiban, ezekre fordítsanak különös figyelmet.
Tehát, mielőtt elkezdené a munkát a csapattal (akik már sejtették, hogy hamarosan változások lesznek), próbálja megérteni, mik a szoftverváltás valódi okai, és egyetért-e azzal, hogy a változtatások annyira szükségesek.
- A régi programmal nehéz dolgozni: drága, kényelmetlen, nem működőképes, már nem felel meg az igényeinek, nem megfelelő a mérlegéhez stb. Ez objektív szükségszerűség.
- Az eladó abbahagyta a rendszer támogatását, vagy a támogatás és a módosítások végtelen számú jóváhagyássá és pénzkidobássá váltak. Ha jelentősen megnőttek a költségei, és a jövőben még nagyobb növekedést ígérnek, akkor nincs mire várni, csökkenteni kell. Igen, egy új rendszer is pénzbe kerül, de az optimalizálás végül kevesebbe fog kerülni, mint egy ilyen támogatás.
- A szoftverváltás egy személy vagy alkalmazotti csoport szeszélye. Például a CTO visszalépést akar, és egy új, drágább rendszer bevezetéséért lobbizik – ez a nagy cégeknél előfordul. Egy másik példa: egy projektmenedzser támogatja az Asana megváltoztatását Basecamp-re, majd a Basecamp-et Jira-ra, a komplex Jira-t pedig Wrike-ra. Gyakran az ilyen migráció egyetlen indítéka az, hogy megmutassák elfoglalt munkájukat és megtartsák pozíciójukat. Ilyen esetekben meg kell határozni a szükségesség mértékét, az indítékokat és az indokoltságot, és általában határozott akarattal kell megtagadni a változtatásokat.
Az egyik szoftverről a másikra való átállás okairól beszélünk, és nem az elsődleges automatizálásról - csak azért, mert az automatizálás eleve szükséges. Ha az Ön cége manuálisan és rutinszerűen csinál valamit, de automatizálható, akkor egyszerűen időt, pénzt és valószínűleg értékes vállalati adatokat pazarol. Automatizáld!
Hogyan léphetsz át: a nagy ugráson vagy a guggoló tigrisen?
A világgyakorlatban három fő stratégia létezik az új szoftverre való váltásra és az ahhoz való alkalmazkodásra – és ezek nekünk nagyon megfelelőnek tűnnek, úgyhogy ne találjuk fel újra a kereket.
Big Bang
A „Big Bang” módszerrel történő átvétel a lehető legnehezebb átmenet, amikor pontos dátumot állít be és éles migrációt hajt végre, 100%-osan letiltva a régi szoftvert.
Érvek
+ Mindenki egy rendszerben dolgozik, nincs szükség adatszinkronizálásra, a dolgozóknak nem kell egyszerre két felületet figyelniük.
+ Egyszerűség a rendszergazda számára – egy migráció, egy feladat, egy rendszertámogatás.
+ Minden lehetséges változás egy időpontban történik, és szinte azonnal észrevehető - nem kell elkülöníteni, hogy mi és milyen arányban befolyásolta a termelékenységet, a fejlődés sebességét, az értékesítést stb.
Hátrányok
— Csak egyszerű szoftverekkel működik sikeresen: chat, vállalati portál, azonnali üzenetküldő. Már az e-mail is megbukhat, nem beszélve a projektmenedzsment-rendszerekről, a CRM/ERP-ről és a többi komoly rendszerről.
— A robbanásszerű migráció egy nagy rendszerből a másikba elkerülhetetlenül káoszt okoz.
Az új munkakörnyezetbe való ilyen típusú átmenethez a legfontosabb a képzés.
Párhuzamos futás
A szoftverhez való párhuzamos adaptáció egy puhább és univerzálisabb átmeneti módszer, melyben be van állítva egy időtartam, amely alatt mindkét rendszer egyszerre fog működni.
Érvek
+ A felhasználóknak elegendő idejük van hozzászokni az új szoftverhez, miközben gyorsan dolgoznak a régiben, megtalálják a párhuzamokat, és megértsék az interakció új logikáját a felülettel.
+ Hirtelen problémák esetén a dolgozók a régi rendszerben dolgoznak tovább.
+ A felhasználói képzés kevésbé szigorú és általában olcsóbb.
+ Gyakorlatilag nincs negatív reakció az alkalmazottak részéről - elvégre nem fosztották meg őket a szokásos eszközeiktől vagy a dolgok módjától (ha az automatizálás először történik meg).
Hátrányok
— Adminisztrációs problémák: mindkét rendszer támogatása, adatszinkronizálás, biztonságkezelés egyszerre két alkalmazásban.
— Az átállási folyamat végtelenül elhúzódik – a dolgozók ráébrednek, hogy már majdnem egy örökkévalóság van hátra, és egy kicsit tovább bővíthetik a megszokott felület használatát.
- Felhasználói zavar - A két interfész zavaros, működési és adathibákat okoz.
- Pénz. Mindkét rendszerért fizetni kell.
Fázisos örökbefogadás
A lépésről lépésre történő adaptáció a legpuhább lehetőség az új szoftverre való váltáshoz. Az átállás funkcionálisan, meghatározott időn belül és részlegenként történik (például június 1-jétől csak az új CRM rendszerbe veszünk fel új ügyfeleket, június 20-tól az új rendszerben bonyolítjuk le a tranzakciókat, augusztus 1-ig a naptárak átvitele és esetek, és szeptember 30-ig befejezzük a migrációt nagyon durva leírás, de általában egyértelmű).
Érvek
+ Szervezett átállás, megosztott terhelés a rendszergazdák és a belső szakértők között.
+ Átgondoltabb és elmélyültebb tanulás.
+ Nincs ellenállás a változással szemben, mert az a lehető legkíméletesebben történik.
Hátrányok - körülbelül ugyanaz, mint a párhuzamos átmenetnél.
Akkor most csak fokozatos átállás?
Logikus kérdés, egyetértesz. Miért kell több gondot okozni, ha ütemtervet készíthet, és világos terv szerint cselekedhet? Valójában nem minden olyan egyszerű.
- Szoftver komplexitás: ha összetett szoftverekről beszélünk (pl. ), akkor a fázisadaptáció alkalmasabb. Ha a szoftver egyszerű (messenger, vállalati portál), akkor a megfelelő modell az, amikor bejelenti a dátumot, és a megbeszélt napon letiltja a régi szoftvert (szerencsés esetben az alkalmazottaknak lesz idejük elővenni az összes szükséges információt , és ha nem számít a szerencsére, akkor a szükséges adatok automatikus importálását a régi rendszerből az újba kell megadnia, ha technikailag lehetséges).
- A vállalat kockázatának mértéke: minél kockázatosabb a megvalósítás, annál lassabbnak kell lennie. Másrészt a késés is kockázatot jelent: például egyik CRM-rendszerről a másikra vált, és az átmeneti időszakban mindkettőt fizetni kényszerül, ezzel növelve az új rendszer bevezetésének költségeit és költségeit, ami azt jelenti, hogy a megtérülési idő meghosszabbodik.
- Alkalmazottak száma: A Big Bang határozottan nem megfelelő, ha sok felhasználói profilt kell méretezni és konfigurálni. Bár vannak esetek, amikor az ultragyors megvalósítás előnyt jelent egy nagyvállalat számára. Ez a lehetőség alkalmas lehet sok alkalmazott által használt rendszerekhez, de előfordulhat, hogy nincsenek követelmények, mert a testreszabás nem célja. De ez ismét egy nagy durranás a végfelhasználók számára, és egy hatalmas lépésről lépésre végzett munka ugyanazon IT-szolgáltatás (például számlázási vagy hozzáférési rendszer) esetében.
- A kiválasztott szoftver megvalósításának jellemzői (revízió stb.). Néha a megvalósítás kezdetben szakaszról-szakaszra történik - követelmények összegyűjtésével, finomításával, képzésével stb. Például, mindig fokozatosan kerül bevezetésre, és ha valaki azt ígéri, hogy „3 napon vagy akár 3 órán belül megtörténik az implementáció és a konfiguráció” - emlékezzen erre a cikkre, és kerülje el az ilyen szolgáltatásokat: telepítés ≠ megvalósítás.
Ismétlem, még a felsorolt paraméterek ismeretében sem lehet határozottan egyik vagy másik utat választani. Felmérheti vállalati környezetét – ez segít megérteni az erőviszonyokat és eldönteni, hogy melyik modell (vagy egyes elemeinek kombinációja) a megfelelő az Ön számára.
Befolyásolók: forradalom vagy evolúció
Az első dolog, amire figyelni kell, az az alkalmazottak, akiket érint az új szoftver bevezetése. Valójában az általunk vizsgált probléma tisztán emberi tényező, így nem kerülhető el a munkavállalókra gyakorolt hatás elemzése. Ezek közül néhányat fentebb már említettünk.
- A vállalatvezetők határozzák meg, hogy az új szoftvert hogyan fogadják el általánosan. És ez nem a promóciós beszédek és a tüzes beszédek helye - fontos, hogy pontosan mutassuk meg a változtatás szükségességét, közvetítsük azt a gondolatot, hogy ez csak egy menőbb és kényelmesebb eszköz kiválasztása, ugyanaz, mint egy régi laptop cseréje. A vezetőség legnagyobb hibája egy ilyen helyzetben az, hogy kezet mos és visszavonul: ha a vezetésnek nincs szüksége cégautomatizálásra, miért érdekelné az alkalmazottakat? Legyen benne a folyamatban.
- Az osztályvezetők (projektmenedzserek) egy köztes láncszem, akiknek minden folyamatban részt kell venniük, kezelniük kell az elégedetlenségeket, ki kell mutatniuk akaratukat és dolgozniuk kell a kollégák minden kifogásán, valamint magas színvonalú és mélyreható képzést kell tartaniuk.
- Informatikai szolgáltatás (vagy rendszergazdák) – első pillantásra ezek az Ön korai madarai, a leginkább alkalmazkodóképesek és alkalmazkodóbbak, de... nem. Gyakran – különösen a kis- és középvállalatoknál – a rendszergazdák ellenzik az informatikai infrastruktúra bármilyen változtatását (megerősítését), és ennek nem a technikai indoklása, hanem a lustaság és a munka iránti kedvetlenség az oka. Ki ne kereste volna közülünk a módját, hogy elkerülje a munkát? De ez ne legyen az egész cég rovására.
- A végfelhasználók általában egyrészt jól és kényelmesen akarnak dolgozni, és mint minden élő ember, félnek a változástól. A fő érv számukra őszinte és egyszerű: miért vezetünk be/változtatunk, mik az ellenőrzés határai, hogyan értékelik a munkát, mi változik és mik a kockázatok (egyébként a kockázatokat mindenki értékelje - noha árusok vagyunk , de nem vállaljuk azt, hogy minden mindig simán megy: egy vállalkozáson belül minden folyamatban vannak kockázatok).
- A vállalaton belüli „hatóságok” olyan partizánok, akik befolyásolhatják a többi alkalmazottat. Ez nem feltétlenül magas beosztású vagy széleskörű tapasztalattal rendelkező személy - szoftverrel végzett munka esetén a „hatóság” egy haladó, mindent tudó lehet, aki például újraolvasta a Habr-t, és elkezdi megfélemlíteni. mindenki arról, milyen rossz lesz minden. Lehet, hogy nem is az a célja, hogy tönkretegye a bevezetési vagy átállási folyamatot – csak a fitogtatás és az ellenállás szelleme –, és az alkalmazottak hinni fognak neki. Az ilyen alkalmazottakkal kell dolgoznia: magyarázza el, kérdezze meg, és különösen nehéz esetekben utaljon a következményekre.
Van egy univerzális recept annak ellenőrzésére, hogy a felhasználók valóban félnek-e valamitől, vagy van-e csoportparanoiájuk, amit egy hozzáértő vezető vezet. Kérdezd meg őket az elégedetlenség okairól, az aggodalmakról – ha ez nem személyes tapasztalat vagy vélemény, akkor 3-4 tisztázó kérdés után elkezdenek áradni a viták.
Két fontos tényező az „ellenállási mozgalom” sikeres leküzdéséhez.
- Képzés biztosítása: szállítói és belső. Győződjön meg arról, hogy az alkalmazottak valóban mindent értenek, elsajátították, és képzettségüktől függetlenül készen állnak a munkakezdésre. A képzés kötelező attribútuma a nyomtatott és elektronikus utasítások (szabályzatok) és a rendszer legteljesebb dokumentációja (az önbecsülő gyártók a szoftverrel együtt kiadják és ingyenesen biztosítják).
- Keress támogatókat és válassz befolyásolókat. A belső szakértők és a korai alkalmazók jelentik az Ön támogatási rendszerét, amely egyszerre oktat és eloszlatja a kételyeket. Általában maguk az alkalmazottak is szívesen segítenek kollégáiknak és ismertetik meg őket az új szoftverekkel. Az Ön feladata, hogy ideiglenesen felmentse őket a munkájuk alól, vagy tisztességes bónuszt adjon nekik az új munkateherhez.
Mit kell figyelni?
- Mennyire fejlettek a munkavállalók a változások? (Viszonylag szólva, ha holnap kitalálnak egy új könyvelő programot, ne adj isten, hogy 50 év feletti hölgyekkel bedugja az orrát a könyvelési osztályra, és javasoljon átállást az 1C-ből, akkor nem jön ki élve).
- Mennyire lesz hatással a munkafolyamatokra? Egy dolog a messengert cserélni egy 100 fős cégnél, másik dolog egy új CRM rendszer bevezetése, ami a cég kulcsfolyamataira épül (és ez nem csak az értékesítés pl. Senior kiadásokban érinti a termelést, a raktározást, a marketinget és a felsővezetőket, akik a csapattal együtt automatizált üzleti folyamatokat építenek ki).
- Megtörtént a képzés és milyen szinten?
Az egyetlen logikus átmenet a vállalati gondolkodás rendszerében
Mi mentheti meg az új szoftverek átállását/bevezetését?
Mielőtt elmondanánk, melyek azok a kulcsfontosságú pontok, amelyek segítenek kényelmesen áttérni az új szoftverre, egy pontra hívjuk fel a figyelmét. Van, amit határozottan nem szabad megtenni – nem kell nyomást gyakorolni az alkalmazottakra és „motiválni” őket bónuszoktól, adminisztratív és fegyelmi szankcióktól való megfosztással. Ettől nem lesz jobb a folyamat, de romlik a dolgozók hozzáállása: ha nyomják, akkor lesz kontroll; Ha kényszerítenek, az azt jelenti, hogy nem tartják tiszteletben az érdekeinket; Ha erőszakosan rákényszerítik, az azt jelenti, hogy nem bíznak bennünk és a munkánkban. Ezért mindent fegyelmezetten, világosan, hozzáértő módon, de nyomás és felesleges erőltetés nélkül teszünk.
Részletes cselekvési tervvel kell rendelkeznie
Lehet, hogy minden más nem létezik, de tervnek kell lennie. Ezenkívül a terv módosítható, frissíthető, világos és elkerülhetetlen, ugyanakkor megvitatásra is hozzáférhető és átlátható minden érdeklődő munkavállaló számára. Lehetetlen direkt módon közölni, hogy reggel 8-tól délelőtt 10-ig bravúr, 16:00-kor pedig háború van Angliával, fontos, hogy az egész tervet távlatban lássuk.
A tervnek feltétlenül tükröznie kell a végfelhasználók igényeit - így minden alkalmazott pontosan tudja, hogy milyen funkciót kíván és mikor tudja használni. Ugyanakkor az átállási vagy megvalósítási terv nem valamiféle megváltoztathatatlan monolit, meg kell hagyni a terv véglegesítésének és attribútumainak megváltoztatásának lehetőségét (de nem a szerkesztések és az új „kívánságok” végtelen folyamaként) és nem a határidők állandó eltolódása formájában).
Mi legyen a tervben?
- A fő átmeneti mérföldkövek (szakaszok) - mit kell tenni.
- Részletes átmeneti pontok minden szakaszhoz – hogyan kell ezt megtenni.
- Kulcspontok és azokról való jelentés (óraegyeztetés) – hogyan mérik az elvégzetteket, és kinek kell az ellenőrzési ponton lennie.
- A felelős emberek azok, akikhez fordulhat, és kérdéseket tehet fel.
- A határidők az egyes szakaszok kezdete és vége, valamint az egész folyamat egésze.
- Érintett folyamatok – milyen változások következnek be az üzleti folyamatokban, mit kell változtatni a bevezetéssel/átállással együtt.
- A végső értékelés olyan mutatók, mérőszámok vagy akár szubjektív értékelések összessége, amelyek segítik a megtörtént megvalósítás/átmenet értékelését.
- A működés kezdete az a pontos dátum, amikor a teljes vállalat csatlakozik a frissített automatizált folyamathoz és az új rendszerben dolgozik.
Találkoztunk már megvalósítók prezentációival, amelyekben a piros vonal a tanács: hajtson végre erőszakkal, hagyja figyelmen kívül a reakciót, ne beszéljen az alkalmazottakkal. Ellenezzük ezt a megközelítést, és itt van az ok.
Nézd meg az alábbi képet:
Egy új egér, egy új billentyűzet, egy lakás, egy autó, de még egy munkahely is kellemes, örömteli események, némelyik akár eredmény is. A felhasználó pedig felkeresi a Yandexet, hogy megtudja, hogyan lehet hozzászokni és alkalmazkodni. Hogyan lépj be egy új lakásba és értsd meg, hogy a tiéd, először nyissa ki a csapot, igyon teát, feküdjön le először. Hogyan ülj volán mögé és barátkozz meg egy új autóval, a tied, de eddig idegen. Az új szoftverek a munkahelyen nem különböznek a leírt helyzetektől: a munkavállaló munkája soha nem lesz ugyanaz. Ezért valósítson meg, alkalmazkodjon, növekedjen új, hatékony szoftverekkel. És ez egy olyan helyzet, amelyre azt mondhatjuk: lassan siess.
Forrás: will.com