Softwarespring vil snart blive en meget almindelig sygdom hos virksomheder. At ændre en software til en anden på grund af hver lille ting, at hoppe fra teknologi til teknologi, eksperimentere med en levende virksomhed er ved at blive normen. Samtidig begynder en ægte borgerkrig på kontoret: en modstandsbevægelse mod implementering dannes, partisaner udfører subversivt arbejde mod det nye system, spioner promoverer en modig ny verden med ny software, styring fra panservognen. virksomhedsportalen udsender om fred, arbejdskraft, KPI'er. En revolution ender normalt i fuldstændig fiasko på den ene side.
Vi ved næsten alt om implementering, så lad os prøve at finde ud af, hvordan man gør en revolution til en udvikling og gør implementeringen så nyttig og smertefri som muligt. Nå, eller i det mindste fortæller vi dig, hvad du kan komme ind på i processen.
Ideel visualisering af medarbejdernes accept af ny software Kilde - Yandex.Images
Udenlandske konsulenter ville starte denne artikel sådan her: "Hvis du tilbyder dine medarbejdere kvalitetssoftware, der kan forbedre deres arbejde, have en kvalitativ indvirkning på ydeevnen, vil vedtagelsen af et nyt program eller system ske naturligt." Men vi er i Rusland, så spørgsmålet om mistænkelige og krigsførende medarbejdere er meget relevant. En naturlig overgang vil ikke fungere, selv med minimal software såsom en virksomheds messenger eller softphone.
Hvor kommer benene til problemet fra?
I dag har hver virksomhed en hel zoologisk have af software installeret (vi tager det generelle tilfælde, for i IT-virksomheder er mængden af software dobbelt eller tredobbelt, og tilpasningsproblemer overlapper delvist og er meget specifikke): projektstyringssystemer, CRM/ERP, e-mail-klienter, instant messengers, virksomhedsportal osv. Og dette tæller ikke det faktum, at der er virksomheder, hvor selv overgangen fra browser til browser udføres af hele teamet uden undtagelse (og der er også hold, der er fuldstændig baseret på Internet Explorer Edge). Generelt er der flere situationer, hvor vores artikel kan være nyttig:
- processen med primær automatisering af en bestemt gruppe af opgaver finder sted: den første CRM/ERP er ved at blive implementeret, en virksomhedsportal åbnes, et system til teknisk support installeres osv.;
- en software erstattes af en anden af en eller anden grund: forældelse, nye krav, skalering, ændring af aktivitet osv.;
- moduler af det eksisterende system er ved at blive bygget op med henblik på udvikling og vækst (for eksempel åbnede en virksomhed produktion og besluttede at skifte fra på med maksimal funktionalitet);
- En større grænseflade og funktionel softwareopdatering finder sted.
Selvfølgelig er de to første tilfælde meget mere akutte og typiske i deres manifestationer, vær særlig opmærksom på dem.
Så før du begynder at arbejde med teamet (som allerede har mistanke om, at der snart vil ske ændringer), prøv at forstå, hvad de reelle grunde til at ændre softwaren er, og om du er enig i, at ændringerne er så nødvendige.
- Det gamle program er svært at arbejde med: det er dyrt, ubelejligt, ikke-funktionelt, opfylder ikke længere dine krav, passer ikke til din skala osv. Dette er en objektiv nødvendighed.
- Sælgeren holdt op med at understøtte systemet, eller support og ændringer blev til en endeløs række af godkendelser og pengedræning. Hvis dine omkostninger er steget markant, og i fremtiden lover de at stige endnu mere, er der ikke noget at vente på, du skal skære. Ja, et nyt system vil også koste penge, men i sidste ende vil optimering koste mindre end en sådan support.
- Ændring af software er en persons eller gruppe af medarbejderes indfald. Eksempelvis ønsker CTO en tilbagerulning og lobbyer for indførelse af et nyt, dyrere system – det sker i store virksomheder. Et andet eksempel: en projektleder går ind for at ændre Asana til Basecamp, derefter Basecamp til Jira og komplekse Jira til Wrike. Ofte er det eneste motiv for sådanne migrationer at vise deres travle arbejde og bevare deres position. I sådanne tilfælde er det nødvendigt at bestemme graden af nødvendighed, motiver og begrundelse og som regel ved en viljestærk beslutning om at afvise ændringer.
Vi taler om årsagerne til overgangen fra en software til en anden, og ikke om primær automatisering – kun fordi automatisering er på forhånd nødvendig. Hvis din virksomhed gør noget manuelt og rutinemæssigt, men kunne automatiseres, spilder du simpelthen tid, penge og højst sandsynligt værdifulde virksomhedsdata. Automatiser det!
Hvordan kan du krydse: det store spring eller den krumbøjede tiger?
I verdenspraksis er der tre hovedstrategier til at skifte til ny software og tilpasse sig den - og de virker meget velegnede for os, så lad os ikke genopfinde hjulet.
Stort brag
Adoption ved hjælp af "Big Bang"-metoden er den sværest mulige overgang, når du sætter en nøjagtig dato og gennemfører en skarp migrering, der deaktiverer den gamle software 100%.
Pros
+ Alle arbejder i ét system, der er ingen grund til at synkronisere data, medarbejderne behøver ikke at overvåge to grænseflader på én gang.
+ Enkelhed for administratoren - én migrering, én opgave, én systemunderstøttelse.
+ Alle mulige ændringer sker på et tidspunkt og er mærkbare næsten øjeblikkeligt - der er ingen grund til at isolere, hvad og i hvilken andel påvirkede produktivitet, udviklingshastighed, salg osv.
Cons
— Fungerer kun med succes med simpel software: chats, virksomhedsportal, instant messengers. Selv e-mail kan allerede fejle, for ikke at nævne projektstyringssystemer, CRM/ERP og andre seriøse systemer.
— En eksplosiv migration fra et stort system til et andet vil uundgåeligt forårsage kaos.
Det vigtigste for denne type overgang til et nyt arbejdsmiljø er træning.
Parallel løb
Parallel tilpasning til software er en blødere og mere universel overgangsmetode, hvor der er fastsat en tidsperiode, hvor begge systemer vil fungere samtidigt.
Pros
+ Brugere har tid nok til at vænne sig til den nye software, mens de hurtigt arbejder i den gamle, finder paralleller og forstår den nye logik i interaktion med grænsefladen.
+ Ved pludselige problemer fortsætter medarbejderne med at arbejde i det gamle system.
+ Brugeruddannelse er mindre streng og generelt billigere.
+ Der er praktisk talt ingen negativ reaktion fra medarbejderne - de blev trods alt ikke frataget deres sædvanlige værktøjer eller måde at gøre tingene på (hvis automatisering sker for første gang).
Cons
— Administrationsproblemer: understøttelse af begge systemer, datasynkronisering, sikkerhedsstyring i to applikationer på én gang.
— Omstillingsprocessen strækker sig uendeligt - medarbejderne indser, at de har næsten en evighed tilbage, og de kan udvide brugen af den velkendte grænseflade lidt mere.
- Brugerforvirring - De to grænseflader er forvirrende og forårsager drifts- og datafejl.
- Penge. Du betaler for begge systemer.
Faseadoption
Trin-for-trin tilpasning er den blødeste mulighed for at skifte til ny software. Overgangen udføres funktionelt, inden for bestemte tidsrum og efter afdeling (f.eks. tilføjer vi fra 1. juni kun nye kunder til det nye CRM-system, fra 20. juni udfører vi transaktioner i det nye system, indtil 1. august overfører vi kalendere og sager, og inden den 30. september afslutter vi migreringen er en meget grov beskrivelse, men generelt klar).
Pros
+ Organiseret overgang, fordelt belastning blandt administratorer og interne eksperter.
+ Mere gennemtænkt og dybdegående læring.
+ Der er ingen modstand mod forandring, fordi det sker så skånsomt som muligt.
Cons - omtrent det samme som for en parallel overgang.
Så nu, bare en gradvis overgang?
Et logisk spørgsmål, du er enig. Hvorfor få noget ekstra besvær, når du kan lave en tidsplan og handle efter en klar plan? Faktisk er alt ikke så simpelt.
- Softwarekompleksitet: hvis vi taler om kompleks software (f.eks. ), så er fasetilpasning mere egnet. Hvis softwaren er enkel (messenger, virksomhedsportal), så er en passende model, når du annoncerer datoen og deaktiverer den gamle software på den aftalte dag (hvis du er heldig, vil medarbejderne have tid til at hente al den information, de har brug for , og hvis du ikke regner med held, så skal du give automatisk import nødvendige data fra det gamle system til det nye, hvis det er teknisk muligt).
- Graden af risiko for virksomheden: Jo mere risikofyldt implementeringen er, jo langsommere bør den være. På den anden side er forsinkelse også en risiko: For eksempel skifter du fra et CRM-system til et andet, og i overgangsperioden er du tvunget til at betale for begge, og derved øger omkostningerne og omkostningerne ved at implementere det nye system, hvilket betyder, at tilbagebetalingsperioden forlænges.
- Antal ansatte: Big Bang egner sig bestemt ikke, hvis du skal skalere og konfigurere mange brugerprofiler. Selvom der er tilfælde, hvor ultrahurtig implementering er en fordel for en stor virksomhed. Denne mulighed kan være velegnet til systemer, der bruges af mange medarbejdere, men har muligvis ikke krav, fordi tilpasning ikke er tilsigtet. Men igen, dette er et stort brag for slutbrugere og et kæmpe trin-for-trin arbejde for den samme IT-service (f.eks. fakturering eller adgangssystem).
- Funktioner ved implementeringen af den valgte software (revision osv.). Nogle gange er implementeringen i første omgang etapevis – med kravindsamling, finpudsning, træning mv. For eksempel, det implementeres altid gradvist, og hvis nogen lover dig "implementering og konfiguration på 3 dage eller endda 3 timer" - husk denne artikel og omgå sådanne tjenester: installation ≠ implementering.
Igen, selv om man kender de anførte parametre, kan man bestemt ikke tage den ene eller den anden vej. Vurder dit virksomhedsmiljø - dette vil hjælpe dig både med at forstå magtbalancen og bestemme, hvilken model (eller kombination af nogle af deres elementer) der er den rigtige for dig.
Påvirkningsagenter: revolution eller evolution
Det første, du skal være opmærksom på, er de medarbejdere, der vil blive berørt af implementeringen af ny software. Faktisk er det problem, vi overvejer nu, udelukkende en menneskelig faktor, så det kan ikke undgås at analysere påvirkningen af medarbejderne. Vi har allerede nævnt nogle af dem ovenfor.
- Virksomhedsledere bestemmer, hvordan den nye software generelt vil blive accepteret. Og dette er ikke stedet for salgsfremmende taler og brændende taler - det er vigtigt at vise præcis behovet for forandring, for at formidle ideen om, at dette bare er at vælge et sejere og mere praktisk værktøj, det samme som at erstatte en gammel bærbar computer. Ledelsens største fejl i en sådan situation er at vaske hænder og trække sig selv: Hvis ledelsen ikke har brug for virksomhedsautomatisering, hvorfor skulle det så være interessant for medarbejderne? Vær i gang.
- Afdelingsledere (projektledere) er et mellemled, der skal deltage i alle processer, styre mistrivsel, vise vilje og gennemarbejde enhver indvending fra kollegaer samt gennemføre en dybdegående uddannelse af høj kvalitet.
- IT-service (eller systemadministratorer) - ved første øjekast er det dine tidlige fugle, de mest tilpasningsdygtige og tilpasningsdygtige, men... nej. Ofte, især i små og mellemstore virksomheder, er systemadministratorer imod enhver ændring (styrkelse) af IT-infrastrukturen, og det skyldes ikke nogen teknisk begrundelse, men dovenskab og arbejdsmodvilje. Hvem af os har ikke ledt efter måder at undgå at arbejde på? Men lad dette ikke være til skade for hele virksomheden.
- Slutbrugere ønsker som regel at arbejde godt og bekvemt på den ene side og er, som alle nulevende mennesker, bange for forandringer. Hovedargumentet for dem er ærligt og enkelt: hvorfor indfører/ændrer vi, hvad er grænserne for kontrol, hvordan vil arbejdet blive vurderet, hvad vil ændre sig, og hvad er risiciene (alle bør i øvrigt vurdere risiciene - selvom vi er sælgere , men vi forpligter os ikke til at sige, at alt altid går glat: der er risici i enhver proces i en virksomhed).
- "Myndigheder" i virksomheden er partisaner, der kan påvirke andre medarbejdere. Dette er ikke nødvendigvis en person med en høj stilling eller stor erfaring - i tilfælde af at arbejde med software kan "autoriteten" være en avanceret know-it-all, som for eksempel har genlæst Habr og vil begynde at skræmme alle om, hvor slemt alting vil blive. Han har måske ikke engang et mål om at ødelægge implementeringen eller overgangsprocessen - bare show-off og modstandsånden - og medarbejderne vil tro på ham. Du skal arbejde med sådanne medarbejdere: forklar, spørg, og i særligt vanskelige tilfælde, antyd konsekvenserne.
Der er en universel opskrift på at tjekke, om brugere virkelig er bange for noget, eller om de har gruppeparanoia ledet af en kyndig leder. Spørg dem om årsagerne til utilfredsheden, om bekymringer – hvis dette ikke er en personlig oplevelse eller mening, vil der begynde at vælte argumenter ind efter 3-4 opklarende spørgsmål.
To vigtige faktorer for succesfuldt at overvinde "modstandsbevægelsen".
- Give undervisning: leverandør og intern. Sørg for, at medarbejderne virkelig forstår alt, har mestret det og, uanset deres uddannelsesniveau, er klar til at begynde at arbejde. En obligatorisk egenskab for uddannelse er trykte og elektroniske instruktioner (regulativer) og den mest komplette dokumentation på systemet (selvrespekterende leverandører frigiver den sammen med softwaren og leverer den gratis).
- Se efter tilhængere og vælg influencers. Interne eksperter og tidlige brugere er dit supportsystem, der både opdrager og fjerner tvivl. Som regel hjælper medarbejderne selv gerne deres kollegaer og introducerer dem til ny software. Din opgave er midlertidigt at aflaste dem fra deres arbejde eller give dem en anstændig bonus for deres nye arbejdsbyrde.
Hvad skal du være opmærksom på?
- Hvor avancerede er medarbejderne påvirket af ændringerne? (Relativt set, hvis de i morgen opfinder et nyt regnskabsprogram, gud forbyde, at du stikker næsen ind i regnskabsafdelingen med damer over 50 og foreslår en overgang fra 1C, kommer du ikke ud i live).
- Hvor meget vil arbejdsgange blive påvirket? En ting er at ændre budbringeren i en virksomhed med 100 personer, en anden ting er at implementere et nyt CRM-system, som er baseret på nøgleprocesser i virksomheden (og det er ikke kun salg, f.eks. i seniorudgaver påvirker det produktions-, lager-, marketing- og topledere, som sammen med teamet skal bygge automatiserede forretningsprocesser).
- Blev der givet undervisning og på hvilket niveau?
Den eneste logiske overgang i virksomhedens tænkningssystem
Hvad vil spare overgangen/implementeringen af ny software?
Før vi fortæller dig, hvilke nøglepunkter der vil hjælpe dig komfortabelt med at flytte til ny software, så lad os henlede din opmærksomhed på ét punkt. Der er noget, der absolut ikke bør gøres - der er ingen grund til at lægge pres på medarbejderne og "motivere" dem ved at fratage dem bonusser, administrative og disciplinære sanktioner. Dette vil ikke gøre processen bedre, men medarbejdernes holdning vil forværres: hvis de presser, så vil der være kontrol; Hvis de tvinger dig, betyder det, at de ikke respekterer vores interesser; Hvis de med magt påtvinger det, betyder det, at de ikke har tillid til os og vores arbejde. Derfor gør vi alt på en disciplineret, overskuelig, kompetent måde, men uden pres eller unødvendige forcering.
Du skal have en detaljeret handlingsplan
Alt andet eksisterer måske ikke, men der skal være en plan. Desuden er planen justerbar, opdateret, klar og uundgåelig, samtidig tilgængelig til diskussion og gennemsigtig for alle interesserede medarbejdere. Det er umuligt at kommunikere direkte, at der er en bedrift fra kl. 8 til kl. 10, og kl. 16 er der krig med England; det er vigtigt at se hele planen i perspektiv.
Planen skal nødvendigvis afspejle kravene fra medarbejdere, der skal være slutbrugere - på denne måde vil hver medarbejder vide præcis, hvilken funktion, han ønsker, og på hvilket tidspunkt han vil være i stand til at bruge den. Samtidig er overgangs- eller implementeringsplanen ikke en form for uforanderlig monolit; det er nødvendigt at efterlade muligheden for at færdiggøre planen og ændre dens attributter (men ikke i form af en endeløs strøm af redigeringer og nye "ønsker" og ikke i form af et konstant skift i deadlines).
Hvad skal der stå i planen?
- De vigtigste overgangsmilepæle (stadier) - hvad skal der gøres.
- Detaljerede overgangspunkter for hvert trin - hvordan det skal gøres.
- Nøglepunkter og rapportering om dem (timeafstemning) - hvordan det udførte vil blive målt og hvem der skal være i kontrolpunktet.
- Ansvarlige mennesker er mennesker, du kan henvende dig til og stille spørgsmål fra.
- Deadlines er begyndelsen og slutningen af hver fase og hele processen som helhed.
- Berørte processer - hvilke ændringer vil der ske i forretningsprocesser, hvad skal ændres sammen med implementeringen/overgangen.
- Den endelige vurdering er et sæt af indikatorer, målinger eller endda subjektive vurderinger, der vil hjælpe med at evaluere implementeringen/overgangen, der har fundet sted.
- Driftsstart er den nøjagtige dato, hvor hele virksomheden tilslutter sig den opdaterede automatiserede proces og arbejder i det nye system.
Vi er stødt på præsentationer af implementere, hvor den røde linje er råd: implementer med magt, ignorer reaktionen, tal ikke med medarbejderne. Vi er imod denne tilgang, og her er hvorfor.
Se på billedet herunder:
En ny mus, et nyt tastatur, en lejlighed, en bil og endda et job er behagelige, glædelige begivenheder, nogle af dem er endda præstationer. Og brugeren går til Yandex for at finde ud af, hvordan man vænner sig til det og tilpasser sig. Sådan kommer du ind i en ny lejlighed og forstår, at den er din, åbner hanen for første gang, drikker te, går i seng for første gang. Sådan sætter du dig bag rattet og bliver venner med en ny bil, din, men indtil videre så fremmed. Ny software på arbejdspladsen adskiller sig ikke fra de beskrevne situationer: medarbejderens job bliver aldrig det samme. Derfor skal du implementere, tilpasse, vokse med ny effektiv software. Og dette er en situation, som vi kan sige: skynd dig langsomt.
Kilde: www.habr.com