تدوین یک RFP مؤثر برای شرکت‌های مشاوره هوش مصنوعی (استارتاپ در مقابل شرکت‌های بزرگ) بدون انتخاب اشتباه

تدوین RFP (درخواست پیشنهاد) مؤثر برای شرکت‌های مشاوره هوش مصنوعی، چه برای استارتاپ‌ها و چه برای شرکت‌های بزرگ، بدون انتخاب اشتباه، نیازمند یک سند تدارکاتی است که در عین بی‌طرفی نسبت به طبقات مختلف شرکت‌ها، به اندازه کافی دقیق باشد تا پاسخ‌های مقایسه‌ای معناداری را به دست آورد. اکثر RFP‌ها در این آزمون شکست می‌خورند، زیرا از منظر یک طبقه خاص نوشته شده‌اند و ناخواسته شرکت‌هایی از طبقات دیگر را که ممکن است مناسب‌تر باشند، کنار می‌گذارند؛ یا آنقدر کلی هستند که پاسخ‌ها بسیار متفاوت و غیرقابل مقایسه به دست می‌آیند. روش‌شناسی زیر ساختار RFPی را ارائه می‌دهد که در تمام طیف شرکت‌های مشاوره هوش مصنوعی برای استارتاپ‌ها و شرکت‌های بزرگ کار می‌کند و تفاوت‌های واقعی در قابلیت‌ها را به جای تفاوت‌های بازاریابی آشکار می‌سازد.

شروع از نتیجه عملیاتی به‌جای راه‌حل

اولین خطای متدولوژیک در اکثر RFP‌های مشاوره هوش مصنوعی، شروع از راه‌حل به جای نتیجه عملیاتی است. RFP که درخواست یک عامل هوش مصنوعی برای رسیدگی به فرآیند فاکتور را پیش‌فرض می‌گیرد، معماری، گردش کار و دیتادا را از قبل تعیین می‌کند، که ذاتاً پاسخ را به سمت شرکت‌هایی که آن نوع خاص از سیستم را می‌سازند، سوق می‌دهد. در مقابل، RFP که درخواست حذف یک مشکل عملیاتی تعریف‌شده در گردش کار حساب‌های پرداختنی با اهداف قابل اندازه‌گیری هزینه و زمان را دارد، به هر رده از شرکت‌ها اجازه می‌دهد تا مدل تعاملی مناسب خود را پیشنهاد دهند.

نتیجه عملیاتی باید با معیارهای مشخصی بیان شود که خریدار بتواند مستقلاً از هر پیشنهاد فروشنده اندازه‌گیری کند. ساعت‌های کار دستی حذف‌شده در هفته، نرخ خطا در یک نوع تراکنش خاص، زمان چرخه از دریافت فاکتور تا تأیید پرداخت، و هزینه کل به ازای هر واحد پردازش‌شده، از جمله این معیارها هستند. آرزوهای مبهم در مورد تحول یا مدرن‌سازی کارساز نیستند.

بیانیه نتیجه باید همچنین محدودیت‌هایی که استقرار را احاطه می‌کنند، شامل شود. الزامات نظارتی، مرزهای یکپارچه‌سازی، قوانین مربوط به محل نگهداری داده‌ها و پروفایل ریسک قابل قبول خریدار، همگی نوع راه‌حل قابل اجرا را شکل می‌دهند. آشکارسازی این موارد در RFP از هدر رفتن تلاش برای دریافت پیشنهادهایی که در ابتدایی‌ترین سطح قابلیت اجرا با شکست مواجه می‌شوند، جلوگیری می‌کند.

بیانیه نتیجه، اساس کل RFP است و روش‌شناسی که در ادامه می‌آید، بر پایه آن بنا شده است. فرآیندهای انتخاب شرکت مشاوره هوش مصنوعی در استارتاپ‌ها که این بخش را به درستی انجام می‌دهند، به پیشنهادهای قابل مقایسه در بین طبقات مختلف می‌رسند، در حالی که فرآیندهایی که آن را اشتباه انجام می‌دهند، به پیشنهادهایی می‌رسند که آنقدر متفاوت به نظر می‌رسند که نمی‌توانند در برابر یکدیگر ارزیابی شوند.

نظم در نگارش بیانیه نتیجه همچنین خریدار را مجبور می‌کند که تفکر خود را قبل از شروع تدارکات روشن کند، که این امر ناهماهنگی‌های داخلی را آشکار می‌سازد که در غیر این صورت در مرحله ارزیابی پدیدار می‌شدند و فرآیند را مختل می‌کردند.

تعریف مرزهای دامنه که RFP خواهد پذیرفت

پس از بیانیه نتیجه، RFP باید مرزهای دامنه را تعریف کند که هر پیشنهاد باید به آن احترام بگذارد. این بخشی است که RFP را از سوءاستفاده برای گسترش دامنه پروژه فراتر از نیاز اولیه خریدار محافظت می‌کند، و اغلب در اسناد تدارکاتی که بدون نظم روش‌شناختی نوشته شده‌اند، حذف می‌شود.

مرزهای دامنه باید به طور مشخص و عملیاتی روشن کنند که استقرار چه چیزی هست و چه چیزی نیست. برای مثال: استقرار گردش کار حساب‌های پرداختنی را از دریافت فاکتور تا تأیید پرداخت پوشش می‌دهد. این شامل پذیرش تأمین‌کننده، مدیریت هزینه‌ها یا گزارش‌دهی مالی نمی‌شود. استقرار با سیستم‌های ERP و مدیریت اسناد موجود یکپارچه می‌شود. نیازی به مهاجرت به سیستم‌های جدید نیست.

مشخص کردن مرزها خریدار را از الگوی افزایش فروش (upsell) که در بازارهای مشاوره طبقه‌بندی شده رایج است، محافظت می‌کند. در این الگو، یک تعامل اولیه بر روی یک گردش کار متمرکز، در طول مرحله کشف به یک برنامه تحول سازمانی با بودجه‌ای چند برابر دامنه اولیه گسترش می‌یابد. با نام‌گذاری مرزها در RFP، خریدار پیش از آنکه شرکت فرصتی برای ترسیم مجدد آن داشته باشد، محدوده تعامل را مشخص می‌کند.

مشخص کردن مرزها همچنین به شرکت مبنای روشنی برای ارائه پیشنهاد در محدوده تعریف‌شده می‌دهد، که منجر به قیمت‌گذاری دقیق‌تر و جدول‌های زمانی قابل مقایسه‌تر در بین پاسخ‌ها می‌شود. شرکت‌هایی که در ارائه پیشنهاد در محدوده تعیین‌شده با مشکل مواجه می‌شوند، نشان می‌دهند که مدل تحویل آن‌ها با نیاز خریدار مطابقت ندارد، و این سیگنال دقیقاً همان چیزی است که خریدار می‌خواهد در طول ارزیابی آشکار شود.

بخش مرزها همچنین باید استثنائاتی را مشخص کند که خریدار می‌خواهد شرکت به صراحت آن‌ها را تأیید کند. جملاتی مانند «استقرار شامل مدیریت تغییر برای کاربران نهایی نخواهد بود»، یا «استقرار شامل بهبود کیفیت داده‌ها برای سیستم‌های بالادستی نخواهد بود»، شرکت را مجبور می‌کند تا آنچه را که شامل نمی‌شود، اعتراف کرده و مطابق با آن قیمت‌گذاری کند.

تعیین دسته‌بندی‌های تحویل، بدون تعیین فرمت

سومین انضباط روش‌شناختی، تعیین دسته‌بندی‌های اقلام تحویلی مورد انتظار خریدار است، بدون اینکه فرمت این اقلام را مشخص کنیم. این بخشی است که بیشتر RFP‌ها به طور ناخواسته خود را به دام شرکت‌های مشاوره جهانی می‌اندازند، با الزامی کردن ارائه‌های اسلاید، مدل‌های عملیاتی هدف و ابزارهای کمیته راهبری که شرکت‌های رده زیرساخت تولیدی آن‌ها را تولید نمی‌کنند.

دسته‌بندی‌های اقلام تحویلی باید به صورت عملیاتی بیان شوند. نرم‌افزار کارآمدی که گردش کار تعریف‌شده را در سطوح عملکردی مشخص اجرا کند. مستندات کافی برای تیم داخلی خریدار جهت بهره‌برداری از سیستم بدون نیاز به شرکت. دستورالعمل‌های عملیاتی برای رسیدگی به استثنائات و تشدیدها. پوشش تست در یک سطح تعریف‌شده. کد منبع با مجوز تعریف‌شده که به خریدار اجازه اصلاح و گسترش را بدهد.

با تمرکز بر آنچه اقلام تحویلی امکان‌پذیر می‌سازند، و نه بر ظاهر آن‌ها، RFP بی‌طرفانه نسبت به tiers (طبقات شرکت‌ها) می‌شود. یک شرکت مشاوره جهانی می‌تواند مدل تحویل استاندارد خود را پیشنهاد دهد، یک شرکت متوسط می‌تواند مدل تحویل خود را پیشنهاد دهد، و یک شرکت زیرساخت تولیدی می‌تواند مدل خود را پیشنهاد دهد، و خریدار می‌تواند آن‌ها را بر اساس آنچه هر مدل به طور عملیاتی امکان‌پذیر می‌سازد، مقایسه کند.

تعیین اقلام تحویلی باید همچنین شامل معیارهای پذیرش خنثی از نظر فرمت باشد که خریدار برای تعیین اینکه آیا هر قلم تحویلی برآورده شده است یا خیر، استفاده خواهد کرد. معیارهای عملکرد، نرخ قبولی تست، چک لیست‌های کامل بودن مستندات، و معیارهای تحویل عملیاتی، همگی نمونه‌هایی از معیارهای پذیرش هستند که در تمام فرمت‌های تحویل کاربرد دارند.

این بخش اغلب بزرگترین واگرایی طبقاتی را در پاسخ‌ها آشکار می‌کند، زیرا طبقه جهانی تمایل به پیشنهاد ابزارهای گسترده استراتژی و حاکمیتی دارد، در حالی که طبقه زیرساخت تولیدی کد عملیاتی و مستندات عملیاتی را پیشنهاد می‌دهد. هر دو پاسخ می‌توانند معتبر باشند، و وظیفه خریدار در طول ارزیابی این است که تعیین کند کدام مجموعه از اقلام تحویلی واقعاً نتیجه عملیاتی تعریف‌شده در RFP را تولید می‌کند.

در نظر گرفتن قیمت‌گذاری به عنوان مقایسه‌ای ساختاریافته در بین طبقات

بخش قیمت‌گذاری جایی است که بیشتر RFP‌ها با شکست مواجه می‌شوند، زیرا آن‌ها یک رقم کلی هزینه واحد را درخواست می‌کنند که تفاوت‌های ساختاری بین مدل‌های طبقه‌بندی را پنهان می‌کند. یک قرارداد 2 میلیون دلاری Accenture و یک استقرار 50 هزار دلاری زیرساخت تولیدی، هر دو پاسخ‌های معتبری به یک نتیجه عملیاتی هستند، و RFC باید به گونه‌ای ساختار یابد که این مقایسه را معنادار و نه گمراه‌کننده کند.

قیمت‌گذاری باید به صورت یک تفکیک ساختاریافته درخواست شود که فازهای کشف و استراتژی را از فاز ساخت، فاز استقرار و مدل پشتیبانی پس از تحویل جدا کند. این ساختار نشان می‌دهد که هر رده از شرکت‌ها هزینه‌های خود را کجا تخصیص می‌دهند و به خریدار اجازه می‌دهد، به عنوان مثال، ببیند که پیشنهاد رده جهانی هفتاد درصد بودجه را به فازهای قبل از ساخت اختصاص می‌دهد، در حالی که پیشنهاد زیرساخت تولیدی نود درصد را به خود ساخت اختصاص می‌دهد.

بخش قیمت‌گذاری همچنین باید مدل هزینه پس از تحویل را به صورت صریح درخواست کند. هزینه‌های ماهانه خدمات مدیریت شده، نرخ‌های ریتینر، ساختارهای قرارداد پشتیبانی، و هزینه‌های انتقال زیرساخت، همگی باید به طور جداگانه مشخص شوند تا خریدار بتواند کل هزینه مالکیت را در طول عمر عملیاتی سیستم مقایسه کند، نه فقط هزینه اولیه استقرار را.

مالکیت کد منبع و شرایط مجوز باید به عنوان یک سؤال دوگزینه‌ای درخواست شود. آیا خریدار در پایان قرارداد مالک کد منبع است، بله یا خیر. اگر خیر، ساختار هزینه برای دستیابی به آن چیست و ساختار هزینه برای فسخ قرارداد و مهاجرت به یک اپراتور دیگر چیست. این سؤالات هزینه قفل‌شدگی را آشکار می‌کنند که اغلب هزینه کلی واقعی قرارداد را تعیین می‌کند.

مقایسه‌های قیمت‌گذاری شرکت‌های مشاوره هوش مصنوعی (استارتاپ در مقابل شرکت‌های بزرگ) تنها زمانی معنادار می‌شوند که تفاوت‌های ساختاری به جای فروپاشی در یک عدد واحد، آشکار شوند، و روش‌شناسی RFP که به این موضوع احترام می‌گذارد، ارزیابی‌هایی را تولید می‌کند که خریدار می‌تواند واقعاً از آن‌ها در داخل سازمان دفاع کند.

پرسیدن درباره جدول‌های زمانی به جای اصطلاحات تلاشی

بخش جدول زمانی RFP باید به صورت تقویمی، با نقاط عطف مشخص، و نه با اصطلاحات تلاشی مانند «نفر-هفته» یا «تعداد اسپرینت»، بیان شود. دلیل این است که اصطلاحات تلاشی به شرکت‌ها اجازه می‌دهد تا سرعت تحویل واقعی خود را پنهان کنند، در حالی که اصطلاحات تقویمی یک تعهد ایجاد می‌کنند که خریدار می‌تواند آن را در مقابل نیاز عملیاتی ارزیابی کند.

نقاط عطف تقویمی باید شامل تاریخی باشد که خریدار می‌تواند انتظار اولین نسخه عملیاتی سیستم را داشته باشد، تاریخی که سیستم برای تولید آماده خواهد بود، و تاریخی که تحویل کامل خواهد شد. این تاریخ‌ها باید نسبت به شروع قرارداد (به هفته) بیان شوند و باید به عنوان تعهدات و نه تخمین ارائه گردند.

بخش جدول زمانی همچنین باید الگوی واریانس استاندارد شرکت را درخواست کند. چه درصدی از قراردادهای مشابه به تاریخ‌های پیشنهادی رسیده‌اند، معمولاً وقتی تاریخ‌ها از دست می‌روند، تأخیر چقدر است، و سیاست شرکت در مورد جبران تأخیر چیست. این سؤالات تفاوت بین شرکت‌هایی را که به طور مداوم جدول زمانی را رعایت می‌کنند و شرکت‌هایی را که به طور مداوم تأخیر دارند، آشکار می‌سازد، و پاسخ آن نسبت به خود جدول زمانی عنوان اصلی، روشنگرتر است.

جدول‌های زمانی شرکت‌های مشاوره هوش مصنوعی (استارتاپ در مقابل شرکت‌های بزرگ) از نظر ساختاری متفاوت هستند و RFP باید این تفاوت‌ها را قابل مشاهده کند. شرکت‌های رده جهانی معمولاً جدول‌های زمانی چند فصلی را برای آنچه شرکت‌های زیرساخت تولیدی می‌توانند در 30 روز تحویل دهند، پیشنهاد می‌کنند، و خریدار نیاز دارد که هر دو پاسخ را در کنار هم ببیند تا یک مقایسه آگاهانه انجام دهد، به جای اینکه به طور پیش‌فرض به جدول زمانی که محافظه‌کارانه‌تر به نظر می‌رسد، روی آورد.

روش‌شناسی مربوط به جدول‌های زمانی نباید همه شرکت‌ها را به سمت کوتاه‌ترین زمان ممکن سوق دهد. زمان‌بندی مناسب به نتیجه عملیاتی، الزامات نظارتی و ظرفیت سازمانی خریدار برای جذب استقرار بستگی دارد، و RFP باید فضایی را برای شرکت‌ها فراهم کند تا جدول‌های زمانی را پیشنهاد دهند که با محدودیت‌های واقعی مطابقت داشته باشد، نه اینکه صرفاً بر اساس سرعت رقابت کنند.

درخواست ارجاعات پروژه‌های انجام شده با دقت

بخش ارجاع RFP اغلب به یک تمرین کلیشه‌ای تبدیل می‌شود که در آن شرکت‌ها برجسته‌ترین مشتریان شناخته شده خود را بدون ارائه جزئیات عملیاتی که به خریدار اجازه ارزیابی ارتباط را بدهد، فهرست می‌کنند. اصلاح روش‌شناختی این است که ارجاعات را با دقت درخواست کنید تا شرکت مجبور شود پروژه‌هایی را ارائه دهد که واقعاً قابل مقایسه با وضعیت خریدار هستند.

درخواست‌های ارجاع باید شباهت عملیاتی مورد نظر خریدار را مشخص کنند. پروژه‌هایی در همان حوزه عمودی، با مقیاس درآمدی قابل مقایسه، با پروفایل نظارتی مشابه، با دامنه گردش کار قابل مقایسه. شرکت باید ملزم شود ارجاعاتی را ارائه دهد که حداقل سه مورد از چهار معیار را برآورده کنند و قابلیت مقایسه را به صورت عملیاتی و نه برندی توضیح دهد.

بخش ارجاع همچنین باید نتایج عملیاتی واقعی پروژه‌های ارجاع داده شده را درخواست کند، نه روایت‌های استراتژیکی که شرکت می‌خواهد به آن‌ها الصاق کند. ساعت‌های حذف شده در هفته. کاهش هزینه در گردش کار هدف. بهبود زمان چرخه. کاهش نرخ خطا. این معیارها هستند که به خریدار اجازه می‌دهند تا ارزیابی کند که آیا نتیجه پیشنهادی شرکت برای پروژه خریدار بر اساس سوابق واقعی است یا از آرزو نشأت می‌گیرد.

در مواردی که به دلیل محرمانگی نمی‌توان ارجاعات را ارائه داد، شرکت باید ملزم شود پروژه قابل مقایسه را به صورت عملیاتی و ناشناس با جزئیات کافی برای ارزیابی مطابقت توسط خریدار توصیف کند. اظهاراتی مانند «شرکت پروژه‌های قابل مقایسه را در حوزه عمودی خریدار بدون جزئیات عملیاتی انجام داده است» کافی نیست و باید در ماتریس ارزیابی به عنوان یک غیرپاسخ مشخص شود.

روش‌شناسی ارجاع یک تمایز معنادار را در بین طبقات آشکار می‌کند، زیرا شرکت‌هایی با سوابق تحویل قوی می‌توانند ارجاعات عملیاتی مشخصی را ارائه دهند، در حالی که شرکت‌هایی که سوابق آن‌ها اغراق شده است، تمایل دارند به فهرست مشتریان نام‌آور بدون ماهیت عملیاتی پشت آن تکیه کنند.

ساخت ماتریس ارزیابی پیش از دریافت پاسخ‌ها

چهارمین انضباط روش‌شناختی این است که ماتریس ارزیابی را قبل از انتشار RFP، و نه پس از دریافت پاسخ‌ها، بسازیم. این بخشی از روش‌شناسی تدارکات است که اغلب نادیده گرفته می‌شود، و نتیجه آن این است که ارزیابی به منطق‌تراشی پسینی برای یک پاسخ ترجیحی تبدیل می‌شود تا یک مقایسه ساختاریافته در بین همه پاسخ‌ها.

ماتریس ارزیابی باید وزنه‌دهی به دسته‌بندی‌های درخواست شده در RFP را به گونه‌ای انجام دهد که اولویت‌های واقعی خریدار را منعکس کند. اگر نتیجه عملیاتی محرک اصلی باشد، بخش اقلام تحویلی باید بالاترین وزن را داشته باشد. اگر کل هزینه مالکیت محرک اصلی باشد، بخش قیمت‌گذاری باید بالاترین وزن را داشته باشد. اگر سرعت رسیدن به تولید محرک اصلی باشد، بخش جدول زمانی باید بالاترین وزن را داشته باشد. وزن‌ها باید از قبل تعیین شوند و پس از دریافت پاسخ‌ها نباید تنظیم شوند.

در هر دسته، معیارهای ارزیابی باید مشخص و قابل امتیازدهی باشند. پاسخی که شامل مالکیت کد منبع باشد، امتیاز بالاتری نسبت به پاسخی که این ویژگی را ندارد، کسب می‌کند. پاسخی که استقرار 30 روزه را پیشنهاد می‌دهد، در اولویت سرعت، امتیاز بالاتری نسبت به پاسخی که شش ماه را پیشنهاد می‌دهد، کسب می‌کند. پاسخی که ارجاعات عملیاتی مشخصی را شامل می‌شود، امتیاز بالاتری نسبت به پاسخی که فقط نام مشتریان را بدون جزئیات عملیاتی فهرست می‌کند، کسب می‌کند.

ماتریس همچنین باید معیارهای رد صلاحیت را نیز شامل شود که هیچ پاسخی نمی‌تواند آن‌ها را برآورده کند. عدم رعایت بیانیه نتیجه عملیاتی. عدم رعایت مرزهای دامنه. عدم ارائه تفکیک قیمت‌گذاری درخواست‌شده. این رد صلاحیت‌ها باید به صورت خودکار اعمال شوند و نباید در مرحله ارزیابی قابل مذاکره باشند.

فرآیندهای انتخاب شرکت مشاوره هوش مصنوعی برای شرکت‌های بزرگ که ماتریس ارزیابی را از قبل می‌سازند، تصمیمات تدارکاتی قابل دفاعی را تولید می‌کنند که در برابر بررسی‌های داخلی مقاومت می‌کنند. فرآیندهای انتخاب شرکت مشاوره هوش مصنوعی برای استارتاپ‌ها حتی بیشتر از این نظم بهره می‌برند، زیرا خریدار کوچکتر معمولاً منابع تدارکاتی کمتری برای جذب بازکاری ارزیابی در زمانی که ماتریس پس از واقعیت مورد بحث قرار می‌گیرد، دارد.

توالی‌بندی فرآیند RFP برای آشکار کردن سریع تفاوت‌های رده‌ها

فرآیند تدارکات حول RFP باید به گونه‌ای توالی‌بندی شود که تفاوت‌های رده‌ها را زودتر آشکار کند تا خریدار بتواند لیست کوتاه را قبل از صرف تلاش ارزیابی قابل توجهی برای پاسخ‌هایی از شرکت‌هایی که نامناسب تشخیص داده می‌شوند، تنظیم کند. اصلاح روش‌شناختی این است که از یک فرآیند RFP دو فاز به جای یک فاز استفاده شود.

فاز اول یک سند صلاحیت کوتاه است که به لیستی طولانی‌تر از شرکت‌ها ارسال می‌شود و سؤالات مربوط به قابلیت‌های اساسی و مدل تعامل را به صورت فشرده می‌پرسد. پاسخ‌های این سند به خریدار اجازه می‌دهد تا شرکت‌هایی را که مدل تعامل آن‌ها نامناسب است، قبل از صدور RFP کامل، فیلتر کند، که این امر تلاش ارزیابی را برای شرکت‌هایی که شانس واقعی برای برنده شدن کار را دارند، حفظ می‌کند.

سپس RFP کامل فقط به لیست کوتاه صلاحیت‌دار صادر می‌شود و پاسخ‌ها می‌توانند با جزئیات در مقابل معیارهای تعیین شده در ماتریس ارزیابی شوند. این توالی‌بندی از صدور یک RFP طولانی و دقیق به بیست شرکت و دریافت بیست پاسخ طولانی و دقیق که هفته‌ها از تلاش ارزیابی را مصرف می‌کند، جلوگیری می‌کند.

فاز صلاحیت همچنین باید شرکت‌هایی را که الگوهای پاسخ‌شان نشان می‌دهد که همکاری با آن‌ها مشکل‌ساز خواهد بود، آشکار سازد. شرکت‌هایی که برای پاسخ به یک سند صلاحیت، زمان زیادی صرف می‌کنند، شرکت‌هایی که سؤالات را نادیده می‌گیرند و مواد بازاریابی را جایگزین می‌کنند، و شرکت‌هایی که تلاش می‌کنند صلاحیت را به یک مکالمه فروش هدایت کنند، همگی الگوهای تحویلی را نشان می‌دهند که خریدار می‌تواند از آن‌ها اجتناب کند.

روش‌شناسی دو فاز، جدول زمانی کلی تدارکات را به جای گسترش آن، فشرده می‌کند، زیرا فاز صلاحیت شرکت‌هایی را که در غیر این صورت زمان ارزیابی را بدون تولید پاسخ‌های رقابتی مصرف می‌کردند، حذف می‌کند، و فاز RFP کامل پاسخ‌های دقیق‌تر و قابل مقایسه‌تری را از شرکت‌هایی که قبلاً مناسب بودن خود را نشان داده‌اند، تولید می‌کند.

رسیدگی به مخالفت‌های فروشنده با روش‌شناسی

مخالفت فروشندگان با یک روش‌شناسی RFP ساختاریافته، خود یک سیگنال مهم است که باید در طول فرآیند تدارکات به آن توجه شود. شرکت‌هایی که با چارچوب نتیجه عملیاتی، تفکیک قیمت‌گذاری ساختاریافته، سؤال صریح مالکیت کد منبع، یا تعهدات تقویمی جدول زمانی مقاومت می‌کنند، نشان می‌دهند که مدل تعامل آن‌ها با روش‌شناسی مطابقت ندارد، و این سیگنال مفیدتر از پاسخ رسمی به RFP است.

شایع‌ترین الگوهای مخالفت شامل درخواست‌هایی برای جایگزینی فرمت قیمت‌گذاری استاندارد شرکت به جای تفکیک ساختاریافته درخواست شده در RFP، درخواست‌هایی برای گسترش تعهدات جدول زمانی به دامنه‌ها یا تخمین‌ها، و درخواست‌هایی برای به تعویق انداختن مالکیت کد منبع به یک مذاکره جداگانه پس از شروع قرارداد است. هر یک از این الگوها باید به عنوان یک عدم پاسخ جزئی در نظر گرفته شود و وزن مناسبی در ماتریس ارزیابی به آن اختصاص داده شود.

برخی از مخالفت‌ها مشروع هستند و ناتوانی واقعی شرکت را در برآورده کردن یک نیاز خاص RFP که با مدل آن‌ها مطابقت ندارد، منعکس می‌کنند. شرکتی که مالکیت کد منبع را در قرارداد استاندارد خود لحاظ نمی‌کند، باید این موضوع را مستقیماً در پاسخ خود بیان کند، و خریدار می‌تواند تصمیم بگیرد که آیا این امر شرکت را رد صلاحیت می‌کند یا نقاط قوت دیگر پیشنهاد، مذاکره برای یک بند سفارشی را توجیه می‌کند. الگوی غیرقابل قبول، مخالفت‌هایی است که سعی در بازگرداندن کل RFP به جای پرداختن به نیازهای خاص دارد.

این روش‌شناسی باید تحت فشار فروشنده شکل خود را حفظ کند. RFP برای تولید پاسخ‌های قابل مقایسه در بین رده‌ها نوشته شده است، و شرکت‌هایی که موفق به از بین بردن روش‌شناسی در فاز پاسخ می‌شوند، قراردادهایی تولید خواهند کرد که مدیریت آن‌ها در طول تحویل کار به همان اندازه دشوار خواهد بود. نظمی که در طول تدارکات حفظ می‌شود، پیش‌بینی‌کننده نظمی است که در طول اجرا حفظ خواهد شد.

اینجاست که تفاوت بین شرکت‌های مشاوره هوش مصنوعی استارتاپی و سازمانی از نظر رفتاری نیز قابل مشاهده می‌شود. شرکت‌های زیرساخت تولیدی تمایل دارند به روش‌شناسی ساختاریافته به طور منظم پاسخ دهند زیرا مدل تعامل آن‌ها از قبل ساختاریافته است، در حالی که شرکت‌های با تمرکز بر استراتژی تمایل به مخالفت دارند زیرا مدل تعامل آن‌ها به ابهامی بستگی دارد که روش‌شناسی آن را از بین می‌برد.

تکمیل چرخه بین RFP و قرارداد

آخرین انضباط روش‌شناختی، تکمیل چرخه بین RFP و قرارداد است، که تضمین می‌کند تعهدات داده شده در پاسخ، به عنوان شرایط قابل اجرا در قرارداد همکاری بازتولید می‌شوند و در فاصله بین تدارکات و بخش حقوقی از بین نمی‌روند. این بخشی است که کار ساختاریافته RFP اغلب در آن از بین می‌رود.

قرارداد باید بیانیه نتیجه عملیاتی از RFP را به عنوان یک محصول قابل تحویل مشخص با معیارهای پذیرش قابل اندازه‌گیری باز تولید کند. مرزهای دامنه باید به عنوان استثنائاتی ظاهر شوند که شرکت نمی‌تواند بدون یک دستور تغییر رسمی آن‌ها را گسترش دهد. تفکیک قیمت‌گذاری باید مبنای فاکتورینگ باشد، با محدودیت‌های واریانس تعریف شده برای هر دسته. نقاط عطف جدول زمانی باید به عنوان تاریخ‌های قراردادی با راه‌حل‌های تعریف شده برای تأخیر ظاهر شوند.

مالکیت کد منبع و مجوز باید به عنوان شرایط صریح با نوع مجوز، فرمت تحویل و زمان انتقال تعریف شده باشد. شرایط پشتیبانی پس از تحویل باید با ساختار نرخ، تعهدات زمان پاسخ و مفاد فسخ تعریف شده باشد. هیچ یک از این شرایط نباید به یک شرح کار که پس از امضای قرارداد مذاکره می‌شود، موکول شود.

قرارداد همچنین باید معیارهای رد صلاحیت از ماتریس ارزیابی را به عنوان محرک‌های فسخ باز تولید کند. عدم رعایت نتیجه عملیاتی در نقاط عطف پذیرش تعریف شده، عدم رعایت مرزهای دامنه، و عدم تحویل کد منبع در نقطه انتقال تعریف شده، همگی باید به خریدار حق فسخ قرارداد را بدون جریمه بدهد.

انضباط روش‌شناختی بازتولید تعهدات RFP در قرارداد، فاصله‌ای را که فروشندگان به طور سنتی در طول اجرا از آن سوءاستفاده می‌کنند، از بین می‌برد، جایی که تعهدات بازاریابی داده شده در فاز فروش به آرامی از واقعیت عملیاتی قرارداد ناپدید می‌شوند. خریداری که این انضباط را در فاز قرارداد حفظ می‌کند، معمولاً قراردادی را که تدارک دیده است دریافت می‌کند، نه قراردادی را که فروشنده ترجیح داده است تحویل دهد.

نتیجه این روش‌شناسی کامل، یک فرآیند تدارکات است که شرکت‌های مشاوره هوش مصنوعی را برای استارتاپ‌ها در مقابل شرکت‌های بزرگ به عنوان رده‌های متمایز با مدل‌های همکاری متمایز می‌شناسد، تفاوت‌های ساختاری را در طول ارزیابی آشکار می‌کند، و قراردادی را تولید می‌کند که شرکت انتخاب شده را به تعهداتی که کار را با آن برنده شده، پایبند می‌کند. هنگامی که این روش‌شناسی به طور کامل دنبال می‌شود، دامنه استقرار شرکت مشاوره هوش مصنوعی بر اساس اندازه شرکت، به یک تصمیم تدارکات قابل مدیریت تبدیل می‌شود و نه یک بازی حدس و گمان.

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت عامل هوشمند را از طریق سه ستون یکپارچه در کسب‌وکارها مستقر می‌کند: زیرساخت‌های عامل، ریل‌های پرداخت غیرسنتی، و یک موتور سرمایه‌گذاری کامل. TFSF با 27 سال تجربه در زمینه پرداخت‌ها و نرم‌افزار، در سطح جهانی فعالیت می‌کند و 21 صنعت عمودی را با روش‌شناسی استقرار 30 روزه پشتیبانی می‌نماید. برای کسب اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.

ارزیابی هوش عملیاتی رایگان را انجام دهید

ارزیابی هوش عملیاتی رایگان را انجام دهید. به چند سوال سریع درباره کسب‌وکار خود پاسخ دهید. یک طرح اولیه استقرار هوش مصنوعی سفارشی ظرف 24 تا 48 ساعت، شامل توصیه‌های عامل، معماری و یک نقشه راه مخصوص عملیات شما دریافت کنید. بدون تماس فروش. بدون تعهد. فقط داده. از https://tfsfventures.com/assessment شروع کنید.

Originally published at https://tfsfventures.com/blog/building-an-rfp-that-works-across-ai-consulting-firms-for-startups-vs-enterprise

نوشته شده توسط TFSF Ventures Research