Աշխատակիցները չեն ցանկանում նոր ծրագրային ապահովում. պե՞տք է նրանք հետևեն առաջնորդությանը, թե՞ հավատարիմ մնան իրենց գծին:

Ծրագրային թռիչքը շուտով կդառնա ընկերությունների շատ տարածված հիվանդություն: Ամեն փոքր բանի պատճառով մեկ ծրագրաշարը մյուսով փոխելը, տեխնոլոգիայից տեխնոլոգիա անցնելը, կենդանի բիզնեսի հետ փորձարկումները դառնում են նորմ: Միևնույն ժամանակ, գրասենյակում սկսվում է իսկական քաղաքացիական պատերազմ. ձևավորվում է իրականացման դիմադրության շարժում, պարտիզանները դիվերսիոն աշխատանք են իրականացնում նոր համակարգի դեմ, լրտեսները նոր ծրագրային ապահովմամբ խթանում են խիզախ նոր աշխարհը, կառավարումը զրահամեքենայից։ կորպորատիվ պորտալը հեռարձակում է խաղաղության, աշխատանքի, KPI-ների մասին: Հեղափոխությունը սովորաբար ավարտվում է մի կողմից լիակատար ձախողմամբ:

Մենք գիտենք գրեթե ամեն ինչ իրականացման մասին, ուստի եկեք փորձենք պարզել, թե ինչպես կարելի է հեղափոխությունը վերածել էվոլյուցիայի և հնարավորինս օգտակար և ցավոտ դարձնել իրականացումը: Դե, կամ գոնե մենք ձեզ կասենք, թե ինչի մեջ կարող եք հայտնվել այդ գործընթացում:

Աշխատակիցների կողմից նոր ծրագրաշարի ընդունման իդեալական վիզուալիզացիա Աղբյուրը՝ Yandex.Images

Օտարերկրյա խորհրդատուները այս հոդվածը կսկսեն այսպես. «Եթե ձեր աշխատակիցներին առաջարկեք որակյալ ծրագրակազմ, որը կարող է բարելավել նրանց աշխատանքը, որակական ազդեցություն ունենալ կատարողականի վրա, նոր ծրագրի կամ համակարգի ընդունումը բնականաբար տեղի կունենա»: Բայց մենք Ռուսաստանում ենք, ուստի կասկածելի ու ռազմատենչ աշխատակիցների հարցը շատ ակտուալ է։ Բնական անցումը չի աշխատի, նույնիսկ նվազագույն ծրագրային ապահովման դեպքում, ինչպիսիք են կորպորատիվ մեսենջերը կամ փափուկ հեռախոսը:

Որտեղի՞ց են գալիս խնդրի ոտքերը:

Այսօր յուրաքանչյուր ընկերություն ունի տեղադրված ծրագրային ապահովման մի ամբողջ կենդանաբանական այգի (մենք վերցնում ենք ընդհանուր դեպքը, քանի որ ՏՏ ընկերություններում ծրագրաշարի քանակը կրկնակի կամ եռակի է, իսկ հարմարվողականության խնդիրները մասամբ համընկնում են և շատ կոնկրետ են). նախագծերի կառավարման համակարգեր, CRM/ERP, էլփոստի հաճախորդներ, ակնթարթային մեսենջերներ, կորպորատիվ պորտալ և այլն: Եվ սա չհաշված այն փաստը, որ կան ընկերություններ, որոնցում նույնիսկ բրաուզերից բրաուզերի անցումը կատարվում է ամբողջ թիմի կողմից առանց բացառության (և կան նաև թիմեր, որոնք ամբողջությամբ հիմնված են Internet Explorer Edge-ի վրա): Ընդհանուր առմամբ, կան մի քանի իրավիճակներ, որոնց համար մեր հոդվածը կարող է օգտակար լինել.

• Գոյություն ունի որոշակի խմբի առաջադրանքների առաջնային ավտոմատացման գործընթաց. ներդրվում է առաջին CRM/ERP-ը, բացվում է կորպորատիվ պորտալ, տեղադրվում է տեխնիկական աջակցության համակարգ և այլն;
• մի ծրագրաշարը ինչ-ինչ պատճառներով փոխարինվում է մյուսով.
• գոյություն ունեցող համակարգի մոդուլները կառուցվում են զարգացման և աճի նպատակներով (օրինակ, ընկերությունը բացեց արտադրությունը և որոշեց անցնել RegionSoft CRM պրոֆեսիոնալ մասին RegionSoft CRM Enterprise Plus առավելագույն ֆունկցիոնալությամբ);
• Կատարվում է հիմնական ինտերֆեյսի և ֆունկցիոնալ ծրագրաշարի թարմացում:

Իհարկե, առաջին երկու դեպքերն իրենց դրսեւորումներով շատ ավելի սուր են ու բնորոշ, հատուկ ուշադրություն դարձրեք դրանց։

Այսպիսով, նախքան թիմի հետ աշխատելը (որոնք արդեն կասկածում են, որ շուտով փոփոխություններ կլինեն), փորձեք հասկանալ, թե որոնք են ծրագրաշարը փոխելու իրական պատճառները և արդյոք համաձայն եք, որ փոփոխություններն այդքան անհրաժեշտ են:

• Հին ծրագրի հետ դժվար է աշխատել՝ այն թանկ է, անհարմար, ոչ ֆունկցիոնալ, այլևս չի համապատասխանում ձեր պահանջներին, հարմար չէ ձեր մասշտաբին և այլն։ Սա օբյեկտիվ անհրաժեշտություն է։
• Վաճառողը դադարեց աջակցել համակարգին, կամ աջակցությունն ու փոփոխությունները վերածվել են հաստատումների և փողերի անվերջանալի շարքի: Եթե ​​ձեր ծախսերը զգալիորեն ավելացել են, իսկ ապագայում խոստանում են էլ ավելի մեծանալ, սպասելու բան չկա, պետք է կրճատել։ Այո, նոր համակարգը նույնպես գումար կարժենա, բայց ի վերջո օպտիմալացումը կարժենա ավելի քիչ, քան նման աջակցությունը։
• Ծրագրային ապահովման փոփոխությունը մեկ անձի կամ աշխատակիցների խմբի քմահաճույքն է: Օրինակ, CTO-ն ցանկանում է հետաձգել և լոբբինգ է անում նոր, ավելի թանկ համակարգի ներդրման համար. դա տեղի է ունենում խոշոր ընկերություններում: Մեկ այլ օրինակ. ծրագրի ղեկավարը պաշտպանում է Asana-ն փոխել Basecamp-ի, այնուհետև Basecamp-ը Jira-ի և կոմպլեքս Jira-ին Wrike-ի: Հաճախ նման միգրացիաների միակ շարժառիթը իրենց զբաղված աշխատանքը ցուցադրելն ու դիրքերը պահպանելն է։ Նման դեպքերում անհրաժեշտ է որոշել անհրաժեշտության աստիճանը, դրդապատճառներն ու հիմնավորումը և, որպես կանոն, փոփոխություններից հրաժարվելու կամային վճռականությամբ։

Խոսքը մի ծրագրաշարից մյուսին անցնելու պատճառների մասին է, այլ ոչ թե առաջնային ավտոմատացման, միայն այն պատճառով, որ ավտոմատացումը ապրիորի անհրաժեշտություն է։ Եթե ​​ձեր ընկերությունը ինչ-որ բան անում է ձեռքով և կանոնավոր կերպով, բայց կարող է ավտոմատացվել, դուք պարզապես ժամանակ, գումար և, ամենայն հավանականությամբ, ընկերության արժեքավոր տվյալներ եք վատնում: Ավտոմատացրեք այն:

Ինչպե՞ս կարող ես անցնել՝ մեծ ցատկը, թե՞ կռացած վագրը:

Համաշխարհային պրակտիկայում կան երեք հիմնական ռազմավարություններ՝ նոր ծրագրակազմին անցնելու և դրան հարմարվելու համար, և դրանք մեզ շատ հարմար են թվում, ուստի եկեք չվերագտնենք անիվը:

Big Bang

«Մեծ պայթյուն» մեթոդով ընդունումը հնարավոր ամենադժվար անցումն է, երբ դուք ճշգրիտ ամսաթիվ եք սահմանում և կատարում եք կտրուկ միգրացիա՝ 100%-ով անջատելով հին ծրագրաշարը։

Կոալիցիայում

+ Բոլորն աշխատում են մեկ համակարգում, տվյալների համաժամացման կարիք չկա, աշխատակիցները պետք չէ վերահսկել միանգամից երկու ինտերֆեյս:
+ Պարզություն ադմինիստրատորի համար՝ մեկ միգրացիա, մեկ առաջադրանք, մեկ համակարգի աջակցություն:
+ Բոլոր հնարավոր փոփոխությունները տեղի են ունենում ժամանակի մեկ կետում և նկատելի են գրեթե անմիջապես. կարիք չկա առանձնացնել, թե ինչ և ինչ համամասնությամբ է ազդել արտադրողականության, զարգացման արագության, վաճառքի և այլնի վրա:

Դեմ

— Հաջողությամբ աշխատում է միայն պարզ ծրագրաշարով՝ չաթեր, կորպորատիվ պորտալ, ակնթարթային մեսենջերներ: Նույնիսկ էլփոստը կարող է արդեն ձախողվել, էլ չեմ խոսում նախագծերի կառավարման համակարգերի, CRM/ERP-ի և այլ լուրջ համակարգերի մասին:
— Պայթուցիկ միգրացիան մեծ համակարգից մյուսն անխուսափելիորեն քաոս կառաջացնի:

Այս տեսակի նոր աշխատանքային միջավայրի անցման համար ամենակարեւորը վերապատրաստումն է:

Զուգահեռ վազք

Ծրագրային ապահովման հետ զուգահեռ հարմարեցումը անցումային ավելի մեղմ և ունիվերսալ մեթոդ է, որի ժամանակ սահմանվում է ժամանակաշրջան, որի ընթացքում երկու համակարգերը կգործեն միաժամանակ:

Կոալիցիայում

+ Օգտատերերը բավական ժամանակ ունեն նոր ծրագրաշարին ընտելանալու՝ հինում արագ աշխատելու, զուգահեռներ գտնելու և ինտերֆեյսի հետ փոխգործակցության նոր տրամաբանությունը հասկանալու համար:
+ Հանկարծակի խնդիրների դեպքում աշխատակիցները շարունակում են աշխատել հին համակարգով.
+ Օգտագործողների ուսուցումն ավելի քիչ խիստ է և, ընդհանուր առմամբ, ավելի էժան:
+ Աշխատակիցների կողմից գործնականում ոչ մի բացասական արձագանք չկա. ի վերջո, նրանք չեն զրկվել իրենց սովորական գործիքներից կամ գործելակերպից (եթե ավտոմատացումը տեղի է ունենում առաջին անգամ):

Դեմ

— Կառավարման խնդիրներ. երկու համակարգերի աջակցություն, տվյալների համաժամացում, անվտանգության կառավարում միանգամից երկու հավելվածում:
— Անցումային գործընթացը ձգվում է անվերջ. աշխատակիցները գիտակցում են, որ իրենց մնացել է գրեթե մեկ հավերժություն, և նրանք կարող են մի փոքր ավելի երկարացնել ծանոթ ինտերֆեյսի օգտագործումը:
- Օգտագործողի շփոթություն - Երկու միջերեսները շփոթեցնող են և առաջացնում են գործառնական և տվյալների սխալներ:
- Փող. Դուք վճարում եք երկու համակարգերի համար:

Փուլային ընդունում

Քայլ առ քայլ հարմարեցումը նոր ծրագրային ապահովմանն անցնելու ամենափափուկ տարբերակն է: Անցումը կատարվում է ֆունկցիոնալ, սահմանված ժամկետներում և ըստ ստորաբաժանումների (օրինակ՝ հունիսի 1-ից նոր հաճախորդներ ենք ավելացնում միայն նոր CRM համակարգում, հունիսի 20-ից գործարքներ ենք իրականացնում նոր համակարգով, մինչև օգոստոսի 1-ը փոխանցում ենք օրացույցներ։ և դեպքերը, և մինչև սեպտեմբերի 30-ը մենք ավարտում ենք միգրացիան, շատ կոպիտ նկարագրություն է, բայց ընդհանուր առմամբ պարզ):

Կոալիցիայում

+ Կազմակերպված անցում, բաշխված բեռ ադմինիստրատորների և ներքին փորձագետների միջև:
+ Ավելի մտածված և խորը ուսուցում:
+ Փոփոխություններին դիմադրություն չկա, քանի որ այն տեղի է ունենում հնարավորինս նրբանկատորեն:

Դեմ - մոտավորապես նույնը, ինչ զուգահեռ անցման դեպքում:

Այսպիսով, հիմա պարզապես աստիճանական անցում.

Տրամաբանական հարց, կհամաձայնեք։ Ինչու՞ ստանալ լրացուցիչ դժվարություններ, երբ կարող եք ժամանակացույց կազմել և գործել ըստ հստակ պլանի: Իրականում ամեն ինչ այդքան էլ պարզ չէ։

• Ծրագրաշարի բարդություն. եթե մենք խոսում ենք բարդ ծրագրաշարի մասին (օրինակ. CRM համակարգ), ապա փուլային ադապտացիան ավելի հարմար է։ Եթե ​​ծրագրաշարը պարզ է (մեսենջեր, կորպորատիվ պորտալ), ապա հարմար մոդելն այն է, երբ դուք հայտարարում եք ամսաթիվը և անջատում եք հին ծրագրակազմը նշանակված օրը (եթե ձեր բախտը բերել է, աշխատակիցները ժամանակ կունենան հանելու իրենց անհրաժեշտ բոլոր տեղեկությունները: , և եթե բախտի վրա հույս չունեք, ապա պետք է տրամադրեք ավտոմատացված ներմուծման անհրաժեշտ տվյալներ հին համակարգից նորին, եթե տեխնիկապես հնարավոր է):
• Ռիսկի աստիճանը ընկերության համար. որքան ռիսկային է իրականացումը, այնքան ավելի դանդաղ պետք է լինի: Մյուս կողմից, ուշացումը նույնպես ռիսկ է. օրինակ՝ դուք մի CRM համակարգից անցնում եք մյուսին, և անցումային շրջանում ստիպված եք վճարել երկուսի համար՝ դրանով իսկ ավելացնելով նոր համակարգի ներդրման ծախսերն ու ծախսերը, ինչը. նշանակում է, որ մարման ժամկետը երկարացվել է:
• Աշխատակիցների թիվը. Big Bang-ը հաստատ հարմար չէ, եթե Ձեզ անհրաժեշտ է չափել և կարգավորել օգտվողների բազմաթիվ պրոֆիլներ: Թեև կան դեպքեր, երբ ծայրահեղ արագ իրականացումը օգուտ է մեծ ընկերության համար։ Այս տարբերակը կարող է հարմար լինել համակարգերի համար, որոնք օգտագործվում են բազմաթիվ աշխատակիցների կողմից, բայց կարող են պահանջներ չունենալ, քանի որ հարմարեցումը նախատեսված չէ: Բայց կրկին, սա մեծ պայթյուն է վերջնական օգտագործողների համար և հսկայական քայլ առ քայլ աշխատանք նույն ՏՏ ծառայության համար (օրինակ՝ վճարումների կամ մուտքի համակարգ):
• Ընտրված ծրագրաշարի ներդրման առանձնահատկությունները (վերանայում և այլն): Երբեմն իրականացումն ի սկզբանե փուլ առ փուլ է՝ պահանջների հավաքագրմամբ, ճշգրտմամբ, վերապատրաստմամբ և այլն: Օրինակ, CRM համակարգ այն միշտ իրականացվում է աստիճանաբար, և եթե որևէ մեկը ձեզ խոստանում է «իրականացում և կազմաձևում 3 օրում կամ նույնիսկ 3 ժամում», հիշեք այս հոդվածը և շրջանցեք այդպիսի ծառայությունները՝ տեղադրում ≠ իրականացում:

Կրկին, նույնիսկ թվարկված պարամետրերը իմանալով, չի կարելի միանշանակ գնալ այս կամ այն ​​ճանապարհով: Գնահատեք ձեր կորպորատիվ միջավայրը. սա կօգնի ձեզ հասկանալ ուժերի հավասարակշռությունը և որոշել, թե որ մոդելը (կամ դրանց որոշ տարրերի համակցությունն է) ճիշտ ձեզ համար:

Ազդեցության գործակալները՝ հեղափոխություն կամ էվոլյուցիա

Առաջին բանը, որին դուք պետք է ուշադրություն դարձնեք, աշխատակիցներն են, որոնց վրա կազդի նոր ծրագրային ապահովման ներդրումը։ Փաստորեն, խնդիրը, որ մենք հիմա քննարկում ենք, զուտ մարդկային գործոն է, ուստի աշխատակիցների վրա ազդեցությունը վերլուծելուց հնարավոր չէ խուսափել։ Դրանցից մի քանիսը վերևում արդեն նշել ենք։

• Ընկերության ղեկավարները որոշում են, թե ինչպես կընդունվի նոր ծրագրակազմը: Եվ սա գովազդային ելույթների և բոցաշունչ ելույթների տեղը չէ. կարևոր է հենց ցույց տալ փոփոխությունների անհրաժեշտությունը, փոխանցել այն միտքը, որ սա պարզապես ավելի սառը և հարմար գործիք ընտրելն է, նույնը, ինչ հին նոութբուքը փոխարինելը: Նման իրավիճակում ղեկավարության ամենամեծ սխալը ձեռքերը լվանալն ու ինքնաբացարկն է. եթե ղեկավարությունը ընկերության ավտոմատացման կարիք չունի, ինչո՞ւ դա պետք է հետաքրքրի աշխատակիցներին: Եղեք գործընթացի մեջ:
• Դեպարտամենտի ղեկավարները (նախագծերի ղեկավարները) միջանկյալ օղակ են, որը պետք է մասնակցի բոլոր գործընթացներին, կառավարի դժգոհությունը, կամք դրսևորի և աշխատի գործընկերների յուրաքանչյուր առարկության դեմ և անցկացնի բարձրորակ և խորը ուսուցում:
• ՏՏ ծառայություն (կամ համակարգի ադմինիստրատորներ) - առաջին հայացքից սրանք ձեր վաղ թռչուններն են, ամենահարմարվողն ու հարմարվողը, բայց... ոչ։ Հաճախ, հատկապես փոքր և միջին ընկերություններում, համակարգային ադմինիստրատորները դեմ են ՏՏ ենթակառուցվածքի ցանկացած փոփոխության (ուժեղացման) և դա պայմանավորված է ոչ թե տեխնիկական հիմնավորմամբ, այլ ծուլությամբ և աշխատելու դժկամությամբ։ Մեզանից ո՞վ չի փնտրել աշխատանքից խուսափելու ուղիներ: Բայց դա թող չլինի ի վնաս ողջ ընկերության։
• Վերջնական օգտվողները, որպես կանոն, ցանկանում են մի կողմից լավ և հարմարավետ աշխատել և, ինչպես ցանկացած կենդանի մարդ, վախենում են փոփոխություններից: Նրանց հիմնական փաստարկն ազնիվ է և պարզ՝ ինչու ենք մենք ներմուծում/փոխում, վերահսկողության որո՞նք են սահմանները, ինչպես է գնահատվելու աշխատանքը, ինչ է փոխվելու և որոնք են ռիսկերը (ի դեպ, ռիսկերը պետք է գնահատեն բոլորը. չնայած մենք վաճառող ենք CRM համակարգեր, բայց մենք չենք պարտավորվում ասել, որ ամեն ինչ միշտ հարթ է ընթանում. բիզնեսի ցանկացած գործընթացում ռիսկեր կան):
• Ընկերության ներսում «հեղինակությունները» կուսակցականներ են, որոնք կարող են ազդել այլ աշխատակիցների վրա: Պարտադիր չէ, որ սա բարձր պաշտոն կամ մեծ փորձ ունեցող անձնավորություն է. ծրագրային ապահովման հետ աշխատելու դեպքում «հեղինակությունը» կարող է լինել առաջադեմ ամեն ինչ, ով, օրինակ, վերընթերցել է Habr-ը և կսկսի վախեցնել: բոլորը այն մասին, թե որքան վատ է դառնալու ամեն ինչ. Նա կարող է նույնիսկ նպատակ չունենա փչացնել իրականացման կամ անցումային գործընթացը՝ պարզապես ցուցադրական ցուցադրություն և դիմադրության ոգի, և աշխատակիցները կհավատան նրան: Նման աշխատողների հետ պետք է աշխատել՝ բացատրել, հարցադրել և հատկապես դժվար դեպքերում ակնարկել հետևանքների մասին։

Գոյություն ունի ունիվերսալ բաղադրատոմս՝ ստուգելու, թե արդյոք օգտատերերն իսկապես վախենում են ինչ-որ բանից, թե արդյոք նրանք ունեն խմբակային պարանոյա, որը ղեկավարում է խելամիտ առաջնորդը: Հարցրեք նրանց դժգոհության պատճառների, մտահոգությունների մասին. եթե դա անձնական փորձ կամ կարծիք չէ, ապա վեճերը կսկսեն թափվել 3-4 պարզաբանող հարցերից հետո:

«Դիմադրության շարժումը» հաջողությամբ հաղթահարելու երկու կարևոր գործոն.

1. Տրամադրել ուսուցում՝ վաճառող և ներքին: Համոզվեք, որ աշխատակիցներն իսկապես հասկանում են ամեն ինչ, տիրապետում են դրան և, անկախ իրենց պատրաստվածության մակարդակից, պատրաստ են սկսել աշխատել։ Դասընթացի պարտադիր հատկանիշը տպագիր և էլեկտրոնային հրահանգներն են (կանոնակարգերը) և համակարգի վերաբերյալ առավել ամբողջական փաստաթղթերը (իրեն հարգող վաճառողները թողարկում են այն ծրագրաշարի հետ միասին և տրամադրում անվճար):
2. Փնտրեք աջակիցներ և ընտրեք ազդեցիկներին: Ներքին փորձագետները և վաղ որդեգրողները ձեր աջակցության համակարգն են՝ և՛ կրթող, և՛ կասկածները փարատող: Որպես կանոն, աշխատակիցներն իրենք հաճույքով օգնում են իրենց գործընկերներին և ծանոթացնում նրանց նոր ծրագրերին: Ձեր խնդիրն է ժամանակավորապես ազատել նրանց աշխատանքից կամ արժանապատիվ բոնուս տալ նոր ծանրաբեռնվածության համար:

Ինչ պետք է ուշադրություն դարձնել:

1. Որքա՞ն առաջադեմ են աշխատողների վրա ազդել փոփոխությունները: (Համեմատաբար, եթե վաղը նոր հաշվապահական ծրագիր հորինեն, Աստված չանի, որ 50-ն անց տիկնանց հետ քիթը խոթես հաշվապահական բաժին և առաջարկես անցում 1C-ից, դու կենդանի դուրս չես գա):
2. Որքա՞ն կազդեն աշխատանքային հոսքերի վրա: Մի բան է փոխել մեսենջերը 100 հոգանոց ընկերությունում, մեկ այլ բան՝ նոր CRM համակարգի ներդրումն է, որը հիմնված է ընկերության հիմնական գործընթացների վրա (և սա միայն վաճառքը չէ, օրինակ. RegionSoft CRM-ի իրականացում ավագ հրատարակություններում այն ​​ազդում է արտադրության, պահեստի, շուկայավարման և թոփ մենեջերների վրա, ովքեր թիմի հետ միասին կկառուցեն ավտոմատացված բիզնես գործընթացներ):
3. Անցկացվե՞լ է վերապատրաստում և ի՞նչ մակարդակով:

Միակ տրամաբանական անցումը կորպորատիվ մտածողության համակարգում

Ի՞նչը կփրկի նոր ծրագրային ապահովման անցումը/ներդրումը:

Նախքան ձեզ ասելը, թե որ հիմնական կետերը կօգնեն ձեզ հարմարավետորեն տեղափոխվել նոր ծրագրակազմ, եկեք ձեր ուշադրությունը հրավիրենք մեկ կետի վրա: Կա մի բան, որը հաստատ չի կարելի անել՝ կարիք չկա աշխատողների վրա ճնշում գործադրել և «մոտիվացնել»՝ զրկելով հավելավճարներից, վարչական և կարգապահական տույժերից։ Սա ոչ թե գործընթացը կլավացնի, այլ աշխատակիցների վերաբերմունքը կվատթարանա. եթե հրում են, ուրեմն վերահսկողություն կլինի. Եթե ​​քեզ պարտադրում են, նշանակում է՝ չեն հարգում մեր շահը. Եթե ​​ստիպողաբար պարտադրում են, նշանակում է՝ չեն վստահում մեզ և մեր աշխատանքին։ Ուստի մենք ամեն ինչ անում ենք կարգապահ, հստակ, գրագետ, բայց առանց ճնշումների կամ ավելորդ պարտադրանքի։

Դուք պետք է ունենաք մանրամասն գործողությունների ծրագիր

Մնացած ամեն ինչ կարող է չլինել, բայց պետք է ծրագիր լինի։ Ավելին, պլանը կարգավորելի է, թարմացված, հստակ և անխուսափելի, միաժամանակ՝ քննարկման համար մատչելի և թափանցիկ բոլոր շահագրգիռ աշխատակիցների համար։ Անհնար է հրահանգավոր կերպով հաղորդել, որ առավոտյան ժամը 8-ից մինչև առավոտյան 10-ը սխրանք է, իսկ ժամը 16:00-ին պատերազմ է Անգլիայի հետ, կարևոր է տեսնել ամբողջ պլանը հեռանկարում:

Պլանը պետք է անպայմանորեն արտացոլի այն աշխատակիցների պահանջները, ովքեր կլինեն վերջնական օգտագործողներ. այս կերպ յուրաքանչյուր աշխատակից հստակ կիմանա, թե ինչ հատկանիշ է ցանկալի և որ ժամին կկարողանա օգտագործել այն: Միևնույն ժամանակ, անցումային կամ իրականացման պլանը ինչ-որ անփոփոխ մոնոլիտ չէ, անհրաժեշտ է թողնել պլանը վերջնական տեսքի բերելու և դրա հատկանիշները փոխելու հնարավորությունը (բայց ոչ խմբագրումների և նոր «ցանկությունների» անվերջանալի հոսքի տեսքով։ և ոչ ժամկետների անընդհատ փոփոխության տեսքով):  

Ի՞նչ պետք է լինի պլանում:

1. Հիմնական անցումային փուլերը (փուլերը) - ինչ պետք է արվի:
2. Մանրամասն անցումային կետեր յուրաքանչյուր փուլի համար՝ ինչպես դա պետք է արվի:
3. Հիմնական կետերը և դրանց վերաբերյալ հաշվետվությունները (ժամերի համաձայնեցում) - ինչպես է չափվելու կատարվածը և ով պետք է լինի հսկիչ կետում:
4. Պատասխանատու մարդիկ այն մարդիկ են, որոնց կարող եք դիմել և հարցեր տալ:
5. Ժամկետները յուրաքանչյուր փուլի և ամբողջ գործընթացի սկիզբն ու ավարտն են:
6. Ազդեցության ենթարկված գործընթացներ. ինչ փոփոխություններ են տեղի ունենալու բիզնես գործընթացներում, ինչ պետք է փոխվի իրականացման/անցման հետ մեկտեղ:
7. Վերջնական գնահատումը ցուցիչների, չափումների կամ նույնիսկ սուբյեկտիվ գնահատումների մի շարք է, որը կօգնի գնահատել տեղի ունեցած իրականացումը/անցումը:
8. Գործարկման սկիզբը ճշգրիտ ամսաթիվն է, երբ ամբողջ ընկերությունը կմիանա նորացված ավտոմատացված գործընթացին և կաշխատի նոր համակարգում:

Հանդիպել ենք իրականացնողների ներկայացումների, որոնցում կարմիր գիծը խորհուրդն է՝ ուժով իրականացնել, անտեսել արձագանքը, չխոսել աշխատակիցների հետ։ Մենք դեմ ենք այս մոտեցմանը, և ահա թե ինչու.

Նայեք ստորև ներկայացված նկարին.

Նոր մկնիկը, նոր ստեղնաշարը, բնակարանը, մեքենան և նույնիսկ աշխատանքը հաճելի, ուրախ իրադարձություններ են, որոշները նույնիսկ ձեռքբերումներ են: Իսկ օգտատերը գնում է Յանդեքս՝ պարզելու, թե ինչպես վարժվել դրան և հարմարվել։ Ինչպես մտնել նոր բնակարան և հասկանալ, որ այն քոնն է, առաջին անգամ բացել ծորակը, խմել թեյ, առաջին անգամ գնալ քնելու։ Ինչպես նստել ղեկին և ընկերանալ նոր մեքենայի հետ՝ քոնը, բայց առայժմ այդքան խորթ: Աշխատավայրում նոր ծրագրակազմը չի տարբերվում նկարագրված իրավիճակներից. աշխատողի աշխատանքը երբեք նույնը չի լինի: Հետևաբար, ներդրեք, հարմարեցրեք, աճեք նոր արդյունավետ ծրագրերով: Եվ սա մի իրավիճակ է, որի մասին կարելի է ասել՝ կամաց շտապե՛ք։

Source: www.habr.com