तुलनीय प्रस्ताव एक स्पष्ट कार्य विवरण से शुरू होते हैं: देने योग्य 12 महत्वपूर्ण जानकारियां

ब्रिटेन का वर्तमान Sourcing Playbook कहता है कि स्पष्ट विनिर्देश में इतनी जानकारी होनी चाहिए कि संभावित बोलीदाता समझदारी से तय कर सकें कि वे प्रस्ताव देना चाहते हैं या नहीं। वह यह भी बताता है कि आवश्यकताओं की साझा समझ न हो तो प्रस्तावित कीमतों को खरीदार की लागत और अपेक्षित परिणामों की समझ से जोड़ना कठिन होता है। [1]

Government Commercial Function इसे और सीधे कहता है: अच्छा विनिर्देश आपूर्तिकर्ताओं को वस्तु या सेवा की लागत सही तरह से निकालने के लिए पर्याप्त जानकारी दे, ताकि खरीदार प्रस्तावों की समान आधार पर तुलना कर सके। [2]

साथ ही ब्रिटेन का Digital, Data and Technology Playbook समाधान को जरूरत से ज्यादा पहले से तय करने के खिलाफ चेतावनी देता है। वह उपयोगकर्ता, समस्या और अपेक्षित परिणाम पर ध्यान देने और आपूर्तिकर्ता को प्रभावी तरीका सुझाने की जगह देने की सलाह देता है। [3]

इसलिए निष्कर्ष "हर बात सबसे अधिक विस्तार से लिखो" नहीं है। बेहतर नियम है:

जो बात सभी प्रस्तावों में समान होनी चाहिए उसे सटीक लिखें, पर वह बात न थोपें जिसे सक्षम विशेषज्ञ उचित रूप से खुद डिजाइन कर सकता है।

दो पेशेवर प्रस्ताव पूरी तरह समान नहीं होंगे, और ऐसा होना लक्ष्य भी नहीं है।

तुलनीयता का अर्थ है कि विशेषज्ञ लगभग समान मान्यताओं के तहत उसी समस्या का उत्तर दे रहे हों।

इसलिए उन्हें लगभग समान जानकारी होनी चाहिए:

• उद्देश्य,
• दायरा,
• शुरुआती स्थिति,
• अपेक्षित परिणाम,
• महत्वपूर्ण सीमाएं,
• समय-सारणी,
• ग्राहक की जिम्मेदारियां,
• कीमत किस रूप में दी जाए,
• प्रस्ताव किस आधार पर चुना जाएगा।

वे इन बातों में अलग हो सकते हैं:

• सुझाया गया तरीका,
• काम का क्रम,
• कार्यविधि,
• टीम संरचना,
• औजार,
• चरणों में विभाजन,
• जोखिम कम करने का तरीका।

ये अंतर अक्सर मूल्यवान होते हैं और दिखाई देने चाहिए।

विशेषताओं की सूची से नहीं, समस्या से शुरू करें।

इसके बजाय:

"मुझे डैशबोर्ड, सूचनाओं और रिपोर्ट वाला अनुप्रयोग चाहिए।"

ऐसा लिखें:

"अभी पांच लोग इलेक्ट्रॉनिक तालिकाओं और ईमेल से प्रक्रिया संभालते हैं। किसी मामले की वर्तमान स्थिति, जिम्मेदार व्यक्ति और अगला काम समझना मुश्किल है। हम हाथ से निगरानी कम करना और वर्तमान स्थिति के लिए एक ही स्थान चाहते हैं।"

दूसरा विवरण अभी यह तय नहीं करता कि कौन सा अनुप्रयोग बनेगा।

लेकिन वह विशेषज्ञ को समझाता है कि परियोजना की जरूरत क्यों पैदा हुई।

परिणाम-आधारित सेवाओं के लिए Federal Acquisition Regulation काम को मुख्य रूप से आवश्यक परिणामों से बताने की सलाह देता है, न कि केवल इस आधार पर कि काम कैसे होगा या कितने घंटे दिए जाएंगे। उसके न्यूनतम उद्देश्य विवरण में उद्देश्य, दायरा, पृष्ठभूमि, आवश्यक परिणाम और संचालन संबंधी सीमाएं जैसे तत्व शामिल हैं। [4]

इसलिए लिखें कि काम पूरा होने पर क्या संभव होना चाहिए।

उदाहरण:

• उपयोगकर्ता तय प्रक्रिया खुद पूरी कर सके,
• टीम हर मामले की वर्तमान स्थिति देख सके,
• ग्राहक को प्राथमिकताओं सहित विश्लेषण मिले,
• प्रणाली नई व्यवस्था में स्थानांतरित हो और सहमत मापदंडों के अनुसार काम करे,
• तैयार सामग्री तय माध्यम में प्रकाशित करने योग्य हो।

परिणाम इतना स्पष्ट हो कि दोनों पक्ष काम की दिशा समझें।

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

एक ही अंतिम जरूरत में शुरुआती स्थिति के आधार पर बहुत अलग मेहनत लग सकती है।

बताना उपयोगी है:

• पहले से क्या मौजूद है,
• क्या काम करता है और बचाना है,
• क्या काम नहीं करता,
• स्रोत फाइलें हैं या नहीं,
• दस्तावेज मौजूद हैं या नहीं,
• डेटा स्थानांतरित करना है या नहीं,
• मौजूदा प्रणाली पर काम करना है या नहीं,
• कौन सी सामग्री पहले से तैयार है।

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

अंतिम रूप समान दिखे तो भी ये अलग काम हैं।

दायरा विशेषज्ञ को यह अनुमान लगाने के लिए मजबूर न करे कि समस्या के किन हिस्सों की कीमत बतानी है।

उदाहरण:

दायरे में:

• मौजूदा समाधान का विश्लेषण,
• नए दृश्यों का डिजाइन,
• कार्यान्वयन,
• डेटा के तय हिस्से का स्थानांतरण।

दायरे से बाहर:

• नई सामग्री बनाना,
• लाइसेंस खरीदना,
• पहले महीने के बाद रखरखाव,
• भुगतान प्रणाली का पुनर्निर्माण।

विश्व बैंक के नमूना Terms of Reference में परामर्श सेवाओं की आवश्यकताओं और अपेक्षाओं को स्पष्ट लिखने तथा उन्हें विशिष्ट परियोजना के अनुसार ढालने पर जोर है। [5]

सीमाएं तब खास तौर पर महत्वपूर्ण हैं जब दो काम स्वाभाविक रूप से जुड़े हों और आसानी से मान लिया जाए कि एक में दूसरा भी शामिल है।

यदि आपको खास सामग्री या परिणाम चाहिए, तो उन्हें नाम से लिखें।

जैसे:

• काम करने वाला समाधान,
• स्रोत फाइलें,
• रिपोर्ट,
• दस्तावेज,
• दृश्य डिजाइन,
• सामग्री का समूह,
• वातावरण की संरचना,
• प्रशिक्षण,
• रिकॉर्डिंग,
• कोड और पहुंच का हस्तांतरण।

"डिजाइन", "विश्लेषण" या "कार्यान्वयन" जैसे शब्द अलग-अलग तरह समझे जा सकते हैं।

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

हर सीमा तकनीकी विवरण नहीं होती।

महत्वपूर्ण सीमाएं हो सकती हैं:

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

FAR उद्देश्य विवरण में संचालन संबंधी सीमाओं को स्पष्ट रूप से शामिल करता है, जबकि Digital, Data and Technology Playbook यह भी दिखाता है कि जहां वास्तविक सीमा न हो वहां समाधान पहले से नहीं थोपना चाहिए। [4] [3]

उपयोगी नियम:

जो विशेषज्ञ बदल नहीं सकता, उसे स्पष्ट करें; पर सिर्फ इसलिए सीमा न बनाएं कि आप एक पुराने समाधान के अभ्यस्त हैं।

विशेषज्ञ को पता होना चाहिए कि वह अपने प्रस्ताव में ग्राहक के किस स्तर के सहयोग पर भरोसा कर सकता है।

बताएं कि क्या आप देंगे:

• निर्णय लेने वाला व्यक्ति,
• प्रणाली तक पहुंच,
• मौजूदा सामग्री,
• डेटा,
• परीक्षण खाते,
• टीम से जानकारी,
• उपयोगकर्ताओं तक पहुंच,
• विषय-वस्तु,
• नियमित बैठकें,
• तय समय में उत्तर।

यदि आपको अभी पता नहीं कि क्या दे पाएंगे, तो यह बताना भी उपयोगी है।

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

हर तारीख का अर्थ समान नहीं होता।

अंतर करें:

• पसंदीदा आरंभ तारीख,
• अटल अंतिम तारीख,
• बाहरी आयोजन से जुड़ी तारीख,
• अनुमानित तारीख,
• वे चरण जो तय क्रम में होने चाहिए।

यदि अंतिम तारीख सच में नहीं बदल सकती तो कारण बताएं।

यदि उसमें लचीलापन है तो यह भी लिखें।

इससे विशेषज्ञ हर तारीख को कठोर शर्त मानने के बजाय अलग दायरा, क्रम या चरणबद्ध वितरण सुझा सकता है।

ऐसा कोई एक नियम नहीं कि ग्राहक को हमेशा पूरा बजट बताना ही चाहिए।

स्थिति के अनुसार आप दे सकते हैं:

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

तुलना के लिए सबसे जरूरी बात है कि विशेषज्ञ लागत को समान ढांचे में प्रस्तुत करें।

उदाहरण:

"विश्लेषण, डिजाइन, कार्यान्वयन और मासिक रखरखाव की कीमत अलग-अलग दिखाएं। बाहरी सेवाओं की वे लागतें भी बताएं जो शामिल नहीं हैं।"

यह प्रारूप चार अलग कुल राशियों से कहीं अधिक आसानी से तुलना योग्य है, यदि हर कुल राशि में अलग चीजें शामिल हों।

अनिश्चितता सिर्फ इसलिए खत्म नहीं होती कि उसे लिखा नहीं गया।

यदि आपको नहीं पता:

• कितना डेटा स्थानांतरित करना होगा,
• बाहरी संपर्क व्यवस्था जरूरी क्रिया की अनुमति देती है या नहीं,
• सारी सामग्री समय पर तैयार होगी या नहीं,
• वर्तमान कोड को उचित रूप से आगे बढ़ाया जा सकता है या नहीं,
• आवश्यक स्वीकृति समय पर मिलेगी या नहीं,

तो यह लिखें।

GAO की विश्वसनीय लागत अनुमान मार्गदर्शिका खुली मान्यताओं और जोखिम व अनिश्चितता विश्लेषण के महत्व पर जोर देती है। [6]

तब अच्छा विशेषज्ञ:

• अतिरिक्त गुंजाइश रख सकता है,
• प्रारंभिक जांच चरण सुझा सकता है,
• विकल्पों की अलग कीमत दे सकता है,
• कीमत बदलने वाली शर्त बता सकता है,
• ऐसी सटीकता दिखाने से मना कर सकता है जो इस चरण में ईमानदारी से संभव नहीं।

खुला अज्ञात, छिपी मान्यता से बेहतर है।

यदि आपको पहले से पता है कि निर्णय में क्या महत्वपूर्ण होगा, तो प्रस्ताव बनने से पहले बताएं।

आप देख सकते हैं:

• सुझाए गए तरीके की उपयुक्तता,
• समान समस्याओं का अनुभव,
• पहले किए काम के प्रमाण की गुणवत्ता,
• समय-सारणी की वास्तविकता,
• उपलब्धता,
• जोखिम प्रबंधन का तरीका,
• वास्तव में काम करने वाले लोगों की क्षमता,
• कीमत,
• रखरखाव लागत,
• संवाद की गुणवत्ता।

विश्व बैंक की वर्तमान Rated Criteria सामग्री बताती है कि गैर-मूल्य मानदंड में कार्यविधि और कार्य-योजना की गुणवत्ता, जोखिम प्रबंधन, प्रदर्शन और क्षमता तथा प्रमुख कर्मी शामिल हो सकते हैं। मानदंड खरीद की जरूरत के अनुसार ढाले और उनके महत्व के अनुसार भार दिए जाते हैं। [7]

इसका अर्थ नहीं कि छोटे काम के लिए औपचारिक अंक व्यवस्था जरूरी है।

अनुरोध भेजने से पहले इतना प्रश्न पर्याप्त है:

"कीमत के अलावा कौन सी बात एक प्रस्ताव को मेरे लिए दूसरे से बेहतर बनाएगी?"

यदि आप सच में प्रस्तावों की तुलना करना चाहते हैं, तो सभी से एक ही मूल प्रश्नों का उत्तर मांगें।

उदाहरण:

1. आप समस्या और अपेक्षित परिणाम को कैसे समझते हैं?
2. आप कौन सा तरीका सुझाते हैं?
3. आपके प्रस्ताव में ठीक-ठीक क्या शामिल है?
4. क्या शामिल नहीं है?
5. आप कौन सी मान्यताएं ले रहे हैं?
6. समय-सारणी क्या है?
7. ग्राहक से आपको क्या चाहिए?
8. प्रमुख जोखिम क्या हैं?
9. कीमत क्या है और उसमें ठीक-ठीक क्या शामिल है?
10. इस काम के लिए कौन सा समान अनुभव या कार्य-प्रमाण प्रासंगिक है?

सार्वजनिक खरीद में उत्तर, मानदंड और कीमत बताने के प्रारूप को समान करने का उद्देश्य यही है कि प्रस्तावों का साझा आधार पर मूल्यांकन हो सके। Government Commercial Function सही लागत और समान आधार पर तुलना के लिए पर्याप्त जानकारी देने पर जोर देता है। [2]

साझा प्रारूप विशेषज्ञों के अंतर मिटाए नहीं, बल्कि उन्हीं स्थानों पर उन अंतरों को दिखाई दे।

यह अनुरोध के उद्देश्य पर निर्भर करता है।

बजट बताना उपयोगी हो सकता है जब:

• दायरा उपलब्ध धन के अनुसार बदला जा सकता है,
• तय सीमा में सबसे अच्छा विकल्प चाहिए,
• वित्तीय वास्तविकता से बाहर प्रस्ताव जल्दी हटाने हैं।

पूरा बजट न बताना उचित हो सकता है जब:

• पहले उचित दायरे पर स्वतंत्र राय चाहिए,
• वास्तविक लागत अभी ज्ञात नहीं,
• अलग समाधान मॉडल तुलना में हैं,
• प्रक्रिया कीमत लेने का दूसरा तरीका मांगती है।

सबसे खराब स्थिति जरूरी नहीं कि बजट न बताना हो। असली समस्या है यह न बताना कि किस तरह की कीमत अपेक्षित है।

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

अच्छे काम-विवरण को हर प्रश्न का उत्तर देना जरूरी नहीं।

वह ईमानदारी से कह सकता है:

• "हम अभी नहीं जानते कि वर्तमान प्रणाली को सुरक्षित रूप से बढ़ाया जा सकता है या नहीं।",
• "हमें स्थानांतरित किए जाने वाले रिकॉर्ड की सही संख्या नहीं पता।",
• "हमने अभी तय नहीं किया कि दूसरी भाषा पहले चरण में होगी या नहीं।",
• "सही विकल्प चुनने में मदद चाहिए।"

यह उपयोगी जानकारी है।

अनिश्चितता प्रस्ताव बनाने के तरीके को प्रभावित करे, दस्तावेज से गायब न हो।

कुछ स्थितियों में पहली सबसे अच्छी सेवा पूरा कार्यान्वयन नहीं, बल्कि छोटा प्रारंभिक जांच चरण हो सकता है जो निर्णय, अधिक सटीक दायरे या बेहतर अनुमान पर खत्म हो।

1. हर विशेषज्ञ को अलग जानकारी देना।

2. समस्या और उद्देश्य बताए बिना विशेषताओं की सूची भेजना।

3. पहले से मौजूद चीजों की जानकारी न देना।

4. ऐसी सीमाएं छिपाना जो बाद में काम करने का तरीका बदलती हैं।

5. यह बताए बिना एक अंतिम कीमत मांगना कि उसमें क्या शामिल होना चाहिए।

6. प्रस्तावों का ऐसे मानदंड से मूल्यांकन करना जिन्हें आपने पहले खुद तय नहीं किया।

7. समस्या का विस्तृत वर्णन और समाधान का विस्तृत निर्देश एक ही चीज मान लेना।

1. क्या मैंने समस्या साफ लिखी है, केवल कल्पित समाधान नहीं?
2. क्या इच्छित परिणाम स्पष्ट है?
3. क्या विशेषज्ञ वर्तमान स्थिति समझता है?
4. क्या बचाना है यह स्पष्ट है?
5. क्या पहले दायरे की सीमाएं स्पष्ट हैं?
6. क्या मैंने प्रमुख मिलने वाली चीजें लिखी हैं?
7. क्या वास्तविक सीमाएं लिखी हैं?
8. मेरी ओर से क्या मिलेगा यह स्पष्ट है?
9. क्या समय-सारणी के साथ उसकी लचीलापन भी बताया है?
10. क्या कीमत का प्रारूप प्रस्तावों की तुलना करने देगा?
11. क्या प्रमुख अज्ञात बातें खुलकर बताई हैं?
12. क्या मुझे पता है कि कीमत के अलावा क्या देखूंगा?
13. क्या सभी विशेषज्ञ समान प्रश्नों का उत्तर देंगे?
14. क्या मैंने अपने कल्पित समाधान से बेहतर समाधान के लिए जगह छोड़ी है?

अच्छे काम-विवरण के दो ऐसे लक्ष्य हैं जो पहली नजर में विपरीत लगते हैं।

वह इतना स्पष्ट हो कि कई विशेषज्ञ एक ही समस्या की कीमत बताएं।

और साथ ही इतना खुला हो कि हर विशेषज्ञ अपना, शायद बेहतर तरीका सुझा सके।

उपयोगी क्रम:

समस्या -> परिणाम -> वर्तमान स्थिति -> दायरा -> मिलने वाली चीजें -> सीमाएं -> ग्राहक की जिम्मेदारियां -> समय-सारणी -> कीमत का प्रारूप -> अज्ञात और जोखिम -> चयन मानदंड -> साझा उत्तर प्रारूप।

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

हो सकता है सभी को एक ही पाठ भेजा गया हो, पर हर व्यक्ति ने वास्तव में अलग काम समझा हो।

[1] UK Government - The Sourcing Playbook
स्रोत खोलें

[2] Government Commercial Function - How to write a procurement specification
स्रोत खोलें

[3] UK Government - The Digital, Data and Technology Playbook
स्रोत खोलें

[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
स्रोत खोलें

[5] World Bank - Sample Consultants Terms of Reference
स्रोत खोलें

[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
स्रोत खोलें

[7] World Bank - Rated Criteria
स्रोत खोलें

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