نرم‌افزار آماده بخرم یا اختصاصی بسازم؟ (راهنمای تصمیم)

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

سؤالِ درست این است: فرایندِ کاری شما یک مزیتِ رقابتی است، یا فقط یک عادت؟ این یک سؤال، بیشترِ موارد را حل می‌کند — و در ادامه نشان می‌دهیم چطور.

یک تفکیکِ لازم هم اول کار: این مقاله درباره‌ی نرم‌افزارِ کسب‌وکار است — حسابداری، CRM، انبار، اتوماسیونِ اداری. اگر انتخابِ شما درباره‌ی پلتفرمِ سایت است، جای درست جای دیگری است: فروشگاه‌ساز یا سایت اختصاصی، ووکامرس یا اختصاصی، و ابزارهای بدون کدنویسی.

سؤالِ درست: مزیت است یا عادت؟

هر نرم‌افزارِ آماده‌ای یک فرضِ ثابت دارد: «کارها این‌طور انجام می‌شوند». وقتی می‌خریدش، دو حالت پیش می‌آید — یا فرضِ او با روشِ شما می‌خواند، یا شما باید روشتان را عوض کنید.

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

• اگر فرایندتان تاریخی است («از قدیم این‌طور بوده»، «فلانی این‌طور یاد گرفته»)، آن یک عادت است. نرم‌افزارِ آماده‌ی خوب، حاصلِ تجربه‌ی هزاران کسب‌وکار است و احتمالاً روشش از روشِ شما بهتر است. عوض‌کردنِ عادت ارزان‌تر از ساختنِ نرم‌افزار است.
• اگر فرایندتان دلیلِ برنده‌شدنِ شماست — روشِ خاصِ قیمت‌گذاری، منطقِ خاصِ تخصیصِ سفارش، شیوه‌ی خاصِ کنترلِ کیفیت که مشتری بابتش می‌آید — آن یک مزیت است. مجبورکردنش به قالبِ نرم‌افزارِ آماده یعنی از دست دادنِ همان چیزی که متمایزتان می‌کند.

پس قبل از هر مقایسه‌ای، فرایندهایتان را به این دو دسته تقسیم کنید. تقریباً همیشه معلوم می‌شود که بخشِ کوچکی مزیت است و بخشِ بزرگی عادت — و همین جواب را می‌سازد.

کدام دسته را بخرید، کدام را بسازید

به‌جای اصولِ کلی، تصمیمِ آماده به‌تفکیکِ دسته:

چرا نرم‌افزارِ قانون‌محور را نباید ساخت

این مهم‌ترین استدلالِ ایرانیِ این مقاله است و صریحاً به‌ضررِ فروشِ نرم‌افزارِ اختصاصی — از جمله فروشِ خودمان.

صدور صورتحساب و ارسالش به سامانه‌ی مؤدیان یک الزامِ قانونی است، با قالبِ داده‌ی مشخص، مهلتِ ارسال، و جریمه در صورتِ تأخیر (مطابق قانون پایانه‌های فروشگاهی و سامانه مؤدیان). نکته این نیست که ساختنش سخت است؛ نکته این است که هدف حرکت می‌کند: قالب‌ها، مهلت‌ها و قواعد به‌مرور تغییر می‌کنند.

فروشنده‌ی نرم‌افزارِ حسابداری هزینه‌ی به‌روزماندن با این تغییرات را بین هزاران مشتری سرشکن می‌کند. اگر خودتان ساخته باشید، هر بار که قواعد عوض شود، تنها شما هزینه‌اش را می‌دهید — و اگر دیر بجنبید، جریمه هم می‌دهید. برای بودجه‌بندیِ مالیاتی راهنمای مالیات نقطه‌ی شروع است.

راهِ سوم که کسی نمی‌گوید: ترکیب

سؤال «بخرم یا بسازم» یک دوگانه‌ی کاذب است. جوابِ درستِ بیشترِ کسب‌وکارهای متوسط هر دو است:

1. کالای عمومی را بخر. حسابداری، حقوق‌ودستمزد، ابزارهای استانداردِ اداری.
2. نقطه‌ی تمایزت را بساز. همان فرایندی که در بخشِ اول «مزیت» تشخیص دادید.
3. وصلشان کن. و این‌جا نکته‌ی مهم است: لایه‌ی اتصال، ارزان‌ترین کارِ اختصاصی با بیشترین بازده است. نه یک سامانه‌ی کاملِ جدید می‌سازید، نه به قالبِ یک نرم‌افزارِ آماده محدود می‌مانید.

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

پنج نشانه که نرم‌افزارِ آماده‌تان دیگر کافی نیست

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

1. کارِ اصلی در اکسل انجام می‌شود. اگر برای هر تصمیمِ واقعی داده را از نرم‌افزار خروجی می‌گیرید و در اکسل کارِ اصلی را می‌کنید، آن نرم‌افزار دیگر ابزارِ کارِ شما نیست؛ فقط یک انبارِ داده است.
2. فایل‌های موازیِ سایه. کنارِ نرم‌افزار، یک یا چند فایل دارید که «واقعیتِ اصلی» در آن‌هاست. این دقیق‌ترین نشانه است، چون خودتان با عمل نشان داده‌اید نرم‌افزار جواب نمی‌دهد.
3. ورودِ دستیِ دوباره. همان داده را در دو سیستم وارد می‌کنید. این‌جا لازم نیست نرم‌افزارِ تازه بسازید — فقط لایه‌ی اتصال را بسازید، که ارزان‌ترین راه‌حل است.
4. بابتِ کاربرانی پول می‌دهید که فقط نگاه می‌کنند. در مدلِ به‌ازای هر کاربر، وقتی نصفِ لایسنس‌ها مالِ کسانی است که فقط گزارش می‌بینند، هزینه با ارزش هم‌خوان نیست.
5. جوابِ «نمی‌شود» را با کارِ دستی جبران می‌کنید. هر فرایندی که با «نرم‌افزار این را ندارد، دستی انجامش می‌دهیم» شروع شود، یک هزینه‌ی پنهانِ ماهانه است. یک ماه ساعتش را بشمارید؛ همان عدد مبنای تصمیم است.

نکته‌ی مهم: هیچ‌کدام از این پنج نشانه به‌تنهایی معنایش «همه‌چیز را اختصاصی کن» نیست. سه موردِ اول را معمولاً می‌شود با یک لایه‌ی اتصال یا یک ابزارِ کوچکِ اختصاصی حل کرد، بدونِ دست‌زدن به نرم‌افزارِ موجود.

هزینه: دو ساختارِ متفاوت، نه دو عدد

مقایسه‌ی «قیمتِ امروز» گمراه‌کننده است، چون ساختارِ هزینه‌ی این دو اساساً فرق دارد:

• آماده: ورودیِ ارزان، ولی هزینه‌ی دائمی — اشتراک، و در بسیاری موارد به‌ازای هر کاربر. یعنی هزینه با رشدِ تیمِ شما بالا می‌رود، حتی اگر استفاده‌تان بیشتر نشود.
• اختصاصی: ورودیِ گران، بعد پشتیبانیِ سالانه. در بازارِ نرم‌افزارِ سازمانیِ ایران این پشتیبانی معمولاً ۲۵ تا ۳۵ درصدِ هزینه‌ی اولیه گزارش می‌شود. یعنی «یک‌بار می‌خرم و تمام» درست نیست.

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

ریسکی که هیچ‌کس قیمت‌گذاری نمی‌کند

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

راهِ کاهشش شعار نیست، یک قاعده‌ی عملی است: نسخه‌ی اولِ قابلِ استفاده باید در بازه‌ی ۶ تا ۸ هفته تحویل داده شود. اگر برنامه‌ی کار می‌گوید ماهِ ششم اولین چیزِ قابل‌استفاده را می‌بینید، اسکوپ غلط است — کوچکش کنید. دلیلش هم مالی نیست، اطلاعاتی است: تا وقتی کسی از نرم‌افزار استفاده نکرده، هیچ‌کس — نه شما نه سازنده — نمی‌داند چه چیزی واقعاً لازم است. راهنمای عملیِ سفارش‌دادن در راهنمای سفارش نرم‌افزار و اپلیکیشن اختصاصی، و اشتباهاتِ رایج در ۱۲ اشتباه رایج.

قفل‌شدگی و خروجِ داده — در هر دو جهت

این را قبل از امضا بپرسید، نه بعدش:

• در نرم‌افزارِ آماده: داده‌هایم را در چه قالبی می‌توانم کامل بیرون بکشم؟ اگر جواب مبهم است یا «با تیکت درخواست بدهید»، شما قفل شده‌اید.
• در نرم‌افزارِ اختصاصی: بعد از تسویه، کدِ منبع به نامِ چه کسی است؟ اگر سازنده نبود، چه کسی می‌تواند ادامه بدهد؟ مستنداتش کجاست؟ اختصاصیِ بدون کد و مستندات، قفل‌شدگیِ بدتری از آماده است — چون فقط یک نفر در دنیا می‌تواند تغییرش دهد.

چک‌لیست تصمیم

1. فرایندهایتان را به دو دسته‌ی «مزیت» و «عادت» تقسیم کنید.
2. برای دسته‌ی «عادت» فقط نرم‌افزارِ آماده بررسی کنید.
3. هر چیزی که نهادِ بیرونی قالبش را تعیین می‌کند (مالیات، بیمه، بانک) را بخرید.
4. هزینه‌ی هر دو گزینه را روی سه تا پنج سال و با تعدادِ کاربرِ سالِ سوم حساب کنید.
5. بپرسید خروجِ کاملِ داده در هر گزینه چطور انجام می‌شود.
6. در گزینه‌ی اختصاصی: مالکیتِ کد، مستندات، و تاریخِ تحویلِ نسخه‌ی اولِ قابلِ استفاده را در قرارداد بیاورید.
7. اگر جوابتان «اختصاصی» شد، اول بپرسید کدام بخشش را می‌شود نخرید و از آماده گرفت. این سؤال را از ما هم بپرسید.

جمع‌بندی

سه چیز را ببرید. اول: سؤال «کدام امکانات را دارد» نیست، «فرایندم مزیت است یا عادت» است — و برای عادت، عوض‌کردنِ روشِ کار ارزان‌تر از ساختنِ نرم‌افزار است. دوم: هر جا نهادی بیرونی قاعده را تعیین می‌کند، بخرید؛ هدفِ متحرک را نمی‌شود تنهایی دنبال کرد. سوم: جوابِ واقعیِ بیشترِ کسب‌وکارها ترکیب است — کالای عمومی را بخر، نقطه‌ی تمایز را بساز، و لایه‌ی اتصال را که ارزان‌ترین کارِ اختصاصی با بیشترین بازده است، بساز.

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

روشِ برآوردِ هزینه‌ی این پروژه — و این‌که ریسک در هر مدلِ قرارداد کجا می‌نشیند — در هزینه‌ی نرم‌افزار اختصاصی چطور برآورد می‌شود آمده.

گیتِ توزیع، پنج قابلیتِ تصمیم‌ساز و مسیرِ چهارپرسشیِ انتخابِ پلتفرم در اندروید، iOS یا PWA آمده.

قبل از خودکار کردن، حذف کنید — و آزمونش این است: این تأییدکننده آخرین بار کِی «نه» گفت؟ اتوماسیون اداری و حذفِ مرحله‌های بی‌اثر.