आप अपने पुराने सिस्टम से बिज़नेस नियम 3 चरणों में निकालते हैं: AI कोड पढ़ता है और हर नियम को एक साफ़ वाक्य में लिखता है जो उस लाइन से जुड़ा होता है जहाँ से वह आया; प्रक्रिया का मालिक उसे जाँचकर पुष्टि करता है या सुधारता है; और आप उसकी तुलना असली इनवॉइस पर सिस्टम के असली व्यवहार से करते हैं। मेनफ़्रेम के लिए AWS Transform जैसा टूल नियमों को समीक्षा योग्य ज़रूरतों के रूप में लिखता है, और 29 सितंबर 2026 को Amazon के साथ Thought Machine की घोषणा में नियम निकालने की प्रक्रिया 4 चरणों से गुज़रती है जिसका आख़िरी चरण इंसानी मंज़ूरी है। नियमों की पुष्टि होने तक कोई नया कोड न लिखें।

भाग 3 में आपने हर सिस्टम की सूची और एक अस्थायी फ़ैसला तैयार किया था। जिन सिस्टमों को आपने दोबारा बनाने या बदलने का फ़ैसला किया है, उन्हें सबसे पहले इस चरण की ज़रूरत है।

बिज़नेस नियम आपके पुराने सिस्टम की सबसे क़ीमती चीज़ क्यों हैं

बिज़नेस नियम वह तरीका है जिससे आपकी कंपनी कुछ गिनती या तय करती है: थोक ग्राहक की छूट कैसे निकलती है, देरी का जुर्माना कब जुड़ता है, एक तय सीमा से ऊपर के ख़रीद ऑर्डर को कौन मंज़ूर करता है, किस्त की रक़म कैसे राउंड होती है। ये नियम सालों के बदलावों में जमा हुए हैं, और इनमें से कई किसी दस्तावेज़ में कभी लिखे ही नहीं गए।

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

अगर आप इन नियमों के बिना सिस्टम दोबारा बनाते हैं, तो आप एक नया सिस्टम बनाएँगे जो अलग तरह से हिसाब लगाता है, और आपको यह तभी पता चलेगा जब कोई ग्राहक किसी इनवॉइस पर आपत्ति करेगा। जिसे आगे जाना है वह नियम हैं; पुरानी प्रोग्रामिंग भाषा तो बस एक बर्तन है।

AI कोड कैसे पढ़ता है और नियम कैसे लिखता है

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

नियम किस फ़ॉर्मेट में लिखा जाता है, यह मायने रखता है। एक जाना-माना फ़ॉर्मेट EARS है, यानी Easy Approach to Requirements Syntax, जिसे Alistair Mavin और Rolls-Royce में उनके साथियों ने विकसित किया और पहली बार 2009 में प्रकाशित किया। इसका विचार यह है कि हर नियम एक तय क्रम में लिखा जाए: पहले स्थिति, फिर ट्रिगर, फिर वह जो सिस्टम को करना है। इसके 5 बुनियादी पैटर्न हैं; यहाँ बिज़नेस से जुड़े उदाहरण हैं:

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

इस फ़ॉर्मेट की ख़ूबी यह है कि प्रक्रिया का मालिक प्रोग्रामिंग जाने बिना इसे पढ़कर परख सकता है। हर नियम के लिए एक वाक्य, और जवाब हाँ, नहीं या अधूरा।

बैंकिंग से एक उदाहरण: लाइन दर लाइन अनुवाद नहीं, बिज़नेस का इरादा

सबसे साफ़ हालिया उदाहरण बैंकिंग से है, जहाँ ब्याज, शुल्क और भुगतान के नियम दशकों से मेनफ़्रेम पर COBOL कोड में रहते आए हैं। COBOL एक पुरानी प्रोग्रामिंग भाषा है जो आज भी बैंकिंग और बीमा के कई सिस्टम चलाती है। बैंकिंग टेक्नोलॉजी कंपनी Thought Machine ने 29 सितंबर 2026 की अपनी घोषणा में कहा कि वह Amazon के साथ एक ऐसी प्रक्रिया पर काम कर रही है जो कोड का लाइन दर लाइन अनुवाद नहीं करती, बल्कि शुद्ध बिज़नेस इरादा निकालती है। घोषणा के अनुसार यह प्रक्रिया 4 चरणों में चलती है:

  1. निकालना: AWS Transform पुराने ऐप्लिकेशन पढ़ता है और बिज़नेस लॉजिक को EARS फ़ॉर्मेट में लिखे स्पेसिफ़िकेशन में निकालता है।
  2. एकीकरण: एक ही प्रोडक्ट के सैकड़ों दोहराए गए रूपों को छोटे, आधुनिक स्पेसिफ़िकेशन में मिला दिया जाता है।
  3. निर्माण: AI एजेंट Python में वित्तीय प्रोडक्ट और उनके टेस्ट बनाते हैं।
  4. सत्यापन: इंसानी समीक्षा, जिसमें बैंक की इंजीनियरिंग और जोखिम टीमों के पास साफ़ मंज़ूरी का अधिकार होता है।

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

प्रक्रिया के मालिक को हर नियम की पुष्टि क्यों करनी चाहिए

AI पढ़ता है कि कोड क्या करता है, यह नहीं कि कंपनी क्या चाहती है। इन दोनों के बीच का फ़ासला ही वह जगह है जहाँ आधुनिकीकरण की गलतियाँ होती हैं:

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

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

Origami का नज़रिया

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

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

इस हफ़्ते का अभ्यास: एक नियम, तीन इनवॉइस

शुरू करने के लिए किसी टूल का इंतज़ार ज़रूरी नहीं। कोई ऐसा नियम चुनें जिस पर अक्सर बहस होती है, जैसे छूट या देरी का जुर्माना, और ये चरण अपनाएँ:

  1. प्रक्रिया के मालिक से कहें कि वह नियम को एक वाक्य में इस रूप में लिखे: जब ..., सिस्टम को ... करना होगा
  2. सिस्टम से 3 असली इनवॉइस निकालें जिन पर यह नियम लागू हुआ: एक सामान्य, एक सीमा पर और एक अपवाद वाला।
  3. लिखे गए वाक्य से हर इनवॉइस का हाथ से हिसाब लगाएँ और नतीजे की तुलना सिस्टम के नतीजे से करें।
इनवॉइसलिखा गया नियम क्या कहता हैसिस्टम ने क्या कियामेल खाता है?
1 - सामान्य मामला
2 - सीमा पर
3 - अपवाद

अगर तीनों मेल खाते हैं, तो नियम दर्ज हो गया। अगर एक भी अलग है, तो आपने एक छिपा नियम या पुरानी गलती ढूँढ ली है, और किसी भी आधुनिकीकरण से पहले ठीक यही जानना ज़रूरी है।

अगले भाग में

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

स्रोत