Sagteware-sprong sal binnekort 'n baie algemene siekte van maatskappye word. Om een sagteware vir 'n ander te verander as gevolg van elke klein dingetjie, om van tegnologie na tegnologie te spring, om met 'n lewendige besigheid te eksperimenteer, word die norm. Terselfdertyd begin 'n ware burgeroorlog in die kantoor: 'n beweging van weerstand teen implementering word gevorm, partisane voer ondermynende werk teen die nuwe stelsel uit, spioene bevorder 'n dapper nuwe wêreld met nuwe sagteware, bestuur vanuit die gepantserde motor van die korporatiewe portaal saai uit oor vrede, arbeid, KPI's. ’n Rewolusie eindig gewoonlik in algehele mislukking aan die een kant.
Ons weet byna alles oor implementering, so kom ons probeer uitvind hoe om 'n revolusie in 'n evolusie te omskep en implementering so nuttig en pynloos moontlik te maak. Wel, of ten minste sal ons jou vertel waarby jy in die proses kan inkom.
Ideale visualisering van werknemeraanvaarding van nuwe sagteware Bron - Yandex.Images
Buitelandse konsultante sal hierdie artikel so begin: "As jy jou werknemers kwaliteitsagteware aanbied wat hul werk kan verbeter, 'n kwalitatiewe impak op prestasie het, sal die aanvaarding van 'n nuwe program of stelsel natuurlik gebeur." Maar ons is in Rusland, so die kwessie van verdagte en strydlustige werknemers is baie relevant. 'n Natuurlike oorgang sal nie werk nie, selfs met minimale sagteware soos 'n korporatiewe boodskapper of sagtefoon.
Waar kom die bene van die probleem vandaan?
Vandag het elke maatskappy 'n hele dieretuin sagteware geïnstalleer (ons neem die algemene geval, want in IT-maatskappye is die hoeveelheid sagteware dubbel of drievoudig, en aanpassingsprobleme oorvleuel gedeeltelik en is baie spesifiek): projekbestuurstelsels, CRM/ERP, e-poskliënte, kitsboodskappers, korporatiewe portaal, ens. En dit tel nie die feit dat daar maatskappye is waarin selfs die oorgang van blaaier na blaaier sonder uitsondering deur die hele span uitgevoer word nie (en daar is ook spanne wat heeltemal op Internet Explorer Edge gebaseer is). Oor die algemeen is daar verskeie situasies waarvoor ons artikel nuttig kan wees:
- Daar is 'n proses van primêre outomatisering van een of ander groep take: die eerste CRM/ERP word geïmplementeer, 'n korporatiewe portaal word oopgemaak, 'n stelsel vir tegniese ondersteuning word geïnstalleer, ens.;
- een sagteware word om een of ander rede deur 'n ander vervang: veroudering, nuwe vereistes, skaal, verandering van aktiwiteit, ens.;
- modules van die bestaande stelsel word opgebou vir die doeleindes van ontwikkeling en groei ('n maatskappy het byvoorbeeld produksie geopen en besluit om oor te skakel van op met maksimum funksionaliteit);
- 'n Groot koppelvlak en funksionele sagteware-opdatering vind plaas.
Natuurlik is die eerste twee gevalle baie meer akuut en tipies in hul manifestasies, let veral daarop.
Dus, voordat jy met die span begin werk (wat reeds vermoed het dat daar binnekort veranderinge gaan wees), probeer om te verstaan wat die werklike redes vir die verandering van die sagteware is en of jy saamstem dat die veranderinge so nodig is.
- Die ou program is moeilik om mee te werk: dit is duur, ongerieflik, nie-funksioneel, voldoen nie meer aan jou vereistes nie, is nie geskik vir jou skaal nie, ens. Dit is 'n objektiewe noodsaaklikheid.
- Die verkoper het opgehou om die stelsel te ondersteun, of ondersteuning en wysigings het verander in 'n eindelose reeks goedkeurings en geld dreineer. As jou koste aansienlik toegeneem het, en in die toekoms belowe hulle om nog meer te styg, is daar niks om voor te wag nie, jy moet sny. Ja, 'n nuwe stelsel sal ook geld kos, maar op die ou end sal optimalisering minder kos as sulke ondersteuning.
- Die verandering van sagteware is die gril van een persoon of groep werknemers. Die CTO wil byvoorbeeld 'n terugrol hê en beywer hom vir die bekendstelling van 'n nuwe, duurder stelsel – dit gebeur in groot maatskappye. Nog 'n voorbeeld: 'n projekbestuurder bepleit die verandering van Asana na Basecamp, dan Basecamp na Jira, en kompleks Jira na Wrike. Dikwels is die enigste motief vir sulke migrasies om met hul besige werk te spog en hul posisie te behou. In sulke gevalle is dit nodig om die graad van noodsaaklikheid, motiewe en regverdiging te bepaal en, as 'n reël, deur 'n sterk wilsbesluit om veranderinge te weier.
Ons praat oor die redes vir die oorgang van een sagteware na 'n ander, en nie van primêre outomatisering nie - net omdat outomatisering a priori nodig is. As jou maatskappy iets handmatig en gereeld doen, maar geoutomatiseer kan word, mors jy bloot tyd, geld en, heel waarskynlik, waardevolle maatskappydata. Outomatiseer dit!
Hoe kan jy oorsteek: die groot sprong of die hurkende tier?
In die wêreldpraktyk is daar drie hoofstrategieë om na nuwe sagteware oor te skakel en daarby aan te pas - en dit lyk vir ons baie geskik, so laat ons nie die wiel herontdek nie.
Groot ontploffing
Aanneming met behulp van die "Big Bang" metode is die moeilikste moontlike oorgang, wanneer jy 'n presiese datum stel en 'n skerp migrasie uitvoer, wat die ou sagteware 100% deaktiveer.
Pros
+ Almal werk in een stelsel, dit is nie nodig om data te sinchroniseer nie, werknemers hoef nie twee koppelvlakke gelyktydig te monitor nie.
+ Eenvoud vir die administrateur - een migrasie, een taak, een stelselondersteuning.
+ Alle moontlike veranderinge vind op een tydstip plaas en is feitlik onmiddellik merkbaar - dit is nie nodig om te isoleer wat en in watter verhouding produktiwiteit, spoed van ontwikkeling, verkope, ens.
Nadele
— Werk slegs suksesvol met eenvoudige sagteware: kletse, korporatiewe portaal, kitsboodskappers. Selfs e-pos kan reeds misluk, om nie eens te praat van projekbestuurstelsels, CRM/ERP en ander ernstige stelsels nie.
— ’n “Plofbare” migrasie van ’n groot stelsel na ’n ander sal onvermydelik chaos veroorsaak.
Die belangrikste ding vir hierdie tipe oorgang na 'n nuwe werksomgewing is opleiding.
Parallel hardloop
Parallelle aanpassing aan sagteware is 'n sagter en meer universele metode van oorgang, waarin 'n tydperk gestel word waartydens beide stelsels gelyktydig sal funksioneer.
Pros
+ Gebruikers het genoeg tyd om gewoond te raak aan die nuwe sagteware terwyl hulle vinnig in die ou werk, parallelle vind en die nuwe logika van interaksie met die koppelvlak verstaan.
+ In die geval van skielike probleme, gaan werknemers voort om in die ou stelsel te werk.
+ Gebruikersopleiding is minder streng en oor die algemeen goedkoper.
+ Daar is feitlik geen negatiewe reaksie van werknemers nie - hulle is immers nie van hul gewone gereedskap of manier van doen ontneem nie (as outomatisering vir die eerste keer plaasvind).
Nadele
— Administrasieprobleme: ondersteuning vir beide stelsels, datasinchronisasie, sekuriteitsbestuur in twee toepassings gelyktydig.
— Die oorgangsproses strek eindeloos uit - werknemers besef dat hulle amper 'n ewigheid oor het, en hulle kan die gebruik van die bekende koppelvlak 'n bietjie meer uitbrei.
- Gebruiker verwarring - Die twee koppelvlakke is verwarrend en veroorsaak operasionele en data foute.
- Geld. Jy betaal vir beide stelsels.
Gefaseerde aanneming
Stap-vir-stap aanpassing is die sagste opsie om na nuwe sagteware oor te skakel. Die oorgang word funksioneel uitgevoer, binne bepaalde tydperke en per departement (byvoorbeeld, vanaf 1 Junie voeg ons slegs nuwe kliënte by die nuwe CRM-stelsel, vanaf 20 Junie doen ons transaksies in die nuwe stelsel, tot 1 Augustus dra ons kalenders oor en gevalle, en teen 30 September voltooi ons migrasie is 'n baie rowwe beskrywing, maar oor die algemeen duidelik).
Pros
+ Georganiseerde oorgang, verspreide vrag onder administrateurs en interne kundiges.
+ Meer deurdagte en in-diepte leer.
+ Daar is geen weerstand teen verandering nie, want dit gebeur so sagkens moontlik.
Nadele - ongeveer dieselfde as vir 'n parallelle oorgang.
So nou, net 'n geleidelike oorgang?
'n Logiese vraag, jy sal saamstem. Hoekom 'n bietjie ekstra moeite doen as jy 'n skedule kan maak en volgens 'n duidelike plan kan optree? Trouens, nie alles is so eenvoudig nie.
- Sagteware kompleksiteit: as ons praat van komplekse sagteware (byvoorbeeld, ), dan is fase-aanpassing meer geskik. As die sagteware eenvoudig is (boodskapper, korporatiewe portaal), dan is 'n geskikte model wanneer jy die datum aankondig en die ou sagteware op die aangewese dag deaktiveer (as jy gelukkig is, sal werknemers tyd hê om al die inligting uit te haal wat hulle nodig het , en as jy nie op geluk reken nie, dan moet jy outomatiese invoer nodige data van die ou stelsel na die nuwe een verskaf, indien tegnies moontlik).
- Die mate van risiko vir die maatskappy: hoe riskanter die implementering, hoe stadiger moet dit wees. Aan die ander kant is vertraging ook 'n risiko: jy skakel byvoorbeeld van een CRM-stelsel na 'n ander oor, en gedurende die oorgangstydperk word jy gedwing om vir beide te betaal, en sodoende die koste en koste van die implementering van die nuwe stelsel verhoog, wat beteken dat die terugbetalingstydperk verleng word.
- Aantal werknemers: Oerknal is beslis nie geskik as jy baie gebruikersprofiele moet skaal en konfigureer nie. Alhoewel daar gevalle is wanneer ultra-vinnige implementering 'n voordeel vir 'n groot maatskappy is. Hierdie opsie kan geskik wees vir stelsels wat deur baie werknemers gebruik word, maar het dalk nie vereistes nie omdat aanpassing nie bedoel is nie. Maar weereens, dit is 'n groot knal vir eindgebruikers en 'n groot stap-vir-stap werk vir dieselfde IT-diens (byvoorbeeld fakturering of toegangstelsel).
- Kenmerke van die implementering van die geselekteerde sagteware (hersiening, ens.). Soms is die implementering aanvanklik stadium-vir-stadium - met vereistes-insameling, verfyning, opleiding, ens. Byvoorbeeld, dit word altyd progressief geïmplementeer, en as iemand jou belowe "implementering en konfigurasie binne 3 dae of selfs 3 uur" - onthou hierdie artikel en omseil sulke dienste: installasie ≠ implementering.
Weereens, selfs as u die gelyste parameters ken, kan u beslis nie een of ander pad neem nie. Evalueer jou korporatiewe omgewing – dit sal jou help om beide die magsbalans te verstaan en te bepaal watter model (of kombinasie van sommige van hul elemente) reg is vir jou.
Agente van invloed: revolusie of evolusie
Die eerste ding waaraan jy moet aandag gee, is die werknemers wat deur die implementering van nuwe sagteware geraak sal word. Eintlik is die probleem wat ons nou oorweeg suiwer 'n menslike faktor, so die ontleding van die impak op werknemers kan nie vermy word nie. Ons het reeds 'n paar van hulle hierbo genoem.
- Maatskappyleiers bepaal hoe die nuwe sagteware algemeen aanvaar sal word. En dit is nie die plek vir promosietoesprake en vurige toesprake nie - dit is belangrik om presies die behoefte aan verandering te wys, om die idee oor te dra dat dit net 'n koeler en geriefliker hulpmiddel is, dieselfde as om 'n ou skootrekenaar te vervang. Die grootste fout van bestuur in so 'n situasie is om hul hande te was en hulself te onttrek: as bestuur nie maatskappy-outomatisering nodig het nie, hoekom moet dit vir werknemers van belang wees? Wees in die proses.
- Departementshoofde (projekbestuurders) is 'n tussenskakel wat aan alle prosesse moet deelneem, ontevredenheid moet bestuur, wil toon en elke beswaar van kollegas moet deurwerk, en hoë kwaliteit en diepgaande opleiding moet doen.
- IT-diens (of stelseladministrateurs) - met die eerste oogopslag is dit jou vroeë voëls, die mees aanpasbare en aanpasbare, maar ... nee. Dikwels, veral in klein en mediumgrootte ondernemings, staan stelseladministrateurs enige veranderinge (versterking) van die IT-infrastruktuur teë, en dit is nie te wyte aan enige tegniese regverdiging nie, maar aan luiheid en onwilligheid om te werk. Wie van ons het nie maniere gesoek om werk te vermy nie? Maar laat dit nie tot nadeel van die hele maatskappy wees nie.
- Eindgebruikers wil aan die een kant goed en gerieflik werk en is, soos enige lewende mense, bang vir verandering. Die hoofargument vir hulle is eerlik en eenvoudig: hoekom stel ons in/verander, wat is die grense van beheer, hoe sal die werk geassesseer word, wat sal verander en wat is die risiko's (terloops, almal moet die risiko's evalueer - al is ons verkopers , maar ons onderneem nie om te sê dat alles altyd glad verloop nie: daar is risiko's in enige proses binne 'n besigheid).
- "Owerhede" binne die maatskappy is partydiges wat ander werknemers kan beïnvloed. Dit is nie noodwendig 'n persoon met 'n hoë posisie of uitgebreide ervaring nie - in die geval van werk met sagteware, kan die "owerheid" 'n gevorderde weet-dit-almal wees wat byvoorbeeld Habr weer gelees het en sal begin intimideer almal oor hoe erg alles gaan word. Hy het dalk nie eens 'n doelwit om die implementering of oorgangsproses te ruïneer nie - net pronk en die gees van weerstand - en werknemers sal hom glo. Jy moet met sulke werknemers werk: verduidelik, bevraagteken, en in veral moeilike gevalle, wenk na die gevolge.
Daar is 'n universele resep om te kyk of gebruikers regtig bang is vir iets en of hulle groepparanoia het wat deur 'n vaardige leier gelei word. Vra hulle oor die redes vir ontevredenheid, oor bekommernisse – as dit nie 'n persoonlike ervaring of opinie is nie, sal argumente begin instroom na 3-4 verhelderende vrae.
Twee belangrike faktore om die “weerstandsbeweging” suksesvol te oorkom.
- Verskaf opleiding: verskaffer en intern. Maak seker dat werknemers regtig alles verstaan, dit bemeester het en, ongeag hul opleidingsvlak, gereed is om te begin werk. 'n Verpligte kenmerk van opleiding is gedrukte en elektroniese instruksies (regulasies) en die mees volledige dokumentasie op die stelsel (selfrespekterende verskaffers stel dit saam met die sagteware vry en verskaf dit gratis).
- Soek ondersteuners en kies beïnvloeders. Interne kundiges en vroeë aannemers is jou ondersteuningstelsel, wat beide twyfel opvoed en uit die weg ruim. As 'n reël help werknemers self graag hul kollegas en stel hulle aan nuwe sagteware bekend. Jou taak is om hulle tydelik van hul werk te onthef of om hulle 'n ordentlike bonus vir hul nuwe werklading te gee.
Waaraan moet jy aandag gee?
- Hoe gevorderd word die werknemers deur die veranderinge geraak? (Relatief gesproke, as hulle môre 'n nuwe rekeningkundige program uitdink, God verhoed dat jy jou neus in die rekeningkunde afdeling steek met dames bo 50 en 'n oorgang van 1C voorstel, sal jy nie lewendig daaruit kom nie).
- Hoeveel sal werkvloei geraak word? Dit is een ding om die boodskapper in 'n maatskappy van 100 mense te verander, 'n ander ding is om 'n nuwe CRM-stelsel te implementeer, wat gebaseer is op sleutelprosesse in die maatskappy (en dit is nie net verkope nie, byvoorbeeld, in senior uitgawes raak dit produksie-, pakhuis-, bemarkings- en topbestuurders wat saam met die span outomatiese besigheidsprosesse sal bou).
- Is opleiding verskaf en op watter vlak?
Die enigste logiese oorgang in die stelsel van korporatiewe denke
Wat sal die oorgang/implementering van nuwe sagteware red?
Voordat ons jou vertel watter sleutelpunte jou sal help om gemaklik na nuwe sagteware oor te gaan, laat ons jou aandag op een punt vestig. Daar is iets wat beslis nie gedoen moet word nie – dit is nie nodig om druk op werknemers te plaas en hulle te “motiveer” deur hulle van bonusse, administratiewe en dissiplinêre sanksies te ontneem nie. Dit sal nie die proses beter maak nie, maar die houding van die werknemers sal vererger: as hulle druk, dan sal daar beheer wees; As hulle jou dwing, beteken dit dat hulle nie ons belange respekteer nie; As hulle dit met geweld afdwing, beteken dit dat hulle ons en ons werk nie vertrou nie. Daarom doen ons alles op 'n gedissiplineerde, duidelike, bekwame wyse, maar sonder druk of onnodige dwing.
Jy moet 'n gedetailleerde aksieplan hê
Alles anders bestaan dalk nie, maar daar moet 'n plan wees. Boonop is die plan aanpasbaar, bygewerk, duidelik en onvermydelik, terselfdertyd toeganklik vir bespreking en deursigtig vir alle belangstellende werknemers. Dit is onmoontlik om direk te kommunikeer dat daar van 8:10 tot 16:00 'n prestasie is, en om XNUMX:XNUMX is daar oorlog met Engeland; dit is belangrik om die hele plan in perspektief te sien.
Die plan moet noodwendig die vereistes weerspieël van werknemers wat eindgebruikers sal wees - op hierdie manier sal elke werknemer presies weet watter gewenste kenmerk en op watter tydstip hy dit sal kan gebruik. Terselfdertyd is die oorgangs- of implementeringsplan nie 'n soort onveranderlike monoliet nie; dit is nodig om die moontlikheid te verlaat om die plan te finaliseer en sy eienskappe te verander (maar nie in die vorm van 'n eindelose stroom van wysigings en nuwe "begeertes" en nie in die vorm van 'n konstante verskuiwing in spertye nie).
Wat moet in die plan wees?
- Die belangrikste oorgangsmylpale (stadia) - wat gedoen moet word.
- Gedetailleerde oorgangspunte vir elke stadium - hoe dit gedoen moet word.
- Sleutelpunte en verslagdoening daaroor (rekonsiliasie van ure) - hoe wat gedoen is gemeet sal word en wie by die kontrolepunt moet wees.
- Verantwoordelike mense is mense na wie jy kan wend en vrae kan vra.
- Sperdatums is die begin en einde van elke stadium en die hele proses as geheel.
- Geaffekteerde prosesse - watter veranderinge sal plaasvind in besigheidsprosesse, wat verander moet word saam met die implementering/oorgang.
- Die finale assessering is 'n stel aanwysers, maatstawwe of selfs subjektiewe assesserings wat sal help om die implementering/oorgang wat plaasgevind het, te evalueer.
- Die begin van die operasie is die presiese datum wanneer die hele maatskappy by die opgedateerde outomatiese proses sal aansluit en in die nuwe stelsel sal werk.
Ons het aanbiedings van implementeerders teëgekom waarin die rooi lyn advies is: implementeer met geweld, ignoreer die reaksie, moenie met werknemers praat nie. Ons is teen hierdie benadering, en hier is hoekom.
Kyk na die prentjie hieronder:
'n Nuwe muis, 'n nuwe sleutelbord, 'n woonstel, 'n motor en selfs 'n werk is aangename, vreugdevolle gebeurtenisse, sommige van hulle is selfs prestasies. En die gebruiker gaan na Yandex om uit te vind hoe om daaraan gewoond te raak en aan te pas. Hoe om 'n nuwe woonstel binne te gaan en te verstaan dat dit joune is, draai die kraan vir die eerste keer oop, drink tee, gaan slaap vir die eerste keer. Hoe om agter die stuur in te klim en vriende te maak met 'n nuwe motor, joune, maar tot dusver so uitheems. Nuwe sagteware in die werkplek verskil nie van die situasies wat beskryf word nie: die werknemer se werk sal nooit dieselfde wees nie. Implementeer, pas aan, groei dus met nuwe effektiewe sagteware. En dit is 'n situasie waaroor ons kan sê: maak gou gou.
Bron: will.com