انتخاب فناوری
نرمافزار آماده یا توسعه اختصاصی؛ کدام انتخاب بهتری است؟
چارچوبی عملی برای تصمیمگیری، بهجای انتخاب بر اساس قیمت اولیه
این تصمیم معمولاً با یک سؤال اشتباه شروع میشود: «کدام ارزانتر است؟» سؤال درست این است: «کدامیک، فرایند ما را در پنج سال آینده کمتر محدود میکند؟» این مقاله هشت معیار مشخص برای این تصمیم ارائه میدهد، سه اشتباه رایج را نشان میدهد و توضیح میدهد چرا پاسخ واقعی برای بیشتر سازمانها، نه این است و نه آن — بلکه ترکیبی از هر دو.
چرا این تصمیم اینقدر سخت میشود
در جلسهای که برای این تصمیم تشکیل میشود، معمولاً سه نفر با سه معیار متفاوت نشستهاند: مدیر مالی به قیمت نگاه میکند، مدیر عملیات به سرعت راهاندازی، و مدیر فنی به قابلیت توسعه. هر سه هم درست میگویند و دقیقاً به همین دلیل جلسه به نتیجه نمیرسد.
مسئله این است که «آماده» و «اختصاصی» دو محصولِ رقیب نیستند؛ دو مدل ریسک متفاوتاند:
▪ در نرمافزار آماده، شما هزینه را قطعی میکنید و انعطاف را ریسک میکنید.
▪ در توسعه اختصاصی، شما انعطاف را قطعی میکنید و اجرا را ریسک میکنید.
هیچکدام ذاتاً بهتر نیست. سؤال این است که کدام ریسک را میتوانید بهتر مدیریت کنید.
هشت معیار برای تصمیمگیری
برای هر معیار، به سازمان خودتان نمرهی ۱ تا ۵ بدهید. در انتها جمع میزنیم.
۱. میزان تمایز فرایند. اگر فرایند شما همان کاری است که همهی رقبا انجام میدهند، آماده کافی است. اگر بخشی از فرایند شما همان چیزی است که مشتری بهخاطرش شما را انتخاب میکند، آن بخش نباید در قالب کسی دیگر ریخته شود. نمرهی بالاتر یعنی تمایز بیشتر و گرایش به اختصاصی.
۲. نرخ تغییر قواعد کسبوکار. هر چند وقت یکبار قاعدهای عوض میشود؟ اگر مدل پورسانت، شرایط تخفیف یا گردش تأییدتان سالی چند بار تغییر میکند، در محصول آماده هر تغییر یعنی یک درخواست، یک مذاکره و یک انتظار.
۳. عمق یکپارچگی مورد نیاز. اتصال به سامانههای حاکمیتی، درگاههای پرداخت، سامانههای حملونقل یا سیستمهای موجود خودتان. محصولات آماده معمولاً APIهای محدود و از پیش تعیینشده دارند؛ اگر یکپارچگی برای شما حیاتی است، این محدودیت زود خودش را نشان میدهد.
۴. حساسیت مالکیت داده. دادهی شما کجا ذخیره میشود، چه کسی به آن دسترسی دارد و اگر فردا خواستید مهاجرت کنید، خروج داده چقدر ممکن است؟ در بسیاری از محصولات، ورود داده آسان و خروج آن گران است.
۵. تعداد کاربر و پیچیدگی نقشها. اگر پنج نفر با سیستم کار میکنند، فرم شلوغ قابل تحمل است. اگر صد نفر در ده نقش مختلف کار میکنند، هر کلیک اضافه در روز، ضرب در صد میشود و به هزینهی واقعی تبدیل میشود.
۶. افق زمانی راهاندازی. اگر باید ظرف یک ماه راه بیفتید، محصول آماده تقریباً همیشه پاسخ درست است — حتی اگر موقتی باشد. توسعه اختصاصی برای افق سهماهه به بالا معنا پیدا میکند.
۷. بلوغ و ثبات سازمان. اگر فرایندهایتان هنوز در حال شکلگیریاند، نرمافزار اختصاصی، بیثباتی را کدنویسی میکند. اول فرایند را تثبیت کنید، بعد آن را سیستمی کنید.
۸. توان مدیریت پروژه. توسعه اختصاصی یک خرید نیست، یک همکاری است. اگر کسی در سازمان مسئولیت تصمیمگیری، بازخورد و تحویل را برعهده نگیرد، بهترین تیم توسعه هم نتیجهی خوبی تحویل نمیدهد.
|
جمع نمرات |
تفسیر |
|
زیر ۲۰ |
نرمافزار آماده انتخاب منطقی است |
|
۲۰ تا ۲۸ |
رویکرد ترکیبی؛ اختصاصی فقط برای فرایندهای متمایز |
|
بالای ۲۸ |
توسعه اختصاصی احتمالاً کمهزینهترین مسیر بلندمدت است |
نرمافزار آماده کجا واقعاً برنده است
انصاف حکم میکند این بخش صادقانه نوشته شود. محصول آماده در این موقعیتها گزینهی بهتری است:
▪ فرایند استاندارد و کمتغییر: حقوقودستمزد، حسابداری پایه، اتوماسیون اداری عمومی. اینجا رقابت بر سر ویژگی نیست، بر سر بلوغ است — و محصول آماده سالها بلوغ پشت سرش دارد.
▪ راهاندازی سریع: وقتی هزینهی نداشتن سیستم از هزینهی سیستم ناقص بیشتر است.
▪ بودجهی محدود در شروع: هزینهی ورود پایینتر است، حتی اگر هزینهی کل بالاتر باشد.
▪ نبود تیم فنی یا مالک محصول: اگر کسی نیست که پروژه را هدایت کند، خرید یک محصول پشتیبانیشده انتخاب مسئولانهتری است.
یک نکتهی مهم: انتخاب محصول آماده را بهعنوان تصمیم موقت هم میشود گرفت. بسیاری از سازمانهای موفق با محصول آماده شروع کردهاند و وقتی فرایندشان تثبیت شد و محدودیتها مشخص شد، بخشهای حیاتی را اختصاصی ساختهاند. این عقبنشینی نیست؛ توالی درست است.
توسعه اختصاصی کجا واقعاً برنده است
▪ وقتی فرایند، خودِ مزیت است: روش قیمتگذاری، مدل تخصیص، قواعد اولویتبندی. اینها را نمیشود از قفسه خرید.
▪ وقتی یکپارچگی، قلب کار است: سامانهای که باید بین انبار، فروش، حسابداری و یک سامانهی بیرونی بنشیند و همه را هماهنگ کند.
▪ وقتی سرعت تغییر اهمیت دارد: بازاری که هر فصل قواعدش عوض میشود، با نرمافزاری که سالی یک نسخه میدهد سازگار نیست.
▪ وقتی مقیاس کاربری بالاست: صرفهجویی چند ثانیهای در هر تراکنش، در مقیاس بزرگ به عدد قابل توجهی تبدیل میشود.
▪ وقتی میخواهید دارایی بسازید: کد و دادهای که در پایان پروژه مال شماست، خودش بخشی از ارزش سازمان است.
سه اشتباه رایج در این تصمیم
اشتباه اول: مقایسهی قیمت اولیه بهجای هزینهی کل مالکیت
لایسنس اولیه فقط نقطهی شروع است. تمدید سالانه، ماژولهای جانبی، هزینهی هر سفارشیسازی، هزینهی آموزش، هزینهی ساعتهایی که کاربران صرف دور زدن سیستم میکنند و هزینهی مهاجرت در آینده را در افق سه تا پنج ساله جمع بزنید. عدد نهایی معمولاً با آنچه در پیشفاکتور دیدهاید فاصلهی زیادی دارد.
اشتباه دوم: خرید بر اساس فهرست امکانات
جدول مقایسهای که دویست ویژگی را تیک میزند، تقریباً بیفایده است. سؤال درست این نیست که «چه چیزهایی دارد»، بلکه این است که «آیا این پنج فرایند حیاتی من را دقیقاً همانطور که هستند پشتیبانی میکند؟» پنج فرایند اصلیتان را بنویسید و از فروشنده بخواهید همانها را در دموی زنده اجرا کند.
اشتباه سوم: تصمیمگیری بدون تحلیل فرایند
بسیاری از سازمانها پیش از آنکه بدانند فرایندشان دقیقاً چیست، برای آن نرمافزار انتخاب میکنند. نتیجه این است که بعداً میفهمند مشکل، انتخاب اشتباه نبوده؛ نداشتن تصویر روشن از فرایند بوده. دو هفته تحلیل فرایند، پیش از هر تصمیمی، ارزانترین سرمایهگذاری این مسیر است.
پاسخ واقعی معمولاً ترکیبی است
در عمل، بیشتر سازمانهای موفقی که با آنها کار کردهایم به یک الگو رسیدهاند:
۱. لایهی استاندارد را بخرید. حسابداری پایه، حقوقودستمزد، اتوماسیون اداری. اینجا نوآوری معنا ندارد.
۲. لایهی متمایز را بسازید. همان بخشی که مزیت رقابتی شماست: مدل فروش، مدیریت تخصیص، گردش عملیات خاص شما.
۳. این دو را به هم وصل کنید. با یکپارچهسازی درست، از طریق API یا لایهی همگامسازی، بهطوری که داده یکبار وارد شود و همهجا معتبر باشد.
شرط موفقیت رویکرد ترکیبی یک چیز است: مرزها باید از ابتدا روشن باشند — کدام سامانه مرجع کدام داده است.
چکلیست پیش از تصمیم
پیش از امضای هر قراردادی، این هفت سؤال را بپرسید:
▪ پنج فرایند حیاتی من کداماند و هر گزینه دقیقاً چطور آنها را پوشش میدهد؟
▪ هزینهی کل مالکیت در افق پنج ساله برای هر گزینه چقدر است؟
▪ اگر سه سال بعد بخواهم مهاجرت کنم، دادهام چطور خارج میشود و با چه هزینهای؟
▪ برای یک تغییر متوسط در قواعد کسبوکار، چقدر زمان و هزینه لازم است؟
▪ امکان اتصال به سامانههای موجود و حاکمیتی چگونه فراهم میشود؟
▪ مالک محصول در سازمان من چه کسی است و چقدر زمان دارد؟
▪ در بدترین حالت (تأخیر، تغییر تیم، تغییر بازار) چه اتفاقی میافتد؟
اگر به بیش از سه سؤال از اینها پاسخ روشن ندارید، هنوز در مرحلهی تحلیل هستید، نه در مرحلهی خرید.
جمعبندی
«آماده یا اختصاصی» یک انتخاب ایدئولوژیک نیست، یک محاسبه است: میان هزینهی قطعی و انعطاف قطعی. اگر فرایندتان استاندارد، پایدار و مشابه رقباست، محصول آماده بخرید و انرژیتان را جای دیگری بگذارید. اگر فرایندتان همان چیزی است که شما را متمایز میکند، آن را به قالب دیگری تحمیل نکنید.
و اگر مثل بیشتر سازمانها هر دو وضعیت را دارید، مرزها را روشن کنید و از هر کدام در جای درستش استفاده کنید.
در فناوری اطلاعات گارنت بارها هر دو طرف این تصمیم را دیدهایم — هم سازمانهایی که بیدلیل اختصاصی ساختند و هم سازمانهایی که سالها هزینهی محدودیت یک محصول آماده را پرداختند. کار را با تحلیل فرایند شروع میکنیم و اگر نتیجهی تحلیل این باشد که به توسعه اختصاصی نیاز ندارید، همان را میگوییم.
متن کامل مقالات و نمونهکارها: garnetapp.ir
در ادامهی این مجموعه
▪ مراحل تحلیل، طراحی و توسعه یک نرمافزار سازمانی
▪ هزینه توسعه نرمافزار اختصاصی چگونه محاسبه میشود؟
▪ چگونه یک پروژه نرمافزاری را بدون شکست اجرا کنیم؟
دیدگاهها (0)