फोर्ड, टोयोटा और गिनी पिग्स

- गिनी पिग का समुद्र से क्या संबंध है?
"हवाई पोत के डिजाइन के लिए प्लैटिपस के समान है।"

परिचय।

मैं कई स्रोतों से जानकारी के माध्यम से स्क्रॉल करते हुए चलते हैं, टुकड़े मिलान करते हैं। दिलचस्प निष्कर्षों में से एक है डेमार्को और लिस्टर के पीपुलवेयर और गोल्डट्रैट की क्रिटिकल चेन में सैद्धांतिक गणनाओं की सांख्यिकीय टिप्पणियों का लगभग पूरा पत्राचार।

2011 के पतन में, मैंने अपने सिर को मोड़ लिया:
[१] एली एम। गोल्डरेट द्वारा "दिग्गजों के कंधों पर खड़े"
[२] "प्रोडक्शन मैनेजमेंट: फ्लो मैनेजमेंट" ओलेड कोवेन, एलेना फेडुरको
[३] "एक ही बोर्ड की कहानी" (http://cartmendum.livejournal.com/tag/theboard)।

इसके अलावा मैं लिखना चाहूंगा: "अचानक ..." - लेकिन यह सच नहीं होगा। यह सब अचानक नहीं हुआ। मुझे कुछ हफ़्ते लग गए, लेकिन, अंत में, मेरे सिर में एक पूरी तरह से बनाई गई तस्वीर।

मैंने वास्तव में क्या पकड़ा:

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

सिद्धांत। स्ट्रीम प्रकार

प्रवाह प्रकार को आमतौर पर प्रमुख पैटर्न से वर्गीकृत किया जाता है। शुद्ध (पतित) रूप में, प्रवाह के प्रकारों को निम्न प्रकार से दर्शाया जा सकता है:

यदि आपको अधिक विस्तृत जानकारी की आवश्यकता है, तो ओलेड-कोहेन और एलेना फेडुरको के लेखों को चालू करना बेहतर है।

सॉफ्टवेयर उत्पादन की दुनिया में, आप एक सादृश्य आकर्षित कर सकते हैं:

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

अस्वीकरण। मुझे यकीन नहीं है कि सामग्री उत्पादन की दुनिया और सॉफ्टवेयर विकास की दुनिया के लिए एक ही प्रकार की उत्पादन श्रृंखला की समस्याएं समान हैं। यह एक परिकल्पना है जिसमें कई सहायक उदाहरण हैं। लेकिन एक अपवाद भी इस परिकल्पना पर संदेह कर सकता है।

शायद कोई वर्गीकरण बदलना चाहता है। उदाहरण के लिए, मैं चाहता था। मैं दो और प्रकार जोड़ना चाहूंगा:


लेकिन यह मानक, और मानक से विचलन, यहां तक ​​कि खराब का पालन करना बेहतर है।

एक संदेह है कि ज़-प्रकार टी-प्रकार के लिए एक अधिक सही नाम है, बस अमेरिकी वर्णमाला के साथ भाग्य से बाहर हैं। ;-)

मैं टाइप करता हूं

प्रबंधन करने के लिए सबसे आसान I- टाइप स्ट्रीम।

लेकिन इस प्रकार के लिए भी, कई सामान्य गलतियाँ हैं। सबसे आम गलती "पुश" नियंत्रण मॉडल का उपयोग है।

आईटी उद्योग के विशिष्ट उदाहरण पर विचार करें। चलो एक सरल, यहां तक ​​कि तुच्छ श्रृंखला लेते हैं, "बिक्री विभाग" -> प्रोग्रामिंग विभाग -> परीक्षण विभाग।

प्रक्रिया आरेख:

विभागों को तदनुसार प्रक्रिया दें:

• बिक्री विभाग - प्रति सप्ताह 20 आदेश
• प्रोग्रामिंग विभाग - प्रति सप्ताह 10 आदेश
• परीक्षण विभाग - प्रति सप्ताह 5 आदेश

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

> हाथों की लकीरों को पीटने और प्रोग्रामर से ज्यादा प्रोजेक्ट्स को भर्ती करने से रोकने के लिए उनके पास समय है। स्वाभाविक रूप से, प्रोग्रामिंग विभाग के सामने एक छोटा प्रोजेक्ट बफर होना चाहिए।

पहली बात जो कम से कम कंपनी के प्रमुख कर सकते हैं, इसे पढ़ने के बाद, लेखक के सिर पर प्रहार किया जाएगा, फिर वह उसे नेपोलियन को टोपी पहनाएगा और उसे मूर्खता के लिए भेज देगा। यह है कि प्रोग्रामर को यह तय करने के लिए किस हद तक एक फर्म को बेचने की जरूरत है? मैं समझता हूं कि अनुरोधित बिक्री के लिए उत्पादन बढ़ाना उनके लिए मुश्किल है, लेकिन बिक्री के अवसरों की उपलब्धता बिक्री को हराने के लिए नहीं, बल्कि उनके अनुरोधों को पूरा करने की संभावनाओं पर काम करने का अवसर है।

रूसी में: वे कंपनी में पैसा लाते हैं, और कुछ इसे भेजने का इरादा रखते हैं।

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

प्रदर्शन क्षेत्रों को संतुलित करने से भी खुशी नहीं मिलती है। सिस्टम में "बीट्स" हैं और औसत लीड टाइम फिर से अशोभनीय मूल्यों तक बढ़ जाता है।

मैक्स क्रेमरेंको के पास एक संतुलित उत्पादन श्रृंखला मॉडलिंग करने पर एक ब्लॉग है:

• http://maximkr.livejournal.com/18940.html
• http://maximkr.livejournal.com/18971.html

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

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

फोर्ड ए-प्रकार और समाधान

इस प्रकार के प्रवाह के साथ समस्या विधानसभा संचालन में लापता घटक है।

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

1913 में, हेनरी फोर्ड ने अपने कारखाने में कारों की कन्वेयर असेंबली विधि पेश की। और 1926 तक, लौह अयस्क के खनन से उत्पादन चक्र एक तैयार कार (5,000 से अधिक भागों से युक्त) प्राप्त करने के लिए एक रेलवे प्लेटफॉर्म पर स्थित है और शिपमेंट के लिए तैयार है! 81 घंटे तक पहुंच गया! .. [1] एक उत्कृष्ट उपलब्धि। एक सॉफ्टवेयर उत्पादन प्रक्रिया स्थापित करने की जटिलता की कल्पना करें जिसमें कम से कम 50 उत्पादन साइटें हों। मेरा मानना ​​है कि अधिकांश आधुनिक प्रबंधक कार्य प्रवाह के प्रबंधन के लिए एक जटिल एसीएस (स्वचालित लेखा प्रणाली) का अनुरोध करेंगे। लेकिन सदी की शुरुआत में कंप्यूटर नहीं थे ...

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

हां, निश्चित रूप से यह प्रणाली काम नहीं करेगी यदि अतिरिक्त नियम पेश नहीं किया गया है: "जब आवंटित स्थान भरा हुआ है, तो इसे भरने वाले श्रमिकों को उत्पादन बंद करना होगा । " टहलने जाएं, झपकी लें, VKontakte पर बैठें, ...

फोर्ड ने आधुनिक प्रबंधन के मुख्य प्रावधानों में से एक को छोड़ दिया। हालांकि, अब, 99 साल बाद, थोड़ा बदल गया है। मुझे लगता है, एक साक्षात्कार के लिए एक ठेठ रूसी कंपनी में फोर्ड आते हैं और कहते हैं कि कंपनी की आय बढ़ाने के लिए अंशकालिक काम एक शर्त है , उसे बताया जाएगा कि वह वास्तविक उत्पादन का प्रबंधन करना नहीं जानता है।

अधिक जटिल प्रकार और टोयोटा प्रणाली

वी-टाइप प्रवाह की समस्याएं - "सामग्री की चोरी";
टी-टाइप प्रवाह समस्याएं - "चोरी" और लापता घटक;

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

दस्ताने को ताइची ओनो द्वारा उठाया गया था, जिन्होंने 1943 में टोयोटा मोटर कॉरपोरेशन में काम शुरू किया था। 1950 के दशक के मध्य में, उन्होंने एक विशेष उत्पादन संगठन प्रणाली का निर्माण करना शुरू किया, जिसे बाद में टोयोटा प्रोडक्शन सिस्टम (जिसे गलती से कानबन, लीन, जस्ट-इन-टाइम भी कहा जाता है) कहा जाने लगा।

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

"उस समय और जब तक टीपीएस को दुनिया भर में ख्याति प्राप्त नहीं हुई, तब तक लॉट का आकार बदलना परंपरागत समय को बदलने के समय को कम करने के लिए माना जाता था -" आर्थिक रूप से बहुत आकार का "एक बहुत लोकप्रिय शब्द था जिसके हजारों लेख समर्पित थे। इस सभी पारंपरिक अनुभव को अस्वीकार कर दिया। "[1]

इसने आधुनिक प्रबंधन प्रणाली को चुनौती दी। यह तर्कसंगत है कि उन्होंने उसे माफ नहीं किया। 40 के दशक के उत्तरार्ध से 60 के दशक की शुरुआत तक, उनकी प्रणाली को "घृणित ओनो प्रणाली" कहा जाता था।

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

जोड़ नियम

और फिर मजा शुरू होता है। यदि कार्य केंद्र एक से अधिक श्रृंखलाओं में शामिल है, तो इन श्रृंखलाओं को आरेख में जोड़ा जाना चाहिए:

ए-प्रकार के बाएं और दाएं प्रवाह को फोर्ड विज़ुअल मॉडल द्वारा नियंत्रित किया जा सकता है, लेकिन कार्य केंद्र "3" और "4" के संयुक्त उपयोग के कारण, यह योजना जटिल है और हमें ऑन मॉडल पर जाने की आवश्यकता है। यदि आप ऐसे जटिल मॉडल का उपयोग नहीं करना चाहते हैं, तो आपको कार्य केंद्रों को "3", "4" को "3 '," 3 "," 4 "," 4 "में विभाजित करना चाहिए।

प्रबंधन मॉडल और उनकी जटिलता की प्रयोज्यता को समझना, उद्यम के संगठनात्मक ढांचे और विकास नियमों को बदलने के निर्णय पर महत्वपूर्ण प्रभाव होना चाहिए।

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

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

मैट्रिक्स प्रणाली भी नकारात्मक प्रभाव की ओर ले जाती है जब एक कर्मचारी में दो प्रबंधक होते हैं: कार्यात्मक इकाई का प्रमुख और परियोजना प्रबंधक। यहां तक ​​कि Truffaldino ने दो स्वामी की सेवा करने का एक खराब काम किया। और वास्तविक परियोजनाओं पर वास्तविक फर्मों में, यह एक शानदार गड़बड़ी और सभी परियोजनाओं के समय में एक राक्षसी वृद्धि की ओर जाता है।

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

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

कानबन बोर्ड और गिनी पिग

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

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

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

कानबन बोर्ड और गिनी पिग में क्या आम है? कन्नन बोर्ड का समुद्र से गिनी पिग के रूप में कण्बन से समान संबंध है।

ऐसा लगता है, ठीक है, उन्होंने इसे गलत कहा, तो क्या? और तथ्य यह है कि गलत शब्द उपकरण की सार्वभौमिक प्रयोज्यता का भ्रम देता है। . , , - . « XP / SCRUM / Kanban / …» , , , . .

«» «XP / SCRUM / Kanban», . , , , .

I-.

, (: http://spmguild.org/news/618/) , , - . , , ( « ») ( «» ).

. . . - , … finita la comedia. « ». « , 2». .
( ) « IT (Kanban Development)» (http://habrahabr.ru/blogs/development/64997/ ). और अब सबसे महत्वपूर्ण बात। प्रत्येक कॉलम के तहत संख्या देखें? यह उन कार्यों की संख्या है जो इन स्तंभों में एक साथ हो सकते हैं। प्रयोगात्मक रूप से आंकड़े चुने जाते हैं, लेकिन यह माना जाता है कि उन्हें टीम में डेवलपर्स की संख्या पर निर्भर होना चाहिए।

यह एक फोर्ड उत्पादन लाइन जैसा दिखता है, लेकिन एक I- टाइप स्ट्रीम पर लागू होता है। वास्तव में, यह हेनरी फोर्ड के शासन का एक दृश्य है: "दो कार्य केंद्रों के बीच प्रगति में काम की मात्रा सीमित होनी चाहिए।"

अजीब तरह से पर्याप्त है, लेकिन अक्सर सिस्टम की सीमा ग्राहक द्वारा कार्य की स्वीकृति की साइट है। मैं कम से कम तीन फर्मों को जानता हूं जहां यह प्रभाव देखा गया था।

आई-बोर्ड के उपयोग पर एक और सीमा है। यह सीमा एक उत्पादन स्थल (एक ठेकेदार के लिए) में चक्र की दक्षता से जुड़ी है। यदि चक्र दक्षता 50% से कम है, तो नियम "एक कलाकार के पास केवल एक काम है" विफल होने लगता है।

नोट।चक्र की दक्षता उत्पादन स्थल पर खर्च किए गए कुल समय के प्रसंस्करण समय का अनुपात है। यदि सुबह आपको एक कार्य मिला, और आपने इसे छोड़ने से ठीक पहले किया था, तो कुल समय 8 घंटे है। यदि आपने 2 घंटे के लिए कार्य पर काम किया है, तो चक्र की दक्षता 25% है।

मैं उदाहरण दूंगा जहां प्रति इकाई समय में एक निष्पादक के लिए एक कार्य का प्रतिबंध अप्रभावी होगा:

• पुलिस परियोजनाएं (www.toc-center.ru/politseiskie_proekty.html)
• टीके और पीएमआई (GOST 34.602 और 34.603) लिखना। दस्तावेज़ एक-दूसरे को दृढ़ता से प्रभावित करते हैं और कभी-कभी एक ही समय में दो दस्तावेज़ लिखना आसान होता है।
• . . . , . .
• , . , , - .

यदि ऐसा होता है, तो उपयोग की शर्तों को कस लें। ठेकेदार को कई कार्यों पर एक साथ काम करने की अनुमति दें।

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

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

इस तरह के बोर्ड को शुरू करने से पहले, आपको चेकलिस्ट से गुजरना होगा:

• मैं- टाइप स्ट्रीम? यदि नहीं, तो सबसे अधिक संभावना है कि आपको एक साधारण बोर्ड शुरू करने के प्रयासों को छोड़ना होगा।
• ? , . .
• 50%? , .
• ? , - . , . -.

अक्सर एक ठोकर एक जटिल प्रकार की एक धारा है। प्रवाह के प्रकार को सरल बनाने के लिए, एक प्रभावी दवा व्यक्तिगत परियोजना टीमों और कार्यात्मक इकाइयों का अलगाव और अलगाव है।

लेकिन, बहुत बार, हम वाक्यांशों को सुनते हैं: “हम मदद नहीं कर सकते लेकिन उसे खींच सकते हैं। उसके सिवा कोई ऐसा नहीं कर सकता। और आप इसे पूरी तरह से हमें हस्तांतरित नहीं कर सकते। हमें सप्ताह में केवल चार घंटे उसकी जरूरत है। ”

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

कंपनी को अलग-थलग समूहों में विभाजित करने से अधिक, अधिक क्रॉस-फ़ंक्शनल विशेषज्ञों को लाभ मिल सकता है।

कंपनियों में से एक में, आपने विकास समूह के लिए एक सिस्टम प्रशासक और एक प्रोग्रामर को सिस्टम एडमिनिस्ट्रेशन ग्रुप को स्वीकार करने की सलाह पर गंभीरता से चर्चा की। सहकर्मियों का कहना है कि एक प्रयोग के रूप में लागू इस नियम ने एक अच्छा परिणाम दिखाया।

आंद्रेई ओर्लोव, एक ऑटोमेटर के नोट्स में, अंगूठे का एक सरल नियम प्रस्तावित किया: "यदि कोई प्रोग्रामर अपरिहार्य हो गया है, तो तुरंत उसे आग दें।"
प्रस्ताव बिल्कुल सही समझ में आता है। एक अपरिवर्तनीय कर्मचारी के पास सबसे अच्छी स्थानीय उत्पादकता हो सकती है, लेकिन उसकी अपरिहार्यता प्रवाह को बहुत अधिक अस्थिर कर देती है।

एक अन्य विकल्प धारा की लंबाई को कम करना है। कार्य केंद्रों की संख्या कम करने से नाटकीय रूप से तस्वीर बदल सकती है।

वास्तविक फर्मों में वास्तविक प्रक्रियाओं की टिप्पणियों पर आधारित एक जिज्ञासु कार्य।
. $2 000 ( ). . , , . , $2 000 : + . , . – 4 , – 6 , - $12 000 4 , . , . – 4 , – 4 , - $8 000.: « ROI ?» : : 18*2000 = $36000… , , , , . : 1 , (18-1)*… , , , , , .… : . « ». «, », «, » « ». - . . – (18-4)*2 000 = 28 000, – 28 000-12 000=16 000, ROI=133%. . . . . . . , . (18-12)*2000 = 12 000. – 4 000, ROI – 50% ROI, . , .
अवलोकनों से: पांच से छह कार्य केंद्रों के चैन जो कि सख्त सामान्य प्रबंधन से नहीं जुड़े होते हैं, अक्सर परियोजना की शुरूआत को संवेदनहीन बना देते हैं। यह पूरा होने से पहले अनावश्यक हो जाएगा। दो कार्य केंद्रों के साथ अपेक्षाकृत स्थिर चेन। तीन को पहले से ही समस्या है। श्रृंखला 1-> 2-> 1 माना जाता है कि 1-> 2-> 3 से अधिक स्थिर है।

मान स्ट्रीम में कार्य केंद्रों की संख्या कम करें। प्रत्यक्ष लागत बढ़ाने के लिए भी जाएं। प्रवाह को स्थिर करना और औसत लीड समय को कम करना इन लागतों को कवर करने से अधिक होगा।

आप चयनित विश्लेषक को मना कर सकते हैं - मना कर सकते हैं। आप चयनित परीक्षक को मना कर सकते हैं - मना कर सकते हैं। यदि आप या तो समर्पित परीक्षण या समर्पित विश्लेषण से इनकार नहीं कर सकते, तो एक व्यक्ति में एक परीक्षक और एक सिस्टम विश्लेषक की भूमिकाओं के संयोजन का प्रयास करें।

और अगर सिस्टम लागू नहीं है?

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

एक आफ्टरवर्ड के बजाय

और अपने समूह के कार्य प्रवाह के प्रकार को भ्रमित न करने का प्रयास करें। दस्त या कब्ज का इलाज करना काफी सरल है। लेकिन अगर आप ड्रग्स को मिलाते हैं, तो परिणाम आपको कुछ हद तक हैरान कर सकता है।

यदि आप प्रवाह के प्रकार को मिलाते हैं और टी-प्रकार के प्रवाह के लिए I-बोर्ड का उपयोग करने का प्रयास करते हैं, तो परिणाम आपको कम आश्चर्यचकित कर सकता है, लेकिन कंपनी के लिए परिणाम काफी बदतर होंगे यदि आप दस्त के लिए दवा मिलाते हैं।