Ansatte vil ikke ha ny programvare - bør de følge ledelsen eller holde seg til sin linje?

Programvaresprang vil snart bli en svært vanlig sykdom hos selskaper. Å endre en programvare for en annen på grunn av hver minste ting, hoppe fra teknologi til teknologi, eksperimentere med en levende virksomhet er i ferd med å bli normen. Samtidig begynner en ekte borgerkrig på kontoret: en motstandsbevegelse mot implementering dannes, partisaner driver undergravende arbeid mot det nye systemet, spioner fremmer en modig ny verden med ny programvare, ledelse fra panserbilen til bedriftsportalen kringkaster om fred, arbeid, KPIer. En revolusjon ender vanligvis i fullstendig fiasko på den ene siden.

Vi vet nesten alt om implementering, så la oss prøve å finne ut hvordan vi kan gjøre en revolusjon til en evolusjon og gjøre implementeringen så nyttig og smertefri som mulig. Vel, eller i det minste vil vi fortelle deg hva du kan komme inn på i prosessen.

Ideell visualisering av ansattes aksept av ny programvare Kilde - Yandex.Images

Utenlandske konsulenter vil starte denne artikkelen omtrent slik: "Hvis du tilbyr dine ansatte kvalitetsprogramvare som kan forbedre arbeidet deres, ha en kvalitativ innvirkning på ytelsen, vil innføringen av et nytt program eller system skje naturlig." Men vi er i Russland, så spørsmålet om mistenkelige og krigerske ansatte er veldig aktuelt. En naturlig overgang vil ikke fungere, selv med minimal programvare som en bedriftsmessenger eller softphone.

Hvor kommer beina til problemet fra?

I dag har hvert selskap en hel dyrehage med programvare installert (vi tar det generelle tilfellet, fordi i IT-selskaper er mengden programvare dobbel eller trippel, og tilpasningsproblemer overlapper delvis og er veldig spesifikke): prosjektstyringssystemer, CRM/ERP, e-postklienter, instant messengers, bedriftsportal, etc. Og dette teller ikke det faktum at det er selskaper der selv overgangen fra nettleser til nettleser utføres av hele teamet uten unntak (og det er også team som er fullstendig basert på Internet Explorer Edge). Generelt er det flere situasjoner som artikkelen vår kan være nyttig for:

• prosessen med primær automatisering av en viss gruppe oppgaver finner sted: den første CRM/ERP blir implementert, en bedriftsportal åpnes, et system for teknisk støtte blir installert, etc.;
• en programvare erstattes av en annen av en eller annen grunn: foreldelse, nye krav, skalering, endring av aktivitet, etc.;
• moduler av det eksisterende systemet bygges opp for utvikling og vekst (for eksempel åpnet et selskap produksjon og bestemte seg for å bytte fra RegionSoft CRM Professional på RegionSoft CRM Enterprise Plus med maksimal funksjonalitet);
• En stor oppdatering av grensesnitt og funksjonell programvare finner sted.

Selvfølgelig er de to første tilfellene mye mer akutte og typiske i deres manifestasjoner, vær spesielt oppmerksom på dem.

Så før du begynner å jobbe med teamet (som allerede har mistenkt at det snart vil bli endringer), prøv å forstå hva de virkelige årsakene til å endre programvaren er og om du er enig i at endringene er så nødvendige.

• Det gamle programmet er vanskelig å jobbe med: det er dyrt, upraktisk, ikke-funksjonelt, oppfyller ikke lenger kravene dine, passer ikke for din skala, etc. Dette er en objektiv nødvendighet.
• Leverandøren sluttet å støtte systemet, eller støtte og modifikasjoner ble til en endeløs serie med godkjenninger og tap av penger. Hvis kostnadene dine har økt betydelig, og i fremtiden lover de å øke enda mer, er det ingenting å vente på, du må kutte. Ja, et nytt system vil også koste penger, men til syvende og sist vil optimalisering koste mindre enn slik støtte.
• Å endre programvare er innfall av én person eller gruppe ansatte. For eksempel ønsker CTO en tilbakerulling og driver lobbyvirksomhet for innføring av et nytt, dyrere system – dette skjer i store selskaper. Et annet eksempel: en prosjektleder går inn for å endre Asana til Basecamp, deretter Basecamp til Jira, og kompleks Jira til Wrike. Ofte er det eneste motivet for slike migrasjoner å vise frem sitt travle arbeid og beholde sin posisjon. I slike tilfeller er det nødvendig å bestemme graden av nødvendighet, motiver og begrunnelse og som regel ved en viljesterk beslutning om å nekte endringer.

Vi snakker om årsakene til overgangen fra en programvare til en annen, og ikke om primær automatisering – kun fordi automatisering er nødvendig på forhånd. Hvis bedriften din gjør noe manuelt og rutinemessig, men som kan automatiseres, kaster du rett og slett bort tid, penger og mest sannsynlig verdifull bedriftsdata. Automatiser det!

Hvordan kan du krysse: det store spranget eller den hukende tigeren?

I verdenspraksis er det tre hovedstrategier for å bytte til ny programvare og tilpasse seg den - og de virker veldig passende for oss, så la oss ikke finne opp hjulet på nytt.

Big Bang

Adopsjon ved bruk av "Big Bang"-metoden er den vanskeligste overgangen når du setter en nøyaktig dato og gjennomfører en skarp migrering, og deaktiverer den gamle programvaren 100 %.

Pros

+ Alle jobber i ett system, det er ikke nødvendig å synkronisere data, ansatte trenger ikke å overvåke to grensesnitt samtidig.
+ Enkelhet for administratoren - én migrering, én oppgave, én systemstøtte.
+ Alle mulige endringer skjer på et tidspunkt og er merkbare nesten umiddelbart - det er ikke nødvendig å isolere hva og i hvilken andel påvirket produktivitet, utviklingshastighet, salg osv.

Cons

— Fungerer vellykket bare med enkel programvare: chatter, bedriftsportal, direktemeldinger. Selv e-post kan allerede mislykkes, for ikke å snakke om prosjektstyringssystemer, CRM/ERP og andre seriøse systemer.
— En eksplosiv migrasjon fra et stort system til et annet vil uunngåelig skape kaos.

Det viktigste for denne typen overgang til nytt arbeidsmiljø er opplæring.

Parallell løping

Parallell tilpasning til programvare er en mykere og mer universell overgangsmetode, der det settes en tidsperiode der begge systemene skal fungere samtidig.

Pros

+ Brukere har nok tid til å venne seg til den nye programvaren mens de raskt jobber i den gamle, finner paralleller og forstår den nye logikken for interaksjon med grensesnittet.
+ Ved plutselige problemer fortsetter ansatte å jobbe i det gamle systemet.
+ Brukeropplæring er mindre streng og generelt billigere.
+ Det er praktisk talt ingen negativ reaksjon fra ansatte - de ble tross alt ikke fratatt de vanlige verktøyene eller måten å gjøre ting på (hvis automatisering skjer for første gang).

Cons

— Administrasjonsproblemer: støtte for begge systemene, datasynkronisering, sikkerhetsstyring i to applikasjoner samtidig.
— Overgangsprosessen strekker seg uendelig ut – ansatte innser at de har nesten en evighet igjen, og de kan utvide bruken av det kjente grensesnittet litt mer.
- Brukerforvirring - De to grensesnittene er forvirrende og forårsaker drifts- og datafeil.
- Penger. Du betaler for begge systemene.

Faseadopsjon

Trinn-for-trinn-tilpasning er det mykeste alternativet for å bytte til ny programvare. Overgangen utføres funksjonelt, innen spesifiserte tidsperioder og etter avdeling (for eksempel fra 1. juni legger vi kun til nye kunder i det nye CRM-systemet, fra 20. juni gjennomfører vi transaksjoner i det nye systemet, til 1. august overfører vi kalendere og saker, og innen 30. september fullfører vi migreringen er en veldig grov beskrivelse, men generelt klar).

Pros

+ Organisert overgang, fordelt belastning mellom administratorer og interne eksperter.
+ Mer gjennomtenkt og dybdelæring.
+ Det er ingen motstand mot forandring, fordi det skjer så skånsomt som mulig.

Cons - omtrent det samme som for en parallell overgang.

Så nå, bare en gradvis overgang?

Et logisk spørsmål, du vil være enig. Hvorfor få litt ekstra stress når du kan lage en tidsplan og handle etter en klar plan? Faktisk er ikke alt så enkelt.

• Programvarekompleksitet: hvis vi snakker om kompleks programvare (f.eks. CRM-system), da er fasetilpasning mer egnet. Hvis programvaren er enkel (messenger, bedriftsportal), er en passende modell når du annonserer datoen og deaktiverer den gamle programvaren på den fastsatte dagen (hvis du er heldig, vil ansatte ha tid til å hente ut all informasjonen de trenger , og hvis du ikke regner med flaks, må du gi automatisk import av nødvendige data fra det gamle systemet til det nye, hvis det er teknisk mulig).
• Graden av risiko for selskapet: jo mer risikofylt implementeringen er, jo tregere bør den gå. På den annen side er forsinkelse også en risiko: for eksempel bytter du fra ett CRM-system til et annet, og i overgangsperioden blir du tvunget til å betale for begge, og øker dermed kostnadene og kostnadene ved å implementere det nye systemet, som betyr at tilbakebetalingsperioden forlenges.
• Antall ansatte: Big Bang er definitivt ikke egnet hvis du skal skalere og konfigurere mange brukerprofiler. Selv om det er tilfeller der ultrarask implementering er en fordel for et stort selskap. Dette alternativet kan være egnet for systemer som brukes av mange ansatte, men har kanskje ikke krav fordi tilpasning ikke er ment. Men igjen, dette er et stort smell for sluttbrukere og et enormt steg-for-steg arbeid for samme IT-tjeneste (for eksempel fakturering eller tilgangssystem).
• Funksjoner ved implementeringen av den valgte programvaren (revisjon, etc.). Noen ganger er implementeringen i utgangspunktet etappevis – med kravinnsamling, foredling, opplæring osv. For eksempel, CRM-system det implementeres alltid gradvis, og hvis noen lover deg "implementering og konfigurasjon på 3 dager eller til og med 3 timer" - husk denne artikkelen og omgå slike tjenester: installasjon ≠ implementering.

Igjen, selv om man kjenner de listede parameterne, kan man ikke definitivt ta en eller annen vei. Vurder bedriftsmiljøet ditt – dette vil hjelpe deg både å forstå maktbalansen og finne ut hvilken modell (eller kombinasjon av noen av elementene deres) som er riktig for deg.

Agenter for innflytelse: revolusjon eller evolusjon

Det første du bør være oppmerksom på er de ansatte som vil bli berørt av implementeringen av ny programvare. Faktisk er problemet som vi vurderer nå en rent menneskelig faktor, så det kan ikke unngås å analysere virkningen på ansatte. Vi har allerede nevnt noen av dem ovenfor.

• Bedriftsledere bestemmer hvordan den nye programvaren vil bli generelt akseptert. Og dette er ikke stedet for salgsfremmende taler og brennende taler - det er viktig å vise nøyaktig behovet for endring, for å formidle ideen om at dette bare er å velge et kulere og mer praktisk verktøy, det samme som å erstatte en gammel bærbar datamaskin. Ledelsens største feil i en slik situasjon er å vaske hendene og trekke seg selv: hvis ledelsen ikke trenger bedriftsautomatisering, hvorfor skulle det være av interesse for ansatte? Vær i prosessen.
• Avdelingsledere (prosjektledere) er et mellomledd som skal delta i alle prosesser, håndtere misnøye, vise vilje og jobbe gjennom enhver innvending fra kollegaer, samt drive høykvalitets og dybdeopplæring.
• IT-tjeneste (eller systemadministratorer) - ved første øyekast er dette dine tidlige fugler, de mest tilpasningsdyktige og tilpasningsdyktige, men... nei. Ofte, spesielt i små og mellomstore bedrifter, er systemadministratorer imot enhver endring (styrking) av IT-infrastrukturen, og dette skyldes ikke noen teknisk begrunnelse, men latskap og arbeidsmotvilje. Hvem av oss har ikke lett etter måter å unngå å jobbe på? Men la dette ikke være til skade for hele selskapet.
• Sluttbrukere ønsker som regel å jobbe godt og praktisk på den ene siden, og er, som alle levende mennesker, redde for endringer. Hovedargumentet for dem er ærlig og enkelt: hvorfor introduserer/endrer vi, hva er grensene for kontroll, hvordan skal arbeidet vurderes, hva vil endres og hva er risikoene (alle bør forresten vurdere risikoene - selv om vi er leverandører CRM-systemer, men vi forplikter oss ikke til å si at alt alltid går knirkefritt: det er risikoer i enhver prosess i en virksomhet).
• "Myndigheter" i selskapet er partisaner som kan påvirke andre ansatte. Dette er ikke nødvendigvis en person med en høy stilling eller lang erfaring - i tilfelle av arbeid med programvare kan "autoriteten" være en avansert kunnskapsrik som for eksempel har lest Habr på nytt og vil begynne å skremme alle om hvor ille alt vil bli. Han har kanskje ikke engang et mål om å ødelegge implementeringen eller overgangsprosessen - bare show-off og motstandsånden - og ansatte vil tro ham. Du må jobbe med slike ansatte: forklare, stille spørsmål, og i spesielt vanskelige tilfeller, hint om konsekvensene.

Det finnes en universell oppskrift for å sjekke om brukere virkelig er redde for noe eller om de har gruppeparanoia ledet av en kyndig leder. Spør dem om årsakene til misnøye, om bekymringer - hvis dette ikke er en personlig opplevelse eller mening, vil argumenter begynne å strømme inn etter 3-4 oppklarende spørsmål.

To viktige faktorer for å lykkes med å overvinne "motstandsbevegelsen".

1. Gi opplæring: leverandør og intern. Sørg for at ansatte virkelig forstår alt, har mestret det og, uavhengig av opplæringsnivå, er klare til å begynne å jobbe. En obligatorisk egenskap for opplæring er trykte og elektroniske instruksjoner (forskrifter) og den mest komplette dokumentasjonen på systemet (selvrespekterende leverandører gir den ut sammen med programvaren og gir den gratis).
2. Se etter støttespillere og velg influencere. Interne eksperter og tidlige brukere er støttesystemet ditt, som både lærer opp og fjerner tvil. Som regel hjelper ansatte selv gjerne sine kolleger og introduserer dem for ny programvare. Din oppgave er å midlertidig avlaste dem fra arbeidet eller gi dem en anstendig bonus for deres nye arbeidsmengde.

Hva må du være oppmerksom på?

1. Hvor avansert er de ansatte berørt av endringene? (Relativt sett, hvis de i morgen finner opp et nytt regnskapsprogram, gud forby deg å stikke nesen inn i regnskapsavdelingen med damer over 50 og foreslå en overgang fra 1C, kommer du ikke ut i live).
2. Hvor mye vil arbeidsflyten bli påvirket? En ting er å endre budbringeren i et selskap med 100 personer, en annen ting er å implementere et nytt CRM-system, som er basert på nøkkelprosesser i selskapet (og dette er ikke bare salg, for eksempel, implementering av RegionSoft CRM i seniorutgaver påvirker det produksjon, lager, markedsføring og toppledere som sammen med teamet skal bygge automatiserte forretningsprosesser).
3. Ble det gitt opplæring og på hvilket nivå?

Den eneste logiske overgangen i systemet for bedriftens tenkning

Hva vil spare overgangen/implementeringen av ny programvare?

Før vi forteller deg hvilke nøkkelpunkter som vil hjelpe deg komfortabelt å gå over til ny programvare, la oss trekke oppmerksomheten din til ett punkt. Det er noe som definitivt ikke bør gjøres - det er ingen grunn til å legge press på ansatte og "motivere" dem ved å frata dem bonuser, administrative og disiplinære sanksjoner. Dette vil ikke gjøre prosessen bedre, men holdningen til de ansatte vil forverres: hvis de presser på, så blir det kontroll; Hvis de tvinger deg, betyr det at de ikke respekterer vår interesse; Hvis de tvinger det til, betyr det at de ikke stoler på oss og arbeidet vårt. Derfor gjør vi alt på en disiplinert, tydelig, kompetent måte, men uten press eller unødvendig tvang.

Du må ha en detaljert handlingsplan

Alt annet finnes kanskje ikke, men det må være en plan. Planen er dessuten justerbar, oppdatert, klar og uunngåelig, samtidig tilgjengelig for diskusjon og transparent for alle interesserte ansatte. Det er umulig å direkte kommunisere at fra kl. 8 til kl. 10 er det en bragd, og kl. 16 er det krig med England; det er viktig å se hele planen i perspektiv.

Planen må nødvendigvis gjenspeile kravene til ansatte som skal være sluttbrukere - på denne måten vil hver ansatt vite nøyaktig hvilken funksjon som ønskes og på hvilket tidspunkt han vil kunne bruke den. Samtidig er ikke overgangs- eller implementeringsplanen en slags uforanderlig monolitt; det er nødvendig å la muligheten til å fullføre planen og endre dens attributter (men ikke i form av en endeløs strøm av redigeringer og nye "ønsker" og ikke i form av et konstant skifte i tidsfrister).  

Hva skal stå i planen?

1. De viktigste overgangsmilepælene (stadier) - hva må gjøres.
2. Detaljerte overgangspunkter for hvert trinn – hvordan det skal gjøres.
3. Sentrale punkter og rapportering på disse (timeavstemming) - hvordan det som er gjort vil måles og hvem som skal være på kontrollpunktet.
4. Ansvarlige mennesker er personer du kan henvende deg til og stille spørsmål fra.
5. Tidsfrister er begynnelsen og slutten av hvert trinn og hele prosessen som helhet.
6. Berørte prosesser - hvilke endringer vil skje i forretningsprosesser, hva som må endres sammen med implementeringen/overgangen.
7. Den endelige vurderingen er et sett med indikatorer, beregninger eller til og med subjektive vurderinger som vil bidra til å evaluere implementeringen/overgangen som har skjedd.
8. Driftsstart er den eksakte datoen når hele bedriften blir med i den oppdaterte automatiserte prosessen og jobber i det nye systemet.

Vi har kommet over presentasjoner av implementere der den røde linjen er råd: implementer med makt, ignorer reaksjonen, ikke snakk med ansatte. Vi er imot denne tilnærmingen, og her er hvorfor.

Se på bildet nedenfor:

En ny mus, et nytt tastatur, en leilighet, en bil og til og med en jobb er hyggelige, gledelige begivenheter, noen av dem er til og med prestasjoner. Og brukeren går til Yandex for å finne ut hvordan han kan venne seg til det og tilpasse seg. Hvordan gå inn i en ny leilighet og forstå at den er din, skru på kranen for første gang, drikke te, gå til sengs for første gang. Hvordan sette seg bak rattet og bli venner med en ny bil, din, men så langt så fremmed. Ny programvare på arbeidsplassen er ikke forskjellig fra situasjonene som er beskrevet: Arbeidstakerens jobb vil aldri bli den samme. Implementer, tilpass, voks med ny effektiv programvare. Og dette er en situasjon som vi kan si: skynd deg sakte.

Kilde: www.habr.com