هزینه نرم افزار سفارشی در کیبووب از ۱۵۰ میلیون تومان شروع میشود و نقطهی شروع پروژه، بررسی فرایندهای فعلی، نیاز کاربران و تعیین محدودهی نسخهی اول است. قیمت نهایی پس از روشن شدن جزئیاتی مثل نقش‌های کاربری، گردش کار، اتصال به نرم‌افزارهای موجود و وضعیت داده‌های قدیمی مشخص میشود. یک عدد ثابت برای همه وجود ندارد، چون سامانه‌ای برای ثبت و پیگیری درخواست‌ها با نرم‌افزاری که چند واحد سازمانی، اطلاعات مالی و تأییدهای چندمرحله‌ای را به هم وصل میکند، حجم کار و مسئولیت یکسانی ندارد.
پیش از سفارش نرمافزار، مسئله‌ی کسب‌وکار را روشن کنید
ممکن است وضعیت شرکت شما آشنا باشد: فروش اطلاعات را در یک فایل اکسل نگه می‌دارد، حسابداری نرمافزار خودش را دارد و مسئول عملیات برای فهمیدن وضعیت هر سفارش باید پیام‌ها و تماس‌ها را دنبال کند. در چنین شرایطی، پیشنهاد ساخت یک سامانه‌ی مشترک منطقی به نظر می‌رسد. اما پیش از انتخاب ابزار، باید مشخص شود مشکل اصلی کجاست: ثبت تکراری اطلاعات، گم شدن مسئولیت‌ها، تأخیر در تأییدها یا نداشتن تصویر قابل اعتماد از وضعیت شرکت؟
این تفاوت مهم است، چون هر مسئله‌ای به ساخت نرمافزار ختم نمی‌شود. گاهی اصلاح یک فرم، مشخص کردن مسئول هر مرحله یا استفاده‌ی درست‌تر از نرمافزار موجود، بخش قابل توجهی از مشکل را حل میکند. اگر اختلاف واحدها بر سر تعریف «سفارش نهایی‌شده» باشد، ساخت یک صفحه‌ی جدید آن اختلاف را برطرف نمی‌کند؛ فقط همان ابهام را وارد سامانه میکند.
برای شروع، چند نمونه‌ی واقعی از کار روزانه جمع کنید: یک درخواست عادی، یک مورد برگشت‌خورده و یک پرونده که بین واحدها معطل مانده است. توضیح دهید چه کسی چه اطلاعاتی را دریافت میکند، چه تصمیمی میگیرد و نتیجه را به چه کسی تحویل میدهد. این نمونه‌ها برای بررسی طراحی نرمافزار سفارشی از فهرستی طولانی از امکانات عمومی مفیدترند، چون نشان میدهند دقیقاً چه چیزی باید تغییر کند.
چرا یک قیمت ثابت برای نرمافزار سفارشی وجود ندارد؟
نرمافزار سفارشی محصولی با مشخصات از پیش بستهبندیشده نیست. عنوانهایی مثل «سامانه فروش» یا «سامانه مدیریت اختصاصی» فقط موضوع کلی را مشخص میکنند. در یک شرکت، فروش با ثبت سفارش تمام میشود؛ در شرکتی دیگر، به بررسی اعتبار مشتری، رزرو موجودی، تأیید تخفیف، صدور سند و هماهنگی ارسال وابسته است. ظاهر صفحات ممکن است شبیه باشد، اما قواعد پشت آنها متفاوت است.
بخشی از هزینه نیز مربوط به اتفاق‌هایی است که در نمایش اولیه دیده نمی‌شوند. اگر کاربر دوبار روی ثبت پرداخت کلیک کند چه میشود؟ اگر مدیر درخواست را تأیید کند و بعد مبلغ تغییر کند، آیا تأیید قبلی معتبر می‌ماند؟ اگر اتصال حسابداری قطع شود، اطلاعات کجا می‌ماند و چه کسی از خطا مطلع میشود؟ پاسخ به این پرسش‌ها به طراحی، پیاده‌سازی و آزمون نیاز دارد.
بنابراین، مقایسه‌ی پیشنهادهای مالی فقط با عدد پایانی آنها قابل اتکا نیست. باید دید هر پیشنهاد چه محدوده‌ای را پوشش میدهد، چه فرض‌هایی دارد و چه چیزهایی را کنار گذاشته است. قیمت پایین‌تر ممکن است حاصل محدودهی کوچک‌تر باشد؛ قیمت بالاتر هم به‌خودی‌خود کیفیت بیشتر را ثابت نمی‌کند. پیشنهاد قابل بررسی باید روشن کند چه چیزی ساخته میشود، چگونه تحویل گرفته میشود و چه مواردی هزینهی جداگانه دارند.
هفت چیزی که هزینه را بالا و پایین می‌برد
برای برآورد اولیه لازم نیست مدیر شرکت برنامه‌نویسی بداند، اما باید عوامل اصلی هزینه را بشناسد. این عوامل کمک میکنند هنگام مذاکره بفهمید کدام درخواست واقعاً دامنه‌ی پروژه را تغییر میدهد و کدام تصمیم را می‌توان تا نسخههای بعدی عقب انداخت.
- تعداد نقش‌های کاربری: تفاوت فقط در تعداد کاربران نیست. کارشناس، سرپرست، مدیر شعبه و مدیر مالی ممکن است هرکدام اطلاعات متفاوتی ببینند و اجازه‌ی انجام کارهای متفاوتی داشته باشند. هزینه بیشتر به تنوع این قواعد وابسته است.
- پیچیدگی گردش کار: مسیری ساده از ثبت تا تأیید با فرایندی که بازگشت، اصلاح، جانشینی مدیر، تأیید مشروط و استثنا دارد یکسان نیست. هر مسیر باید تعریف و آزمایش شود.
- اتصال به سامانه‌های دیگر: ارتباط با حسابداری، انبار یا سرویسهای بیرونی به امکانات و محدودیت‌های طرف مقابل بستگی دارد. مستندات ناقص و دسترسی نامطمئن، برآورد را دشوارتر میکنند.
- گزارش‌گیری: نمایش چند گزارش مشخص با ساخت ابزاری که کاربران در آن گزارش‌های دلخواه بسازند، دامنه‌ی متفاوتی دارد. تعریف شاخص‌ها و کنترل دسترسی به خروجی‌ها نیز بخشی از کار است.
- نسخهی موبایل: نمایش مناسب سامانه در مرورگر تلفن همراه با ساخت اپلیکیشن مستقل یکسان نیست. نیاز به کار بدون اینترنت یا استفاده از امکانات دستگاه، تصمیم را تغییر میدهد.
- مهاجرت داده‌ی قدیمی: انتقال اطلاعات مرتب و یکپارچه با ترکیب فایل‌های تکراری، ناقص و ناسازگار تفاوت دارد. بررسی کیفیت داده باید پیش از تعهد به انتقال کامل انجام شود.
- سطح امنیت و حسابرسی: محدود کردن دسترسی، ثبت سابقه‌ی تغییرات، محافظت از اطلاعات حساس و امکان بررسی رویدادها، نیازمند تصمیم‌های روشن و اجرای متناسب با حساسیت سازمان است.
این عوامل مستقل از هم نیستند. اضافه کردن یک شعبه ممکن است هم دسترسی‌ها را تغییر دهد، هم گزارش‌ها را و هم قواعد تأیید را. به همین دلیل، برآورد دقیق‌تر از بررسی ارتباط نیازها به دست می‌آید، نه از شمردن تعداد صفحه‌ها یا دکمه‌ها.
فاز کشف چیست و پیش از قیمت نهایی چه چیزی تحویل میدهد؟
فاز کشف یا Discovery مرحلهای است که در آن تیم اجرا و نمایندگان سازمان، مسئله و محدودهی راهحل را روشن میکنند. هدف این مرحله صرفاً برگزاری جلسه نیست؛ باید ابهامهایی را کاهش دهد که در غیر این صورت، هنگام اجرا به اختلاف، دوبارهکاری یا افزایش هزینه تبدیل میشوند. در این مرحله لازم است علاوه بر مدیران، صدای افرادی شنیده شود که کار روزانه را انجام میدهند.
خروجی قابل استفاده‌ی کشف میتواند شامل نقشه‌ی فرایند فعلی و پیشنهادی، فهرست نقش‌ها، قواعد دسترسی، نمونه‌ی اولیه‌ی صفحات و فهرست نیازهای اولویت‌بندی‌شده باشد. همچنین باید وضعیت داده‌های قدیمی، وابستگی به شرکت‌های دیگر و پرسش‌های حل‌نشده ثبت شود. نمونه‌ی اولیه یا Prototype نمایشی برای بررسی مسیر کار است و نباید با نرمافزار آمادهی استفاده اشتباه گرفته شود.
یکی از مهم‌ترین تحویل‌دادنی‌ها، معیار پذیرش است: توضیحی قابل بررسی دربارهی اینکه هر قابلیت چه زمانی درست کار میکند. مثلاً به جای «امکان تأیید درخواست»، نوشته شود چه کسی اجازه‌ی تأیید دارد، بعد از تأیید چه چیزی تغییر میکند و درخواست ردشده به کجا برمی‌گردد. این تعریف، مبنای مشترک ساخت و تحویل خواهد بود.
پیش از شروع کشف باید روشن باشد هزینه و زمان آن چگونه محاسبه میشود، چه خروجی‌هایی دارد و آیا مستنداتش در صورت ادامه ندادن همکاری قابل استفاده هستند. کشف همه‌ی تغییرات آینده را حذف نمی‌کند، اما امکان ارائه‌ی قیمت و برنامه‌ای با فرض‌های روشن‌تر را فراهم میکند.
نسخهی اول کوچک باشد؛ MVP دقیقاً یعنی چه؟
حداقل محصول پذیرفتنی یا Minimum Viable Product که به اختصار MVP گفته میشود، کوچک‌ترین نسخه‌ای است که یک نیاز واقعی را به شکل قابل استفاده پاسخ میدهد. منظور نرم‌افزاری ناقص و پرخطا نیست. اگر هدف، پیگیری درخواست خدمات است، نسخهی اول باید بتواند درخواست را ثبت کند، مسئولش را مشخص کند و وضعیتش را تا پایان نشان دهد؛ حتی اگر فعلاً امکانات جانبی زیادی نداشته باشد.
کوچک کردن نسخهی اول یعنی محدود کردن دامنه، نه حذف کیفیت پایه. کنترل دسترسی، حفاظت از اطلاعات و جلوگیری از خراب شدن داده را نمی‌توان صرفاً به دلیل اولیه بودن نسخه کنار گذاشت. در مقابل، بعضی گزارش‌های فرعی، تنظیمات کم‌کاربرد یا قابلیت‌های مناسب آینده می‌توانند تا روشن شدن نیاز واقعی صبر کنند.
برای انتخاب محدوده، از هر قابلیت بپرسید: اگر فعلاً وجود نداشته باشد، آیا فرایند اصلی متوقف میشود؟ آیا راهحل موقت قابل قبولی داریم؟ آیا کاربران واقعاً به آن نیاز دارند یا فقط تصور می‌کنیم شاید روزی مفید باشد؟ پاسخ‌ها کمک میکنند بودجه صرف مسیر اصلی شود.
پس از استفاده‌ی واقعی، بازخورد کاربران جهت توسعه را دقیق‌تر میکند. ممکن است سازمان متوجه شود اصلاح فرم ثبت اطلاعات از افزودن داشبورد تازه مهم‌تر است. نسخهی اول کوچک، فرصت چنین یادگیری‌ای را فراهم میکند، پیش از آنکه تصمیم‌های اولیه در سراسر نرمافزار تثبیت شوند.
پروژه از توافق اولیه تا استفاده‌ی روزانه چطور پیش می‌رود؟
پس از کشف و توافق بر محدوده، مسیرهای اصلی کار و شکل صفحات بررسی میشوند. مدیر لازم نیست دربارهی جزئیات فنی تصمیم بگیرد، اما باید تأیید کند که ترتیب مراحل و اطلاعات مورد نیاز با کار سازمان سازگار است. حضور یک نماینده‌ی مشخص از طرف شرکت، تصمیمگیری را منسجم‌تر میکند؛ کسی که بتواند نظر واحدها را جمع کند و پاسخ نهایی بدهد.
در مرحله‌ی ساخت، بهتر است بخشهای قابل مشاهده در فاصله‌های توافق‌شده نمایش داده شوند. نمایش پیشرفت باید بر انجام یک کار واقعی متمرکز باشد، مثلاً ثبت درخواست و رساندن آن به مسئول مربوط. دیدن چند صفحه‌ی جداگانه لزوماً نشان نمی‌دهد فرایند کامل درست اجرا میشود. بازخورد هر نمایش نیز باید ثبت شود تا اصلاح نقص با درخواست قابلیت تازه اشتباه نشود.
پیش از استقرار عمومی، کاربران منتخب باید سناریوهای واقعی را امتحان کنند. آموزش، آماده‌سازی داده، تعیین مسیر گزارش خطا و برنامه‌ی بازگشت در صورت بروز مشکل نیز جزو راهاندازی هستند. تحویل موفق زمانی اتفاق می‌افتد که افراد بتوانند کار روزانه را در سامانه انجام دهند و بدانند هنگام مواجهه با مشکل از چه مسیری کمک بگیرند.
مهاجرت از اکسل؛ بخشی که به‌راحتی دست‌کم گرفته میشود
انتقال داده یا Data Migration در ظاهر شبیه وارد کردن چند فایل است، اما دشواری اصلی معمولاً در معنی و کیفیت اطلاعات قرار دارد. ممکن است نام یک مشتری با نگارش‌های مختلف ثبت شده باشد، تاریخ‌ها قالب یکسانی نداشته باشند یا وضعیت یک سفارش فقط با رنگ سلول مشخص شده باشد. نرمافزار جدید نمی‌تواند بدون قاعده‌ی روشن تشخیص دهد کدام برداشت درست است.
پیش از انتقال، باید منابع داده فهرست شوند و سازمان مشخص کند کدام فایل مرجع است. سپس دربارهی حذف رکوردهای تکراری، اصلاح داده‌های ناقص و نگاشت ستون‌های قدیمی به ساختار جدید تصمیم گرفته شود. نگاشت یعنی مشخص کردن اینکه هر داده‌ی قدیمی در کدام بخش سامانه‌ی تازه قرار میگیرد. تصمیم دربارهی اعتبار اطلاعات باید با مشارکت صاحب فرایند انجام شود، نه صرفاً برنامه‌نویس.
لازم نیست همه‌ی تاریخچه با همان جزئیات وارد سامانه شود. گاهی نگهداری بخشی از سوابق در یک آرشیو قابل جست‌وجو مناسب‌تر است. این تصمیم به نیاز عملیاتی و الزامات نگهداری اسناد سازمان بستگی دارد. مهم این است که اطلاعات کنارگذاشته‌شده، محل نگهداری و روش دسترسی به آنها مشخص باشد.
انتقال آزمایشی باید پیش از انتقال نهایی انجام شود و کاربران مسئول، نتیجه را بررسی کنند. همچنین باید معلوم باشد هنگام جابه‌جایی، ثبت اطلاعات جدید در فایل‌های قدیمی چگونه مدیریت میشود. بدون این هماهنگی، حتی انتقال فنی درست هم ممکن است با داده‌های ناقص یا دو نسخهی ناسازگار از واقعیت همراه شود.
اتصال به حسابداری، انبار، پیامک و درگاه پرداخت
سامانه‌ی تازه معمولاً قرار نیست به‌تنهایی کار کند. ممکن است اطلاعات مشتری را به حسابداری بفرستد، موجودی را از انبار بخواند یا بعد از تغییر وضعیت، پیامک ارسال کند. پیش از قیمت‌گذاری باید مشخص شود هر داده در کدام نرمافزار مرجع است، انتقال در چه جهتی انجام میشود و در صورت اختلاف، کدام مقدار اعتبار دارد.
رابط برنامه‌نویسی کاربردی یا API راهی تعریف‌شده برای ارتباط نرم‌افزارهاست. اگر با این مفهوم آشنا نیستید، مطلب API چیست مقدمه‌ی مناسبی است. برای برآورد اتصال، صرف شنیدن اینکه نرمافزار مقصد API دارد کافی نیست؛ باید مستندات، مجوز استفاده، دسترسی آزمایشی و امکانات واقعی آن بررسی شود. ممکن است رابط موجود فقط خواندن اطلاعات را اجازه دهد و امکان ثبت یا اصلاح نداشته باشد.
نبودن API میتواند مسیر اجرا را تغییر دهد. شاید انتقال فایل با قالب توافق‌شده کافی باشد، شاید شرکت تأمین‌کننده نیاز به توسعه‌ی رابط داشته باشد یا بخشی از فرایند فعلاً دستی بماند. دسترسی مستقیم به پایگاه داده یا شبیه‌سازی رفتار کاربر، جایگزین‌هایی هستند که باید محدودیت و شکنندگی آنها بررسی شود؛ نباید خودکار و بدون ارزیابی، راهحل نهایی فرض شوند.
اتصال کامل همچنین باید با قطعی، پاسخ نامعتبر و ارسال تکراری کنار بیاید. لازم است معلوم باشد خطا چگونه ثبت میشود، چه کسی آن را پیگیری میکند و اطلاعات چگونه دوباره ارسال میشوند. هزینهی اتصال فقط مربوط به برقرار شدن اولین ارتباط موفق نیست؛ قابل اعتماد ماندن آن در استفاده‌ی روزانه نیز بخشی از کار است.
گزارش ثابت با گزارشساز چه فرقی دارد؟
گزارش ثابت برای یک پرسش مشخص ساخته میشود: چه درخواستهایی باز ماندهاند، وضعیت سفارشها چیست یا عملکرد هر واحد چگونه بوده است. ممکن است فیلتر تاریخ، شعبه و مسئول داشته باشد، اما تعریف ستونها و محاسبات از قبل روشن است. وقتی نیاز مدیریتی مشخص باشد، چنین گزارشی میتواند پاسخ مستقیم و قابل کنترل بدهد.
گزارشساز یا Report Builder به کاربر امکان میدهد بخشی از ساختار گزارش را خودش انتخاب کند؛ مثلاً ستونها، گروه‌بندی و شرط‌ها را تغییر دهد. این قابلیت به طراحی گسترده‌تری نیاز دارد، چون باید جلوی ترکیب‌های نامعتبر را بگیرد، سطح دسترسی را رعایت کند و اجازه ندهد یک درخواست سنگین، کار سامانه را مختل کند. امکان خروجی گرفتن از اطلاعات حساس نیز باید جداگانه بررسی شود.
داشبورد یا Dashboard خلاصه‌ای بصری از وضعیت است، اما نمودار زیبا جای تعریف دقیق شاخص را نمی‌گیرد. پیش از ساخت باید توافق شود «فروش»، «درخواست معوق» یا «زمان رسیدگی» دقیقاً چگونه محاسبه میشوند. اگر واحدها تعریف متفاوتی داشته باشند، داشبورد فقط اختلاف را آشکارتر میکند. برای نسخهی اول، گزارش‌های مشخصی که به تصمیم واقعی منتهی میشوند می‌توانند از گزارش‌سازی با دامنه‌ی نامعلوم مفیدتر باشند.
نقش‌ها و سطح دسترسی؛ پیچیدگی پشت صفحات ساده
عبارت «هر کس اطلاعات خودش را ببیند» ظاهراً روشن است، اما بلافاصله پرسش‌های دیگری ایجاد میکند. مدیر شعبه فقط اطلاعات شعبه‌ی فعلی را می‌بیند یا سوابق کارکنانی را که جابه‌جا شده‌اند هم دارد؟ جانشین مدیر هنگام مرخصی چه اختیاراتی دارد؟ کارشناس میتواند درخواست تأییدشده را ویرایش کند؟ مسئول مالی اجازه‌ی دیدن توضیحات داخلی واحد عملیات را دارد؟
برای پاسخ، بهتر است جدولی از نقش‌ها و عملیات تهیه شود. مشاهده، ایجاد، ویرایش، تأیید، حذف و خروجی گرفتن، مجوزهای یکسانی نیستند. ممکن است کاربری اجازه‌ی دیدن مبلغ را داشته باشد، اما نتواند آن را تغییر دهد. همچنین محدودهی دسترسی میتواند به شعبه، واحد، پرونده یا وضعیت فرایند وابسته باشد. این قواعد باید در خود سامانه اجرا شوند؛ پنهان کردن یک دکمه به‌تنهایی کافی نیست.
سابقه‌ی حسابرسی یا Audit Log نیز مشخص میکند چه کسی، چه زمانی و چه تغییری انجام داده است. در نرمافزار اختصاصی سازمانی، این سابقه برای پیگیری خطا و پاسخ‌گویی داخلی ارزش دارد. لازم است از ابتدا روشن شود کدام رویدادها ثبت میشوند، چه کسی به آنها دسترسی دارد و چگونه نگهداری میشوند. ثبت رویدادها نباید به جمع‌آوری بی‌دلیل اطلاعات حساس تبدیل شود.
سامانه تحت وب کافی است یا نسخهی موبایل هم لازم دارید؟
سامانه تحت وب از طریق مرورگر در دسترس قرار میگیرد و میتواند برای نمایش مناسب روی تلفن همراه طراحی شود. طراحی واکنشگرا یا Responsive یعنی چیدمان صفحات با اندازهی نمایشگر سازگار شود. اگر کاربران بیشتر فرم تکمیل میکنند، وضعیت میبینند یا درخواست تأیید میکنند، بررسی همین گزینه نقطهی شروع مناسبی است؛ البته تجربهی استفاده باید روی دستگاههای واقعی آزمایش شود.
اپلیکیشن مستقل موبایل زمانی قابل بررسی است که نیاز مشخصی وجود داشته باشد؛ مثلاً استفاده‌ی جدی بدون اینترنت یا وابستگی به امکانات خاص دستگاه. هرکدام از این نیازها باید دقیق توصیف شوند. «نسخهی موبایل هم داشته باشد» برای برآورد کافی نیست، چون ممکن است منظور مدیر فقط خوانا بودن صفحات باشد، در حالی که تیم فنی ساخت محصول جداگانه‌ای را برداشت کند.
اگر اطلاعات در حالت آفلاین ثبت شوند، باید مشخص شود پس از اتصال، تعارض داده‌ها چگونه حل میشود. ساخت و نگهداری نسخههای جداگانه نیز روی آزمون، انتشار و پشتیبانی اثر دارد. انتخاب باید از شرایط کار کاربران بیاید، نه از تصور اینکه هر نرمافزار سازمانی الزاماً به اپلیکیشن نیاز دارد.
نگهداری بعد از تحویل؛ چرا نرمافزار زنده هزینهی ماهانه دارد؟
نرمافزار پس از راهاندازی در محیطی ثابت باقی نمیماند. کاربران تازه اضافه میشوند، حجم اطلاعات تغییر میکند و سرویسهای متصل ممکن است رفتار یا شرایط دسترسی خود را عوض کنند. بهروزرسانی اجزای فنی، بررسی خطاها، مراقبت از نسخههای پشتیبان و رسیدگی به رخدادها، کارهایی ادامهدار هستند. پرداخت هزینهی ساخت به معنی انجام همیشگی این فعالیتها نیست.
در کیبووب، سه ماه نخست پشتیبانی رایگان است و پس از آن، پشتیبانی با قرارداد ماهانه ادامه پیدا میکند. با این حال، واژه‌ی پشتیبانی باید در قرارداد معنی مشخصی داشته باشد. رفع اشکال، آموزش کاربر، رسیدگی به سرور و افزودن قابلیت جدید خدمات یکسانی نیستند. باید معلوم شود کدام موارد پوشش داده میشوند و برای موارد خارج از محدوده چگونه توافق میشود.
زمان پاسخ‌گویی نیز با زمان رفع مشکل فرق دارد. ممکن است تیم بتواند دریافت یک خطا را اعلام و بررسی را شروع کند، اما حل آن به همکاری تأمین‌کننده‌ی دیگری وابسته باشد. قرارداد باید مسیر ثبت درخواست، اولویت‌بندی رخدادها و مسئولیت طرفین را روشن کند. برای سازمان، داشتن روال قابل پیگیری از وعده‌ی مبهم «همیشه در دسترس هستیم» مفیدتر است.
پشتیبان‌گیری هم صرفاً تولید فایل نیست. باید امکان بازیابی اطلاعات بررسی شود و سازمان بداند در صورت خرابی، چه داده‌ای و از چه زمانی قابل بازگردانی است. مسئولیت این کار نباید بین تیم نرمافزار، شرکت میزبان و واحد داخلی بدون صاحب بماند.
مالکیت کد و مستندات؛ اگر پیمانکار تغییر کرد چه میشود؟
پیش از قرارداد، روشن کنید حقوق استفاده و مالکیت بخشهای اختصاصی نرمافزار چگونه تعریف میشود و چه چیزهایی تحویل میگیرید. بعضی اجزا ممکن است متعلق به کتابخانهها یا محصولات دارای مجوز جداگانه باشند. عبارت کلی «مالکیت کامل» بدون توضیح دربارهی این اجزا، کد منبع و شرایط تحویل، برای تصمیمگیری کافی نیست.
کد منبع یا Source Code بخشی از امکان ادامه‌ی کار است، اما به‌تنهایی کافی نیست. تیم جایگزین به راهنمای راهاندازی، ساختار داده، توضیح اتصال‌ها، روش انتشار و اطلاعات مربوط به وابستگی‌ها نیاز دارد. حساب‌های میزبانی و سرویسهای بیرونی نیز باید وضعیت مالکیت و دسترسی روشنی داشته باشند. اطلاعات ورود باید از مسیر امن تحویل داده شوند و در مستندات عمومی قرار نگیرند.
برای پایان همکاری هم از ابتدا روال داشته باشید: خروجی گرفتن از داده‌ها، تحویل آخرین نسخه، انتقال دسترسی‌ها و توضیح وضعیت کارهای باز. امکان انتقال به معنی بی‌هزینه بودن تغییر تیم نیست؛ تیم تازه همچنان برای شناخت سامانه زمان می‌خواهد. اما مستندات قابل استفاده و دسترسی‌های منظم می‌توانند وابستگی غیرضروری سازمان به افراد مشخص را کاهش دهند.
کجا اصلاً نباید اختصاصی ساخت؟
اگر یک نرمافزار آمادهی ایرانی یا خارجی، نیازهای اصلی شما را با شرایط قابل قبول پاسخ میدهد، خرید اشتراک آن اغلب تصمیم درستتری است. سازمان مجبور نیست هزینهی ساخت، آزمون و نگهداری قابلیتهایی را بپردازد که از قبل وجود دارند. ارزیابی ابزار آماده باید شامل تناسب فرایند، امکان خروجی داده، کیفیت پشتیبانی، محدودیت دسترسی و شرایط استفاده باشد؛ صرف داخلی یا خارجی بودن، پاسخ نهایی نیست.
وقتی فرایند در خود سازمان هنوز ثابت نشده، طراحی سامانه اختصاصی میتواند تغییرهای پی‌درپی را به هزینهی توسعه تبدیل کند. اگر مدیران هنوز دربارهی مسئول تأیید یا قواعد رسیدگی توافق ندارند، بهتر است ابتدا فرایند در مقیاسی محدود امتحان و اصلاح شود. نرمافزار نمی‌تواند به جای مدیریت، دربارهی مسئولیت‌ها تصمیم بگیرد.
وقتی تعداد کاربران کم است و پیچیدگی کار محدود، هزینهی اختصاصی‌سازی ممکن است توجیه نداشته باشد. تعداد کم به‌تنهایی مانع قطعی نیست؛ ممکن است همان کاربران فرایندی حساس و خاص داشته باشند. اما برای کار ساده، یک ابزار آماده یا ترکیبی منظم از ابزارهای موجود میتواند انتخاب متناسب‌تری باشد.
وقتی تیم یا بودجه‌ای برای نگهداری وجود ندارد نیز باید محتاط بود. لازم نیست حتماً برنامه‌نویس داخلی استخدام کنید، اما مسئول سازمانی، مسیر پشتیبانی و بودجه‌ی ادامه‌ی کار باید مشخص باشد. سامانه‌ای که پس از تحویل بدون متولی می‌ماند، ممکن است خودش به مسئله‌ی تازه‌ای تبدیل شود.
در نهایت، اختصاصی ساختن زمانی قابل دفاع است که تفاوت فرایند شما ارزش هزینهی توسعه و نگهداری را داشته باشد. حتی آن زمان هم لازم نیست همه‌چیز از ابتدا ساخته شود. حفظ حسابداری آماده و ساخت فقط بخش عملیاتی خاص شرکت، میتواند انتخاب منطقی‌تری از جایگزین کردن تمام ابزارها باشد.
نرمافزار سفارشی و سایت اختصاصی چه مرزی دارند؟
سایت معمولاً با معرفی خدمات، انتشار محتوا، جذب مخاطب یا فروش سروکار دارد. نرمافزار سازمانی بیشتر برای اجرای فرایند، ثبت داده و هماهنگی کار افراد ساخته میشود. این مرز مطلق نیست؛ یک سایت میتواند پنل مشتری و فرایند عملیاتی داشته باشد. معیار مناسب‌تر، نوع مسئله و قواعد پشت صفحات است، نه صرفاً اینکه محصول در مرورگر باز میشود.
در کیبووب، نرمافزار سفارشی از ۱۵۰ میلیون تومان شروع میشود و سایت اختصاصی با لاراول از ۲۵۰ میلیون تومان. این اعداد برای دامنه‌های متفاوت خدمات هستند و نباید از آنها نتیجه گرفت که هر نرمافزار سازمانی از هر سایت اختصاصی ارزان‌تر است. برای بررسی مسیر وب‌سایت اختصاصی، صفحه‌ی طراحی سایت با لاراول به همان دسته از نیازها مربوط است.
طراحی سایت وردپرس از ۴۰ میلیون تومان شروع میشود و پکیج حرفه‌ای آن ۸۰ میلیون تومان است. اگر نیاز اصلی معرفی شرکت و مدیریت محتوا باشد، بررسی این مسیر پیش از سفارش توسعه‌ی اختصاصی منطقی است. جزئیات این دسته از خدمات را می‌توانید در صفحه‌ی قیمت طراحی سایت بررسی کنید.
لاراول یک چارچوب توسعه یا Framework است؛ مجموعه‌ای از امکانات پایه برای ساخت نرمافزار وب. انتخاب آن به‌تنهایی کیفیت، امنیت یا هزینه را تعیین نمی‌کند. مطلب لاراول برای سامانه‌های سازمانی به بررسی این گزینه کمک میکند، اما تصمیم نهایی باید با توجه به نیاز پروژه و توان تیم نگهداری گرفته شود.
هزینهی واقعی مالکیت در دو سال را ببینید
هزینهی کل مالکیت یا Total Cost of Ownership فقط مبلغ قرارداد ساخت نیست. برای نگاه دوساله، هزینهی کشف و توسعه را کنار میزبانی، پشتیبانی، سرویسهای جانبی، آموزش، پاک‌سازی داده و تغییرات احتمالی قرار دهید. وقت کارکنان سازمان برای توضیح نیازها، آزمون و یادگیری نیز منبعی واقعی است، حتی اگر مستقیماً در فاکتور پیمانکار دیده نشود.
برای مقایسه‌ی گزینه‌ها، یک فهرست مشترک تهیه کنید و مشخص کنید هر هزینه بر عهده‌ی چه کسی است. در ابزار آماده ممکن است هزینه به اشتراک، کاربران یا امکانات وابسته باشد؛ در سامانه‌ی اختصاصی، توسعه و نگهداری سهم متفاوتی دارند. تا زمانی که محدوده و شرایط استفاده یکسان نشده، مقایسه‌ی مبلغ اشتراک با مبلغ ساخت نتیجه‌ی روشنی نمی‌دهد.
ارزش مورد انتظار را هم قابل بررسی تعریف کنید. کاهش ثبت تکراری، مشخص شدن وضعیت پرونده‌ها یا دسترسی به گزارش قابل اعتماد، اهدافی هستند که می‌توان وضعیت قبل و بعدشان را مشاهده کرد. لازم نیست برای توجیه خرید، درصدهای حدسی یا وعده‌ی بازگشت سرمایه بسازید. اگر داده‌ی کافی ندارید، ابتدا وضعیت فعلی را ثبت کنید و بعد دربارهی نتیجه قضاوت کنید.
همچنین مشخص کنید اگر اولویت سازمان عوض شد، پروژه در کدام نقطه میتواند با یک خروجی قابل استفاده متوقف شود. تقسیم کار به مراحل معنادار، امکان کنترل تعهد مالی را فراهم میکند. بودجه‌ی دوساله باید با برنامه‌ی استفاده و نگهداری هماهنگ باشد، نه فقط با توان پرداخت صورت‌حساب آغاز پروژه.
پیش از امضای قرارداد چه پرسش‌هایی از تیم فنی بپرسید؟
جلسه‌ی قرارداد جای آزمودن دانش فنی مدیر نیست. هدف این است که تعهدها، فرض‌ها و مسئولیت‌ها قابل فهم باشند. اگر پاسخ‌ها فقط با اصطلاحات پیچیده داده میشوند، درخواست کنید نتیجه‌ی عملی هر تصمیم با یک نمونه از کار سازمان توضیح داده شود. پرسش‌های زیر می‌توانند پایه‌ی گفت‌وگو باشند:
- مسئله‌ی اصلی ما را چگونه فهمیده‌اید و کدام بخش آن با نرمافزار حل میشود؟
- چه ابزارهای آماده‌ای بررسی شده‌اند و دلیل پیشنهاد ساخت اختصاصی چیست؟
- فاز کشف چه خروجی‌هایی دارد و قیمت نهایی بر اساس چه فرض‌هایی تعیین میشود؟
- نسخهی اول دقیقاً شامل چه کارهایی است و چه درخواستهایی خارج از محدوده هستند؟
- برای پذیرش هر بخش چه سناریوهایی را با هم بررسی می‌کنیم؟
- کدام اطلاعات یا تصمیم‌ها باید از طرف سازمان ما آماده شوند؟
- وضعیت داده‌های اکسل چگونه بررسی میشود و مسئول تأیید اطلاعات انتقال‌یافته کیست؟
- اتصال به نرم‌افزارهای موجود به چه مجوزها و همکاری‌هایی وابسته است؟
- اگر نرمافزار مقصد API مناسب نداشت، گزینه‌های جایگزین و اثرشان بر هزینه چیست؟
- تغییر نیاز در میانه‌ی پروژه چگونه ثبت، برآورد و تأیید میشود؟
- پشتیبانی چه مواردی را پوشش میدهد و مرز آن با توسعه‌ی قابلیت تازه کجاست؟
- مسئول پشتیبان‌گیری، بررسی بازیابی و رسیدگی به رخدادهای امنیتی چه کسی است؟
- کد، مستندات، داده‌ها و حساب‌های سرویس‌ها با چه شرایطی در اختیار سازمان قرار می‌گیرند؟
- اگر همکاری پایان یافت، انتقال سامانه به تیم دیگر چگونه انجام میشود؟
- چه هزینه‌های جاری یا وابستگی‌هایی خارج از مبلغ پیشنهادی وجود دارند؟
پاسخ‌های مهم باید وارد پیشنهاد مکتوب و قرارداد شوند. توافق شفاهی دربارهی موضوع‌هایی مثل مالکیت داده، انتقال اطلاعات یا پشتیبانی، هنگام تغییر اعضای تیم به‌سادگی مبهم میشود. سند مناسب قرار نیست طولانی و پیچیده باشد؛ باید برای هر دو طرف روشن کند چه چیزی انتظار می‌رود و اختلاف برداشت چگونه حل خواهد شد.
جمع‌بندی؛ تصمیم را از فرایند شروع کنید
ساخت نرم افزار سفارشی زمانی ارزش بررسی دارد که مشکل سازمان روشن باشد، ابزار آماده پاسخ مناسبی ندهد و مسئولیت استفاده و نگهداری مشخص باشد. عدد شروع، فقط نقطهی ورود به گفت‌وگوست. مبلغ قابل اتکا از محدودهی روشن، شناخت داده‌ها، بررسی اتصال‌ها و توافق بر معیارهای تحویل به دست می‌آید.
برای یک شرکت در شیراز، امکان گفت‌وگوی نزدیک با تیم اجرا میتواند به شناخت فرایند کمک کند، اما نزدیکی جغرافیایی جای قرارداد روشن و مستندات را نمی‌گیرد. هنگام بررسی نرمافزار سفارشی در شیراز، از تیم بخواهید نشان دهد مسئله‌ی شما را فهمیده و میتواند نسخه‌ای محدود اما قابل استفاده تعریف کند.
برای شروع گفت‌وگو با کیبووب لازم نیست سند فنی آماده داشته باشید. شرح کار فعلی، نمونه‌ی فرم‌ها بدون اطلاعات محرمانه، فهرست نرم‌افزارهای موجود و توضیح نقاط مشکل‌دار کافی است تا بررسی اولیه جهت پیدا کند. می‌توانید این اطلاعات را در فرم بریف پروژه ثبت کنید. نتیجه‌ی بررسی باید روشن کند که توسعه‌ی اختصاصی مناسب است، محدودهی آن چه باشد یا بهتر است فعلاً سراغ یک ابزار آماده و اصلاح فرایند بروید.
