ورود یک سامانه جدید به یک سازمان همیشه به معنای شروع از صفر نیست. در بسیاری از سازمانها، از سالها قبل نرمافزارهایی برای امور مالی، منابع انسانی، مکاتبات، پروژهها، خدمات عمومی یا گزارشگیری راهاندازی شدهاند و بخشی از عملیات روزانه همچنان به آنها وابسته است.
در چنین شرایطی، مسئله اصلی دیگر صرفاً «انتخاب سامانه جدید» نیست؛ تصمیم مهمتر این است که با سامانههای موجود چه باید کرد. آیا باید آنها را کنار گذاشت؟ آیا امکان اتصال میان سیستمها وجود دارد؟ یا بهتر است برای مدتی ــ و گاهی حتی بهصورت دائمی ــ چند سامانه در کنار یکدیگر فعالیت کنند؟
علیرغم این که این موضوع یک مسئله کلیدی برای مدیریت سازمان است، اما پاسخ واحدی برای همه سازمانها وجود ندارد. انتخاب میان جایگزینی، اتصال و همزیستی باید بر اساس نقش هر سامانه، کیفیت دادهها، هزینه مهاجرت، الزامات قانونی و معماری کلان سازمان انجام شود.
مسئله از کجا شروع میشود؟
فرض کنید یک سازمان تصمیم میگیرد یک سامانه یکپارچه جدید راهاندازی کند، اما پیش از آن سیستمهای جداگانهای برای حسابداری، منابع انسانی، اتوماسیون اداری یا مدیریت پروژه داشته است.
در ظاهر سه راه وجود دارد:
اما هر یک از این انتخابها پیامدهای متفاوتی برای داده، کاربران، فرایندهای اجرایی و هزینههای آینده دارد.
مشکل زمانی ایجاد میشود که تصمیم بدون شناخت دقیق این وابستگیها گرفته شود. حذف عجولانه یک سامانه میتواند بخشی از عملیات سازمان را مختل کند و از سوی دیگر، حفظ بیدلیل همه سیستمهای قدیمی نیز میتواند همان پراکندگی و چندپارگی قبلی را برای سالها ادامه دهد.
گزینه اول؛ جایگزینی کامل سامانه قبلی
جایگزینی زمانی منطقی است که سامانه جدید بتواند تقریباً تمام مأموریت سامانه قبلی را با کیفیت مناسب پوشش دهد و ادامه استفاده از سیستم قدیمی ارزش قابلتوجهی برای سازمان ایجاد نکند.
در این سناریو، دادههای مورد نیاز منتقل میشوند، کاربران به محیط جدید مهاجرت میکنند و پس از یک دوره انتقال، سامانه قبلی از چرخه عملیاتی خارج میشود.
این مدل چند مزیت مهم دارد:
با این حال، جایگزینی کامل معمولاً پرریسکترین گزینه هم هست.
احتمال دارد سامانه قدیمی سالها دادهی تاریخی داشته باشد، با تجهیزات یا سیستمهای دیگری ارتباط برقرار کرده باشد یا دارای فرایندهایی باشد که در سامانه جدید هنوز معادل دقیقی برای آنها وجود ندارد. مهاجرت داده نیز همیشه به معنای انتقال ساده چند جدول نیست؛ ساختار اطلاعات، شناسهها، اسناد و ارتباط میان سوابق باید حفظ شود.
لذا «این سامانه جدیدتر است» بهتنهایی دلیل کافی برای حذف سیستم قبلی نیست.
چه زمانی جایگزینی انتخاب مناسبی است؟
جایگزینی کامل معمولاً زمانی قابل دفاعتر است که چند شرط همزمان وجود داشته باشد:
در این شرایط، حفظ دو سیستم مشابه معمولاً تنها باعث تولید دادههای موازی و سردرگمی کاربران خواهد شد.
اما حتی در این حالت نیز خاموشکردن سامانه قبلی بهتر است مرحلهای باشد. امکان دارد سیستم قدیمی برای مدتی صرفاً بهعنوان آرشیو سوابق در دسترس باقی بماند، در حالی که تمام عملیات جدید در سامانه تازه انجام میشود.
گزینه دوم؛ اتصال سامانه جدید به سیستم موجود
گاهی سامانه قبلی باید باقی بماند، اما اطلاعات آن برای سایر بخشهای سازمان نیز لازم است.
در این حالت، بهجای حذف سامانه میتوان میان سیستمها ارتباط ایجاد کرد.
این ارتباط ممکن است از طریق API، وبسرویس، تبادل فایل استاندارد، سرویسهای واسط یا دیگر سازوکارهای تبادل داده انجام شود.
برای مثال، اطلاعات پرسنلی میتواند در یک سامانه تخصصی منابع انسانی مدیریت شود، اما سامانه مالی نیز برای محاسبات خود به بخشی از همان اطلاعات نیاز داشته باشد. اگر بتوان این داده را بهصورت کنترلشده میان دو سیستم تبادل کرد، لزومی ندارد کاربران دوباره همان اطلاعات را وارد کنند.
هدف اتصال دقیقاً همین است:
هر داده تا حد ممکن در محل اصلی خود مدیریت شود و سایر سامانهها در صورت نیاز، آن را از منبع معتبر دریافت کنند.
اتصال خوب با «کپیکردن اطلاعات» تفاوت دارد
امروزه در بسیاری از پروژهها از واژه یکپارچگی استفاده میشود، اما آنچه در عمل اتفاق میافتد صرفاً انتقال دورهای فایل Excel یا کپی داده از یک سامانه به سامانه دیگر است.
شاید این روش برای یک انتقال محدود مفید باشد، اما یکپارچگی پایدار محسوب نمیشود. در یک ارتباط ساختاریافته باید مشخص باشد:
بدون پاسخ به این پرسشها، اتصال سامانهها ممکن است خود به منبع جدیدی از ناسازگاری تبدیل شود.
گزینه سوم؛ همزیستی سامانهها
همزیستی الزاماً نشانه ضعف معماری نیست.
در سازمانهای بزرگ طبیعی است که چند سامانه تخصصی در کنار یکدیگر فعالیت کنند. مسئله اصلی «چند سامانه داشتن» نیست؛ مشکل زمانی ایجاد میشود که مرز مسئولیت آنها مشخص نباشد و هر یک نسخه جداگانهای از یک واقعیت سازمانی تولید کنند.
برای مثال، امکان دارد سازمان شما یک سامانه تخصصی مالی بسیار پیشرفته داشته باشد که نیازی به جایگزینی آن وجود ندارد. همزمان، سامانه جدید وظیفه مدیریت سایر فرایندهای سازمان را بر عهده بگیرد.
در این حالت، همزیستی منطقی است؛ به شرط این که رابطه میان این دو سیستم روشن باشد.
سامانه مالی باید منبع اصلی دادههای مالی باقی بماند و سامانه دیگر فقط اطلاعاتی را که برای فرایندها یا گزارشهای مدیریتی نیاز دارد دریافت کند. این مدل بهویژه زمانی مناسب است که سامانه موجود:
در چنین شرایطی، حذف سامانه میتواند بیشتر از حفظ آن هزینه ایجاد کند.
وجود چند سامانه در یک سازمان الزاماً نشانه پراکندگی نیست. مسئله زمانی آغاز میشود که چند سیستم، یک داده یا یک فرایند واحد را بدون مرز مشخص مدیریت کنند.
مسئله اصلی تعداد سامانهها نیست؛ تعدد «منبع حقیقت» است
وجود چند سیستم در یک سازمان لزوماً مشکلآفرین نیست.
مشکل جدی زمانی شکل میگیرد که یک داده واحد در چند سامانه مستقل نگهداری شود و مشخص نباشد کدام نسخه معتبر است.
فرض کنیم نام، سمت و وضعیت استخدام یک فرد در سه سامانه مختلف ثبت شده باشد. اگر یکی از آنها تغییر کند و سایر سیستمها بهروز نشوند، سازمان خیلی زود با سه روایت متفاوت از یک واقعیت مواجه میشود.
برای جلوگیری از چنین وضعیتی، برای هر گروه مهم داده باید یک منبع مرجع مشخص وجود داشته باشد؛ مفهومی که در معماری اطلاعات گاهی از آن با عنوان Single Source of Truth یاد میشود.
سامانههای دیگر میتوانند از آن داده استفاده کنند، اما نباید بدون منطق مشخص، نسخه مستقل خود را ایجاد کنند.
معماری گذار؛ سامانه جدید نباید یکشبه جای همهچیز را بگیرد
در پروژههای بزرگ، معمولاً فاصلهای میان وضعیت فعلی سازمان و معماری مطلوب آینده وجود دارد.
به همین دلیل استقرار سامانه جدید بهتر است نه به شکل یک تغییر ناگهانی، بلکه بر اساس یک «معماری گذار» طراحی شود.
در معماری گذار مشخص میشود:
وضعیت فعلی چیست، در مرحله بعد کدام سیستمها باقی میمانند، کدام ارتباطات باید ایجاد شوند، چه دادههایی مهاجرت خواهند کرد و در نهایت معماری مطلوب سازمان چگونه خواهد بود.
برای مثال ممکن است مسیر انتقال چنین باشد:
این رویکرد ریسک استقرار را کاهش میدهد و به کاربران نیز فرصت میدهد بهتدریج با محیط جدید سازگار شوند.
هر سامانه قدیمی الزاماً میراث نامطلوب نیست
در پروژههای تحول دیجیتال گاهی هر نرمافزار قدیمی با عنوان Legacy System معرفی میشود و فرض بر این است که باید حذف شود. اما قدمت یک سیستم بهتنهایی معیار خوبی برای تصمیمگیری نیست.
شاید یک سامانه قدیمی باشد، اما پایدار عمل کند، دادههای باکیفیتی داشته باشد، هزینه نگهداری مناسبی داشته باشد و وظیفه تخصصی خود را بهخوبی انجام دهد.
در مقابل، یک سامانه نسبتاً جدید نیز ممکن است فاقد API، دارای ساختار داده ضعیف یا وابسته به فرایندهای ناکارآمد باشد.
بنابراین سؤال مناسب این نیست که «این سامانه چند سال قدمت دارد؟»
بلکه باید پرسید: «آیا این سامانه هنوز نقش مفیدی در معماری آینده سازمان دارد؟»
میراث سامانههای قدیمی؛ یک مسئله جدی در ایران
در بسیاری از سازمانها و دستگاههای دولتی ایران، تحول دیجیتال طی سالها بهصورت مرحلهای و توسط پیمانکاران، فناوریها و ساختارهای متفاوت انجام شده است. نتیجهی این روند در برخی موارد، باقیماندن سامانههایی است که هنوز بخشی از اطلاعات سازمان را در خود نگه داشتهاند، اما توسعه و بروزرسانیِ فعال آنها متوقف شده، متولی مشخصی ندارند یا امکان تبادل ساختاریافته داده با سامانههای جدید در آنها پیشبینی نشده است.
در کنار این سامانهها، سیستمهایی نیز وجود دارند که همچنان فعال و ضروریاند، اما به دلیل نبود API، استاندارد مشترک داده یا شناسههای هماهنگ، عملاً بهصورت جزیرهای کار میکنند. بنابراین مسئله ورود یک سامانه جدید در ایران اغلب فقط «استقرار نرمافزار» نیست؛ بلکه مدیریت یک میراث دیجیتال چندلایه است که باید ابتدا شناسایی، دستهبندی و درباره آینده هر بخش آن تصمیمگیری شود.
چه دادههایی باید مهاجرت کنند؟
یکی از دشوارترین تصمیمها در جایگزینی سامانهها، تعیین دامنه مهاجرت داده است. انتقال همه اطلاعات تاریخی همیشه لازم نیست.
بعضی دادهها برای ادامه عملیات ضروریاند، بعضی فقط ارزش آرشیوی دارند و بعضی نیز به دلیل کیفیت پایین یا تکراریبودن اساساً نباید وارد سیستم جدید شوند.
به همین دلیل دادهها را میتوان پیش از مهاجرت در چند گروه قرار داد:
-
- دادههای فعال و موردنیاز عملیات روزانه
- سوابق تاریخی که باید در دسترس باقی بمانند
- دادههای موردنیاز گزارشگیری و تحلیل
- اطلاعات تکراری، ناقص یا فاقد ارزش عملیاتی
گروه اول میتواند بهطور کامل به سامانه جدید منتقل شود، گروه دوم در آرشیو قبلی باقی بماند و گروه چهارم پس از کنترل کیفیت اصلاً مهاجرت داده نشود.
مهاجرت داده، فرصت مناسبی برای پاکسازی میراث اطلاعاتی سازمان نیز هست.
نقش API در همزیستی سامانهها
هرچه سازمان به سمت معماری چندسامانهای حرکت کند، اهمیت APIها بیشتر میشود.
API به سامانهها اجازه میدهد بدون نیاز به دخالت مستقیم کاربر، اطلاعات موردنیاز را به شکل کنترلشده مبادله کنند.
برای مثال، یک سامانه میتواند اطلاعات پایه یک دهیاری یا سازمان را از منبع اصلی دریافت کند، سامانه دیگری وضعیت یک پرداخت را ارائه دهد و سیستم مدیریتی دادههای حاصل را در داشبورد خود نمایش دهد.
اما API بهتنهایی یکپارچگی ایجاد نمیکند. پیش از طراحی API باید درباره مالکیت داده، سطح دسترسی، استاندارد شناسهها، امنیت، زمانبندی تبادل و مسئولیت هر سیستم تصمیمگیری شده باشد.
API ابزار اجرای معماری است؛ نه جایگزین معماری.
سه سؤال برای هر سامانه موجود
قبل از تصمیمگیری درباره هر سیستم، میتوان سه سؤال نسبتاً ساده مطرح کرد:
پاسخ در عمل ممکن است ترکیبی باشد. یک سازمان میتواند بعضی سامانهها را حذف کند، بعضی را متصل نگه دارد و برخی را تنها برای دسترسی به سوابق تاریخی حفظ کند.
| وضعیت سامانه موجود | گزینه محتمل |
|---|---|
| قابلیتها کاملاً در سامانه جدید تکرار شدهاند | جایگزینی |
| سامانه تخصصی و همچنان کارآمد است | همزیستی |
| اطلاعات آن برای سامانه جدید ضروری است | اتصال |
| فقط سوابق تاریخی ارزشمند دارد | آرشیو و خروج تدریجی |
| همپوشانی بخشی با سامانه جدید دارد | مهاجرت مرحلهای |
| فاقد امکان تبادل داده است اما باید موقتاً باقی بماند | اتصال واسط یا راهکار انتقال موقت |
این جدول نسخهی سادهشده مسئله است؛ تصمیم نهایی باید با توجه به فرایند، داده، هزینه، ریسک و الزامات سازمان انجام شود.
بدترین سناریو؛ سامانه جدید در کنار قبلی، بدون تعیین مرز
یکی از رایجترین مشکلات زمانی شکل میگیرد که سامانه جدید راهاندازی میشود اما درباره سیستمهای قبلی هیچ تصمیم مشخصی گرفته نشده است.
در این شرایط ممکن است کاربران بخشی از اطلاعات را در سامانه قدیمی و بخشی دیگر را در سامانه جدید ثبت کنند. گاهی حتی یک اطلاعات واحد باید در هر دو سیستم وارد شود.
نتیجه معمولاً قابل پیشبینی است: دوبارهکاری، اختلاف دادهها، گزارشهای ناسازگار، افزایش خطای انسانی و مقاومت کاربران در برابر سامانه جدید.
این وضعیت نه جایگزینی است، نه یکپارچگی و نه همزیستی طراحیشده؛ بلکه صرفاً اضافهشدن یک جزیره جدید به جزایر قبلی است.
نمود این مسئله در سامانههای مدیریت روستایی
در حوزه مدیریت روستایی نیز ممکن است پیش از استقرار یک سامانه یکپارچه، ابزارهای مختلفی در سطح دهیاری، بخشداری یا استان مورد استفاده قرار گرفته باشند.
هدف از استقرار یک زیرساخت یکپارچه مانند سامانه مدیریت امور دهیاریها «سماد» لزوماً به این معنا نیست که هر نرمافزار موجود باید بدون ارزیابی کنار گذاشته شود.
در برخی حوزهها انتقال کامل فرایند به سماد میتواند منطقی باشد؛ در بعضی موارد، تبادل داده با یک سامانه تخصصی انتخاب مناسبتری باشد، و در موارد دیگر نیز برای یک دوره مشخص، همزیستی سیستمها اجتنابناپذیر باشد.
آنچه اهمیت دارد حفظ یکپارچگی در سطح مأموریت، داده و تجربه مدیریتی است؛ نه الزاماً قرار گرفتن تمام قابلیتهای سازمان در یک نرمافزار واحد.
سماد، تجربهای منحصر بفرد
سامانه یکپارچه و هوشمند مدیریت امور دهیاریها، برای تغییر رویکرد از مدیریت سنتی به یک سیستم شفاف و منسجم.
جمعبندی
تحول دیجیتال در سازمانی که از قبل چند سامانه دارد، با نصب یک نرمافزار جدید تمام نمیشود. بخش مهمتر کار، تصمیمگیری درباره آینده سیستمهای موجود است.
جایگزینی زمانی مناسب است که سامانه قبلی دیگر ارزش مستقل قابلتوجهی نداشته باشد. اتصال زمانی اهمیت پیدا میکند که سیستم موجود همچنان منبع معتبر یک داده یا خدمت باشد. همزیستی نیز زمانی منطقی است که چند سامانه تخصصی بتوانند با مرزهای مشخص در یک معماری مشترک فعالیت کنند.
در نهایت، هدف نباید «کمکردن تعداد سامانهها به هر قیمت» باشد. هدف این است که سازمان بداند هر داده کجا تولید میشود، هر فرایند در کدام سیستم انجام میشود و سامانهها چگونه بدون دوبارهکاری و تناقض اطلاعاتی با یکدیگر همکاری میکنند.
معماری خوب الزاماً معماری یکسامانهای نیست؛ معماریای است که اجزای آن نقش مشخصی داشته باشند و در کنار هم، یک سیستم مدیریتی منسجم ایجاد کنند.
شرکت دانشبنیان تدبیرنگر، توسعهدهنده راهکارهای هوشمند، سامانههای اتوماسیون و خدمات یکپارچه دیجیتال در مسیر تحول و توانمندسازی سازمانی کارآمد.
آدرس
ارومیه – خیابان برق از سمت بلوار شهید بهشتی، کوچه ۳، پلاک ۱۲
ایمیل
hello@tadbirnegar.ir
tadbirnegar.com@gmail.com
