Software leapfrog kommer snart att bli en mycket vanlig sjukdom hos företag. Att byta en mjukvara mot en annan på grund av varje liten sak, hoppa från teknik till teknik, experimentera med ett levande företag blir normen. Samtidigt börjar ett verkligt inbördeskrig på kontoret: en motståndsrörelse mot implementering bildas, partisaner bedriver subversivt arbete mot det nya systemet, spioner främjar en modig ny värld med ny programvara, ledning från pansarvagnen av företagsportalen sänder om fred, arbete, nyckeltal. En revolution slutar vanligtvis i ett totalt misslyckande på ena sidan.
Vi vet nästan allt om implementering, så låt oss försöka ta reda på hur man förvandlar en revolution till en utveckling och gör implementeringen så användbar och smärtfri som möjligt. Tja, eller åtminstone berättar vi vad du kan komma in på i processen.
Idealisk visualisering av anställdas acceptans av ny programvara Källa - Yandex.Images
Utländska konsulter skulle börja den här artikeln ungefär så här: "Om du erbjuder dina anställda kvalitetsmjukvara som kan förbättra deras arbete, har en kvalitativ inverkan på prestanda, kommer antagandet av ett nytt program eller system att ske naturligt." Men vi är i Ryssland, så frågan om misstänkta och krigförande anställda är mycket relevant. En naturlig övergång kommer inte att fungera, även med minimal programvara som en företagsbudbärare eller datortelefon.
Var kommer benen på problemet ifrån?
Idag har varje företag en hel zoo med programvara installerad (vi tar det allmänna fallet, eftersom mängden mjukvara i IT-företag är dubbel eller tredubblad, och anpassningsproblem överlappar delvis och är mycket specifika): projektledningssystem, CRM/ERP, e-postklienter, instant messengers, företagsportal, etc. Och detta räknar inte det faktum att det finns företag där till och med övergången från webbläsare till webbläsare utförs av hela teamet utan undantag (och det finns också team som är helt baserade på Internet Explorer Edge). I allmänhet finns det flera situationer som vår artikel kan vara användbar för:
- Det finns en process av primär automatisering av någon grupp av uppgifter: den första CRM/ERP implementeras, en företagsportal öppnas, ett system för teknisk support installeras, etc.;
- en programvara ersätts av en annan av någon anledning: inkurans, nya krav, skalning, förändring av aktivitet, etc.;
- moduler i det befintliga systemet byggs upp för utveckling och tillväxt (till exempel ett företag öppnade produktion och beslutade att byta från på med maximal funktionalitet);
- En stor uppdatering av gränssnitt och funktionell mjukvara pågår.
Naturligtvis är de två första fallen mycket mer akuta och typiska i sina manifestationer, var särskilt uppmärksam på dem.
Så, innan du börjar arbeta med teamet (som redan har misstänkt att det kommer att bli förändringar snart), försök att förstå vad de verkliga anledningarna till att ändra programvaran är och om du håller med om att ändringarna är så nödvändiga.
- Det gamla programmet är svårt att arbeta med: det är dyrt, obekvämt, icke-funktionellt, uppfyller inte längre dina krav, är inte lämpligt för din skala, etc. Detta är en objektiv nödvändighet.
- Säljaren slutade stödja systemet, eller så förvandlades support och modifieringar till en oändlig serie av godkännanden och pengar. Om dina kostnader har ökat rejält, och i framtiden lovar de att öka ännu mer, finns det inget att vänta på, du måste skära. Ja, ett nytt system kommer också att kosta pengar, men i slutändan kommer optimering att kosta mindre än sådant stöd.
- Att byta mjukvara är en persons eller grupp anställdas infall. Till exempel vill CTO:n ha en rollback och lobbar för införandet av ett nytt, dyrare system – detta sker i stora företag. Ett annat exempel: en projektledare förespråkar att byta Asana till Basecamp, sedan Basecamp till Jira och komplexet Jira till Wrike. Ofta är det enda motivet för sådana migrationer att visa upp sitt hektiska arbete och behålla sin position. I sådana fall är det nödvändigt att fastställa graden av nödvändighet, motiv och berättigande och, som regel, genom ett starkt beslut att vägra ändringar.
Vi talar om orsakerna till övergången från en mjukvara till en annan, och inte om primär automatisering - bara för att automatisering är a priori nödvändig. Om ditt företag gör något manuellt och rutinmässigt men skulle kunna automatiseras, slösar du helt enkelt bort tid, pengar och, med största sannolikhet, värdefull företagsdata. Automatisera det!
Hur kan du korsa: det stora språnget eller den hukande tigern?
I världspraxis finns det tre huvudstrategier för att byta till ny mjukvara och anpassa sig till den - och de verkar väldigt lämpliga för oss, så låt oss inte uppfinna hjulet på nytt.
Big Bang
Adoption med "Big Bang"-metoden är den svåraste möjliga övergången, när du ställer in ett exakt datum och genomför en kraftig migrering, vilket inaktiverar den gamla programvaran till 100 %.
Fördelar
+ Alla arbetar i ett system, det finns inget behov av att synkronisera data, anställda behöver inte övervaka två gränssnitt samtidigt.
+ Enkelhet för administratören - en migrering, en uppgift, ett systemstöd.
+ Alla möjliga förändringar inträffar vid en tidpunkt och märks nästan omedelbart - det finns ingen anledning att isolera vad och i vilken andel som påverkade produktivitet, utvecklingshastighet, försäljning etc.
Nackdelar
— Fungerar framgångsrikt endast med enkel programvara: chattar, företagsportal, snabbmeddelanden. Även e-post kan redan misslyckas, för att inte tala om projektledningssystem, CRM/ERP och andra seriösa system.
— En explosiv migration från ett stort system till ett annat kommer oundvikligen att orsaka kaos.
Det viktigaste för den här typen av övergång till en ny arbetsmiljö är träning.
Parallelllöpning
Parallell anpassning till mjukvara är en mjukare och mer universell övergångsmetod, där en tidsperiod ställs in under vilken båda systemen ska fungera samtidigt.
Fördelar
+ Användare har tillräckligt med tid att vänja sig vid den nya mjukvaran samtidigt som de snabbt arbetar i den gamla, hittar paralleller och förstår den nya logiken för interaktion med gränssnittet.
+ Vid plötsliga problem fortsätter de anställda att arbeta i det gamla systemet.
+ Användarutbildning är mindre rigorös och generellt sett billigare.
+ Det finns praktiskt taget ingen negativ reaktion från anställda - trots allt blev de inte berövade sina vanliga verktyg eller sätt att göra saker (om automatisering sker för första gången).
Nackdelar
— Administrationsproblem: stöd för båda systemen, datasynkronisering, säkerhetshantering i två applikationer samtidigt.
— Övergångsprocessen sträcker sig ut i det oändliga - anställda inser att de har nästan en evighet kvar, och de kan utöka användningen av det välbekanta gränssnittet lite mer.
- Användarförvirring - De två gränssnitten är förvirrande och orsakar drifts- och datafel.
- Pengar. Du betalar för båda systemen.
Fasad adoption
Steg-för-steg-anpassning är det mjukaste alternativet för att byta till ny mjukvara. Övergången utförs funktionellt, inom specificerade tidsperioder och per avdelning (till exempel från 1 juni lägger vi till nya kunder endast i det nya CRM-systemet, från 20 juni genomför vi transaktioner i det nya systemet, till 1 augusti överför vi kalendrar och fall, och senast den 30 september slutför vi migreringen är en mycket grov beskrivning, men allmänt tydlig).
Fördelar
+ Organiserad övergång, fördelad belastning mellan administratörer och interna experter.
+ Mer genomtänkt och djupgående lärande.
+ Det finns inget motstånd mot förändring, eftersom det sker så skonsamt som möjligt.
Nackdelar - ungefär samma som för en parallell övergång.
Så nu, bara en gradvis övergång?
En logisk fråga, du håller med. Varför ha lite extra krångel när du kan göra ett schema och agera enligt en tydlig plan? Faktum är att allt inte är så enkelt.
- Programvarukomplexitet: om vi talar om komplex programvara (till exempel, ), då är fasanpassning mer lämplig. Om programvaran är enkel (messenger, företagsportal) så är en lämplig modell när du tillkännager datum och inaktiverar den gamla programvaran på den utsatta dagen (om du har tur kommer anställda att ha tid att ta fram all information de behöver , och om du inte räknar med tur, måste du tillhandahålla automatisk import nödvändig data från det gamla systemet till det nya, om det är tekniskt möjligt).
- Graden av risk för företaget: ju mer riskfylld implementeringen är, desto långsammare bör den gå. Å andra sidan är försening också en risk: till exempel byter du från ett CRM-system till ett annat, och under övergångsperioden tvingas du betala för båda, vilket ökar kostnaderna och kostnaderna för att implementera det nya systemet, vilket innebär att återbetalningstiden förlängs.
- Antal anställda: Big Bang är definitivt inte lämpligt om du behöver skala och konfigurera många användarprofiler. Även om det finns fall då ultrasnabb implementering är en fördel för ett stort företag. Det här alternativet kan vara lämpligt för system som används av många anställda, men kanske inte har krav eftersom anpassning inte är avsedd. Men återigen, detta är en stor skräll för slutanvändarna och ett enormt steg-för-steg-arbete för samma IT-tjänst (till exempel fakturering eller åtkomstsystem).
- Funktioner för implementeringen av den valda programvaran (revision, etc.). Ibland sker implementeringen initialt stegvis – med kravinsamling, förfining, utbildning m.m. Till exempel, det implementeras alltid progressivt, och om någon lovar dig "implementering och konfiguration inom 3 dagar eller till och med 3 timmar" - kom ihåg den här artikeln och kringgå sådana tjänster: installation ≠ implementering.
Återigen, även om man känner till de listade parametrarna, kan man inte definitivt ta en eller annan väg. Utvärdera din företagsmiljö – detta kommer att hjälpa dig både att förstå maktbalansen och avgöra vilken modell (eller kombination av några av deras element) som är rätt för dig.
Agenter för inflytande: revolution eller evolution
Det första du bör vara uppmärksam på är de anställda som kommer att påverkas av implementeringen av ny programvara. Faktum är att problemet som vi överväger nu är en rent mänsklig faktor, så det går inte att undvika att analysera påverkan på anställda. Vi har redan nämnt några av dem ovan.
- Företagsledare bestämmer hur den nya mjukvaran kommer att accepteras allmänt. Och det här är inte platsen för reklamtal och eldtal - det är viktigt att visa exakt behovet av förändring, för att förmedla tanken att detta bara är att välja ett coolare och bekvämare verktyg, samma som att byta ut en gammal bärbar dator. Ledningens största misstag i en sådan situation är att tvätta händerna och dra sig tillbaka: om ledningen inte behöver företagsautomatisering, varför skulle det vara av intresse för de anställda? Var i processen.
- Avdelningschefer (projektledare) är en mellanlänk som ska delta i alla processer, hantera missnöje, visa vilja och arbeta igenom varje invändning från kollegor samt bedriva högkvalitativ och fördjupad utbildning.
- IT-tjänst (eller systemadministratörer) - vid första anblicken är dessa dina tidiga fåglar, de mest anpassningsbara och anpassningsbara, men... nej. Ofta, särskilt i små och medelstora företag, motsätter sig systemadministratörer alla förändringar (förstärkningar) av IT-infrastrukturen, och det beror inte på någon teknisk motivering, utan på lättja och ovilja att arbeta. Vem av oss har inte letat efter sätt att undvika att arbeta? Men låt detta inte vara till nackdel för hela företaget.
- Slutanvändare vill som regel arbeta bra och bekvämt å ena sidan och är, som alla levande människor, rädda för förändringar. Huvudargumentet för dem är ärligt och enkelt: varför inför/förändrar vi, vilka är gränserna för kontroll, hur kommer arbetet att bedömas, vad kommer att förändras och vilka är riskerna (förresten, alla borde utvärdera riskerna - även om vi är säljare , men vi åtar oss inte att säga att allt alltid går smidigt: det finns risker i alla processer inom ett företag).
- "Myndigheter" inom företaget är partisaner som kan påverka andra anställda. Det här är inte nödvändigtvis en person med en hög position eller lång erfarenhet - i fallet med att arbeta med mjukvara kan "auktoriteten" vara en avancerad kunnig person som till exempel har läst om Habr och kommer att börja skrämma alla om hur illa allt kommer att bli. Han kanske inte ens har ett mål att förstöra implementeringen eller övergångsprocessen - bara visa upp och andan av motstånd - och anställda kommer att tro honom. Du måste arbeta med sådana anställda: förklara, ifrågasätta och i särskilt svåra fall tipsa om konsekvenserna.
Det finns ett universellt recept för att kontrollera om användare verkligen är rädda för något eller om de har gruppparanoia ledd av en kunnig ledare. Fråga dem om orsakerna till missnöje, om oro - om detta inte är en personlig upplevelse eller åsikt kommer argument att börja strömma in efter 3-4 förtydligande frågor.
Två viktiga faktorer för att framgångsrikt övervinna "motståndsrörelsen".
- Ge utbildning: leverantör och intern. Se till att medarbetarna verkligen förstår allt, har bemästrat det och, oavsett utbildningsnivå, är redo att börja arbeta. Ett obligatoriskt attribut för utbildning är tryckta och elektroniska instruktioner (föreskrifter) och den mest kompletta dokumentationen om systemet (leverantörer med självrespekt släpper den tillsammans med programvaran och tillhandahåller den gratis).
- Leta efter supportrar och välj influencers. Interna experter och tidiga användare är ditt stödsystem, som både utbildar och undanröjer tvivel. Som regel hjälper de anställda själva gärna sina kollegor och introducerar dem för ny programvara. Din uppgift är att tillfälligt befria dem från deras arbete eller ge dem en anständig bonus för deras nya arbetsbörda.
Vad behöver du vara uppmärksam på?
- Hur långt framme berörs medarbetarna av förändringarna? (Relativt sett, om de imorgon uppfinner ett nytt redovisningsprogram, gud förbjude att du sticker in näsan i redovisningsavdelningen med damer över 50 och föreslår en övergång från 1C, kommer du inte ut levande).
- Hur mycket kommer arbetsflöden att påverkas? Det är en sak att ändra budbäraren i ett företag med 100 personer, en annan sak är att implementera ett nytt CRM-system, som är baserat på nyckelprocesser i företaget (och detta är inte bara försäljning, till exempel, i seniorutgåvor påverkar det produktion, lager, marknadsföring och toppchefer som tillsammans med teamet kommer att bygga automatiserade affärsprocesser).
- Erbjöds utbildning och på vilken nivå?
Den enda logiska övergången i systemet för företagstänkande
Vad kommer att rädda övergången/implementeringen av ny programvara?
Innan vi berättar vilka nyckelpunkter som hjälper dig att bekvämt gå över till ny programvara, låt oss fästa din uppmärksamhet på en punkt. Det finns något som definitivt inte bör göras - det finns ingen anledning att sätta press på anställda och "motivera" dem genom att beröva dem bonusar, administrativa och disciplinära sanktioner. Detta kommer inte att göra processen bättre, men de anställdas attityd kommer att försämras: om de trycker på, kommer det att finnas kontroll; Om de tvingar dig betyder det att de inte respekterar vårt intresse; Om de tvingar på det betyder det att de inte litar på oss och vårt arbete. Därför gör vi allt på ett disciplinerat, tydligt, kompetent sätt, men utan press eller onödigt tvång.
Du måste ha en detaljerad handlingsplan
Allt annat kanske inte finns, men det måste finnas en plan. Dessutom är planen justerbar, uppdaterad, tydlig och oundviklig, samtidigt tillgänglig för diskussion och transparent för alla intresserade medarbetare. Det är omöjligt att direkt kommunicera att det är en bragd från 8 till 10, och klockan 16 är det krig med England, det är viktigt att se hela planen i perspektiv.
Planen måste nödvändigtvis återspegla kraven från anställda som kommer att vara slutanvändare - på detta sätt kommer varje anställd att veta exakt vilken önskad funktion och vid vilken tidpunkt han kommer att kunna använda den. Samtidigt är övergångs- eller implementeringsplanen inte någon form av oföränderlig monolit; det är nödvändigt att lämna möjligheten att slutföra planen och ändra dess attribut (men inte i form av en oändlig ström av redigeringar och nya "önskningar" och inte i form av en konstant förskjutning av deadlines).
Vad ska stå i planen?
- De viktigaste övergångsmilstolparna (etapperna) - vad som behöver göras.
- Detaljerade övergångspunkter för varje steg – hur det ska göras.
- Nyckelpunkter och rapportering om dem (avstämning av timmar) - hur det som gjorts kommer att mätas och vem som ska vara på kontrollpunkten.
- Ansvarsfulla personer är människor du kan vända dig till och ställa frågor från.
- Deadlines är början och slutet av varje steg och hela processen som helhet.
- Berörda processer - vilka förändringar som kommer att ske i affärsprocesser, vad som behöver förändras tillsammans med implementeringen/övergången.
- Den slutliga bedömningen är en uppsättning indikatorer, mätetal eller till och med subjektiva bedömningar som hjälper till att utvärdera implementeringen/övergången som har inträffat.
- Driftstart är det exakta datumet då hela företaget ska gå med i den uppdaterade automatiserade processen och arbeta i det nya systemet.
Vi har stött på presentationer av implementerare där den röda linjen är råd: implementera med våld, strunta i reaktionen, prata inte med anställda. Vi är emot detta tillvägagångssätt, och här är varför.
Titta på bilden nedan:
En ny mus, ett nytt tangentbord, en lägenhet, en bil och till och med ett jobb är trevliga, glada händelser, några av dem är till och med prestationer. Och användaren går till Yandex för att ta reda på hur man vänjer sig och anpassar sig. Hur man går in i en ny lägenhet och förstår att den är din, slår på kranen för första gången, dricker te, går och lägger sig för första gången. Hur man sätter sig bakom ratten och blir vän med en ny bil, din, men än så länge främmande. Ny programvara på arbetsplatsen skiljer sig inte från de beskrivna situationerna: den anställdes jobb kommer aldrig att bli detsamma. Därför implementera, anpassa, växa med ny effektiv programvara. Och detta är en situation som vi kan säga: skynda långsamt.
Källa: will.com