هر کسب‌وکاری دیر یا زود به جایی می‌رسد که اکسل و دفترچه دیگر جواب نمی‌دهد. حسابداری، انبار، نوبت‌دهی، مدیریت مشتری یا فروش آنلاین؛ بالاخره یک نرم‌افزار لازم می‌شود. و سؤال همیشگی پیش می‌آید: خودمان بسازیم، یک نرم‌افزار آماده بخریم، یا یک سرویس اشتراکی (SaaS) بگیریم؟
جواب درست به نوع کسب‌وکار، بودجه و مهم‌تر از همه به این بستگی دارد که آن نرم‌افزار چه نقشی در رقابت شما دارد. این مقاله یک چارچوب ساده برای همین تصمیم است.
سه گزینه، دقیقاً یعنی چه؟
ساختن (Build): نرم‌افزار را خودتان یا یک پیمانکار، مخصوص کسب‌وکار شما می‌نویسد. کد مال شماست، اختیار کامل دارید و مسئولیت کامل هم با شماست.
خریدن (Buy): یک نرم‌افزار آماده را با لایسنس دائمی می‌خرید و روی سرور یا رایانه‌های خودتان نصب می‌کنید. نمونه‌ی رایجش نرم‌افزارهای حسابداری و انبار نصبی است. معمولاً هزینه‌ی پشتیبانی یا به‌روزرسانی سالانه هم جدا دارد.
اشتراک (Subscribe / SaaS): نرم‌افزار روی سرورهای فروشنده اجرا می‌شود و شما با مرورگر یا اپ از آن استفاده می‌کنید و ماهانه یا سالانه هزینه می‌دهید. نصب و نگهداری با فروشنده است، اما داده‌ی شما هم روی سرور اوست.
مرز این سه همیشه تیز نیست. گاهی یک سرویس اشتراکی را با چند افزونه‌ی سفارشی ترکیب می‌کنیم، یا یک نرم‌افزار متن‌باز را روی سرور خودمان نصب و کمی شخصی‌سازی می‌کنیم. اما برای فکرکردن، همین سه دسته کافی است.
هزینه‌ی واقعی: کل هزینه در سه سال
بزرگ‌ترین اشتباه در این تصمیم، مقایسه‌ی قیمت روز اول است. نرم‌افزار سفارشی در روز اول گران به نظر می‌رسد و اشتراک ماهانه ارزان؛ ولی تصمیم درست را کل هزینه‌ی مالکیت (TCO) در یک بازه‌ی چندساله نشان می‌دهد. سه سال بازه‌ی معقولی است: آن‌قدر کوتاه که بشود برآوردش کرد و آن‌قدر بلند که هزینه‌های پنهان خودشان را نشان بدهند.
این اقلام را برای هر گزینه جدا بنویسید:
| قلم هزینه | ساختن | خریدن | اشتراک |
|---|---|---|---|
| هزینه‌ی اولیه | توسعه، معمولاً بزرگ‌ترین رقم | لایسنس | معمولاً کم یا صفر |
| هزینه‌ی دوره‌ای | نگهداری، رفع اشکال، تغییرات | پشتیبانی و به‌روزرسانی سالانه | اشتراک ماهانه یا سالانه، به ازای هر کاربر |
| زیرساخت | سرور، دامنه، پشتیبان‌گیری | سرور یا رایانه، پشتیبان‌گیری | معمولاً در قیمت اشتراک |
| راه‌اندازی | تست و آموزش | نصب، انتقال داده، آموزش | انتقال داده، تنظیمات، آموزش |
| وقت تیم خودتان | زیاد: جلسه، تست، تصمیم | متوسط | کم تا متوسط |
| خروج در آینده | کم، کد مال شماست | متوسط | گاهی زیاد، بسته به امکان خروجی داده |
چند نکته که معمولاً از قلم می‌افتد:
- نرم‌افزار سفارشی بعد از تحویل تمام نمی‌شود. سیستم‌عامل، زبان برنامه‌نویسی و کتابخانه‌ها به‌روز می‌شوند، نیازهای کسب‌وکار تغییر می‌کند و اشکال‌ها پیدا می‌شوند. برای نگهداری هر سال بودجه بگذارید؛ صفر گذاشتن این ردیف یعنی برآورد غلط.
- اشتراک با رشد شما بالا می‌رود. بیشتر سرویس‌ها به ازای کاربر، حجم یا تعداد تراکنش قیمت می‌گیرند. قیمت را برای اندازه‌ی سه سال بعدتان حساب کنید، نه امروز.
- وقت خودتان هم هزینه است. ساختن نرم‌افزار سفارشی ساعت‌های زیادی از مدیر و کارکنان می‌گیرد؛ برای توضیح نیاز، تست و تصمیم‌گیری.
- تورم و نرخ ارز را در نظر بگیرید. اگر هزینه‌ای به ارز خارجی یا با افزایش سالانه گره خورده، برآورد سه‌ساله را با یک سناریوی بدبینانه هم حساب کنید.
وابستگی به فروشنده و بیرون‌آوردن داده
نرم‌افزار را می‌شود عوض کرد؛ داده را نه. سؤال کلیدی در هر انتخابی این است: اگر فردا بخواهیم برویم، داده‌مان را چطور و در چه قالبی پس می‌گیریم؟
- در اشتراک، ببینید آیا خروجی کامل در قالب استاندارد (CSV، Excel، JSON یا دسترسی از طریق API) وجود دارد یا فقط گزارش‌های تکه‌تکه. خروجی‌ای که فقط فهرست مشتری‌ها را بدهد ولی سابقه‌ی سفارش‌ها را نه، عملاً شما را نگه می‌دارد.
- در خرید، ببینید داده در چه پایگاه‌داده‌ای ذخیره می‌شود و آیا بدون نرم‌افزار فروشنده قابل‌خواندن است.
- در ساخت، کد و پایگاه‌داده مال شماست، ولی فقط وقتی که واقعاً تحویلش گرفته باشید. در قرارداد صریح بنویسید که کد منبع، دسترسی سرور و مستندات به شما تحویل می‌شود.
یک آزمون عملی: پیش از امضای قرارداد یا در دوره‌ی آزمایشی، یک بار خروجی کامل بگیرید و ببینید واقعاً قابل‌استفاده است.
چه کسی نگهداری می‌کند؟
این سؤال در جلسه‌ی فروش کمتر پرسیده می‌شود و بعدها بیشترین دردسر را درست می‌کند.
در ساختن
اگر پیمانکار نرم‌افزار را ساخته، بعد از تحویل چه کسی اشکال‌ها را رفع می‌کند؟ قرارداد پشتیبانی دارید؟ اگر آن پیمانکار دیگر در دسترس نباشد، آیا برنامه‌نویس دیگری می‌تواند کد را بفهمد؟ نرم‌افزاری که با فناوری‌های رایج و مستندات حداقلی ساخته شده، این ریسک را خیلی کمتر می‌کند.
در خریدن
به‌روزرسانی‌ها را چه کسی نصب می‌کند؟ سرور یا رایانه‌ای که نرم‌افزار رویش است، چه کسی مراقبش است؟ نرم‌افزار نصبی که سال‌ها به‌روز نشده، هم از نظر امنیت و هم از نظر سازگاری با سیستم‌عامل‌های جدید ریسک است.
در اشتراک
نگهداری فنی با فروشنده است، و همین بزرگ‌ترین مزیت این مدل برای کسب‌وکار کوچک است. اما تنظیمات، کاربران و دسترسی‌ها هنوز با شماست و یک نفر در تیم باید مسئولش باشد.
امنیت و پشتیبان‌گیری با کیست؟
یک قاعده‌ی ساده: مسئولیت امنیت هیچ‌وقت کاملاً به فروشنده منتقل نمی‌شود. حتی در بهترین سرویس اشتراکی، رمزهای ضعیف، دسترسی کارمندی که رفته و هنوز حذف نشده، یا اشتراک‌گذاری یک حساب بین چند نفر، مشکل شماست.
| موضوع | ساختن | خریدن | اشتراک |
|---|---|---|---|
| امنیت سرور و به‌روزرسانی‌ها | شما یا پیمانکار | شما | فروشنده |
| امنیت کد برنامه | پیمانکار | فروشنده | فروشنده |
| کاربران، رمزها و دسترسی‌ها | شما | شما | شما |
| پشتیبان‌گیری | شما | شما | فروشنده، ولی خروجی مستقل با شما |
| آزمودن بازگردانی پشتیبان | شما | شما | بپرسید و تا حد ممکن خودتان امتحان کنید |
درباره‌ی پشتیبان‌گیری یک نکته را جدی بگیرید: پشتیبانی که هیچ‌وقت بازگردانی‌اش امتحان نشده، فقط یک امید است. هر چند ماه یک بار، بازگردانی را روی یک محیط جدا امتحان کنید. در سرویس اشتراکی هم، حتی اگر فروشنده پشتیبان می‌گیرد، یک خروجی دوره‌ای مستقل از داده‌ها نزد خودتان نگه دارید.
نرم‌افزار سفارشی کِی توجیه دارد؟
قاعده‌ی کلی این است: برای کارهایی که همه‌ی کسب‌وکارها مثل هم انجام می‌دهند، نسازید. حسابداری، حقوق و دستمزد، ایمیل، ذخیره‌ی فایل و مدیریت پروژه، تقریباً برای همه یکسان است و نرم‌افزارهای آماده‌ی بالغی برایشان وجود دارد. ساختن دوباره‌ی این‌ها معمولاً یعنی پرداخت هزینه‌ی بیشتر برای نتیجه‌ی ضعیف‌تر.
نرم‌افزار سفارشی وقتی توجیه دارد که هسته‌ی رقابت شما باشد؛ یعنی همان چیزی که شما را از رقبا متمایز می‌کند:
- روش قیمت‌گذاری، زمان‌بندی یا تخصیص منابعی که مخصوص شماست و نرم‌افزار آماده آن را پشتیبانی نمی‌کند.
- تجربه‌ای که مشتری با آن شما را می‌شناسد و انتخاب می‌کند.
- فرایندی که اگر با یک ابزار عمومی انجامش دهید، مجبورید روش کارتان را به شکل رقبا دربیاورید و مزیتتان را از دست بدهید.
و حتی در این حالت هم، بهتر است فقط همان هسته را بسازید و بقیه را به ابزارهای آماده وصل کنید. یک سیستم نوبت‌دهی اختصاصی لازم نیست حسابداری خودش را داشته باشد.
علامت‌های هشدار، که نشان می‌دهد شاید ساختن انتخاب درستی نیست:
- نمی‌توانید در یک جمله بگویید چرا ابزارهای آماده برایتان کار نمی‌کنند.
- هنوز مسئله را دقیق ننوشته‌اید (این موضوع را در مقاله‌ی اول مسئله را بنویسید، بعد سراغ کد بروید باز کرده‌ایم).
- برای نگهداری بعد از تحویل نه بودجه دارید و نه برنامه.
جدول تصمیم
| اگر… | گزینه‌ی معمولاً مناسب |
|---|---|
| کار عمومی است و همه آن را مثل هم انجام می‌دهند | اشتراک |
| تیم فنی ندارید و نمی‌خواهید مسئول سرور باشید | اشتراک |
| الزام قانونی یا قراردادی دارید که داده باید نزد خودتان بماند | خرید، یا ساخت روی زیرساخت خودتان |
| اتصال اینترنت یا دسترسی به سرویس خارجی برایتان قابل‌اتکا نیست | خرید و نصب محلی |
| نرم‌افزار هسته‌ی رقابت شماست و ابزار آماده آن را پشتیبانی نمی‌کند | ساخت |
| نیازتان ۸۰ درصد عمومی و ۲۰ درصد خاص است | اشتراک یا خرید، به‌علاوه‌ی توسعه‌ی سفارشی همان بخش خاص |
| هنوز مطمئن نیستید روش کارتان ثابت بماند | اشتراک با تعهد کوتاه‌مدت، تا روش کار جا بیفتد |
سؤال‌هایی که باید از هر فروشنده بپرسید
چه پیمانکار ساخت باشد، چه فروشنده‌ی نرم‌افزار، چه سرویس اشتراکی، این فهرست را همراه داشته باشید و جواب‌ها را مکتوب بگیرید:
- داده‌های ما در چه قالبی و با چه کاملیتی قابل‌خروجی گرفتن است؟ می‌توانیم همین الان امتحانش کنیم؟
- اگر قرارداد تمام شود یا شما فعالیتتان را متوقف کنید، داده‌ی ما چه می‌شود و تا کی در دسترس است؟
- قیمت با افزایش کاربر، حجم داده یا تراکنش چطور تغییر می‌کند؟ افزایش قیمت سالانه چطور تعیین می‌شود؟
- پشتیبان‌گیری چند وقت یک بار انجام می‌شود، کجا نگهداری می‌شود و آخرین بار کی بازگردانی‌اش آزمایش شده؟
- اگر مشکلی پیش بیاید، از چه راهی و در چه مدتی پاسخ می‌دهید؟
- چه کسانی در سمت شما به داده‌های ما دسترسی دارند؟
- آیا امکان ورود دومرحله‌ای و تعریف سطح دسترسی برای کاربران وجود دارد؟
- (برای ساخت) کد منبع، دسترسی سرور و مستندات در پایان به ما تحویل می‌شود؟ با چه فناوری‌ای ساخته می‌شود؟
- (برای خرید) به‌روزرسانی‌ها تا کی ارائه می‌شود و هزینه‌اش چقدر است؟
اگر فروشنده‌ای به این سؤال‌ها جواب روشن و مکتوب نمی‌دهد، همین خودش جواب است.
جمع‌بندی
انتخاب بین ساختن، خریدن و اشتراک، تصمیمی فنی نیست؛ تصمیمی درباره‌ی هزینه، ریسک و مسئولیت است. برای کارهای عمومی، اشتراک یا نرم‌افزار آماده تقریباً همیشه منطقی‌تر است. ساختن را برای همان بخشی نگه دارید که هسته‌ی رقابت شماست.
در هر سه حالت، هزینه را برای سه سال حساب کنید نه برای روز اول، راه بیرون‌آوردن داده را پیش از امضا امتحان کنید، و روشن کنید نگهداری، امنیت و پشتیبان‌گیری دقیقاً با کیست. این سه سؤال، بیشتر تصمیم‌های بد را پیش از آنکه گران تمام شوند نشان می‌دهند.