آپ کا براؤزر جاوا اسکرپٹ کو سپورٹ نہیں کرتا ہے!

باب 24 - تجاویز کے لیے درخواستیں اور مسابقتی مذاکرات

ضمیمہ D: معیاری IT RFP کے مشمولات

سیکشن سیکشن مواد کی تفصیل

1

تعارف

مسئلہ کا بیان فراہم کرتا ہے اور فراہم کنندگان کے لیے RFP کو چلانے والے کاروباری مسائل اور تکنیکی مسائل کو سمجھنے کے لیے کافی تفصیلی ہونا چاہیے جن کی وجہ سے مسئلہ پیدا ہوا ہو گا۔

2

تجویز کی ہدایات اور انتظامیہ

تمام انتظامی تقاضوں اور معلومات پر مشتمل ہے جس کے ساتھ ایک سپلائر کو قابل قبول تجویز پیش کرنے کے لیے ان کی تعمیل کرنا ضروری ہے۔ اس سیکشن میں آر ایف پی جمع کروانے سے لے کر کنٹریکٹ دینے تک پروکیورمنٹ کے بنیادی اصول شامل ہیں اور اس میں درج ذیل قسم کی معلومات ہونی چاہئیں:

  • اگر اور کب ایک پیشگی تجویز کانفرنس منعقد کی جائے گی۔
  • پروکیورمنٹ سائیکل کے لیے متعلقہ تاریخیں۔
  • پروپوزل کی تیاری اور جمع کروانے کے تقاضے (یعنی کوڈ آف ورجینیا کے تقاضے، نیز پروٹوکول)
  • تجاویز کا جائزہ کیسے لیا جائے گا۔
  • RFP سنگل پوائنٹ آف رابطہ کا نام اور رابطہ کی معلومات
  • کب، کہاں اور کس کو تجاویز پیش کرنی ہیں۔
  • دوسری معلومات جو ایک سپلائر کے لیے مکمل طور پر جوابدہ ہونے کے لیے درکار ہیں۔

اگر ہدایات نامکمل یا غیر واضح ہیں، تو سپلائرز اہم ملاقاتوں یا سنگ میلوں کو نظر انداز کر سکتے ہیں۔ کچھ سپلائرز کوالٹی ہدایات کی کمی کو کمزور پروجیکٹ ٹیم یا متنازعہ پروجیکٹ کی علامت کے طور پر دیکھ سکتے ہیں جو بڑے صنعتی سپلائرز کو تجاویز پیش نہ کرنے پر اثر انداز ہو سکتے ہیں۔ RFP کے انتظامی تقاضوں کی تعمیل کرنے میں سپلائر کی ناکامی تجویز کو مسترد کرنے کا سبب بن سکتی ہے۔ اس سیکشن کو RFP کا جواب دینے اور سپلائی کرنے والوں کو ان پر عمل نہ کرنے کے جرمانے سے آگاہ کرنے کے لیے واضح اصول پیش کرنے چاہئیں۔

3

تجویز کی شکل

اس بارے میں تفصیلات فراہم کرتا ہے کہ تجاویز کو کس طرح فارمیٹ اور پابند کیا جائے اور مطلوبہ میڈیا (یعنی ہارڈ کاپی، سی ڈی وغیرہ)۔ یہ بتانے کے لیے ایک ٹیبل شامل کرنا مفید ہے کہ آیا مختلف تجاویز کے حصے الگ سے جمع کرائے جائیں؛ یعنی، لاگت سے تکنیکی، ترمیم شدہ، وغیرہ)۔ اس حصے کو سیکشن 2 میں تجویز کردہ ہدایات کے ساتھ نقل یا متصادم نہیں ہونا چاہیے۔

4

موجودہ صورتحال

ایجنسی کے تنظیمی پس منظر اور پروجیکٹ کے موجودہ کاروباری اور تکنیکی ماحول کو درست طریقے سے بیان کریں تاکہ سپلائرز نئی ضروریات کو پورا کرنے کے لیے اس ماحول کو ڈھالنے یا اس میں ترمیم کرنے کے لیے مؤثر اور درست طریقے سے حل تجویز کر سکیں۔ موجودہ کاروباری ماحول کی تفصیل میں تمام صارفین اور موجودہ کاروباری خدمات اور متاثر ہونے والے عمل کے فائدہ اٹھانے والے شامل ہونے چاہئیں۔ موجودہ تکنیکی ماحول کی تفصیل ایک واضح تعریف ہونی چاہیے جس میں تمام موجودہ ہارڈ ویئر اور سافٹ ویئر استعمال کیے جا رہے ہیں، پراجیکٹ کی ضروریات کو پورا کرنے کے لیے کیا استعمال کیا جا سکتا ہے یا استعمال کیا جانا چاہیے، ساتھ ہی دیگر موجودہ سسٹمز/پلیٹ فارمز اور/یا ایپلی کیشنز کے لیے موجودہ انٹرفیس۔ ورک فلو اور ایپلیکیشن انٹرفیس کو بصری استعمال کرتے ہوئے پیش کیا جا سکتا ہے۔

5

فنکشنل اور تکنیکی ضروریات

فنکشنل اور تکنیکی ضروریات اور کافی معلومات فراہم کرتا ہے تاکہ سپلائرز کو مسائل کو سمجھنے اور ایک مکمل اور پختہ تجویز تیار کرنے کے قابل بنایا جا سکے۔ اس جائزہ کو موجودہ کاروباری ایپلیکیشن اور تکنیکی ماحول (ہارڈ ویئر، سافٹ ویئر، کمیونیکیشنز) دونوں پر توجہ دینی چاہیے۔ یہ سفارش کی جاتی ہے کہ ایجنسیاں تکنیکی تقاضوں کو "لازمی" اور "شال" استعمال نہ کریں، لیکن سپلائرز کو یہ تجویز کرنے کی اجازت دیں کہ وہ حل پر مبنی تجویز کے حصے کے طور پر اس مسئلے کو کیسے حل کریں گے۔ تکنیکی اور فنکشنل ضروریات کے سیکشن میں ایسے سوالات شامل ہیں جن کا جواب فراہم کرنے والوں کو دینا چاہیے، جیسے:

  • اہم کامیابی کے عوامل
  • موجودہ نظام کے لیے فنکشنل وضاحتیں
  • متوقع نظام کے لیے فنکشنل وضاحتیں
  • کارکردگی کی وضاحتیں
  • سروس کی سطح کی توقعات
  • ہارڈ ویئر کے تقاضے (اگر ضروری ہو)
  • سافٹ ویئر کی ضروریات
  • سیکورٹی اور ڈیٹا کے تحفظ کی ضروریات
  • مواصلات کی ضروریات (اگر ضروری ہو)
  • جانچ کی ضروریات
  • آیا ان کا حل VITA سیکیورٹی، ڈیٹا اسٹینڈرڈز اور انٹرپرائز آرکیٹیکچر اور IT ایکسیسبیلٹی/508 تعمیل ITRMPSGs کی تعمیل کرتا ہے (یا اس کی تعمیل کر سکتا ہے)

پراجیکٹ مینجمنٹ کی ضروریات منصوبے کے انتظام اور نفاذ کے لیے شرائط بیان کرتی ہیں۔ اس حصے کو فراہم کنندگان کو وہ معلومات فراہم کرنی چاہئیں جن کی انہیں پروجیکٹ پلان، رسک کم کرنے کا منصوبہ یا دیگر انتظامی منصوبہ تیار کرنے کے لیے درکار ہے، جیسا کہ پراجیکٹ کی پیچیدگی اور مشن کی اہمیت کے لیے درکار ہے اور جو کہ ضروریات کی تعریف، نفاذ، تنصیب، جانچ، تربیت، دیکھ بھال، اور پروجیکٹ کے دیگر مراحل پر محیط ہے۔ مجوزہ پروجیکٹ پلان اس بات کی یقین دہانی فراہم کرتا ہے کہ سپلائر کے پاس معاہدے کو کامیابی سے انجام دینے کے لیے درکار وسائل موجود ہیں۔ پراجیکٹ مینجمنٹ پلان میں عام طور پر درج ذیل شامل ہوتے ہیں:

  • عملے کی ضروریات
  • سائٹ کی تیاری کی ذمہ داریاں
  • ترسیل اور تنصیب کا شیڈول اور منصوبہ
  • سسٹم قبولیت ٹیسٹ کی ضروریات
  • نظام کی بحالی کی ضروریات
  • نظام کی تربیت کی ضروریات
  • دستاویزات کی ضروریات

ایجنسیوں کو یاد رکھنا چاہیے کہ یہ ممکن ہے کہ کوئی سپلائر تکنیکی تقاضوں کو پورا کر سکے، لیکن انتظامی تقاضوں کو پورا نہیں کر سکتا جیسا کہ اس سیکشن کے بارے میں ان کے ناقص یا ناکافی ردعمل سے ظاہر ہوتا ہے۔ انتظامی سیکشن بالغ یا ناپختہ انتظامی صلاحیتوں والے سپلائرز کے درمیان فرق کرنے میں مدد کرے گا۔

آپ سپلائرز سے RFP اور مطلوبہ پروجیکٹ کے مقاصد سے وابستہ تمام مفروضوں اور ممکنہ خطرات کی نشاندہی کرنے کے لیے کہہ سکتے ہیں۔ اور/یا ان سے ملتے جلتے پروجیکٹ کی تفصیل سے وضاحت کرنے کو کہیں اور کس طرح انہوں نے اپنے صارفین کے اطمینان کے مطابق اپنی کارکردگی کے دوران پیش آنے والے مسائل یا مسائل کو حل کیا۔

6

واضح اور واضح کارکردگی کے اقدامات اور نفاذ کی دفعات

IT درخواستیں اور معاہدے جو "زیادہ خطرہ" کی تعریف پر پورا اترتے ہیں جیسا کہ کوڈ آف ورجینیا کے § 2.2-4303.01 میں بیان کیا گیا ہے، ان میں واضح اور واضح کارکردگی کے اقدامات اور نفاذ کی دفعات شامل ہونی چاہئیں، بشمول سپلائر کی عدم کارکردگی کی صورت میں علاج۔

واضح اور واضح کارکردگی کے اقدامات اور نفاذ کی دفعات کے بارے میں مزید جاننے کے لیے نیچے دیے گئے ٹولز کا استعمال کریں، بشمول علاج:

         اہم IT پروکیورمنٹس، ہائی رسک IT پروکیورمنٹس، اور کے لیے کم از کم تقاضے میٹرکس

         1 تفویض شدہ پروکیورمنٹس 

         2 کارکردگی میٹرکس ٹول

 

7

سپلائر پروفائل

سپلائرز سے کہا جاتا ہے کہ وہ اپنے کاروبار اور پیشہ ورانہ قابلیت کی وضاحت کریں اور حوالہ جات فراہم کریں۔ ان سے کہا جائے کہ وہ اپنی کارپوریٹ اور مالی حیثیت اور ان صارفین کے بارے میں تفصیل پیش کریں جو ان کی پیشہ ورانہ کارکردگی اور دیانتداری کے حوالے سے کام کریں گے۔ مندرجہ ذیل مثالیں اس سیکشن میں عام طور پر درکار ہیں:

  • سپلائر کی کارپوریٹ تاریخ، تنظیمی ڈھانچہ، مقامات اور کاروباری سائز کی حیثیت (یعنی، DSBSD-سرٹیفیکیشن کی حیثیت، اگر قابل اطلاق ہو)۔
  • فراہم کنندہ کا عمومی پس منظر کا تجربہ اور حل یا مصنوعات کی قسم فراہم کرنے کی صلاحیت
  • سپلائر اور کسی بھی مجوزہ پارٹنر/ ذیلی ٹھیکیدار/ مینوفیکچرر کے درمیان تعلقات کی تفصیل، اگر کوئی ہے، اور یہ تعلق کتنے عرصے سے ہے۔
  • اس بات کا ثبوت کہ فراہم کنندہ کے پاس ضروری تکنیکی، آپریشنل اور انتظامی مہارتیں، عملہ اور مالی وسائل اور عمل کو انجام دینے کی اہلیت ہے۔
  • اسی/مماثل فی الحال انسٹال کردہ مصنوعات، سسٹمز یا کی فہرست
  • اسی طرح کے پروجیکٹس، کنفیگریشنز اور/یا ایپلی کیشنز والے صارفین کے نام جو حوالہ جات فراہم کر سکتے ہیں، بشمول رابطے کے نام اور ٹیلی فون نمبر۔
  • فراہم کنندہ کی قابلیت، بشمول ریزیوم، کمپنی پروفائل اور کاروبار
  • فراہم کنندہ کا خدمات فراہم کرنے کا معمول کا طریقہ بشمول ورک پلان کی تفصیل، استعمال کیے جانے والے طریقے اور پروجیکٹ کے لیے ڈیلیوری ایبلز/ٹائم لائن کا نمونہ شیڈول

8

SWaM سیکشن

سپلائرز سے کہا جاتا ہے کہ وہ ایک "سپلائر پروکیورمنٹ اور سب کنٹریکٹنگ پلان" فراہم کریں جس میں مجموعی وابستگی کا فیصد بتایا گیا ہے جو سپلائر معاہدے کی ضروریات کو پورا کرنے میں براہ راست ذیلی ٹھیکیداروں کے ساتھ خرچ کرنے کی توقع کرتا ہے۔ مزید برآں، سپلائرز سے کہا جاتا ہے کہ وہ ان تمام ذیلی ٹھیکیداروں کی فہرست فراہم کریں جن کے استعمال سے وہ سپلائر کی معاہدے کی کارکردگی میں متوقع ہے۔ ذیلی ٹھیکیداروں کی فہرست میں ان ذیلی ٹھیکیداروں کو نامزد کرنا چاہیے جو SWaM کاروبار ہیں، ساتھ ہی وہ جو غیر SWaM کاروبار ہیں۔ اس صورت میں کہ ایک سپلائر DOE کسی معاہدے کی کارکردگی میں ذیلی ٹھیکیداروں کے استعمال کی توقع نہیں رکھتا ہے، سپلائر سے کہا جاتا ہے کہ وہ اپنے جواب میں اس حقیقت کو بیان کرے۔

9

قیمتوں کی معلومات

یہ بتاتا ہے کہ سپلائرز قیمتوں کی معلومات کیسے فراہم کرتے ہیں اور ان کے لیے قیمت کی تجاویز تیار کرنے میں ان کے لیے ایک تفصیلی فارمیٹ فراہم کرتا ہے۔ اس بات کو یقینی بنانے کے لیے ہدایات کافی واضح ہونی چاہئیں کہ قیمت کی تجاویز کا برابری کی بنیاد پر موازنہ کیا جا سکے۔ اس موازنہ کو آسان بنانے کے لیے، ایک نمونہ اسپریڈشیٹ فراہم کرنے پر غور کریں جو مجوزہ نظام کو مندرجہ ذیل اجزاء میں توڑ دے:

  • سسٹم سافٹ ویئر
  • ایپلی کیشن ڈویلپمنٹ سافٹ ویئر
  • تنصیب
  • دیکھ بھال
  • تربیت
  • دستاویزات
  • پروجیکٹ مینجمنٹ
  • منفرد ہارڈ ویئر یا سافٹ ویئر کا انضمام
  • لائسنس فیس (جاری ہے)

قیمتوں کا تعین کرنے کا شیڈول/منظر نامہ اس کی مثال کے طور پر شامل کریں کہ تجویز کی قیمتوں کو کس طرح جمع کیا جانا چاہیے۔ اگر یکمشت قیمتوں کا تعین فائدہ مند نہیں ہے تو، نامعلوم مقدار یا گھنٹوں کے لیے قیمتیں حاصل کرنے کے لیے قیمتوں کا تعین کرنے کا منظر نامہ استعمال کریں۔ اعادی بمقابلہ غیر اعادی اخراجات کے وقفے کے لئے پوچھیں۔ قیمتوں کے تعین کا شیڈول ڈیلیوری ایبلز سے منسلک ہونا چاہیے اور درخواست میں بیان کردہ ادائیگی کے طریقہ سے موافق ہونا چاہیے۔

قیمتوں کا تعین کرنے کے نظام الاوقات کو دیکھتے وقت، قیمتوں کے تعین پر توجہ دیں جس میں ایک بار کے اخراجات بمقابلہ بار بار آنے والے اخراجات شامل ہوں۔ سافٹ ویئر پیکج کی ابتدائی قیمت ایک بار کی قیمت ہے؛ سالانہ دیکھ بھال اور سافٹ ویئر لائسنسنگ فیس بار بار چلنے والے اخراجات ہیں جن کی شناخت کسی پروجیکٹ کی کل لائف سائیکل لاگت کو تیار کرنے کے لیے ضروری ہے۔ قیمتوں کا تعین عام طور پر ایوارڈ کے لیے واحد فیصلہ کن نہیں ہوتا ہے، لیکن اس کا استعمال یکساں طور پر اچھی تکنیکی اور انتظامی تجاویز کے ساتھ دو سپلائرز کے درمیان تعلق کو توڑنے کے لیے کیا جانا چاہیے۔

پیچیدہ پراجیکٹس کے لیے آپ سپلائرز سے ایک سنگ میل کی قیمت کا شیڈول جمع کرانے کے لیے بھی کہہ سکتے ہیں جس پر حتمی رسید کی حتمی منظوری کے بعد ادائیگی کے لیے ہولڈ بیک فیصد لاگو کیا جا سکتا ہے۔ یہ فراہم کنندگان کی حوصلہ افزائی کرتا ہے اور اگر حتمی قبولیت میں تاخیر یا پریشانی کا سامنا کرنا پڑتا ہے تو ایجنسی کے تحفظ میں اضافہ کرتا ہے۔ یہ کسی بھی سنگ میل پر معاہدے کی آسانی کی اجازت دیتا ہے اگر سپلائر غیر کارکردگی کا مظاہرہ کر رہا ہے۔

10

ایجنسی کا معیاری معاہدہ (یعنی معاہدہ ٹیمپلیٹ)

غیر افشاء کرنے والے معاہدوں، رازداری، ڈیٹا کے تحفظ اور حفاظتی تقاضوں، وارنٹیوں، لائسنسنگ معاہدے کے تقاضوں اور دیگر قانونی، قانونی اور IT سے متعلق مخصوص شرائط و ضوابط، یا کسی بھی وفاقی بہاؤ کی شرائط کے ساتھ ایک مجوزہ معاہدہ ٹیمپلیٹ پر مشتمل ہے جس کی ضرورت ہو سکتی ہے۔ فراہم کنندگان سے کہا جانا چاہیے کہ وہ مجوزہ معاہدے کے سانچے کو ریڈ لائن کریں تاکہ وہ تمام مستثنیات کو نمایاں کریں جن سے وہ اتفاق نہیں کر سکتے۔ فراہم کنندگان کو اس وقت ذمہ داری کی شق کو دوبارہ نہیں لکھنا چاہیے۔

وہ بعد میں مذاکرات کے دوران پہلی بار مسائل یا تبصرے اٹھا سکتے ہیں۔ تجویز کی جانچ کی مدت کے دوران شو اسٹاپپر کے مسائل کی نشاندہی کریں کیونکہ ایسا سپلائر منتخب کرنا ممکن ہے جو ایجنسی کا معاہدہ قبول نہیں کرے گا۔

11

سپلائر کا سیکشن (اختیاری)

فراہم کنندگان کو وہ معلومات شامل کرنے کی اجازت دیتا ہے جو وہ محسوس کرتے ہیں کہ وہ متعلقہ ہے حالانکہ RFP میں اس کی ضرورت یا درخواست نہیں کی گئی ہے۔ وہ ممکنہ مسائل پر بھی بات کر سکتے ہیں جو RFP اور ان کی تجویز سے متعلق ہیں۔ مثال کے طور پر، ایک سپلائر کے پاس یہ ظاہر کرنے کے لیے اضافی مصنوعات کی خصوصیات ہو سکتی ہیں جو RFP کے دائرہ کار سے باہر ہیں، ایک منفرد حل پیش کر سکتا ہے جس کی خریدار نے توقع نہیں کی تھی، یا RFP میں ظاہر ہونے والے کسی مسئلے کا حل فراہم کر سکتا ہے جس پر دوسرے سپلائرز نے غور نہیں کیا۔ یہاں تک کہ اگر یہ خاص سپلائر DOE نہیں جیتتا ہے، تب بھی مسئلہ کی وضاحت اور ممکنہ حل قابل غور ہوگا۔

12

ضمیمہ

بھاری لیکن متعلقہ معلومات پر مشتمل ہے جیسے نیٹ ورک ڈایاگرام، تکنیکی ضروریات کے مطالعہ، پروجیکٹ پلان کی خاکہ اور دیگر تفصیلی معلومات۔ مثالوں میں درج ذیل شامل ہیں:

  • شماریاتی کے ساتھ اسپریڈ شیٹس
  • مواصلاتی نیٹ ورک ڈرائنگ اور
  • موجودہ کی فہرست
  • کے اندر استعمال ہونے والے معیارات
  • کے ساتھ عارضی منصوبے کا منصوبہ
  • معاہدہ ٹیمپلیٹ
  • چھوٹے کاروباری ذیلی کنٹریکٹنگ پلان فارم
  • میں کاروبار کے لین دین کے لیے رجسٹرڈ کے طور پر سپلائر کا مکمل شدہ اسٹیٹ کارپوریشن کمیشن فارم

اس کے بعد معلومات فراہم کنندہ کے لیے دستیاب ہوتی ہے لیکن DOE RFP کے بیانیہ والے حصے سے توجہ نہیں ہٹاتا ہے۔ نوٹ: فراہم کنندگان کو بتائیں کہ آیا انہیں اپنی تجاویز تیار کرتے وقت اس معلومات کا استعمال کرنا چاہیے۔


ہدایت نامے کو کلیدی الفاظ یا عام اصطلاحات کے ذریعے تلاش کریں۔