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

چه زمانی نرم‌افزار سفارشی به‌صرفه است؟

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

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

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

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

تحلیل فرایند پیش از کدنویسی چه چیزی را روشن می‌کند؟

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

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

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

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

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

چرا نسخه‌ی اول باید کوچک باشد؟

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

کوچک بودن نسخه‌ی اول به‌معنای ناقص بودن نیست. نسخه‌ی اول باید یک جریان کاری را کامل و قابل اتکا انجام دهد؛ مثلاً «ثبت درخواست مشتری تا تخصیص به کارشناس و بستن پرونده». بقیه‌ی جریان‌ها بعد از پایدار شدن همین یکی اضافه می‌شوند.

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

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

هزینه‌ی نرم‌افزار سفارشی چطور برآورد می‌شود؟

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

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

دو ردیف بیشتر از همه فراموش می‌شوند: مهاجرت داده‌ی قدیمی و آموزش کاربران. هر دو مستقیماً روی موفقیت پروژه اثر دارند و هیچ‌کدام رایگان نیستند.

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

تیم توسعه را با چه معیارهایی انتخاب کنیم؟

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

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

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

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

قرارداد توسعه‌ی نرم‌افزار چه چیزهایی باید داشته باشد؟

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

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

برای تغییر دامنه سازوکار داشته باشید. تغییر در پروژه‌ی نرم‌افزاری اجتناب‌ناپذیر است؛ چیزی که باید کنترل شود، ثبت، برآورد و تأیید تغییر است، نه ممنوع کردن آن.

معیار تحویل را قابل آزمون تعریف کنید. «سامانه تحویل شد» تعریف مناقشه‌برانگیزی است؛ «کاربر با نقش انباردار می‌تواند رسید ورود کالا ثبت کند و گزارش موجودی بگیرد» تعریفی است که در جلسه‌ی تحویل قابل بررسی است.

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

داده‌ی قدیمی چطور به سامانه‌ی جدید منتقل می‌شود؟

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

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

همیشه یک انتقال آزمایشی کامل انجام دهید و چند نمونه‌ی واقعی را دستی مقایسه کنید. بررسی تعداد رکورد کافی نیست؛ باید محتوای رکوردها هم درست باشد.

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

چطور مطمئن شویم کارکنان از نرم‌افزار جدید استفاده می‌کنند؟

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

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

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

در ماه اول، بازخوردها را جمع کنید و چند بهبود کوچک و سریع اعمال کنید. دیدن اینکه پیشنهادشان اجرا شده، بیشترین اثر را روی پذیرش سامانه دارد.

بعد از تحویل، نگه‌داری شامل چه چیزهایی است؟

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

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

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

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

نرم‌افزار آماده یا سفارشی؛ معیار تصمیم چیست؟

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

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

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

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

یکپارچگی با سامانه‌های موجود چطور مدیریت می‌شود؟

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

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

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

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

• فهرست سامانه‌های موجود و داده‌ی مشترکشان
• تعیین منبع حقیقت برای هر موجودیت داده
• شروع با اتصال‌های فقط‌خواندنی
• صف و تلاش مجدد برای اتصال‌های ناموفق
• ثبت خطا و هشدار برای قطعی‌های طولانی

شایع‌ترین دلایل شکست پروژه‌های نرم‌افزار سفارشی چیست؟

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

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

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

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