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

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

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

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

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

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

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

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

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

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

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

Cloud ERP और दो-स्तरीय हक़ीक़त। Cloud ERP की ओर बढ़ने को अक्सर मानक प्रोसेसों पर लौटने और वर्षों के अनुकूलन को त्यागने के अवसर के रूप में बेचा जाता है, और वास्तव में सामान्य काम के लिए यह सही सलाह है। पर यही क़दम अक्सर एक दो-स्तरीय परिदृश्य में कठोर हो जाता है, एक मानकीकृत कोर जो उन विशेषीकृत सिस्टमों से घिरा होता है जो किसी कंपनी की वास्तविक विशिष्टता ढोते हैं। इसलिए डिज़ाइन का प्रश्न यह नहीं है कि अनुकूलन करें या नहीं, बल्कि यह कि विशिष्टता वैध रूप से कहाँ रहती है, कोर को मानक के क़रीब रखते हुए किनारे को भिन्न होने देना, और दोनों को दुर्घटनावश के बजाय जानबूझकर इंटीग्रेट करना।

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

एक रीइंजीनियर्ड प्रोसेस उतनी ही अच्छी होती है जितनी वह वास्तुकला जो उसे ढोती है। कुछ डिज़ाइन सिद्धांत उन पुनर्रचनाओं को उनसे अलग करते हैं जो टिकती हैं और जो चुपचाप पुराने रूप में लौट जाती हैं।

प्रति सिस्टम नहीं, प्रति तथ्य एकल सत्य स्रोत। हर चीज़ का मास्टर किसी एक सिस्टम को घोषित करने की प्रवृत्ति उतनी ही ग़लत है जितना कोई मास्टर न होना। अनुशासन अधिक सूक्ष्म है: हर महत्वपूर्ण इकाई और विशेषता के लिए, ठीक एक सिस्टम को नाम दें जो उसे रचता है, और बाकियों को सब्सक्राइब करने दें। CRM ग्राहक संबंध का स्वामी हो सकता है जबकि ERP कानूनी खाते और क्रेडिट स्थिति का स्वामी हो; जो मायने रखता है वह यह है कि स्वामित्व स्पष्ट, सहमत और प्रवर्तित हो, ताकि मिलान एक मासिक अनुष्ठान होना बंद कर दे।

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

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

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

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

इन कार्यक्रमों के विफल होने के तरीके इतने सुसंगत हैं कि उन्हें सूचीबद्ध किया जा सकता है, और अधिकांश तकनीक के बजाय निर्णय की विफलताएँ हैं।

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

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

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

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

परिणाम के बजाय सिस्टम द्वारा दायरा। एक ERP परियोजना या एक CRM परियोजना के रूप में गठित कार्यक्रम काम की सीमाओं के बजाय सॉफ़्टवेयर की सीमाएँ विरासत में पाते हैं, और क्रॉस-सिस्टम प्रवाह, जो ठीक वहीं हैं जहाँ मूल्य बैठता है, कार्यधाराओं के बीच की खाइयों में गिर जाते हैं। गठन को एक परिणाम और एक प्रवाह को नाम देना चाहिए, और सिस्टमों को उसके भीतर आने देना चाहिए।

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

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

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

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

प्रोसेस रीइंजीनियरिंग में हमारे काम को जो अलग करता है वह यह है कि हम CRM, सप्लाई चेन और ERP को अलग-अलग पुनर्रचनाओं वाले अलग-अलग क्षेत्रों के रूप में मानने से इनकार करते हैं। हम एंड-टू-एंड प्रवाह, उसमें से बहने वाले डेटा और उसे संचालित करने वाले संगठन को एक ही दृश्य में रखते हैं, और स्वामित्व तथा इंटीग्रेशन के कठिन प्रश्नों को कार्यान्वयन तक टालने के बजाय डिज़ाइन निर्णयों के रूप में सुलझाते हैं। यह शुरू करने के लिए एक कठिनतर बातचीत है और समाप्त करने के लिए कहीं अधिक टिकाऊ परिणाम है।

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

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