कर्मचारी नया सॉफ़्टवेयर नहीं चाहते - क्या उन्हें नेतृत्व का पालन करना चाहिए या अपनी लाइन पर बने रहना चाहिए?

सॉफ्टवेयर लीपफ्रॉग जल्द ही कंपनियों की एक बहुत ही आम बीमारी बन जाएगी। हर छोटी-छोटी बात के कारण एक सॉफ्टवेयर को दूसरे में बदलना, एक प्रौद्योगिकी से दूसरी प्रौद्योगिकी की ओर छलांग लगाना, एक जीवंत व्यवसाय के साथ प्रयोग करना आदर्श बनता जा रहा है। उसी समय, कार्यालय में एक वास्तविक गृहयुद्ध शुरू हो जाता है: कार्यान्वयन के प्रतिरोध का एक आंदोलन बनता है, पक्षपातपूर्ण नई प्रणाली के खिलाफ विध्वंसक कार्य कर रहे हैं, जासूस नए सॉफ्टवेयर के साथ एक बहादुर नई दुनिया को बढ़ावा दे रहे हैं, बख्तरबंद कार से प्रबंधन कॉर्पोरेट पोर्टल शांति, श्रम, KPI के बारे में प्रसारण कर रहा है। एक क्रांति आम तौर पर एक तरफ पूर्ण विफलता में समाप्त होती है।

हम कार्यान्वयन के बारे में लगभग सब कुछ जानते हैं, तो आइए यह पता लगाने का प्रयास करें कि एक क्रांति को विकास में कैसे बदला जाए और कार्यान्वयन को यथासंभव उपयोगी और दर्द रहित कैसे बनाया जाए। ठीक है, या कम से कम हम आपको बताएंगे कि इस प्रक्रिया में आपको क्या मिल सकता है।

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

विदेशी सलाहकार इस लेख को कुछ इस तरह शुरू करेंगे: "यदि आप अपने कर्मचारियों को गुणवत्तापूर्ण सॉफ़्टवेयर प्रदान करते हैं जो उनके काम में सुधार कर सकता है, प्रदर्शन पर गुणात्मक प्रभाव डाल सकता है, तो एक नए कार्यक्रम या प्रणाली को अपनाना स्वाभाविक रूप से होगा।" लेकिन हम रूस में हैं, इसलिए संदिग्ध और जुझारू कर्मचारियों का मुद्दा बहुत प्रासंगिक है। कॉर्पोरेट मैसेंजर या सॉफ्टफ़ोन जैसे न्यूनतम सॉफ़्टवेयर के साथ भी, एक प्राकृतिक परिवर्तन काम नहीं करेगा।

समस्या के पैर कहाँ से आते हैं?

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

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

बेशक, पहले दो मामले अपनी अभिव्यक्तियों में बहुत अधिक तीव्र और विशिष्ट हैं, उन पर विशेष ध्यान दें।

इसलिए, इससे पहले कि आप टीम के साथ काम करना शुरू करें (जिन्हें पहले से ही संदेह है कि जल्द ही बदलाव होंगे), यह समझने की कोशिश करें कि सॉफ़्टवेयर को बदलने के वास्तविक कारण क्या हैं और क्या आप सहमत हैं कि परिवर्तन इतने आवश्यक हैं।

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

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

आप कैसे पार कर सकते हैं: बड़ी छलांग या झुके हुए बाघ को?

विश्व अभ्यास में, नए सॉफ़्टवेयर पर स्विच करने और उसे अपनाने के लिए तीन मुख्य रणनीतियाँ हैं - और वे हमें बहुत उपयुक्त लगती हैं, तो आइए पहिये का दोबारा आविष्कार न करें।

बड़ा धमाका

"बिग बैंग" पद्धति का उपयोग करके अपनाना सबसे कठिन संभव संक्रमण है, जब आप एक सटीक तारीख निर्धारित करते हैं और तीव्र माइग्रेशन करते हैं, जिससे पुराना सॉफ़्टवेयर 100% अक्षम हो जाता है।

पेशेवरों

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

विपक्ष

- केवल सरल सॉफ़्टवेयर के साथ सफलतापूर्वक काम करता है: चैट, कॉर्पोरेट पोर्टल, त्वरित संदेशवाहक। यहां तक ​​कि ईमेल भी पहले से ही विफल हो सकती है, परियोजना प्रबंधन प्रणालियों, सीआरएम/ईआरपी और अन्य गंभीर प्रणालियों का तो जिक्र ही नहीं किया जा सकता।
- एक बड़ी प्रणाली से दूसरी प्रणाली में विस्फोटक प्रवासन अनिवार्य रूप से अराजकता का कारण बनेगा।

नए कार्य परिवेश में इस प्रकार के परिवर्तन के लिए सबसे महत्वपूर्ण चीज़ प्रशिक्षण है।

समानांतर चल रहा है

सॉफ़्टवेयर के लिए समानांतर अनुकूलन संक्रमण का एक नरम और अधिक सार्वभौमिक तरीका है, जिसमें एक समय अवधि निर्धारित की जाती है जिसके दौरान दोनों प्रणालियाँ एक साथ कार्य करेंगी।

पेशेवरों

+ उपयोगकर्ताओं के पास पुराने सॉफ्टवेयर में तेजी से काम करते हुए नए सॉफ्टवेयर का आदी होने, समानताएं ढूंढने और इंटरफ़ेस के साथ इंटरैक्शन के नए तर्क को समझने के लिए पर्याप्त समय है।
+ अचानक समस्या आने पर कर्मचारी पुरानी व्यवस्था में ही काम करते रहेंगे।
+ उपयोगकर्ता प्रशिक्षण कम कठोर और आम तौर पर सस्ता है।
+ कर्मचारियों की ओर से व्यावहारिक रूप से कोई नकारात्मक प्रतिक्रिया नहीं है - आखिरकार, वे अपने सामान्य उपकरणों या काम करने के तरीके से वंचित नहीं थे (यदि स्वचालन पहली बार होता है)।

विपक्ष

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

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

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

पेशेवरों

+ व्यवस्थित परिवर्तन, प्रशासकों और आंतरिक विशेषज्ञों के बीच वितरित भार।
+ अधिक विचारशील और गहन शिक्षा।
+ परिवर्तन का कोई प्रतिरोध नहीं है, क्योंकि यह यथासंभव धीरे-धीरे घटित होता है।

विपक्ष - लगभग समानांतर संक्रमण के समान।

तो अब, बस एक क्रमिक परिवर्तन?

एक तार्किक प्रश्न, आप सहमत होंगे। जब आप एक कार्यक्रम बना सकते हैं और एक स्पष्ट योजना के अनुसार कार्य कर सकते हैं तो अतिरिक्त परेशानी क्यों उठाएँ? वास्तव में, सब कुछ इतना सरल नहीं है.

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

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

प्रभाव के कारक: क्रांति या विकास

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

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

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

"प्रतिरोध आंदोलन" पर सफलतापूर्वक काबू पाने के लिए दो महत्वपूर्ण कारक।

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

आपको किस पर ध्यान देने की आवश्यकता है?

1. परिवर्तनों से कर्मचारी कितने उन्नत प्रभावित हुए हैं? (अपेक्षाकृत रूप से कहें तो, यदि कल वे एक नए लेखांकन कार्यक्रम का आविष्कार करते हैं, भगवान न करे कि आप 50 से अधिक महिलाओं के साथ लेखांकन विभाग में अपनी नाक घुसाएं और 1 सी से संक्रमण का सुझाव दें, तो आप जीवित नहीं निकलेंगे)।
2. कार्यप्रवाह कितना प्रभावित होगा? 100 लोगों की कंपनी में मैसेंजर को बदलना एक बात है, एक नई सीआरएम प्रणाली को लागू करना दूसरी बात है, जो कंपनी में प्रमुख प्रक्रियाओं पर आधारित है (और यह केवल बिक्री नहीं है, उदाहरण के लिए, रीजनसॉफ्ट सीआरएम का कार्यान्वयन वरिष्ठ संस्करणों में यह उत्पादन, गोदाम, विपणन और शीर्ष प्रबंधकों को प्रभावित करता है, जो टीम के साथ मिलकर स्वचालित व्यावसायिक प्रक्रियाओं का निर्माण करेंगे)।
3. क्या प्रशिक्षण प्रदान किया गया और किस स्तर पर?

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

नए सॉफ़्टवेयर के परिवर्तन/कार्यान्वयन से क्या बचाएगा?

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

आपके पास एक विस्तृत कार्य योजना होनी चाहिए

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

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

योजना में क्या होना चाहिए?

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

हमने कार्यान्वयनकर्ताओं की प्रस्तुतियाँ देखी हैं जिनमें लाल रेखा सलाह है: बलपूर्वक लागू करें, प्रतिक्रिया को अनदेखा करें, कर्मचारियों से बात न करें। हम इस दृष्टिकोण के विरुद्ध हैं, और इसका कारण यहां बताया गया है।

नीचे दी गई तस्वीर को देखें:

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

स्रोत: www.habr.com