اجتناب از Vendor Lock-in چرا و چگونه؟

فرایند تامین نیازهای نرم‌افزاری سازمان

شما مدیر فناوری اطلاعات (CIO) یک سازمان هستید؟ اگر باشید حتماً هر روز و هر شب واحدهای سازمان برای پیش‌برد بهتر کارهایشان از شما نرم‌افزار می‌خواهند. در واقع یکی از وظایف اصلی CIO تامین نیازهای نرم‌افزاری سازمان است. شما باید تصمیم بگیرید چه نیازی را چگونه تامین کنید. کجا بروید سراغ خرید بسته‌های نرم‌افزاری آماده؟ چه زمانی پروژه تولید نرم‌افزار سفارشی تعریف کنید؟ چه مواردی را به تیم توسعه داخل سازمان بسپارید؟ کجا از سرویس‌های آماده (SaaS) استفاده کنید؟ تا کجا می‌شود به BPMS یا Low Code Platform اتکا کرد؟ کی از شرکت‌های بزرگ و کجا از شرکت‌های کوچک کمک بگیرید؟ مزیت دانشگاه‌ها و پژوهشگاه‌ها در چه جور کارهایی است؟

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

قفل شدن به فروشنده (Vendor Lock-in)

به عنوان یک CIO دانش و تجربه ما دایماً در حال رشد است. طبیعی است که به مرور متوجه برخی اشتباهاتمان شویم. مثلاً ممکن است جایی که باید یک بسته نرم‌افزاری برای سازمانی می‌خریدیم یک پروژه سفارشی تعریف کرده باشیم. حتی اگر اشتباهی نکرده باشیم تغییر نیازهای سازمان، اقتضائات جدیدی ایجاد می‌کند. خوب بسم‌الله. هر کاری لازم باشد برای بهتر کردن اوضاع انجام می‌دهیم. هدف جدید و مسیر رسیدن بهش مشخص می‌شود و راه می‌افتیم. راه می‌افتیم مگر اینکه دست و پامون بسته شده باشد. محدودیت‌های متنوعی می‌توانند مانع حرکت ما شوند. بودجه،‌ بوروکراسی، تضاد منافع و غیره. یکی از این محدودیت‌ها هست که می‌تواند مستقیماً به میزان درایت CIO برگردد و آن چیزی نیست به جز «قفل شدن به فروشنده» یا به قول خارجی‌ها Vendor Lock-in.

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

شاید باورش سخت باشد ولی مشاهدات ما در تیم چکاپ نشان می‌دهد برخی از مشکلات کلان اقتصادی کشور و زمینه‌های فساد یا ناکارآمدی سازمان‌ها به Vendor Lock-in ارتباط دارند. در حدی که بعضاً کار به مجلس و سران قوا رسیده است.

آثار قفل‌شدن به فروشنده

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

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

تکنیک‌های اجتناب از قفل شدن به فروشنده

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

• حفظ مالکیت داده: بدترین نوع قفل شدنی که مشاهده کردیم در شرایطی رخ داده که سازمان به داده خودش دسترسی نداشته. تولید یک نرم‌افزار مشابه سخت است ولی تولید داده‌های قبلی معمولاً غیرممکن است.
• تحویل گرفتن کدهای منبع: اگر نرم‌افزار سفارشی تهیه کردید به شیوه مطمئنی کدهای منبع را تحویل بگیرد، طوری که مطمئن باشید همیشه کد آخرین نسخه نصب شده را دارید.
• همکاری موازی با چند فروشنده: برای برخی از موضوعات می‌شود همزمان از چند فروشنده استفاده کرد. مثلاً می‌شود همزمان از دو شرکت، سرویس زیرساخت ابری گرفت.
• استفاده از محصولات متن‌باز معتبر: احتمال اینکه بتونید برای یک محصول متن‌باز معتبر یک سرویس دهنده جدید پیدا کنید بیشتر است تا یک محصول تجاری.
• مستقل بودن سرویس‌دهنده انباره داده و هوش تجاری: در این دوره زمونه سازمان بدون انباره داده و هوش‌تجاری مثل زنبور بی‌عسل می‌ماند. دغدغه‌های هوش تجاری را از دل پروژه‌ها بیرون بکشید و یک پیمانکار مستقل براش انتخاب کنید. اینطوری یک کپی دیگر از داده‌ها خواهید داشت و تیم دیگری که نسبت به آن‌ها شناخت دارد. البته این کار مزایای دیگری هم دارد که در این مقال نمی‌گنجد.
• مستقل بودن سرویس‌دهنده زیرساخت ابری: نگویید که «معماری میکروسرویس» را در تعریف همه پروژه‌هایتان نمی‌گنجانید. لازمه معماری میکروسرویس داشتن «زیرساخت ابری» هست. راه‌اندازی زیرساخت ابری را از محدوده پروژه‌ها خارج کنید و به یک یا چند سرویس‌دهنده مستقل بسپارید که به تولیدکنندگان نرم‌افزار سرویس می‌دهد. اینطوری ضمن اینکه به تخصص‌گرایی،‌ کیفیت سرویس، کاهش هزینه‌ها و مدیریت بهینه‌تر منابع کمک می‌شود، با ایجاد یک برش افقی در مسئولیت‌ها موجب استاندارد شدن فرایند نصب و راه‌اندازی و شفاف شدن ابعادی از معماری خواهیم شد. البته مخاطراتی هم دارد که باید کنترلش کنیم.
• استفاده از Low Code Platformها: برخی ابزارها، از توسعه سیستم با دانش کم برنامه‌نویسی (Citizen Development) پشتیبانی می‌کنند. با به کارگیری آن‌ها می‌توانید برخی نیازهای سازمان را به کارشناسان داخلی بسپارید.
• کوچک کردن پروژه‌ها: گاهی بهتر است به جای یک پروژه بزرگ، چند تا پروژه کوچک‌تر با مرزهای شفاف تعریف کنیم. قطعات کوچکتر راحت‌تر قابل جایگزینی هستند. به همین دلیل معماری میکروسرویس را به عنوان راهکار اجتناب از قفل شدن به فروشنده معرفی می‌کنند. البته تعدد پروژه‌ها سربار مدیریت رو بیشتر می‌کند.
• مستندسازی و استاندارد کردن: لازم است که از همه فروشنده‌ها مستنداتی را بخواهید و یک سری استانداردهای فنی را طراحی کنید که همه ملزم به رعایت کردنش باشند. یکی از کمک‌هایی که ما در تیم چکاپ به سازمان‌ها و پیمانکارانشان می‌کنیم کمک به مستندسازی، طراحی استانداردهای فنی و ارزیابی میزان رعایت آن‌هاست.

از قفل شدن اجتناب کنید تا بتوانید بیشتر با یک فروشنده ادامه بدهید!

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