कर्मचारीहरू नयाँ सफ्टवेयर चाहँदैनन् - के तिनीहरूले नेतृत्वलाई पछ्याउन वा तिनीहरूको लाइनमा अडिग रहनुपर्छ?

सफ्टवेयर लीपफ्रग चाँडै कम्पनीहरूको धेरै सामान्य रोग बन्नेछ। हरेक सानो कुराको लागि एउटा सफ्टवेयरलाई अर्कोको लागि परिवर्तन गर्ने, प्रविधिबाट प्रविधिमा हाम फाल्ने, प्रत्यक्ष व्यवसायको साथ प्रयोग गर्ने सामान्य बन्दै गएको छ। उही समयमा, कार्यालयमा वास्तविक गृहयुद्ध सुरु हुन्छ: कार्यान्वयनको प्रतिरोधको आन्दोलन गठन हुन्छ, पक्षपातहरूले नयाँ प्रणालीको विरुद्ध विध्वंसक कार्यहरू सञ्चालन गर्दैछन्, जासूसहरूले नयाँ सफ्टवेयरको साथ बहादुर नयाँ संसारलाई बढावा दिइरहेका छन्, बख्तरबंद कारबाट व्यवस्थापन। कर्पोरेट पोर्टलले शान्ति, श्रम, केपीआईहरू बारे प्रसारण गर्दैछ। क्रान्ति सामान्यतया एकतर्फ पूर्ण असफलतामा समाप्त हुन्छ।

हामीलाई कार्यान्वयनको बारेमा लगभग सबै थाहा छ, त्यसैले क्रान्तिलाई कसरी विकासमा परिणत गर्ने र कार्यान्वयनलाई सकेसम्म उपयोगी र पीडारहित बनाउने प्रयास गरौं। ठिक छ, वा कम्तिमा हामी तपाईंलाई यस प्रक्रियामा के प्राप्त गर्न सक्नुहुन्छ भनेर बताउनेछौं।

नयाँ सफ्टवेयरको कर्मचारी स्वीकृतिको आदर्श दृश्य स्रोत - Yandex.Images

विदेशी सल्लाहकारहरूले यस लेखलाई यसरी सुरु गर्नेछन्: "यदि तपाईंले आफ्ना कर्मचारीहरूलाई गुणस्तरीय सफ्टवेयर प्रस्ताव गर्नुहुन्छ जसले उनीहरूको काममा सुधार गर्न सक्छ, कार्यसम्पादनमा गुणात्मक प्रभाव पार्छ, नयाँ कार्यक्रम वा प्रणाली अपनाउने स्वाभाविक रूपमा हुनेछ।" तर हामी रूसमा छौं, त्यसैले शंकास्पद र युद्धरत कर्मचारीहरूको मुद्दा धेरै सान्दर्भिक छ। कर्पोरेट मेसेन्जर वा सफ्टफोन जस्ता न्यूनतम सफ्टवेयरको साथमा पनि प्राकृतिक संक्रमणले काम गर्दैन।

समस्याको खुट्टा कहाँबाट आउँछ?

आज, प्रत्येक कम्पनीमा सफ्टवेयर स्थापना गरिएको छ (हामी सामान्य मामला लिन्छौं, किनभने आईटी कम्पनीहरूमा सफ्टवेयरको मात्रा दोब्बर वा तीन गुणा हुन्छ, र अनुकूलन समस्याहरू आंशिक रूपमा ओभरल्याप हुन्छन् र धेरै विशिष्ट हुन्छन्): परियोजना व्यवस्थापन प्रणाली, CRM/ERP, इमेल क्लाइन्टहरू, इन्स्ट्यान्ट मेसेन्जरहरू, कर्पोरेट पोर्टल, आदि। र यो तथ्यलाई गणना गर्दैन कि त्यहाँ कम्पनीहरू छन् जसमा ब्राउजरबाट ब्राउजरमा ट्रान्जिसन पनि अपवाद बिना सम्पूर्ण टोलीद्वारा गरिन्छ (र त्यहाँ टोलीहरू पनि छन् जुन पूर्ण रूपमा इन्टरनेट एक्सप्लोरर एजमा आधारित छन्)। सामान्यतया, त्यहाँ धेरै परिस्थितिहरू छन् जसको लागि हाम्रो लेख उपयोगी हुन सक्छ:

• त्यहाँ कार्यहरूको केही समूहको प्राथमिक स्वचालनको प्रक्रिया छ: पहिलो CRM/ERP कार्यान्वयन भइरहेको छ, कर्पोरेट पोर्टल खोल्दै छ, प्राविधिक समर्थनको लागि प्रणाली स्थापना भइरहेको छ, आदि।
• एउटा सफ्टवेयर कुनै कारणको लागि अर्को द्वारा प्रतिस्थापन गरिएको छ: अप्रचलित, नयाँ आवश्यकताहरू, स्केलिंग, गतिविधि परिवर्तन, आदि।
• अवस्थित प्रणालीको मोड्युलहरू विकास र वृद्धिको उद्देश्यका लागि निर्माण भइरहेका छन् (उदाहरणका लागि, एक कम्पनीले उत्पादन खोल्यो र बाट स्विच गर्ने निर्णय गर्यो। RegionSoft CRM प्रोफेशनल मा RegionSoft CRM उद्यम प्लस अधिकतम कार्यक्षमता संग);
• एक प्रमुख इन्टरफेस र कार्यात्मक सफ्टवेयर अपडेट भइरहेको छ।

निस्सन्देह, पहिलो दुई केसहरू तिनीहरूको अभिव्यक्तिमा धेरै तीव्र र विशिष्ट छन्, तिनीहरूलाई विशेष ध्यान दिनुहोस्।

त्यसोभए, तपाईंले टोलीसँग काम सुरु गर्नु अघि (जसले पहिले नै परिवर्तनहरू हुनेछन् भन्ने शंका गरेका छन्), सफ्टवेयर परिवर्तन गर्नुको वास्तविक कारणहरू के हुन् र तपाईं परिवर्तनहरू आवश्यक छ भनी सहमत हुनुहुन्छ कि भनेर बुझ्न प्रयास गर्नुहोस्।

• पुरानो कार्यक्रमसँग काम गर्न गाह्रो छ: यो महँगो, असुविधाजनक, गैर-कार्यात्मक छ, अब तपाईंको आवश्यकताहरू पूरा गर्दैन, तपाईंको स्केलको लागि उपयुक्त छैन, आदि। यो वस्तुगत आवश्यकता हो।
• विक्रेताले प्रणालीलाई समर्थन गर्न बन्द गर्यो, वा समर्थन र परिमार्जनहरू अनुमोदन र पैसा निकासीको अनन्त श्रृंखलामा परिणत भयो। यदि तपाईंको लागतहरू उल्लेखनीय रूपमा बढेको छ, र भविष्यमा उनीहरूले अझ बढि बढाउने वाचा गर्छन्, त्यहाँ पर्खन केही छैन, तपाईंले कटौती गर्न आवश्यक छ। हो, नयाँ प्रणालीले पनि पैसा खर्च गर्नेछ, तर अन्तमा अप्टिमाइजेसनले यस्तो समर्थन भन्दा कम खर्च गर्नेछ।
• सफ्टवेयर परिवर्तन गर्नु भनेको एक व्यक्ति वा कर्मचारीहरूको समूहको इच्छा हो। उदाहरणका लागि, CTO ले रोलब्याक चाहन्छ र नयाँ, अधिक महँगो प्रणालीको परिचयको लागि लबिङ गरिरहेको छ - यो ठूला कम्पनीहरूमा हुन्छ। अर्को उदाहरण: एक परियोजना प्रबन्धकले आसनलाई बेसक्याम्प, त्यसपछि बेसक्याम्पलाई जिरा र जटिल जिरालाई राइकमा परिवर्तन गर्ने वकालत गर्दछ। प्रायः यस्ता बसाइँसराइहरूको एउटै उद्देश्य भनेको आफ्नो व्यस्त काम देखाउनु र आफ्नो स्थिति कायम राख्नु हो। यस्तो अवस्थामा, यो आवश्यकता, मनसाय र औचित्य को डिग्री निर्धारण गर्न आवश्यक छ र, एक नियम को रूप मा, परिवर्तन अस्वीकार गर्न को लागी एक बलियो इच्छा निर्णय द्वारा।

हामी एक सफ्टवेयरबाट अर्को सफ्टवेयरमा संक्रमणको कारणहरूको बारेमा कुरा गर्दैछौं, र प्राथमिक स्वचालनको बारेमा होइन - केवल किनभने स्वचालन एक प्राथमिकता आवश्यक छ। यदि तपाइँको कम्पनीले म्यानुअल र नियमित रूपमा केहि गर्छ भने, तर स्वचालित हुन सक्छ, तपाइँ केवल समय, पैसा र, सम्भवतः, बहुमूल्य कम्पनी डेटा बर्बाद गर्दै हुनुहुन्छ। यसलाई स्वचालित गर्नुहोस्!

तपाईं कसरी पार गर्न सक्नुहुन्छ: ठूलो छलांग वा घुम्ने बाघ?

विश्व अभ्यासमा, नयाँ सफ्टवेयरमा स्विच गर्न र यसलाई अनुकूलन गर्नका लागि तीनवटा मुख्य रणनीतिहरू छन् - र तिनीहरू हामीलाई धेरै उपयुक्त देखिन्छन्, त्यसैले हामी पाङ्ग्रालाई पुन: आविष्कार नगरौं।

बिग बैंग

पुरानो सफ्टवेयर १००% असक्षम पारेर, तपाईंले सही मिति सेट गर्दा र तीव्र माइग्रेसन गर्दा, "बिग ब्याङ्ग" विधि प्रयोग गर्नु सबैभन्दा कठिन सम्भव संक्रमण हो।

Плюсы

+ सबैजना एउटै प्रणालीमा काम गर्दछ, त्यहाँ डाटा सिंक्रोनाइज गर्न आवश्यक छैन, कर्मचारीहरूले एकैचोटि दुई इन्टरफेसहरू निगरानी गर्न आवश्यक छैन।
+ प्रशासकको लागि सरलता - एक माइग्रेसन, एक कार्य, एक प्रणाली समर्थन।
+ सबै सम्भावित परिवर्तनहरू समयको एक बिन्दुमा हुन्छन् र लगभग तुरुन्तै देख्न सकिन्छ - त्यहाँ कुन र कुन अनुपातमा उत्पादकता, विकासको गति, बिक्री, इत्यादिलाई असर गर्छ भनेर अलग गर्न आवश्यक छैन।

Минусы

- सरल सफ्टवेयरको साथ मात्र सफलतापूर्वक काम गर्दछ: च्याटहरू, कर्पोरेट पोर्टल, तत्काल सन्देशवाहकहरू। इमेल पहिले नै असफल हुन सक्छ, परियोजना व्यवस्थापन प्रणाली, CRM/ERP र अन्य गम्भीर प्रणालीहरू उल्लेख नगर्नुहोस्।
- ठूलो प्रणालीबाट अर्कोमा विस्फोटक स्थानान्तरणले अनिवार्य रूपमा अराजकता निम्त्याउँछ।

नयाँ कार्य वातावरणमा यस प्रकारको संक्रमणको लागि सबैभन्दा महत्त्वपूर्ण कुरा प्रशिक्षण हो।

समानान्तर दौड

सफ्टवेयरमा समानान्तर अनुकूलन संक्रमणको एक नरम र अधिक विश्वव्यापी विधि हो, जसमा एक समयावधि सेट गरिएको छ जसमा दुबै प्रणालीहरू एकैसाथ काम गर्नेछन्।

Плюсы

+ प्रयोगकर्ताहरूसँग पुरानोमा द्रुत रूपमा काम गर्दा नयाँ सफ्टवेयरमा अभ्यस्त हुन पर्याप्त समय छ, समानान्तरहरू फेला पार्नुहोस्, र इन्टरफेससँग अन्तरक्रियाको नयाँ तर्क बुझ्न।
+ अचानक समस्याको अवस्थामा, कर्मचारीहरूले पुरानो प्रणालीमा काम गर्न जारी राख्छन्।
+ प्रयोगकर्ता प्रशिक्षण कम कठोर र सामान्यतया सस्तो छ।
+ त्यहाँ कर्मचारीहरूबाट व्यावहारिक रूपमा कुनै नकारात्मक प्रतिक्रिया छैन - आखिर, तिनीहरू आफ्नो सामान्य उपकरण वा काम गर्ने तरिकाबाट वञ्चित भएनन् (यदि स्वचालन पहिलो पटक हुन्छ)।

Минусы

— प्रशासन समस्याहरू: दुबै प्रणालीहरूको लागि समर्थन, डाटा सिङ्क्रोनाइजेसन, एकै पटक दुई अनुप्रयोगहरूमा सुरक्षा व्यवस्थापन।
- संक्रमण प्रक्रिया अनन्त रूपमा फैलिएको छ - कर्मचारीहरूले महसुस गर्छन् कि उनीहरूसँग लगभग अनन्त समय बाँकी छ, र उनीहरूले परिचित इन्टरफेसको प्रयोगलाई अलि बढी विस्तार गर्न सक्छन्।
- प्रयोगकर्ता भ्रम - दुई इन्टरफेसहरू भ्रमित छन् र परिचालन र डेटा त्रुटिहरू निम्त्याउँछन्।
- पैसा। तपाइँ दुबै प्रणालीहरूको लागि भुक्तान गर्नुहुन्छ।

चरणबद्ध ग्रहण

नयाँ सफ्टवेयरमा स्विच गर्नको लागि चरण-दर-चरण अनुकूलन सबैभन्दा नरम विकल्प हो। ट्रान्जिसन कार्यात्मक रूपमा गरिन्छ, निर्दिष्ट अवधि भित्र र विभाग द्वारा (उदाहरणका लागि, जुन 1 बाट हामी नयाँ ग्राहकहरू नयाँ CRM प्रणालीमा थप्छौं, जुन 20 देखि हामी नयाँ प्रणालीमा लेनदेनहरू सञ्चालन गर्छौं, अगस्ट 1 सम्म हामी क्यालेन्डरहरू स्थानान्तरण गर्छौं। र मामिलाहरू, र सेप्टेम्बर 30 सम्ममा हामी माइग्रेसन पूरा गर्छौं एक धेरै नराम्रो विवरण हो, तर सामान्यतया स्पष्ट)।

Плюсы

+ संगठित संक्रमण, प्रशासकहरू र आन्तरिक विशेषज्ञहरू बीच लोड वितरित।
+ अधिक विचारशील र गहिरो शिक्षा।
+ परिवर्तन गर्न कुनै प्रतिरोध छैन, किनकि यो सम्भव भएसम्म बिस्तारै हुन्छ।

Минусы - लगभग समानान्तर संक्रमणको लागि जस्तै।

त्यसोभए अब, केवल एक क्रमिक संक्रमण?

तार्किक प्रश्न, तपाईं सहमत हुनुहुनेछ। तपाइँ तालिका बनाउन र स्पष्ट योजना अनुसार कार्य गर्न सक्नुहुँदा किन केहि थप झन्झट पाउनु हुन्छ? वास्तवमा, सबै कुरा यति सरल छैन।

• सफ्टवेयर जटिलता: यदि हामी जटिल सफ्टवेयरको बारेमा कुरा गर्दैछौं (उदाहरणका लागि, CRM प्रणाली), त्यसपछि चरण अनुकूलन अधिक उपयुक्त छ। यदि सफ्टवेयर सरल छ (मेसेन्जर, कर्पोरेट पोर्टल), तब एक उपयुक्त मोडेल हो जब तपाइँ मिति घोषणा गर्नुहुन्छ र पुरानो सफ्टवेयरलाई तोकिएको दिनमा असक्षम गर्नुहुन्छ (यदि तपाइँ भाग्यशाली हुनुहुन्छ भने, कर्मचारीहरूले उनीहरूलाई आवश्यक सबै जानकारी निकाल्न समय पाउनेछन्। , र यदि तपाइँ भाग्यमा भरोसा गर्नुहुन्न भने, तपाइँ पुरानो प्रणालीबाट नयाँ प्रणालीमा स्वचालित आयात आवश्यक डेटा प्रदान गर्न आवश्यक छ, यदि प्राविधिक रूपमा सम्भव छ)।
• कम्पनीको लागि जोखिमको डिग्री: कार्यान्वयन जति जोखिमपूर्ण हुन्छ, त्यति ढिलो हुनुपर्छ। अर्कोतर्फ, ढिलाइ पनि एक जोखिम हो: उदाहरणका लागि, तपाइँ एक CRM प्रणालीबाट अर्कोमा स्विच गर्दै हुनुहुन्छ, र संक्रमण अवधिमा तपाइँ दुवैको लागि भुक्तान गर्न बाध्य हुनुहुन्छ, जसले गर्दा नयाँ प्रणाली लागू गर्ने लागत र लागत बढ्छ, जुन। यसको अर्थ भुक्तानी अवधि थपिएको छ।
• कर्मचारीहरूको संख्या: यदि तपाईंलाई धेरै प्रयोगकर्ता प्रोफाइलहरू मापन र कन्फिगर गर्न आवश्यक छ भने बिग ब्याङ्ग निश्चित रूपमा उपयुक्त छैन। यद्यपि त्यहाँ केसहरू छन् जब अल्ट्रा-फास्ट कार्यान्वयन ठूलो कम्पनीको लागि फाइदा हो। यो विकल्प धेरै कर्मचारीहरूले प्रयोग गर्ने प्रणालीहरूको लागि उपयुक्त हुन सक्छ, तर आवश्यकताहरू नहुन सक्छ किनभने अनुकूलन उद्देश्य छैन। तर फेरि, यो अन्त प्रयोगकर्ताहरूको लागि ठूलो धमाका हो र उही आईटी सेवाको लागि ठूलो चरण-दर-चरण काम हो (उदाहरणका लागि, बिलिङ वा पहुँच प्रणाली)।
• चयन गरिएको सफ्टवेयर (संशोधन, आदि) को कार्यान्वयन को विशेषताहरु। कहिलेकाहीं कार्यान्वयन प्रारम्भिक चरण-द्वारा-चरण हुन्छ - आवश्यकताहरू सङ्कलन, परिष्करण, प्रशिक्षण, आदि सहित। उदाहरण को लागी, CRM प्रणाली यो सधैं क्रमिक रूपमा लागू हुन्छ, र यदि कसैले तपाईंलाई "3 दिन वा 3 घण्टामा कार्यान्वयन र कन्फिगरेसन" वाचा गर्छ भने - यो लेख सम्झनुहोस् र त्यस्ता सेवाहरूलाई बाइपास गर्नुहोस्: स्थापना ≠ कार्यान्वयन।

फेरि, सूचीबद्ध प्यारामिटरहरू थाहा पाएर पनि, एक निश्चित रूपमा एक वा अर्को बाटो लिन सक्दैन। तपाईंको कर्पोरेट वातावरणको मूल्याङ्कन गर्नुहोस् - यसले तपाईंलाई शक्ति सन्तुलन बुझ्न र कुन मोडेल (वा तिनीहरूका केही तत्वहरूको संयोजन) तपाईंको लागि सही छ भनेर निर्धारण गर्न मद्दत गर्नेछ।

प्रभाव को एजेन्ट: क्रान्ति वा विकास

तपाईंले ध्यान दिनु पर्ने पहिलो कुरा कर्मचारीहरू हुन् जुन नयाँ सफ्टवेयरको कार्यान्वयनबाट प्रभावित हुनेछन्। वास्तवमा, हामीले अहिले विचार गरिरहेको समस्या विशुद्ध रूपमा एक मानव कारक हो, त्यसैले कर्मचारीहरूमा पर्ने प्रभावको विश्लेषणबाट बच्न सकिँदैन। हामीले ती मध्ये केही माथि उल्लेख गरिसकेका छौं।

• कम्पनीका नेताहरूले नयाँ सफ्टवेयरलाई सामान्यतया कसरी स्वीकार गर्ने भनेर निर्धारण गर्छन्। र यो प्रमोशनल भाषणहरू र ज्वलन्त भाषणहरूको लागि ठाउँ होइन - यो परिवर्तनको आवश्यकतालाई ठ्याक्कै देखाउन महत्त्वपूर्ण छ, यो विचार व्यक्त गर्न कि यो केवल एक कूलर र अधिक सुविधाजनक उपकरण छनोट गर्दै छ, पुरानो ल्यापटप प्रतिस्थापन जस्तै। यस्तो अवस्थामा व्यवस्थापनको सबैभन्दा ठूलो गल्ती भनेको आफ्नो हात धुनु र आफैलाई फिर्ता लिनु हो: यदि व्यवस्थापनलाई कम्पनी स्वचालन आवश्यक छैन भने, यो किन कर्मचारीहरूको चासोको हुनुपर्छ? प्रक्रियामा रहनुहोस्।
• विभाग प्रमुखहरू (परियोजना प्रबन्धकहरू) एक मध्यवर्ती लिङ्क हुन् जसले सबै प्रक्रियाहरूमा भाग लिनुपर्दछ, असन्तुष्टि व्यवस्थापन गर्नुपर्दछ, सहकर्मीहरूको प्रत्येक आपत्तिको माध्यमबाट इच्छा देखाउन र काम गर्नुपर्दछ, र उच्च गुणस्तर र गहन प्रशिक्षण सञ्चालन गर्नुपर्दछ।
• IT सेवा (वा प्रणाली प्रशासकहरू) - पहिलो नजरमा, यी तपाईंका प्रारम्भिक पक्षीहरू हुन्, सबैभन्दा अनुकूलनीय र अनुकूलनीय, तर... होइन। अक्सर, विशेष गरी साना र मध्यम आकारका कम्पनीहरूमा, प्रणाली प्रशासकहरूले आईटी पूर्वाधारको कुनै पनि परिवर्तन (सुदृढीकरण) को विरोध गर्छन्, र यो कुनै प्राविधिक औचित्यको कारण होइन, तर काम गर्न आलस्य र अनिच्छाको कारण हो। हामी मध्ये कसले काम गर्नबाट बच्ने उपायहरू खोजेको छैन? तर यसले सम्पूर्ण कम्पनीलाई हानि नहोस्।
• अन्त प्रयोगकर्ताहरू, एक नियमको रूपमा, एक हातमा राम्रो र सुविधाजनक रूपमा काम गर्न चाहन्छन् र, कुनै पनि जीवित मानिसहरू जस्तै, परिवर्तनबाट डराउँछन्। तिनीहरूको लागि मुख्य तर्क इमानदार र सरल छ: हामी किन परिचय/परिवर्तन गर्दैछौं, नियन्त्रणका सीमाहरू के हुन्, काम कसरी मूल्याङ्कन गरिनेछ, के परिवर्तन हुनेछ र जोखिमहरू के हुन् (यसैले, सबैले जोखिमहरू मूल्याङ्कन गर्नुपर्छ - यद्यपि हामी विक्रेताहरू हौं CRM प्रणालीहरू, तर हामी सबै कुरा सँधै सहज रूपमा जान्छ भनेर भन्न वाध्य गर्दैनौं: व्यवसाय भित्र कुनै पनि प्रक्रियामा जोखिमहरू छन्)।
• कम्पनी भित्रका "अधिकारीहरू" पक्षपाती हुन् जसले अन्य कर्मचारीहरूलाई प्रभाव पार्न सक्छन्। यो आवश्यक छैन कि उच्च स्थिति वा व्यापक अनुभव भएको व्यक्ति हो - सफ्टवेयरसँग काम गर्ने सन्दर्भमा, "अधिकार" एक उन्नत जानकार हुन सक्छ-जसले, उदाहरणका लागि, Habr पुन: पढेको छ र डराउन थाल्छ। सबै कति खराब हुनेछ भन्ने बारे सबैलाई। उहाँसँग कार्यान्वयन वा संक्रमण प्रक्रियालाई बर्बाद गर्ने लक्ष्य पनि नहुन सक्छ - केवल देखाउने र प्रतिरोधको भावना - र कर्मचारीहरूले उहाँलाई विश्वास गर्नेछन्। तपाईंले त्यस्ता कर्मचारीहरूसँग काम गर्न आवश्यक छ: व्याख्या गर्नुहोस्, प्रश्न गर्नुहोस्, र विशेष गरी कठिन अवस्थामा, परिणामहरूमा संकेत गर्नुहोस्।

प्रयोगकर्ताहरू साँच्चै कुनै चीजसँग डराउँछन् वा उनीहरूसँग एक ज्ञानी नेताको नेतृत्वमा समूह पागलपन छ कि छैन भनेर जाँच गर्नको लागि त्यहाँ एक विश्वव्यापी नुस्खा छ। उनीहरूलाई असन्तुष्टिको कारणहरू बारे सोध्नुहोस्, चिन्ताहरूको बारेमा - यदि यो व्यक्तिगत अनुभव वा विचार होइन भने, 3-4 स्पष्ट प्रश्नहरू पछि तर्कहरू आउन सुरु हुनेछ।

"प्रतिरोध आन्दोलन" लाई सफलतापूर्वक पार गर्न दुईवटा महत्त्वपूर्ण कारकहरू।

1. प्रशिक्षण प्रदान गर्नुहोस्: विक्रेता र आन्तरिक। सुनिश्चित गर्नुहोस् कि कर्मचारीहरूले साँच्चै सबै कुरा बुझेका छन्, त्यसमा महारत हासिल गरेका छन् र उनीहरूको प्रशिक्षणको स्तरलाई ध्यान नदिई काम सुरु गर्न तयार छन्। प्रशिक्षणको अनिवार्य विशेषता छापिएको छ र इलेक्ट्रोनिक निर्देशनहरू (नियमहरू) र प्रणालीमा सबैभन्दा पूर्ण कागजातहरू (आत्म-सम्मान विक्रेताहरूले यसलाई सफ्टवेयरको साथ जारी गर्छन् र यसलाई निःशुल्क उपलब्ध गराउँछन्)।
2. समर्थकहरू खोज्नुहोस् र प्रभावकारीहरू छान्नुहोस्। आन्तरिक विशेषज्ञहरू र प्रारम्भिक अपनाउनेहरू तपाईंको समर्थन प्रणाली हुन्, दुबै शिक्षा र शंकाहरू हटाउने। नियमको रूपमा, कर्मचारीहरू आफैं आफ्ना सहकर्मीहरूलाई मद्दत गर्न र नयाँ सफ्टवेयरमा परिचय दिन खुसी छन्। तपाईंको कार्य भनेको तिनीहरूलाई तिनीहरूको कामबाट अस्थायी रूपमा छुटकारा दिनु वा तिनीहरूको नयाँ कार्यभारको लागि उनीहरूलाई उचित बोनस दिनु हो।

तपाईंले केमा ध्यान दिनुपर्छ?

1. परिवर्तनबाट कर्मचारीहरू कत्तिको उन्नत छन्? (सापेक्ष रूपमा भन्नुपर्दा, यदि भोलि उनीहरूले नयाँ लेखा कार्यक्रम आविष्कार गरे भने, भगवानले तपाईंलाई 50 भन्दा माथिका महिलाहरूसँग लेखा विभागमा नाक हान्न नदिनुहोस् र 1C बाट संक्रमणको सुझाव दिनुहोस्, तपाईं जीवितै बाहिर आउनुहुनेछैन)।
2. कार्यप्रवाह कत्तिको प्रभावित हुनेछ? १०० व्यक्तिको कम्पनीमा मेसेन्जर परिवर्तन गर्नु एउटा कुरा हो, अर्को कुरा नयाँ CRM प्रणाली लागू गर्नु हो, जुन कम्पनीमा प्रमुख प्रक्रियाहरूमा आधारित छ (र यो बिक्री मात्र होइन, उदाहरणका लागि, RegionSoft CRM को कार्यान्वयन वरिष्ठ संस्करणहरूमा यसले उत्पादन, गोदाम, मार्केटिङ, र शीर्ष प्रबन्धकहरूलाई असर गर्छ जसले टोलीसँग मिलेर स्वचालित व्यापार प्रक्रियाहरू निर्माण गर्नेछ)।
3. तालिम कुन तहमा र कुन तहमा दिइएको थियो ?

कर्पोरेट सोचको प्रणालीमा मात्र तार्किक संक्रमण

नयाँ सफ्टवेयरको संक्रमण / कार्यान्वयनले के बचत गर्नेछ?

हामीले तपाइँलाई कुन मुख्य बुँदाहरूले तपाइँलाई नयाँ सफ्टवेयरमा सहज रूपमा सार्न मद्दत गर्दछ भन्ने कुरा बताउन अघि, हामी तपाइँको ध्यान एउटा बिन्दुमा आकर्षित गरौं। त्यहाँ केहि छ जुन निश्चित रूपमा गर्नु हुँदैन - त्यहाँ कर्मचारीहरूलाई दबाब दिन र तिनीहरूलाई बोनस, प्रशासनिक र अनुशासनात्मक प्रतिबन्धहरूबाट वञ्चित गरेर "उप्रेरित" गर्न आवश्यक छैन। यसले प्रक्रियालाई अझ राम्रो बनाउँदैन, तर कर्मचारीहरूको मनोवृत्ति बिग्रनेछ: यदि उनीहरूले धकेल्छन् भने नियन्त्रण हुनेछ; यदि तिनीहरूले तपाईंलाई जबरजस्ती गर्छन् भने, यसको मतलब तिनीहरूले हाम्रो रुचिलाई आदर गर्दैनन्; यदि उनीहरूले जबरजस्ती यसलाई थोप्छन् भने, यसको मतलब उनीहरूले हामी र हाम्रो काममा विश्वास गर्दैनन्। त्यसकारण, हामी सबै कुरा अनुशासित, स्पष्ट, सक्षम ढंगले गर्छौं, तर दबाब वा अनावश्यक जबरजस्ती बिना।

तपाईंसँग विस्तृत कार्य योजना हुनुपर्छ

अरू सबै नहुन सक्छ, तर योजना हुनुपर्छ। यसबाहेक, योजना समायोज्य, अद्यावधिक, स्पष्ट र अपरिहार्य छ, एकै समयमा छलफलको लागि पहुँचयोग्य र सबै इच्छुक कर्मचारीहरूको लागि पारदर्शी छ। बिहान 8 देखि 10 बजे सम्म त्यहाँ एक उपलब्धि छ, र 16:00 मा इङ्गल्याण्ड संग युद्ध छ भनेर प्रत्यक्ष रूपमा संवाद गर्न असम्भव छ; सम्पूर्ण योजनालाई परिप्रेक्ष्यमा हेर्न महत्त्वपूर्ण छ।

योजनाले अनिवार्य रूपमा कर्मचारीहरूको आवश्यकताहरू प्रतिबिम्बित गर्नुपर्दछ जो अन्तिम प्रयोगकर्ताहरू हुनेछन् - यसरी प्रत्येक कर्मचारीले कुन चाहिँ सुविधा र कुन समयमा प्रयोग गर्न सक्षम हुनेछ भन्ने कुरा थाहा पाउनेछन्। एकै समयमा, संक्रमण वा कार्यान्वयन योजना कुनै प्रकारको अपरिवर्तनीय मोनोलिथ होइन; यो योजनालाई अन्तिम रूप दिने र यसको विशेषताहरू परिवर्तन गर्ने सम्भावना छोड्न आवश्यक छ (तर सम्पादन र नयाँ "चाहनाहरू" को अनन्त स्ट्रिमको रूपमा होइन। र समयसीमामा निरन्तर परिवर्तनको रूपमा होइन)।  

योजनामा ​​के हुनुपर्छ ?

1. मुख्य संक्रमण माइलस्टोन (चरणहरू) - के गर्न आवश्यक छ।
2. प्रत्येक चरणको लागि विस्तृत संक्रमण बिन्दुहरू - यो कसरी गर्नुपर्छ।
3. मुख्य बिन्दुहरू र तिनीहरूमा रिपोर्टिङ (घण्टाको मेलमिलाप) - कसरी के गरिएको छ मापन गरिनेछ र को नियन्त्रण बिन्दुमा हुनुपर्छ।
4. जिम्मेवार व्यक्तिहरू तपाईंले फर्केर प्रश्नहरू सोध्न सक्ने व्यक्तिहरू हुन्।
5. समय सीमा प्रत्येक चरणको सुरुवात र अन्त्य र सम्पूर्ण प्रक्रियाको रूपमा सम्पूर्ण प्रक्रिया हो।
6. प्रभावित प्रक्रियाहरू - व्यापार प्रक्रियाहरूमा के परिवर्तनहरू हुनेछन्, कार्यान्वयन/संक्रमणसँगै के परिवर्तन गर्न आवश्यक छ।
7. अन्तिम मूल्याङ्कन सूचकहरू, मेट्रिक्स वा व्यक्तिपरक मूल्याङ्कनहरूको सेट हो जसले कार्यान्वयन/संक्रमण भएको मूल्याङ्कन गर्न मद्दत गर्दछ।
8. सञ्चालनको सुरुवात सही मिति हो जब सम्पूर्ण कम्पनी अद्यावधिक स्वचालित प्रक्रियामा सामेल हुनेछ र नयाँ प्रणालीमा काम गर्नेछ।

हामीले कार्यान्वयनकर्ताहरूको प्रस्तुतीकरणहरू भेट्टाएका छौं जसमा रातो रेखा सल्लाह हो: बल प्रयोग गर्नुहोस्, प्रतिक्रियालाई बेवास्ता गर्नुहोस्, कर्मचारीहरूसँग कुरा नगर्नुहोस्। हामी यो दृष्टिकोणको विरुद्धमा छौं, र यहाँ किन छ।

तलको चित्रमा हेर्नुहोस्:

नयाँ माउस, नयाँ किबोर्ड, अपार्टमेन्ट, कार र जागिर पनि सुखद, रमाइलो घटनाहरू हुन्, तिनीहरूमध्ये केही उपलब्धिहरू पनि हुन्। र प्रयोगकर्ता Yandex मा जान्छ कि यसलाई कसरी प्रयोग गर्ने र अनुकूलन गर्न। नयाँ अपार्टमेन्टमा कसरी प्रवेश गर्ने र यो तपाइँको हो भनेर बुझ्नुहोस्, पहिलो पटक ट्याप खोल्नुहोस्, चिया पिउनुहोस्, पहिलो पटक ओछ्यानमा जानुहोस्। कसरी पाङ्ग्रा पछाडि जान र नयाँ कार संग साथी बनाउन, तपाइँको, तर अहिले सम्म विदेशी। कार्यस्थलमा नयाँ सफ्टवेयर वर्णन गरिएका परिस्थितिहरू भन्दा फरक छैन: कर्मचारीको काम कहिल्यै उस्तै हुँदैन। त्यसकारण, नयाँ प्रभावकारी सफ्टवेयरको साथ लागू गर्नुहोस्, अनुकूलन गर्नुहोस्, बढाउनुहोस्। र यो एक अवस्था हो जसको बारेमा हामी भन्न सक्छौं: बिस्तारै हतार गर्नुहोस्।

स्रोत: www.habr.com