Medewerkers willen geen nieuwe software: moeten ze het voorbeeld volgen of vasthouden aan hun lijn?

Softwarehaasje-over zal binnenkort een veel voorkomende ziekte van bedrijven worden. Het veranderen van de ene software voor de andere vanwege elk klein dingetje, het springen van technologie naar technologie, experimenteren met een live bedrijf wordt de norm. Tegelijkertijd begint er op kantoor een echte burgeroorlog: er ontstaat een beweging van verzet tegen de implementatie, partizanen voeren subversief werk uit tegen het nieuwe systeem, spionnen promoten een dappere nieuwe wereld met nieuwe software, management vanuit de gepantserde auto van het bedrijfsportaal zendt uit over vrede, arbeid en KPI's. Een revolutie eindigt meestal in een volledige mislukking aan één kant.

We weten bijna alles over implementatie, dus laten we proberen uit te vinden hoe we van een revolutie een evolutie kunnen maken en de implementatie zo nuttig en pijnloos mogelijk kunnen maken. Nou ja, of we zullen je in ieder geval vertellen waar je tijdens het proces mee te maken kunt krijgen.

Ideale visualisatie van acceptatie door medewerkers van nieuwe software. Bron - Yandex.Images

Buitenlandse consultants zouden dit artikel ongeveer zo beginnen: “Als u uw medewerkers hoogwaardige software aanbiedt die hun werk kan verbeteren en een kwalitatieve impact heeft op de prestaties, zal de adoptie van een nieuw programma of systeem vanzelf gebeuren.” Maar we zijn in Rusland, dus de kwestie van wantrouwige en strijdlustige werknemers is zeer relevant. Een natuurlijke transitie zal niet werken, zelfs niet met minimale software zoals een bedrijfsmessenger of softphone.

Waar komen de poten van het probleem vandaan?

Tegenwoordig heeft elk bedrijf een hele dierentuin aan software geïnstalleerd (we nemen het algemene geval, omdat in IT-bedrijven de hoeveelheid software dubbel of drievoudig is, en aanpassingsproblemen elkaar gedeeltelijk overlappen en zeer specifiek zijn): projectmanagementsystemen, CRM/ERP, e-mailclients, instant messengers, bedrijfsportaal, enz. En dan tellen we nog niet mee dat er bedrijven zijn waar zelfs de overgang van browser naar browser zonder uitzondering door het hele team wordt uitgevoerd (en er zijn ook teams die volledig op Internet Explorer Edge zijn gebaseerd). Over het algemeen zijn er verschillende situaties waarvoor ons artikel nuttig kan zijn:

• Er is een proces van primaire automatisering van een bepaalde groep taken: de eerste CRM/ERP wordt geïmplementeerd, een bedrijfsportaal wordt geopend, een systeem voor technische ondersteuning wordt geïnstalleerd, enz.;
• de ene software wordt om de een of andere reden vervangen door een andere: veroudering, nieuwe vereisten, schaalvergroting, verandering van activiteit, enz.;
• modules van het bestaande systeem worden opgebouwd met het oog op ontwikkeling en groei (een bedrijf opende bijvoorbeeld de productie en besloot over te stappen van RegionSoft CRM Professional op RegionSoft CRM Enterprise Plus met maximale functionaliteit);
• Er vindt een grote interface- en functionele software-update plaats.

Natuurlijk zijn de eerste twee gevallen veel acuter en typischer in hun manifestaties, besteed er speciale aandacht aan.

Probeer dus, voordat u met het team gaat samenwerken (die al vermoedden dat er binnenkort veranderingen zullen plaatsvinden), te begrijpen wat de echte redenen zijn om de software te wijzigen en of u het ermee eens bent dat de veranderingen zo noodzakelijk zijn.

• Het oude programma is lastig om mee te werken: het is duur, onhandig, niet functioneel, voldoet niet meer aan jouw eisen, is niet geschikt voor jouw schaal, etc. Dit is een objectieve noodzaak.
• De leverancier stopte met de ondersteuning van het systeem, of ondersteuning en aanpassingen veranderden in een eindeloze reeks goedkeuringen en geldverspilling. Als uw kosten aanzienlijk zijn gestegen en ze beloven dat ze in de toekomst nog meer zullen stijgen, dan hoeft u niet te wachten, u moet bezuinigen. Ja, een nieuw systeem kost ook geld, maar uiteindelijk zal optimalisatie minder kosten dan dergelijke ondersteuning.
• Het veranderen van software is de gril van één persoon of groep medewerkers. De CTO wil bijvoorbeeld een rollback en lobbyt voor de introductie van een nieuw, duurder systeem – dit gebeurt bij grote bedrijven. Nog een voorbeeld: een projectmanager pleit ervoor om Asana te veranderen in Basecamp, vervolgens Basecamp in Jira en de complexe Jira in Wrike. Vaak is het enige motief voor dergelijke migraties het laten zien van hun drukke werk en het behouden van hun positie. In dergelijke gevallen is het noodzakelijk om de mate van noodzaak, motieven en rechtvaardiging te bepalen en, in de regel, door een wilskrachtig besluit om veranderingen te weigeren.

We hebben het over de redenen voor de overgang van de ene software naar de andere, en niet over primaire automatisering - alleen omdat automatisering a priori noodzakelijk is. Als uw bedrijf iets handmatig en routinematig doet, maar geautomatiseerd zou kunnen worden, verspilt u eenvoudigweg tijd, geld en hoogstwaarschijnlijk waardevolle bedrijfsgegevens. Automatiseer het!

Hoe kun je oversteken: de grote sprong of de hurkende tijger?

In de wereldpraktijk zijn er drie belangrijke strategieën om over te stappen op nieuwe software en je eraan aan te passen. Deze lijken ons zeer geschikt, dus laten we het wiel niet opnieuw uitvinden.

Big Bang

Adoptie via de ‘Big Bang’-methode is de moeilijkst mogelijke transitie, wanneer je een exacte datum instelt en een scherpe migratie uitvoert, waarbij de oude software voor 100% wordt uitgeschakeld.

Voors

+ Iedereen werkt in één systeem, er is geen noodzaak om gegevens te synchroniseren, medewerkers hoeven niet twee interfaces tegelijk te monitoren.
+ Eenvoud voor de beheerder - één migratie, één taak, één systeemondersteuning.
+ Alle mogelijke veranderingen vinden op een bepaald moment plaats en zijn vrijwel onmiddellijk merkbaar - het is niet nodig om te isoleren wat en in welke mate de productiviteit, ontwikkelingssnelheid, verkoop, enz. beïnvloedde.

Tegens

— Werkt alleen succesvol met eenvoudige software: chats, bedrijfsportaal, instant messengers. Zelfs e-mail kan al falen, om nog maar te zwijgen van projectmanagementsystemen, CRM/ERP en andere serieuze systemen.
— Een explosieve migratie van het ene grote systeem naar het andere zal onvermijdelijk chaos veroorzaken.

Het allerbelangrijkste bij dit soort overgangen naar een nieuwe werkomgeving is opleiding.

Parallel lopen

Parallelle aanpassing aan software is een zachtere en meer universele transitiemethode, waarbij een tijdsperiode wordt vastgesteld waarin beide systemen gelijktijdig zullen functioneren.

Voors

+ Gebruikers hebben voldoende tijd om aan de nieuwe software te wennen terwijl ze snel in de oude werken, parallellen vinden en de nieuwe logica van interactie met de interface begrijpen.
+ Bij plotselinge problemen blijven medewerkers in het oude systeem werken.
+ Gebruikerstraining is minder rigoureus en over het algemeen goedkoper.
+ Er is vrijwel geen negatieve reactie van werknemers - ze zijn tenslotte niet verstoken van hun gebruikelijke hulpmiddelen of manier van doen (als automatisering voor de eerste keer plaatsvindt).

Tegens

— Administratieproblemen: ondersteuning voor beide systemen, gegevenssynchronisatie, beveiligingsbeheer in twee applicaties tegelijk.
— Het transitieproces strekt zich eindeloos uit: medewerkers beseffen dat ze bijna een eeuwigheid te gaan hebben, en ze kunnen het gebruik van de vertrouwde interface nog wat uitbreiden.
- Gebruikersverwarring - De twee interfaces zijn verwarrend en veroorzaken operationele en gegevensfouten.
- Geld. U betaalt voor beide systemen.

Gefaseerde adoptie

Stapsgewijs aanpassen is de zachtste optie om over te stappen naar nieuwe software. De transitie wordt functioneel, binnen bepaalde tijdsperioden en per afdeling uitgevoerd (zo voegen we vanaf 1 juni alleen nieuwe klanten toe aan het nieuwe CRM-systeem, vanaf 20 juni voeren we transacties uit in het nieuwe systeem, tot 1 augustus zetten we kalenders over en gevallen, en tegen 30 september voltooien we de migratie is een zeer ruwe beschrijving, maar over het algemeen duidelijk).

Voors

+ Georganiseerde transitie, verdeelde last over bestuurders en interne experts.
+ Meer doordacht en diepgaand leren.
+ Er is geen weerstand tegen verandering, omdat het zo zacht mogelijk gebeurt.

Tegens - ongeveer hetzelfde als voor een parallelle overgang.

Dus nu slechts een geleidelijke overgang?

Een logische vraag, daar zult u het mee eens zijn. Waarom extra rompslomp als u een planning kunt maken en volgens een duidelijk plan kunt handelen? In feite is niet alles zo eenvoudig.

• Softwarecomplexiteit: als we het hebben over complexe software (bijvoorbeeld CRM-systeem), dan is fase-aanpassing geschikter. Als de software eenvoudig is (messenger, bedrijfsportaal), dan is een geschikt model wanneer u de datum aankondigt en de oude software op de afgesproken dag uitschakelt (als u geluk heeft, hebben werknemers de tijd om alle informatie op te halen die ze nodig hebben , en als u niet op geluk rekent, moet u de noodzakelijke gegevens automatisch importeren van het oude systeem naar het nieuwe, indien technisch mogelijk).
• De mate van risico voor het bedrijf: hoe risicovoller de implementatie, hoe langzamer deze zou moeten verlopen. Aan de andere kant is uitstel ook een risico: u stapt bijvoorbeeld over van het ene CRM-systeem naar het andere, en tijdens de overgangsperiode bent u gedwongen voor beide te betalen, waardoor de kosten en kosten van de implementatie van het nieuwe systeem toenemen, wat betekent dat de terugverdientijd wordt verlengd.
• Aantal medewerkers: Big Bang is zeker niet geschikt als je veel gebruikersprofielen moet schalen en configureren. Hoewel er gevallen zijn waarin ultrasnelle implementatie een voordeel is voor een groot bedrijf. Deze optie kan geschikt zijn voor systemen die door veel medewerkers worden gebruikt, maar waar geen eisen aan worden gesteld omdat maatwerk niet de bedoeling is. Maar nogmaals, dit is een big bang voor eindgebruikers en een enorm stapsgewijs werk voor dezelfde IT-dienst (bijvoorbeeld facturatie- of toegangssysteem).
• Kenmerken van de implementatie van de geselecteerde software (revisie, enz.). Soms gebeurt de implementatie in eerste instantie stap voor stap - met het verzamelen van eisen, verfijning, training, enz. Bijvoorbeeld, CRM-systeem het wordt altijd progressief geïmplementeerd, en als iemand u “implementatie en configuratie in 3 dagen of zelfs 3 uur” belooft, onthoud dan dit artikel en omzeil dergelijke services: installatie ≠ implementatie.

Nogmaals, zelfs als je de opgesomde parameters kent, kun je niet zeker het ene of het andere pad volgen. Beoordeel uw bedrijfsomgeving - dit zal u helpen de machtsverhoudingen te begrijpen en te bepalen welk model (of een combinatie van enkele van hun elementen) voor u geschikt is.

Agenten van invloed: revolutie of evolutie

Het eerste waar u op moet letten, zijn de medewerkers die gevolgen ondervinden van de implementatie van nieuwe software. Eigenlijk is het probleem waar we nu over nadenken puur een menselijke factor, dus het analyseren van de impact op werknemers kan niet worden vermeden. Een aantal daarvan hebben we hierboven al genoemd.

• Bedrijfsleiders bepalen hoe de nieuwe software algemeen geaccepteerd zal worden. En dit is niet de plaats voor promotionele toespraken en vurige toespraken - het is belangrijk om precies de noodzaak van verandering te laten zien, om het idee over te brengen dat dit alleen maar het kiezen van een cooler en handiger hulpmiddel is, hetzelfde als het vervangen van een oude laptop. De grootste fout van het management in een dergelijke situatie is om de handen te wassen en zich terug te trekken: als het management geen bedrijfsautomatisering nodig heeft, waarom zou dit dan interessant zijn voor de werknemers? Wees in het proces.
• Afdelingshoofden (projectmanagers) zijn een tussenschakel die aan alle processen moet deelnemen, ontevredenheid moet beheersen, wilskracht moet tonen en elk bezwaar van collega's moet doorstaan, en hoogwaardige en diepgaande trainingen moet geven.
• IT-dienstverleners (of systeembeheerders) - op het eerste gezicht zijn dit uw vroege vogels, de meest aanpasbare en adaptieve, maar... nee. Vaak zijn systeembeheerders, vooral in kleine en middelgrote bedrijven, tegen elke verandering (versterking) van de IT-infrastructuur, en dit is niet te wijten aan enige technische rechtvaardiging, maar aan luiheid en onwil om te werken. Wie van ons heeft niet gezocht naar manieren om werk te vermijden? Maar laat dit niet ten koste gaan van het hele bedrijf.
• Eindgebruikers willen in de regel goed en gemakkelijk werken en zijn, net als alle levende mensen, bang voor verandering. Het belangrijkste argument voor hen is eerlijk en eenvoudig: waarom introduceren/veranderen we, wat zijn de grenzen van de controle, hoe zal het werk worden beoordeeld, wat zal er veranderen en wat zijn de risico's (iedereen zou trouwens de risico's moeten evalueren - ook al zijn we verkopers CRM-systemen, maar we beloven niet dat alles altijd soepel verloopt: er zijn risico's in elk proces binnen een bedrijf).
• “Autoriteiten” binnen het bedrijf zijn partizanen die andere werknemers kunnen beïnvloeden. Dit is niet noodzakelijkerwijs een persoon met een hoge positie of uitgebreide ervaring - in het geval van het werken met software kan de "autoriteit" een gevorderde betweter zijn die bijvoorbeeld Habr opnieuw heeft gelezen en zal beginnen te intimideren iedereen over hoe erg alles zal worden. Hij heeft misschien niet eens de bedoeling om het implementatie- of transitieproces te verpesten – alleen maar opschepperij en de geest van verzet – en de medewerkers zullen hem geloven. Met zulke medewerkers moet je samenwerken: uitleg geven, vragen stellen en in bijzonder moeilijke gevallen wijzen op de gevolgen.

Er bestaat een universeel recept om te controleren of gebruikers echt ergens bang voor zijn of dat ze groepsparanoia hebben onder leiding van een slimme leider. Vraag hen naar de redenen voor ontevredenheid, naar zorgen - als dit geen persoonlijke ervaring of mening is, zullen de argumenten na 3-4 verduidelijkende vragen beginnen binnen te stromen.

Twee belangrijke factoren voor het succesvol overwinnen van de ‘verzetsbeweging’.

1. Zorg voor training: leverancier en intern. Zorg ervoor dat medewerkers echt alles begrijpen, onder de knie hebben en, ongeacht hun opleidingsniveau, klaar zijn om aan de slag te gaan. Een verplicht kenmerk van training zijn gedrukte en elektronische instructies (voorschriften) en de meest complete documentatie over het systeem (zichzelf respecterende leveranciers geven deze samen met de software vrij en bieden deze gratis aan).
2. Zoek supporters en kies influencers. Interne experts en early adopters zijn uw ondersteuningssysteem, waarbij ze zowel twijfels onderwijzen als wegnemen. In de regel helpen medewerkers zelf graag hun collega's en laten ze kennismaken met nieuwe software. Het is jouw taak om ze tijdelijk van hun werk te ontlasten of een behoorlijke bonus te geven voor hun nieuwe werklast.

Wat moeten aandacht besteden aan?

1. Hoe gevorderd zijn de medewerkers die door de veranderingen worden getroffen? (Relatief gesproken: als ze morgen een nieuw boekhoudprogramma uitvinden, God verhoede dat je je neus in de boekhoudafdeling steekt met dames boven de 50 en een overgang van 1C voorstelt, kom je er niet levend uit).
2. In welke mate zullen de workflows worden beïnvloed? Het is één ding om de boodschapper te veranderen in een bedrijf met 100 mensen, een ander ding is het implementeren van een nieuw CRM-systeem, dat is gebaseerd op de belangrijkste processen in het bedrijf (en dit is bijvoorbeeld niet alleen verkoop, implementatie van RegionSoft CRM in senior edities heeft dit gevolgen voor productie, magazijn, marketing en topmanagers die samen met het team geautomatiseerde bedrijfsprocessen gaan bouwen).
3. Is er training gegeven en op welk niveau?

De enige logische overgang in het systeem van bedrijfsdenken

Wat bespaart de transitie/implementatie van nieuwe software?

Voordat we u vertellen welke belangrijke punten u zullen helpen comfortabel over te stappen op nieuwe software, willen we eerst uw aandacht vestigen op één punt. Er is iets dat beslist niet mag worden gedaan: het is niet nodig om druk uit te oefenen op werknemers en hen te ‘motiveren’ door hen bonussen en administratieve en disciplinaire sancties te ontnemen. Dit zal het proces er niet beter op maken, maar de houding van de medewerkers zal verslechteren: als ze pushen, zal er controle zijn; Als ze je dwingen, betekent dit dat ze onze belangen niet respecteren; Als ze het met geweld opleggen, betekent dit dat ze ons en ons werk niet vertrouwen. Daarom doen wij alles gedisciplineerd, duidelijk en vakkundig, maar zonder druk of onnodig forceren.

U moet over een gedetailleerd actieplan beschikken

Al het andere bestaat misschien niet, maar er moet een plan zijn. Bovendien is het plan aanpasbaar, actueel, duidelijk en onvermijdelijk, tegelijkertijd bespreekbaar en transparant voor alle geïnteresseerde medewerkers. Het is onmogelijk om directief te communiceren dat er van 8 uur tot 10 uur een prestatie is, en om 16 uur is er oorlog met Engeland; het is belangrijk om het hele plan in perspectief te zien.

Het plan moet noodzakelijkerwijs de behoeften weerspiegelen van werknemers die eindgebruikers zullen zijn - op deze manier weet elke werknemer precies welke gewenste functie en op welk tijdstip hij deze kan gebruiken. Tegelijkertijd is het transitie- of implementatieplan niet een soort onveranderlijke monoliet; het is noodzakelijk om de mogelijkheid te laten om het plan te finaliseren en de kenmerken ervan te veranderen (maar niet in de vorm van een eindeloze stroom van bewerkingen en nieuwe ‘wensen’). en niet in de vorm van een constante verschuiving van deadlines).  

Wat moet er in het plan staan?

1. De belangrijkste transitiemijlpalen (fasen) – wat er moet gebeuren.
2. Gedetailleerde overgangspunten voor elke fase - hoe dit moet gebeuren.
3. Kernpunten en rapportage daarover (afstemming van uren) - hoe wordt gemeten wat er is gedaan en wie er bij het controlepunt moet zijn.
4. Verantwoordelijke mensen zijn mensen bij wie u terecht kunt en waar u vragen aan kunt stellen.
5. Deadlines vormen het begin en het einde van elke fase en het hele proces als geheel.
6. Betrokken processen - welke veranderingen zullen er optreden in bedrijfsprocessen, wat moet er tijdens de implementatie/transitie veranderd worden.
7. De eindbeoordeling is een reeks indicatoren, maatstaven of zelfs subjectieve beoordelingen die zullen helpen bij het evalueren van de implementatie/transitie die heeft plaatsgevonden.
8. De ingebruikname is de exacte datum waarop het hele bedrijf deelneemt aan het bijgewerkte geautomatiseerde proces en in het nieuwe systeem gaat werken.

We zijn presentaties tegengekomen van uitvoerders waarin de rode lijn advies is: implementeer met geweld, negeer de reactie, praat niet met medewerkers. Wij zijn tegen deze aanpak, en dit is waarom.

Kijk naar de afbeelding hieronder:

Een nieuwe muis, een nieuw toetsenbord, een appartement, een auto en zelfs een baan zijn aangename, vreugdevolle gebeurtenissen, sommige zijn zelfs prestaties. En de gebruiker gaat naar Yandex om erachter te komen hoe hij eraan kan wennen en zich kan aanpassen. Hoe je een nieuw appartement binnengaat en begrijpt dat het van jou is, de kraan voor de eerste keer openzet, thee drinkt, voor de eerste keer naar bed gaat. Hoe je achter het stuur kruipt en vrienden maakt met een nieuwe auto, die van jou, maar tot nu toe zo vreemd. Nieuwe software op de werkvloer verschilt niet van de beschreven situaties: de baan van de medewerker zal nooit meer hetzelfde zijn. Implementeer daarom, pas het aan en groei met nieuwe effectieve software. En dit is een situatie waarover we kunnen zeggen: schiet langzaam op.

Bron: www.habr.com