क्रॉस-फ़ंक्शनल वार्ताओं के लिए निर्णय भूमिकाएँ परिभाषित करें

एक वार्ता RACI को अधिकार को महत्वपूर्ण निर्णय या डिलिवरेबल के आधार पर विभाजित करना चाहिए—पूरे सौदे के लिए एक ही भूमिका नहीं सौंपनी चाहिए। हर महत्वपूर्ण निर्णय के लिए यह पहचानें कि परिणाम का स्वामी कौन है, कार्य की तैयारी कौन करता है, विशेषज्ञ साक्ष्य कौन देता है, अपवाद को कौन अनुमोदित करता है, आपूर्तिकर्ता से कौन संवाद कर सकता है, और परिणामी प्रतिबद्धता को कौन निष्पादित करता है।

यह निर्णय-स्तरीय दृष्टिकोण वार्ता भूमिकाओं और Cross Functional Negotiation Ownership को स्पष्ट करता है। यह प्रोक्योरमेंट, वित्त, विधि, संचालन, सुरक्षा और तकनीकी टीमों को प्रतिस्पर्धी आवाज़ों में बदलने से रोकता है, जबकि एक Enterprise negotiation के लिए आवश्यक समीक्षाओं को बनाए रखता है।

त्वरित उत्तर

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

पूरी वार्ता के लिए एक ही RACI क्यों विफल होता है

एक तालिका जो प्रोक्योरमेंट को “Responsible”, व्यवसाय को “Accountable” और बाकी सभी को “Consulted” बताती है, व्यवस्थित दिख सकती है, लेकिन यह महत्वपूर्ण प्रश्नों को अनुत्तरित छोड़ देती है:

• मूल्य की अधिकतम सीमा कौन तय करता है?
• कौन निर्णय करता है कि कोई तकनीकी विकल्प स्वीकार्य है या नहीं?
• साइबरसुरक्षा अपवाद कौन स्वीकार कर सकता है?
• अतिरिक्त एक वर्ष की अवधि को कौन अधिकृत करता है?
• आपूर्तिकर्ता बैठक के दौरान रियायत कौन दे सकता है?
• अवार्ड को कौन अनुमोदित करता है?
• हस्ताक्षर करने का प्रत्यायोजित प्राधिकरण किसके पास है?
• हस्ताक्षर के बाद कार्यान्वयन का स्वामी कौन है?

ये अलग-अलग निर्णय हैं, जिनके लिए अलग-अलग साक्ष्य और प्राधिकरण आवश्यकताएँ होती हैं। इन्हें एक ही पंक्ति में रखने से स्पष्टता का आभास होता है, जबकि गवर्नेंस की खामियाँ छिप जाती हैं।

प्रभावी Negotiation management इसके बजाय निर्णय अधिकारों को किसी सौदे की परिचालन प्रणाली का हिस्सा मानता है। RACI उन अधिकारों को संप्रेषित करता है; वह उन्हें बनाता नहीं है।

नाम सौंपने से पहले वार्ता भूमिकाएँ परिभाषित करें

पारंपरिक RACI अर्थ एक उपयोगी प्रारंभिक बिंदु प्रदान करते हैं। एक draft NIST publication Responsible, Accountable, Consulted, और Informed भूमिकाओं का वर्णन करता है। क्योंकि वह दस्तावेज़ एक ड्राफ्ट है और एक बाहरी business-analysis स्रोत का संदर्भ देता है, इसलिए वह परिभाषात्मक समर्थन है—बाध्यकारी मानक नहीं।

Responsible: कार्य की तैयारी करता है या उसे पूरा करता है

Responsible व्यक्ति वित्तीय मॉडल बनाता है, जनादेश का मसौदा तैयार करता है, तकनीकी मूल्यांकन का नेतृत्व करता है, समझौते का मसौदा तैयार करता है, या कोई अन्य निर्दिष्ट कार्य पूरा करता है। जटिल कार्यों में कई लोग responsible हो सकते हैं, हालांकि प्रत्येक व्यक्ति का डिलिवरेबल स्पष्ट होना चाहिए।

Accountable: निर्णय या परिणाम का स्वामी होता है

Accountable व्यक्ति किसी विशिष्ट निर्णय को लेता है या उसका स्वामी होता है। प्रति पंक्ति एक accountable मानव रखें। यदि दो अधिकारियों की सहमति आवश्यक हो, तो एक परिणाम-स्वामी की पहचान करें और दूसरे को अनिवार्य अनुमोदक के रूप में सूचीबद्ध करें।

Accountability का अर्थ यह नहीं है कि वही व्यक्ति सारा काम भी करे। कोई business sponsor आवश्यक परिणाम का स्वामी हो सकता है, जबकि कोई procurement lead वाणिज्यिक रणनीति तैयार करे।

Consulted: निर्णय से पहले इनपुट देता है

वित्त, विधि, गोपनीयता, सुरक्षा, संचालन, गुणवत्ता और तकनीकी विशेषज्ञों को अपने-अपने क्षेत्रों में विश्लेषण देना चाहिए। Consultation उन्हें एक परिभाषित आवाज़ देता है, लेकिन यह उन्हें संगठन की ओर से प्रतिबद्धता करने का स्वचालित अधिकार नहीं देता।

इस विभाजन का एक उपयोगी सार्वजनिक-क्षेत्र समानांतर है: FAR Part 15 contracting officers को विशेषज्ञ सलाह लेने की अनुमति देता है, जबकि संबंधित acquisition determinations की ज़िम्मेदारी उनके पास ही रहती है। सरकारी नियम निजी कंपनियों पर स्वतः लागू नहीं होते, लेकिन विशेषज्ञ विश्लेषण और अंतिम प्राधिकरण के बीच का यह अंतर व्यापक रूप से उपयोगी है।

Informed: परिणाम प्राप्त करता है

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

Approver: प्रतिबद्धता या अपवाद को अधिकृत करता है

एक बुनियादी RACI अनुमोदन प्राधिकरण को धुंधला कर सकता है, इसलिए एक अलग approval column जोड़ें। Approver को प्रस्ताव, अवार्ड, नीति अपवाद, जोखिम स्वीकृति, या जनादेश से परे रियायत को स्पष्ट रूप से अधिकृत करना चाहिए।

सार्वजनिक प्रोक्योरमेंट नियम इस अंतर को दर्शाते हैं: FAR 6.304 कुछ निर्णयों के लिए लिखित अनुमोदन और अलग-अलग अनुमोदन स्तर निर्दिष्ट करता है। आपके संगठन की सीमाएँ अलग होंगी, लेकिन recommendation, approval, negotiation, और execution को समानार्थी नहीं माना जाना चाहिए।

Signatory: संगठन को बाध्य करता है

Signatory के पास किसी समझौते को निष्पादित करने का औपचारिक रूप से प्रत्यायोजित प्राधिकरण होता है। Signatory sponsor, approver, या lead negotiator होना आवश्यक नहीं है। FAR Subpart 1.6 एक स्पष्ट सरकारी उदाहरण देता है: contracting officers सरकार को केवल प्रत्यायोजित प्राधिकरण की सीमा के भीतर ही बाध्य कर सकते हैं और उन्हें यह सुनिश्चित करना होता है कि आवश्यक approvals और clearances प्राप्त हो चुके हों।

किसी निजी संगठन के लिए, वास्तविक प्राधिकरण लागू कानून और आंतरिक साधनों—जैसे bylaws, delegation schedules, policies, और board resolutions—से आता है, स्वयं RACI से नहीं।

एक पुन: प्रयोज्य वार्ता RACI टेम्पलेट

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

डिज़ाइन नियम: संयुक्त निर्णयों को विभाजित करें

“अनुबंध को अनुमोदित करें” आमतौर पर बहुत व्यापक होता है। इसके लिए अलग-अलग पंक्तियाँ आवश्यक हो सकती हैं:

1. वाणिज्यिक अनुमोदन
2. बजट प्राधिकरण
3. तकनीकी स्वीकृति
4. विधिक समीक्षा
5. गोपनीयता या सुरक्षा समीक्षा
6. परिचालन जोखिम स्वीकृति
7. आपूर्तिकर्ता अवार्ड प्राधिकरण
8. हस्ताक्षर

हर पंक्ति में निर्णय, साक्ष्य, सीमा, और मानव प्राधिकरण की पहचान होनी चाहिए। यही Cross Functional Negotiation Ownership का व्यावहारिक मूल है।

निर्णय अधिकार सौंपने की छह-चरणीय प्रक्रिया

1. बैठक प्रतिभागियों की नहीं, निर्णयों की सूची बनाएँ

योजना से लेकर कार्यान्वयन तक संगठन जिन विकल्पों का सामना कर सकता है, उनसे शुरुआत करें। अपनी negotiation planning process, requirements, supplier risks, draft terms, और संभावित concessions की समीक्षा करें।

मूल्य, मात्रा, service levels, implementation, term length, data access, exclusivity, liability, termination, transition, और supplier selection से जुड़े निर्णय शामिल करें। केवल उपस्थिति से प्राधिकरण नहीं बनता।

2. हर निर्णय के लिए एक उत्तरदायी मानव नामित करें

“steering committee” जैसे लेबलों से बचें, जब तक कि उसका charter यह परिभाषित न करता हो कि वह कैसे निर्णय लेती है और परिणाम कौन दर्ज करता है। हर परिणाम का स्वामी एक नामित मानव होना चाहिए, भले ही किसी अन्य व्यक्ति की स्वीकृति अनिवार्य हो।

UK Cabinet Office का Sourcing Playbook cross-functional तैयारी, परिभाषित टीम भूमिकाएँ, सक्षम प्रतिभागी, मजबूत chairing, और पूर्व-सहमति वाली negotiation positions का समर्थन करता है।

3. निर्दिष्ट करें कि प्रत्येक contributor को कौन-सा साक्ष्य देना होगा

Consultation से केवल राय नहीं, बल्कि समीक्षा योग्य साक्ष्य उत्पन्न होना चाहिए। निर्णय के आधार पर, निम्नलिखित माँगें:

• बजट स्रोत और affordability limit
• demand और volume assumptions
• technical acceptance criteria
• alternative suppliers और switching constraints
• operational dependencies और exit costs
• privacy, security, safety, sanctions, और geographic risks
• liability, warranty, insurance, और termination implications
• implementation dates और resource requirements
• assumption owners, evidence dates, और uncertainty ranges

मूल्य विश्लेषण के लिए, FAR एक और उपयोगी—हालाँकि बाध्यकारी नहीं—control analogy प्रदान करता है: FAR Part 15 विश्लेषण की गहराई को acquisition की complexity और circumstances से जोड़ता है।

4. वार्ताकार का जनादेश लिखें

जनादेश में यह स्पष्ट होना चाहिए:

• उद्देश्य और प्राथमिकताएँ
• प्रारंभिक स्थिति और लक्ष्य
• walk-away या reservation point
• tradeable terms और prohibited trades
• concessions से जुड़ी शर्तें
• authority limits
• escalation triggers और contacts
• जनादेश की expiration या review date

इसके बाद lead negotiator अनुमोदित सीमाओं के भीतर आत्मविश्वास से काम कर सकता है, बिना हर supplier movement को पूरी टीम को फिर से बुलाने का कारण बनाए। व्यापक तैयारी workflow के लिए, देखें An Eight-Step Negotiation Planning Process।

5. बैठक से पहले escalation rules परिभाषित करें

आपूर्तिकर्ता द्वारा समय-सीमित प्रस्ताव देने का इंतज़ार न करें। यह पहले से तय करें कि किन परिवर्तनों पर विराम आवश्यक होगा, जिनमें nonstandard terms, additional scope, prepayment, longer duration, exclusivity, increased data access, weakened remedies, या altered implementation schedule शामिल हैं।

Escalation में approver, required evidence, communication channel, और expected response window की पहचान होनी चाहिए। response window एक आंतरिक service expectation है, मौन से अनुमोदन मान लेने की अनुमति नहीं।

6. हस्ताक्षर के बाद स्वामित्व हस्तांतरित करें

वार्तित वादों को एक obligation register में बदलें। हर प्रतिबद्धता के लिए owner, deadline, completion evidence, review cadence, और change-control path दर्ज करें।

इसी तरह Negotiation management Institutional knowledge को संरक्षित करता है: तर्क और दायित्व बैठक के बाद भी बने रहते हैं और केवल एक buyer के notes में सीमित नहीं रह जाते।

काल्पनिक उदाहरण: एक महत्वपूर्ण logistics-services renewal

निम्नलिखित परिदृश्य काल्पनिक है। इसके तथ्य और आँकड़े केवल उदाहरणात्मक हैं, benchmark नहीं।

एक निर्माता एक क्षेत्रीय logistics agreement का नवीनीकरण कर रहा है। प्रोक्योरमेंट आपूर्तिकर्ता चर्चाओं का नेतृत्व करता है। संचालन अधिक कड़े delivery windows चाहता है, वित्त affordability analysis का स्वामी है, information security shipment data तक carrier access की समीक्षा करता है, legal liability और termination language की समीक्षा करता है, और supply-chain executive परिणाम को sponsor करता है।

एक कमजोर negotiation RACI पूरे renewal के लिए procurement को Responsible और executive को Accountable सूचीबद्ध करता है। बैठक के दौरान, supplier बेहतर delivery commitments के बदले लंबी अवधि, आंशिक prepayment, और व्यापक data access की पेशकश करता है। टीम यह नहीं समझ पाती कि इस package का मूल्यांकन या अनुमोदन कौन कर सकता है।

एक decision-level matrix इस अस्पष्टता को दूर करता है:

• operations director परिचालन स्वीकार्यता का स्वामी है।
• वित्त cash और affordability effects को validate करता है।
• security यह निर्धारित करती है कि प्रस्तावित access control requirements को पूरा करता है या नहीं।
• legal संविदात्मक परिणामों पर सलाह देता है।
• executive sponsor निर्णय करता है कि कुल package business need को पूरा करता है या नहीं।
• एक नामित risk executive किसी भी threshold-level exception को अनुमोदित करता है।
• procurement केवल अनुमोदित mandate के भीतर ही trade कर सकता है।
• authorized signatory अंतिम अनुमोदित agreement को execute करता है।
• contract manager बाद में delivery, data-access, और implementation obligations को track करता है।

यदि इस workflow में Negotiations.AI का उपयोग किया जाए, तो यह role assignments, source-backed assumptions, mandate boundaries, और concession-log entries को रिकॉर्ड करने के लिए एक structured preparation workspace के रूप में काम कर सकता है। ये रिकॉर्ड समीक्षा में सहायक हो सकते हैं, लेकिन trade-offs का निर्णय, exceptions का अनुमोदन, और commitments का authorization फिर भी नामित मनुष्यों को ही करना होगा।

साक्ष्य लेबल जो RACI को ईमानदार बनाए रखते हैं

एक decision matrix उतना ही विश्वसनीय होता है जितने उसके inputs। हर महत्वपूर्ण input को चार प्रकारों में से एक के रूप में लेबल करें:

Verified fact

ऐसा कथन जो वर्तमान, उद्धृत स्रोत द्वारा समर्थित हो—उदाहरण के लिए, signed contract clause, approved budget, validated technical test, या current delegation schedule। स्रोत और तिथि दर्ज करें।

Assumption

योजना के लिए प्रयुक्त कोई प्रस्तावना जो अभी सत्यापित नहीं हुई है—उदाहरण के लिए, कि transition किसी विशेष तिथि तक हो सकता है। उसके owner और validation deadline का नाम दर्ज करें।

Estimate

अनिश्चितता के साथ कोई गणना-आधारित या निर्णय-आधारित मान—उदाहरण के लिए, implementation effort या switching cost। जहाँ व्यावहारिक हो, method, range, और sensitivity दर्ज करें।

Recommendation

facts, assumptions, और estimates पर आधारित प्रस्तावित कार्यवाही। उसके author और required approver की पहचान करें। किसी recommendation को authority की तरह प्रस्तुत न करें।

यह labeling Institutional knowledge को अनिश्चित inputs को याद किए गए “facts” में बदलने से रोकने में मदद करती है।

जहाँ उत्तरदायी मानव समीक्षा अनिवार्य रहती है

Software साक्ष्य को व्यवस्थित कर सकता है, drafts की तुलना कर सकता है, deviations को flag कर सकता है, records का सारांश बना सकता है, और concession log बनाए रख सकता है। लेकिन निम्नलिखित के लिए वह एकमात्र निर्णयकर्ता नहीं होना चाहिए:

• walk-away position निर्धारित करना या बदलना
• विधिक, नियामकीय, सुरक्षा, गोपनीयता, साइबरसुरक्षा, या प्रतिष्ठात्मक जोखिम स्वीकार करना
• गैर-समतुल्य तकनीकी समाधानों में से चयन करना
• यह निर्धारित करना कि एक रियायत किसी अलग जोखिम की भरपाई करती है या नहीं
• नीति या competitive-process exceptions को अनुमोदित करना
• वाणिज्यिक, परिचालन, और control objectives के बीच संघर्षों का समाधान करना
• यह पुष्टि करना कि अंतिम agreement अनुमोदित business case से मेल खाता है
• यह स्थापित करना कि किसी व्यक्ति के पास संगठन को बाध्य करने का प्राधिकरण है या नहीं
• किसी agreement को award, sign, terminate, या materially modify करना

उत्तरदायी मानव को संबंधित साक्ष्य की समीक्षा करनी चाहिए, अनिश्चितता को समझना चाहिए, और निर्णय दर्ज करना चाहिए। कोई automated status change वास्तविक अनुमोदन नहीं है।

सामान्य विफलता पैटर्न और सुधार

अनेक accountable owners

जोखिम: किसी के पास स्पष्ट स्वामित्व नहीं होता, या हर स्वामी मान लेता है कि दूसरा निर्णय करेगा।

सुधार: एक accountable owner रखें और जहाँ सहमति आवश्यक हो वहाँ mandatory approvers जोड़ें।

प्रोक्योरमेंट हर पंक्ति का स्वामी है

जोखिम: प्रोक्योरमेंट को नाममात्र रूप से उन तकनीकी, विधिक, या परिचालन निर्णयों के लिए accountable बना दिया जाता है जो उसकी विशेषज्ञता और प्राधिकरण से बाहर हैं।

सुधार: जहाँ उपयुक्त हो, प्रोक्योरमेंट वाणिज्यिक प्रक्रिया का स्वामी हो; domain owners अपने विशेषज्ञ निर्णय बनाए रखें।

हर चीज़ पर सभी consulted हैं

जोखिम: तैयारी धीमी हो जाती है, आंतरिक असहमतियाँ फैलती हैं, और प्रभावित हितधारक वास्तविक veto holders बन जाते हैं।

सुधार: केवल उन्हीं भूमिकाओं से consultation लें जिनका साक्ष्य उस निर्णय के लिए आवश्यक है। बाकी सभी को informed रखें।

केवल value ही approval trigger है

जोखिम: कम-मूल्य वाला agreement भी गंभीर data, safety, operational, liability, exclusivity, या continuity exposure पैदा कर सकता है।

सुधार: value, duration, reversibility, criticality, data access, legal deviation, prepayment, और concentration risk को कवर करने वाले multidimensional triggers का उपयोग करें।

वार्ताकार और signatory को एक-दूसरे के स्थान पर मान लिया जाता है

जोखिम: आपूर्तिकर्ता चर्चा को प्रतिबद्धता समझ लेता है, या कोई अनधिकृत व्यक्ति संगठन को बाध्य करता हुआ प्रतीत होता है।

सुधार: वार्ताकार का mandate स्पष्ट रूप से संप्रेषित करें और अंतिम प्रतिबद्धता authorized signatory के लिए सुरक्षित रखें।

प्रारंभिक अनुमोदन को अंतिम package पर भी लागू मान लिया जाता है

जोखिम: महत्वपूर्ण रूप से बदला हुआ सौदा पुराने authorization के आधार पर आगे बढ़ जाता है।

सुधार: जब परिभाषित सीमाएँ या assumptions बदलें, तो renewed approval आवश्यक करें।

सीमाएँ और अनुपातिक अनुप्रयोग

एक negotiation RACI संचार का तंत्र है, विधिक प्राधिकरण का प्रमाण नहीं। लागू कानून, corporate governance, procurement policy, delegations, और sector-specific rules ही नियंत्रण करते हैं।

सरकारी प्रोक्योरमेंट स्रोत उपयोगी governance examples देते हैं, लेकिन वे निजी संगठनों पर स्वतः बाध्यकारी नहीं होते। इसी तरह, एक RACI अस्पष्ट उद्देश्यों, अनुपस्थित साक्ष्य, परस्पर विरोधी प्रोत्साहनों, या अवास्तविक mandate को ठीक नहीं कर सकता।

नियंत्रण अनुपातिक होने चाहिए। एक नियमित खरीद को regulated service, strategic outsourcing, या critical technology agreement की तुलना में कम decision rows की आवश्यकता हो सकती है। छोटे संगठनों में हर duty को अलग करने के लिए पर्याप्त लोग नहीं हो सकते। जहाँ separation व्यावहारिक न हो, वहाँ independent review, dual approval, restricted system permissions, या post-transaction audit पर विचार करें। उपयुक्त नियंत्रण के लिए उत्तरदायी मानव निर्णय आवश्यक है।

GAO Green Book एक प्रामाणिक public-sector internal-control framework प्रदान करता है, जिसमें incompatible duties को अलग करने से संबंधित सिद्धांत शामिल हैं। यह उपयोगी reference material है, लेकिन संगठनों को controls को अपने दायित्वों और risk context के अनुसार अनुकूलित करना चाहिए।

वार्ता नेताओं के लिए अंतिम चेकलिस्ट

आपूर्तिकर्ता से जुड़ने से पहले, पुष्टि करें कि:

• हर महत्वपूर्ण निर्णय के लिए एक उत्तरदायी मानव है।
• Responsible contributors के पास विशिष्ट deliverables और deadlines हैं।
• Consultation से प्रलेखित साक्ष्य उत्पन्न होता है।
• facts, assumptions, estimates, और recommendations को अलग-अलग लेबल किया गया है।
• approval thresholds केवल value नहीं, बल्कि risk और terms को भी कवर करते हैं।
• negotiation mandate targets, limits, trades, और escalation triggers को परिभाषित करता है।
• supplier-facing participants जानते हैं कि कौन प्रस्ताव दे सकता है, सिफारिश कर सकता है, अनुमोदित कर सकता है, और संगठन को बाध्य कर सकता है।
• signature authority का सत्यापन RACI से स्वतंत्र रूप से किया गया है।
• महत्वपूर्ण परिवर्तनों पर renewed human review शुरू होता है।
• अंतिम commitments को नामित implementation और supplier-management owners को हस्तांतरित किया जाता है।

इस प्रकार उपयोग किए जाने पर, Negotiation Roles केवल बैठक को व्यवस्थित करने से अधिक काम करते हैं। वे विशेषज्ञों को कई supplier-facing आवाज़ें बनाए बिना योगदान करने देते हैं, वार्ताकारों को स्पष्ट सीमाओं के भीतर आगे बढ़ने में सक्षम बनाते हैं, और महत्वपूर्ण प्रतिबद्धताओं पर executive control को सुरक्षित रखते हैं।

आगे पढ़ें

• The Sourcing Playbook — UK Cabinet Office
• FAR Part 15: Contracting by Negotiation
• FAR Subpart 1.6: Contracting Authority and Responsibilities
• The Green Book — U.S. Government Accountability Office
• Draft NISTIR 8179: RACI definitions

FAQ

क्या procurement को हमेशा procurement negotiation का स्वामी होना चाहिए?

Procurement वाणिज्यिक प्रक्रिया का स्वामी हो सकता है और supplier discussions का नेतृत्व कर सकता है, लेकिन उसे स्वतः हर निर्णय का स्वामी नहीं होना चाहिए। वित्त model integrity का स्वामी हो सकता है, technical teams technical acceptability की स्वामी हो सकती हैं, legal legal interpretation का स्वामी हो सकता है, नामित executives परिभाषित risks स्वीकार कर सकते हैं, और business sponsor यह तय कर सकता है कि पूरा package business need को पूरा करता है या नहीं।

क्या negotiation RACI में दो लोग Accountable हो सकते हैं?

एक निर्णय के लिए संयुक्त accountability से बचें। एक outcome owner नामित करें और दूसरे व्यक्ति को mandatory approver के रूप में दिखाएँ। यदि दोनों लोग वास्तव में अलग-अलग निर्णयों के स्वामी हैं, तो पंक्ति विभाजित करें—उदाहरण के लिए, affordability approval को operational acceptance से अलग करें।

क्या approval, Consulted होने के समान है?

नहीं। consulted specialist निर्णय से पहले input देता है। approver को प्रस्ताव, अपवाद, या प्रतिबद्धता को स्पष्ट रूप से अधिकृत करना होता है। यदि approval अनिवार्य है, तो उसे अलग column में उसकी threshold और evidence requirements के साथ दर्ज करें।

negotiation roles को कितनी बार अपडेट किया जाना चाहिए?

जब scope, risk, team membership, supplier proposals, assumptions, या final terms में महत्वपूर्ण परिवर्तन हो, तब उनकी समीक्षा करें। award, signature, और handoff से पहले भी उन्हें पुनः पुष्टि करें। negotiation RACI को वर्तमान decision path को दर्शाना चाहिए, केवल kickoff के समय की team structure को नहीं।

क्या RACI किसी को अनुबंध पर हस्ताक्षर करने का प्राधिकरण देता है?

नहीं। signature authority लागू कानून और वैध organizational delegations से आती है, matrix से नहीं। signatory के वर्तमान authority और आवश्यक prior approvals का अलग से सत्यापन करें।

अस्वीकरण: यह लेख सामान्य परिचालन मार्गदर्शन प्रदान करता है और यह विधिक, वित्तीय, नियामकीय, या प्रोक्योरमेंट सलाह नहीं है।