اجتناب از 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) پشتیبانی می‌کنند. با به کارگیری اونها می‌تونید برخی نیازهای سازمان رو به کارشناسان داخلی بسپارید.
• کوچک کردن پروژه‌ها: گاهی بهتره به جای یک پروژه بزرگ، چند تا پروژه کوچک‌تر با مرزهای شفاف تعریف کنیم. قطعات کوچکتر راحت‌تر قابل جایگزینی هستند. به همین دلیل معماری میکروسرویس رو به عنوان راهکار اجتناب از قفل شدن به فروشنده معرفی می‌کنند. البته تعدد پروژه‌ها سربار مدیریت رو بیشتر می‌کنه.
• مستندسازی و استاندارد کردن: لازمه که از همه فروشنده‌ها مستنداتی رو بخواهید و یک سری استانداردهای فنی رو طراحی کنید که همه ملزم به رعایت کردنش باشند. یکی از کمک‌هایی که ما در تیم چکاپ به سازمانها و پیمانکاران‌شون می‌کنیم کمک به مستندسازی، طراحی استانداردهای فنی و ارزیابی میزان رعایت اونهاست.

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

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

دعوت به همکاری

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

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