कर्मचारी नया सॉफ्टवेयर नहीं चाहते हैं - अवसर पर जाएं या अपनी लाइन में झुकें?

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

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


कर्मचारियों द्वारा नए सॉफ्टवेयर को अपनाने का आदर्श दृश्य। स्रोत - Yandex.Pictures

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

समस्या कहां से बढ़ती है?

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

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

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

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

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

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

मैं कैसे जा सकता हूं: एक महान छलांग या एक क्राउचिंग टाइगर?

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

बड़ा धमाका

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

आकर्षण आते हैं

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

विपक्ष

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

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

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

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

आकर्षण आते हैं

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

विपक्ष

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

चरणबद्ध अनुकूलन

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

आकर्षण आते हैं

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

विपक्ष - एक समानांतर संक्रमण के रूप में उसी के बारे में।

तो अब, बस एक चरणबद्ध संक्रमण?

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

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

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

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

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

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

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

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

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

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

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

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

नए सॉफ़्टवेयर के संक्रमण / कार्यान्वयन को क्या बचाएगा?

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

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

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

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

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

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

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

नीचे दी गई तस्वीर पर एक नज़र डालें:



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