وقتی پشتیبانی یک نرمافزار متوقف میشود؛ تجربهای از یک مهاجرت دو ساله
یکی از تجربههای جالبی که در پروژههای نرمافزاری داشتهام، مربوط به یک شرکت تعاونی بود که از ابتدای فعالیت خود، از یک نرمافزار حسابداری و صندوق استفاده میکرد. این نرمافزار سالها در مجموعه مورد استفاده قرار گرفته بود و اطلاعات زیادی نیز در طول این سالها در آن ثبت شده بود.
با گذشت زمان، مدیریت شرکت از کند شدن نرمافزار، بروز خطاهای مختلف و همچنین تأخیر در پاسخگویی واحد پشتیبانی ناراضی شده بود. در ابتدا، مشکل کندی نرمافزار بیشتر به زیرساخت شبکه نسبت داده میشد و به مدیریت پیشنهاد شده بود که کابل و کارتهای شبکه و حتی سرور مجموعه تعویض یا ارتقا پیدا کند.
مدیریت شرکت از من خواست وضعیت سختافزار و زیرساخت شبکه را بررسی کنم. پس از بررسی، مشخص شد که شبکه مشکل جدی و غیرعادی ندارد. البته با توجه به افزایش حجم اطلاعات در طول چندین سال، ارتقای سرور را منطقی میدانستم، اما شواهدی وجود نداشت که تعویض کامل تجهیزات شبکه بتواند مشکل کندی نرمافزار را برطرف کند.
با این حال، با توجه به نظر واحد پشتیبان، تجهیزات موردنظر نیز طبق درخواست مدیریت تعویض و سرور ارتقا داده شد. اما نتیجه آن چیزی نبود که انتظار میرفت. نرمافزار همچنان کند بود و تغییرات سختافزاری تأثیر قابل توجهی بر عملکرد آن نداشت.
این موضوع به مرور باعث اختلاف جدی میان مدیریت شرکت و واحد پشتیبانی شد. اختلاف تا جایی پیش رفت که شرکت پشتیبان اعلام کرد دیگر خدمات پشتیبانی ارائه نخواهد کرد و حتی پاسخگوی تماسهای شرکت نیز نبود.
در همین شرایط، نرمافزار با یک خطای مهم مواجه شد و اطلاعات چندین هزار سهامدار در معرض خطر قرار گرفت. مدیریت شرکت بارها برای دریافت کمک با واحد پشتیبانی تماس گرفت، اما پاسخی دریافت نکرد.
شرایط برای شرکت بسیار نگرانکننده بود. اطلاعاتی که طی سالها در سیستم ثبت شده و برای ادامه فعالیت مجموعه حیاتی بود، اکنون در خطر فروپاشی قرار گرفته و حتی دسترسی به پشتیبانی نرمافزار نیز وجود نداشت.
مدیریت شرکت که از قبل شناخت و اعتماد کافی نسبت به من داشت، از من خواست مسئولیت بررسی و رفع مشکل را بر عهده بگیرم و دسترسیهای لازم را نیز در اختیارم قرار داد.
من از ابتدا به آنها توضیح دادم که این کار سادهای نیست و نرمافزار متعلق به مجموعه دیگری است و طبیعتاً پشتیبانی و شناخت کامل سیستم باید توسط سازنده آن انجام شود. اما مدیریت پاسخ داد که دیگر پشتیبانی در دسترس نیست و از من خواست هر کاری که میتوانم برای حل مشکل انجام دهم.
در ادامه، پس از بررسی و تلاش فراوان، مشخص شد که ادامه فعالیت با نرمافزار موجود ریسک بالایی دارد و بهتر است مجموعه به یک نرمافزار جدید مهاجرت کند. این کار برخلاف تصور اولیه، یک انتقال ساده نبود. حجم و ساختار اطلاعات چندین ساله و حساسیت دادهها باعث شد فرآیند انتقال اطلاعات بسیار پیچیده و زمانبر باشد.
در نهایت، فرآیند مهاجرت حدود دو سال طول کشید و پس از طی مراحل مختلف، شرکت توانست از نرمافزار قدیمی خارج شود و فعالیت خود را با سیستم جدید ادامه دهد.
امروز سالهاست که آن شرکت بدون وابستگی به سیستم قبلی و با آرامش بیشتری به فعالیت خود ادامه میدهد.
درسی که این تجربه به من داد
این تجربه برای من فقط یک تجربه فنی نبود. یکی از مهمترین درسهایی که از آن گرفتم این بود که یک کسبوکار نباید خود را به یک نرمافزار یا یک مجموعه پشتیبان وابسته کند.
هنگام انتخاب یک نرمافزار، معمولاً امکانات، قیمت و ظاهر سیستم مورد توجه قرار میگیرد؛ اما موضوعاتی مانند امکان دسترسی به اطلاعات، پشتیبانگیری، مستندسازی، تداوم پشتیبانی و حتی امکان مهاجرت در آینده نیز اهمیت زیادی دارند.
نرمافزاری که سالها اطلاعات حیاتی یک مجموعه را در خود نگهداری میکند، فقط یک ابزار نیست؛ بخشی از زیرساخت آن کسبوکار است.
به همین دلیل، به نظر من هنگام انتخاب یا طراحی یک نرمافزار باید یک سؤال مهم را هم از خودمان بپرسیم:
اگر روزی این نرمافزار دیگر پشتیبانی نشد، آیا هنوز میتوانیم به اطلاعات و کسبوکار خود ادامه دهیم؟
تجربهای که تعریف کردم به من نشان داد پاسخ این سؤال باید خیلی قبلتر از زمانی که چنین بحرانی اتفاق میافتد، مشخص شده باشد.
دیدگاه شما
اگر تجربه یا نظری درباره این مقاله دارید، خوشحال میشوم آن را با من و سایر خوانندگان به اشتراک بگذارید.