فرایند خرید نرمافزار در سازمان
خرید نرمافزار در سازمان معمولاً به یکی از این دو شکل انجام میشود، و هر دو بد است.
شکل اول: واحد فناوری خودش تصمیم میگیرد و میخرد. نتیجه سامانهای است که از نظر فنی درست است و کاربران استفاده نمیکنند، چون با روش کارشان نمیخواند.
شکل دوم: واحد کسبوکاری خودش میخرد و بعد به فناوری میگوید راهاندازی کنید. نتیجه سامانهای است که کاربران دوستش دارند و به هیچ چیز دیگری وصل نمیشود.
فرایند درست، هر دو را از ابتدا سر یک میز میآورد — و یک نفر را مسئول میکند.
چه کسانی باید در تصمیم باشند
پنج نقش. در سازمان کوچک، یک نفر میتواند دو نقش داشته باشد؛ آنچه نباید اتفاق بیفتد، نبودن یکی از آنهاست.
مالک کسبوکاری. کسی که فرایند مال اوست و بابت نتیجه پاسخگوست. این نفر باید تصمیمگیر نهایی باشد، نه واحد فناوری.
کاربر واقعی. کسی که هر روز با سامانه کار خواهد کرد. نبودن این نفر، شایعترین علت سامانهای است که کسی استفاده نمیکند.
واحد فناوری. برای امکانسنجی اتصالها، امنیت، زیرساخت و نگهداری.
مالی. برای هزینهٔ مالکیت، نه فقط رقم قرارداد.
حقوقی یا قراردادها. برای مالکیت، محرمانگی و شرط خروج.
مرحله ۱: نیاز را بنویسید، نه راهحل را
اشتباهی که کل فرایند را از ابتدا خراب میکند: سازمان با «یک CRM میخواهیم» شروع میکند.
این راهحل است، نه نیاز. نیاز چیزی شبیه این است:
«هفتاد درصد سرنخهای فروش پیگیری نمیشوند، چون در دفترچهٔ شخصی هر کارشناساند و وقتی کسی میرود با او میروند.»
تفاوت عملی این دو زیاد است. جملهٔ دوم ممکن است با CRM حل شود، یا با یک ماژول در سامانهٔ موجود، یا با تغییر فرایند بدون هیچ نرمافزاری.
سه سؤالی که پیش از هر جستوجویی باید جواب داشته باشند:
- مشکل امروز دقیقاً چیست و چقدر هزینه دارد؟ با عدد، حتی تقریبی.
- اگر حل شود، چه چیزی متفاوت خواهد بود؟ قابل اندازهگیری.
- اگر هیچکاری نکنیم چه میشود؟ گاهی جواب «هیچ» است و همانجا باید متوقف شد.
مرحله ۲: بسازیم، بخریم، یا هیچکدام
سه گزینه که همیشه باید کنار هم دیده شوند:
فرایند را عوض کنید، بدون نرمافزار. ارزانترین گزینه و کمتر از همه بررسی میشود. اگر مشکل از هفت مرحله تأیید است، حذف چهارتایش نرمافزار نمیخواهد.
نرمافزار آماده. اگر فرایند شما استاندارد است — حسابداری، حقوق و دستمزد، حضور و غیاب — تقریباً همیشه گزینهٔ درست است. ساختن چیزی که هزاران سازمان دیگر هم دارند، توجیه ندارد.
سفارشی. وقتی فرایند شما همان چیزی است که مزیت رقابتیتان را میسازد، یا هیچ محصولی پوششش نمیدهد.
معیار عملی: اگر محصول آماده بیش از هفتاد درصد نیازتان را پوشش میدهد، بخرید و فرایند را کمی تطبیق دهید. زیر پنجاه درصد، بسازید. بین این دو، هزینهٔ مالکیت پنجساله تصمیم را میگیرد — نه رقم اولیه.
مرحله ۳: پیشنهادها را قابل مقایسه کنید
سه پیشنهاد با اختلاف سهبرابری، معمولاً یعنی سه نفر سه چیز متفاوت فهمیدهاند.
پس دامنه را خودتان بنویسید و به همه یک متن بدهید. ساختارش در نگارش RFP آمده. حداقلی که باید در آن متن باشد:
- مشکل و وضع موجود.
- فهرست آنچه لازم است و آنچه لازم نیست — بند دوم بهاندازهٔ اولی مهم است.
- سامانههایی که باید به آنها وصل شود، با نام و نسخه.
- تعداد کاربر و حجم داده.
- قالب پاسخ: چه چیزی و با چه ساختاری میخواهید.
آن بند آخر ساده به نظر میرسد و بیشترین اثر را دارد: اگر همه در یک قالب جواب بدهند، مقایسه ممکن میشود.
مرحله ۴: ارزیابی، نه بر اساس فهرست امکانات
جدول امکانات — آن جدول با تیک سبز — بدترین ابزار تصمیمگیری در این حوزه است.
دو دلیل: هر فروشندهای میتواند تقریباً به هر بندی تیک بزند، و امکانی که هست ولی بد است، در جدول با امکانی که خوب است یکسان دیده میشود.
آنچه بهتر کار میکند:
سناریوی واقعی بدهید. «سفارشی با این شرایط ثبت میشود، مشتری اعتبارش تمام است، تخفیف قراردادی دارد. نشان دهید در سامانهٔ شما چطور انجام میشود.» این یک نمایش پنجدقیقهای است که از دو ساعت ارائه بیشتر میگوید.
با دادهٔ خودتان. حتی نمونهٔ کوچک. سامانهای که با دادهٔ نمایشی عالی است، ممکن است با کدهای کالای واقعی شما به مشکل بخورد.
با کاربر واقعی، نه با مدیر. بگذارید کسی که هر روز کار میکند خودش امتحان کند.
با مشتری قبلی حرف بزنید — و بپرسید «پروژهای که سخت پیش رفت کدام بود؟». معیارهای کاملش در انتخاب پیمانکار آمده.
مرحله ۵: قرارداد
بندهایی که نبودشان گران تمام میشود:
- مالکیت کد، داده، دامنه و حسابهای سرویس. صریح.
- تحویل و پرداخت مرحلهای، گرهخورده به چیز قابل بررسی.
- معیار پذیرش برای هر مرحله.
- هزینهٔ سال دوم و سوم، با عدد.
- نرخ تغییرات خارج از دامنه.
- سطح خدمت پشتیبانی — زمان پاسخ به تفکیک شدت. جزئیاتش در SLA.
- شرط خروج: داده در چه قالبی و در چه مدتی تحویل میشود.
- محرمانگی و محل نگهداری داده.
دامهای خاص خرید سازمانی در ایران
خرید بر اساس رابطه، نه ارزیابی. رایج است و همیشه بد نیست — اعتماد ارزش دارد. اما دستکم یک گزینهٔ دیگر را جدی بررسی کنید تا بدانید بازار کجاست.
تخفیف پایان سال مالی. فشار برای بستن قرارداد پیش از پایان اسفند، تصمیم را عجولانه میکند. تخفیفی که باعث شود سامانهٔ اشتباه بخرید، تخفیف نیست.
«این را هم اضافه کنید» در مذاکره. هر قابلیتی که خارج از دامنهٔ اولیه اضافه شود، یا هزینه دارد یا از کیفیت جای دیگری کم میکند. الگویش در تغییر دامنه.
نادیدهگرفتن اتصال به سامانههای حاکمیتی. فرایند اداری دریافت دسترسی هفتهها طول میکشد و در دست شما نیست. این را در زمانبندی بهعنوان قلم مستقل و موازی ببینید.
تصمیم بدون کاربر. اگر یک بند از این مقاله بماند، همین باشد. سامانهای که کاربرانش در انتخابش نقشی نداشتهاند، با مقاومت روبهرو میشود — و آن مقاومت، نه فناوری، چیزی است که پروژه را شکست میدهد.
یک آزمون ساده پیش از امضا
از خودتان بپرسید: اگر یک سال بعد این سامانه شکست بخورد، دلیلش چه خواهد بود؟
اگر جوابی دارید، همان را همین حالا رفع کنید. اگر جوابی ندارید، بهاندازهٔ کافی فکر نکردهاید.