लगभग एक जना केटा

कथा यथार्थ हो, सबै कुरा आफ्नै आँखाले देखेको छु ।

धेरै वर्षको लागि, एक केटा, तपाईं धेरैजस्तै, प्रोग्रामरको रूपमा काम गर्नुभयो। केवल केसमा, म यसलाई यसरी लेख्नेछु: "प्रोग्रामर।" किनभने उहाँ 1Snik हुनुहुन्थ्यो, फिक्स, उत्पादन कम्पनीमा।

त्यस अघि, उनले विभिन्न विशेषताहरू प्रयास गरे - फ्रान्समा 4 वर्ष एक प्रोग्रामर, परियोजना प्रबन्धकको रूपमा, उहाँले 200 घण्टा पूरा गर्न सक्षम हुनुहुन्थ्यो, एकै समयमा परियोजनाको प्रतिशत प्राप्त गर्दै, व्यवस्थापन र थोरै बिक्री गर्न। मैले आफ्नै उत्पादनहरू विकास गर्ने प्रयास गरें, 6 हजार मानिसहरूको साथ ठूलो कम्पनीमा आईटी विभागको प्रमुख थिए, मेरो उद्धरण योग्य पेशा - 1C प्रोग्रामर प्रयोग गर्नका लागि विभिन्न विकल्पहरूमा प्रयास गरे।

तर यी सबै पदहरू केही हदसम्म डेड-एंड थिए, मुख्य रूपमा आयको सर्तमा। त्यो समयमा, हामी सबैले लगभग समान पैसा प्राप्त गर्यौं र समान परिस्थितिहरूमा काम गर्यौं।

यो केटा सोचिरहेको थियो कि उसले आफ्नो व्यवसाय बेच्न वा सिर्जना नगरी कसरी धेरै पैसा कमाउन सक्छ।

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

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

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

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

केटा मालिकसँग सहमत भयो कि उसले सूचीको नतिजाबाट विचलनलाई आधाले घटाउनुपर्छ। यसबाहेक, मालिकसँग गुमाउनको लागि केहि विशेष थिएन, किनभने हाम्रो नायक भन्दा पहिले, विभिन्न कार्यकर्ताहरूले पहिले नै सबै कुरा ठीक गर्न प्रयास गरिसकेका थिए, र सामान्यतया कार्य व्यावहारिक रूपमा समाधान गर्न नसकिने मानिन्छ। यी सबैले धेरै चासोलाई बढायो, किनकि यदि सबै कुराले काम गर्यो भने, त्यसपछि साथी स्वचालित रूपमा एक व्यक्ति बन्नेछ जसले चीजहरू कसरी व्यवस्थित गर्ने र समाधान गर्न नसकिने समस्याहरू समाधान गर्न जान्दछन्।

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

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

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

त्यसपछि उनले प्रयोग दोहोर्याउने निर्णय गरे र मालिकले अर्को समस्याग्रस्त प्रक्रिया सुधार गर्न सुझाव दिए - आपूर्ति। त्यहाँ अभावहरू थिए जसले हामीलाई हाम्रा ग्राहकहरूले चाहेको भोल्युमहरू पठाउन अनुमति दिएनन्। हामी सहमत भयौं कि एक वर्ष भित्र घाटा आधा हुनेछ, र केटाले 10C सम्बन्धी 15-1 परियोजनाहरू पनि पूरा गर्नेछ - विभिन्न व्यापार प्रक्रियाहरू र अन्य पाखण्डहरू स्वचालित गर्न।

दोस्रो वर्षमा, सबै कुरा सफलतापूर्वक पुन: सम्पन्न भयो, घाटा 2 गुणा भन्दा बढीले घट्यो, सबै आईटी परियोजनाहरू सफलतापूर्वक सम्पन्न भए।

तलबले पहिले नै दुई वर्षको लागि त्यो केटाको सबै आवश्यकताहरू पूर्ण रूपमा सन्तुष्ट गरेको हुनाले, उसले थोरै बसोबास गर्ने, शान्त हुने र आफूले आफैंको लागि सिर्जना गरेको आरामदायक, न्यानो ठाउँमा बस्ने निर्णय गर्‍यो।

यो कस्तो थियो? औपचारिक रूपमा, उनी आईटी निर्देशक थिए। तर उहाँ वास्तवमा को हुनुहुन्थ्यो बुझ्न गाह्रो छ। आखिर, आईटी निर्देशकले के गर्छ? एक नियमको रूपमा, उहाँले IT पूर्वाधारको व्यवस्थापन गर्नुहुन्छ, प्रणाली प्रशासकहरू प्रबन्ध गर्नुहुन्छ, एक ERP प्रणाली लागू गर्नुहुन्छ, र निर्देशक बोर्डको बैठकहरूमा भाग लिनुहुन्छ।

र यो साथीसँग परिवर्तन प्रक्रियाहरूमा भाग लिने मुख्य जिम्मेवारीहरू मध्ये एक थियो, र मुख्य रूपमा - उत्पादन, यी प्रक्रियाहरूको प्रारम्भ, समाधानहरूको खोज र प्रस्ताव, नयाँ व्यवस्थापन प्रविधिहरूको प्रयोग, प्रस्तावित परिवर्तनहरूको परीक्षण, अन्य कार्यहरूको प्रभावकारिताको विश्लेषण र। विभाजनहरू, र अन्तमा, उद्यमको रणनीतिक विकासमा प्रत्यक्ष सहभागिता, सम्पूर्ण कम्पनीको लागि रणनीतिक योजनाको स्वतन्त्र विकाससम्म।

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

बैठकमा उनले विरलै केही उपयोगी कुरा दिए। उसले छोड्यो, सोच्यो, त्यसपछि एउटा चिठी आयो - या त आलोचनाको साथ, वा एक रायको साथ, वा सुझावहरू सहित, वा समाधानहरूको विवरणको साथ जुन उनले पहिले नै लागू गरिसकेका थिए।

तर प्रायः उहाँ आफैंले बैठक बोलाउनुभयो। मैले समस्या भेट्टाएँ, समाधानहरू लिएँ, इच्छुक पक्षहरू पहिचान गरें र सबैलाई बैठकमा ल्याएँ। र त्यसपछि - सक्दो राम्रो। उहाँले आश्वस्त गर्नुभयो, उत्प्रेरित गर्नुभयो, प्रमाणित गर्नुभयो, तर्क गर्नुभयो, हासिल गर्नुभयो।

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

मालिकले उसलाई दिनमा १ घण्टा समय दियो। हरेक दिन। उनीहरूले समस्या, समाधान, नयाँ व्यवसाय, विकासका क्षेत्रहरू, सूचक र दक्षता, व्यक्तिगत विकास, पुस्तकहरू र सरल जीवनबारे कुराकानी, छलफल गरे।

तर यो केटा अनौठो थियो। यो जस्तो छ, पछाडि बस्नुहोस् र खुसी हुनुहोस्, जीवन राम्रो छ। तर होइन। उनले प्रतिबिम्बित गर्ने निर्णय गरे।

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

उनले गुणस्तरका लागि उपनिर्देशककहाँ आएर जापानीभन्दा उत्पादन राम्रो हुने गरी शेवार्ट कन्ट्रोल चार्ट ल्याउन सुझाव दिए । तर यो पत्ता लाग्यो कि सहकर्मीले Shewhart नियन्त्रण चार्टहरू के हुन्, सांख्यिकीय प्रक्रिया नियन्त्रण के हो भनेर थाहा थिएन, र गुणस्तर व्यवस्थापनमा डेमिङ चक्रको प्रयोगको बारेमा मात्र सुनेको थियो। ठिक छ…

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

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

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

प्रोग्रामरहरू, उनले महसुस गरे, आवश्यक विवरणहरू सहित सामान्य रूपमा व्यापार प्रक्रियाहरू बुझ्न सक्नेहरू मात्र हुन्।

तिनीहरू किन? वास्तवमा, उनले कहिल्यै स्पष्ट जवाफ पाएनन्। मैले थेसिस संकेतहरू मात्र तयार गरें।

सर्वप्रथम, प्रोग्रामरहरूलाई व्यवसायको विषय क्षेत्रहरू थाहा छ, र तिनीहरू कम्पनीमा अन्य सबै व्यक्तिहरू भन्दा राम्रोसँग जान्दछन्।

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

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

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

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

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

अनि उसले छोड्यो। आवश्यक दुई हप्ताको हिरासतमा, हामीले उसलाई आफ्नो अनुभव साझा गर्न बाध्य गऱ्यौं किनभने हामी उसले गरिरहेको काम जारी राख्न चाहन्छौं। तर, उनको पद खाली भयो ।

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

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

तर हामीले उहाँको मोनोलोगबाट केही उपयोगी कुरा निकाल्न सफल भयौं। म तिमीलाई सम्झने कुरा भन्छु।

त्यसोभए, त्यो केटाको सिफारिसहरू। व्यापार प्रक्रियाहरूमा चीजहरू राख्न प्रयास गर्न चाहनेहरूका लागि।

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

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

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

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

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

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

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

लिनुहोस्, उनले भने, उदाहरणका लागि, स्क्रम वा एजाइल। आफ्नो मोनोलोगहरूमा, केटाले धेरै पटक दोहोर्याएको छ कि सबैले स्क्रमको सारलाई पूर्णतया बुझ्दैनन्। उनले जेफ सदरल्याण्डको पुस्तक पनि पढे, जसलाई केही मानिसहरूले "हल्का पढाइ" पाउँछन्। यो उहाँलाई गहिरो पढेको जस्तो लाग्यो, किनकि Scrum को आधारभूत सिद्धान्तहरू मध्ये एक गुणस्तर व्यवस्थापन हो, यो सीधा पुस्तकमा लेखिएको छ।

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

सायद यो अनुवादको कुरा हो, किनभने हाम्रो पुस्तक "स्क्रम - परियोजना व्यवस्थापनको एक क्रान्तिकारी विधि" को रूपमा अनुवाद गरिएको थियो, र यदि अंग्रेजी शीर्षकलाई शाब्दिक रूपमा अनुवाद गरियो भने, यो बाहिर आउनेछ: "स्क्रम - आधा समयमा दुई गुणा बढी"। , त्यो हो, नाम मा पनि स्क्रम को एक प्रमुख कार्य को रूप मा गति को संदर्भित गर्दछ।

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

उहाँले व्यक्तिगत रूपमा धेरै प्रविधिहरू सिफारिस गर्नुभयो। उहाँले तिनीहरूलाई आधारभूत र आधारभूत भन्नुभयो।

पहिलो भनेको सीमा व्यवस्थापन हो ।

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

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

तर सबै भन्दा, केटाले नियन्त्रणको बारेमा कुरा गर्यो। उसले यस विषयमा केहि प्रकारको चकचके गरेको थियो।

नियन्त्रण, संक्षेपमा, संख्यामा आधारित व्यवस्थापन हो। यहाँ, उनले भने, परिभाषाको प्रत्येक भाग महत्त्वपूर्ण छ - दुबै "व्यवस्थापन" र "आधारित" र "संख्याहरू"।

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

पहिलो कुरा खराब छ संख्या हो। तिनीहरूमध्ये थोरै छन् र तिनीहरू कम गुणस्तरका छन्।

हामीले त्यसपछि 1C सूचना प्रणालीबाट संख्याहरूको महत्त्वपूर्ण भाग लियौं। त्यसोभए, 1C मा संख्याहरूको गुणस्तर, उनले दाबी गरे अनुसार, राम्रो छैन। कम्तिमा, पूर्वव्यापी रूपमा डेटा परिवर्तन गर्ने क्षमताको कारण।

यो स्पष्ट छ कि यो 1C विकासकर्ताहरूको गल्ती होइन - तिनीहरूले मात्र बजारको आवश्यकताहरू र घरेलु लेखाको मानसिकतालाई ध्यानमा राख्छन्। तर नियन्त्रण उद्देश्यका लागि, यो एक विशेष उद्यम मा डाटा संग 1C काम को सिद्धान्त परिवर्तन गर्न राम्रो छ।

यसबाहेक, 1C बाट नम्बरहरू, उहाँका अनुसार, उदाहरणका लागि, एक्सेल प्रयोग गरेर, अर्ध-म्यानुअल प्रशोधनबाट गुजर्छन्। यस्तो प्रशोधनले डाटामा गुणस्तर, साथै दक्षता पनि थप्दैन।

अन्तमा, अरू कसैले अन्तिम रिपोर्ट दोहोरो-जाँच गर्दछ ताकि गल्तिले प्रबन्धकलाई त्रुटिहरू सहित तथ्याङ्कहरू पेश नगर्नुहोस्। नतिजाको रूपमा, नम्बरहरू प्राप्तकर्तामा सुन्दर, प्रमाणित, तर धेरै ढिलो पुग्छन्। सामान्यतया - अवधिको अन्त्य पछि (महिना, हप्ता, आदि)।

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

र यदि तथ्याङ्कहरू लेखामा आधारित छन्, र कम्पनी सबैभन्दा सामान्य हो, VAT को त्रैमासिक पेसको साथ, त्यसपछि यसको प्रबन्धकले त्रैमासिक एक पटक अपेक्षाकृत पर्याप्त आंकडाहरू प्राप्त गर्दछ।

बाँकी प्रष्ट छ। तपाइँ महिनामा एक पटक नम्बरहरू प्राप्त गर्नुहुन्छ - तपाइँसँग एक वर्षमा 12 पटक नम्बरहरू (अर्थात, नियन्त्रण) द्वारा व्यवस्थापन गर्ने अवसर छ। यदि तपाइँ त्रैमासिक रिपोर्टिङ अभ्यास गर्नुहुन्छ भने, तपाइँ यसलाई एक वर्ष 4 पटक व्यवस्थापन गर्नुहुन्छ। प्लस एक बोनस - वार्षिक रिपोर्टिङ। एक पटक फेरि स्टेयर गर्नुहोस्।

बाँकी समय, नियन्त्रण सामान्यतया अन्धाले प्रदर्शन गरिन्छ।

जब (र यदि) संख्याहरू देखा पर्छन्, त्यसपछि दोस्रो समस्या खेलमा आउँछ - कसरी संख्याहरूमा आधारित व्यवस्थापन गर्ने? उहाँको यो तर्कसँग म सहमत हुन सकिनँ ।

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

अपर्याप्त व्यवस्थापकीय दक्षताका कारण यस्तो भएको उनले बताए । नियन्त्रण मा, सबै भन्दा पहिले। यी नम्बरहरूसँग के गर्ने भनेर प्रबन्धकलाई मात्र थाहा छैन। के сगर्न - के गर्ने थाहा छ - छैन। गर्नु भनेको माथि लेखिएको कुरा हो (झगडा गर्नु, खेल्नु)। गर्नु दैनिक व्यापार प्रक्रिया हो।

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

र त्यसैले उनले मुख्य दुविधालाई रूपरेखा दिए: संख्या अवस्थित छ, यो व्यवस्थापन दक्षता बढाउनको लागि व्यापार प्रणालीको हिस्सा बन्नुपर्दछ, तर ... यो भइरहेको छैन। किन?

किनभने रूसी नेताले आफ्नो शक्तिको एक टुक्रा प्रतियोगीलाई छोड्ने छैनन्।

रूसी प्रबन्धकका प्रतिद्वन्द्वीहरू - एक उच्च-गुणस्तर र काम गर्ने व्यापार प्रक्रिया, राम्रोसँग विचार गरीएको पारस्परिक लाभकारी प्रेरणा र उचित स्वचालन - अफसोस, प्रबन्धकलाई जागिर बिना छोड्नेछ।

एक प्रकारको बकवास, तपाईं सहमत हुनुहुन्न? खासगरी नेताहरुको बारेमा । ठिक छ, मैले तिमीलाई भनें, तिमी आफै निर्णय गर।

अलि कम, तर अझै धेरै, मेरो विचारमा, उसले स्क्रमको बारेमा कुरा गर्यो।

निश्चित हुनुहोस्, मैले भने, पढ्नुहोस् र अभ्यासमा Scrum प्रयास गर्नुहोस्। यदि, उसले भन्यो, तपाईंले यो पढ्नुभयो तर प्रयास गर्नुभएको छैन, आफैलाई अज्ञानी सम्झनुहोस्। इन्टरनेटमा लेखहरू र सबै प्रकारका गाइडहरू (के हो?) भन्दा सथरल्याण्डको पुस्तक पढ्नु राम्रो हुन्छ।

स्क्रम, उनले भने, अभ्यास मार्फत मात्र सिक्न सकिन्छ, र कार्यको मात्राको अनिवार्य मापन संग। व्यक्तिगत रूपमा दुई सबैभन्दा महत्त्वपूर्ण भूमिकाहरू प्रयास गर्नुहोस् - उत्पादन मालिक र स्क्रम मास्टर।

यो विशेष गरी महत्त्वपूर्ण छ, केटाका अनुसार, अभ्यासमा स्क्रम मास्टरको भूमिका अनुभव गर्न, जब तपाइँ स्प्रिन्टको स्रोत र लागत नबढाई प्रति स्प्रिन्ट पूरा हुने कार्यहरूको मात्रा बढाउन सक्नुहुन्छ।

ठीक छ, उनको शीर्षमा TOS (प्रणाली सीमितताहरूको सिद्धान्त) थियो।

यी, केटाको अनुसार, दक्षता बढाउने आधारभूत, आधारभूत सिद्धान्तहरू हुन् जुन लगभग कुनै पनि क्षेत्रमा लागू गर्न सकिन्छ, कुनै पनि व्यवसाय प्रक्रिया र समग्र रूपमा व्यापार प्रणालीमा।

जब उनले थाहा पाए कि हामी TOS सँग परिचित छैनौं, उसले हामीलाई बताउन छोड्यो। उनले एलीयाहु गोल्ड्राटका पुस्तकहरू पढ्नको आनन्दबाट हामीलाई वञ्चित नगर्ने बताए। उनले स्क्रमलाई यस्तै सिफारिस दिए - यसलाई पढ्नुहोस् र प्रयास गर्नुहोस्। जस्तै, तपाईं जुनसुकै स्थितिमा हुनुहुन्छ, तपाईंले जुनसुकै काम गर्नुभए पनि, TOC विधिहरू प्रयोग गरेर दक्षता बढाउने ठाउँ छ।

त्यसपछि उनको प्रविधिको झोला स्पष्ट रूपमा सुक्यो, र उनले भने: एक विशेष परिस्थितिमा लागू समाधानहरू सिर्जना गर्न सिद्धान्तहरू मिलाउनुहोस्।

यो, उनी भन्छन्, मुख्य सिफारिस हो, सफलताको कुञ्जी। सिद्धान्तहरू, सार बुझ्नुहोस्, र अद्वितीय अनुप्रयोग समाधानहरू सिर्जना गर्नुहोस् - व्यापार प्रक्रियाहरू र व्यापार प्रणालीहरू।

त्यसपछि उसले केही उद्धरण सम्झने प्रयास गर्यो, र अन्तमा उसले अनलाइन जानुपर्‍यो। यो एलियाहु गोल्डरट द्वारा "द शाल्डर्सको काँधमा खडा" लेखबाट उद्धरण भयो:

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

उनले भने कि प्रोग्रामर र "व्यापार प्रक्रिया सुधारकर्ता" को काम धेरै समान छन्। अनि छोडियो।

स्रोत: www.habr.com