شناسایی ریسکهای شکست در پروژههای مهاجرت و پیادهسازی بانکداری متمرکز
احمد شریفی
مدیر بخش عملیات واحد راهکارهای بانکی داتین
مؤسسه گارتنر، نرمافزار بانکداری متمرکز (کربنکینگ) را اینگونه تعریف میکند: «یک سامانه بکاند که تراکنشهای روزمره بانکی را پردازش میکند و به این ترتیب، دادههای مربوط به اطلاعات حسابهای بانکی مشتریان و دیگر رکوردهای اطلاعاتی مالی بهروزرسانی میشود.»
یک سامانه بانکداری متمرکز معمولا شامل زیربخشهایی چون سپردهگذاری، پرداختها، تسهیلات و اعتبارات، عملیات بانکداری تجاری و مانند آنهاست و از طریق مجموعهای از میانافزارها به «دفترکل بانک» و ابزارهای گزارشگیری متصل میشود. بانکها از طریق نرمافزار بانکداری متمرکز، این مجموعه خدمات را در کانالهای مختلف دسترسی مانند خودپرداز، اینترنتبانک، همراهبانک و شعب، به مشتریان خود ارائه میدهند.
بسیاری از بانکها نرمافزار بانکداری متمرکز را به صورت سفارشیشده توسط خودشان تولید و پیادهسازی میکنند. دیگر بانکها ممکن است از بستههای نرمافزاری بانکداری متمرکز موجود در بازار به دو شکل خرید نرمافزار استاندارد یا پیادهسازی سفارشیسازی نرمافزار بر اساس نیازهای خود استفاده کنند. بانکها برای موفقیت در فرایند انتخاب رویکرد مناسب خود و همچنین موفقیت در پیادهسازی نرمافزار بانکداری متمرکز در بانک از شرکتهای متخصص در حوزه «یکپارچهسازی سامانهها» مانند کوگنیزانت، کپجمینی، اکسنچر، آیبیام، شرکت مشاوره تاتا و دیگر شرکتهای مشابه کمک میگیرند.
پیادهسازی یک سامانه جدید بانکداری متمرکز در قالب جایگزینی یک راهکار قدیمی با یک راهکار جدید، یک سرمایهگذاری عظیم و بلندمدت برای بانک محسوب میشود. این، یک پروژه تحول پیچیده است که معمولا چند سال طول میکشد و متأسفانه احتمال شکست بسیار بالایی هم دارد. یک تعریف سرانگشتی از شکست در پروژههای اینچنینی عبارت است از:
• لغو پروژه
• بیش از ۲ بار / بیش از ۱۲ ماه تأخیر در اتمام پروژه
• بازخورد منفی پروژه در افکار عمومی و رسانهها
بنابراین پرسش کلیدی برای هر یک از اعضای تیمهای پیادهساز نرمافزارهای بانکداری متمرکز این است که چگونه ریسکهای شکست در این پروژهها را در زودترین زمان ممکن شناسایی و چگونه از این ریسکها در زمان اجرای پروژه اجتناب کنیم. در این مقاله یک راهنمای ساده برای شناسایی ریسکها و چالشهای پروژههای پیادهسازی نرمافزارهای بانکداری متمرکز و بهترین روشهای مدیریت آنها بر اساس تجارب بهدستآمده از بیش از ۲۰ پروژه در شش کشور اروپایی ارائه میشود.
مهمترین حوزههای ریسکهای پروژههای پیادهسازی نرمافزارهای بانکداری متمرکز و روشهای مدیریت این ریسکها عبارتند از:
۱- ریسکهای مربوط به دامنه پروژه: دامنه پروژه خود را صرفا به پیادهسازی هسته نرمافزار بانکداری متمرکز، محدود کنید. هر گونه تغییر دیگری در زیرساختهای بانک، باید در قالب پروژههای جداگانه تعریف و اجرا شوند. پروژه پیادهسازی و مهاجرت نرمافزار بانکداری متمرکز به خودی خود، پروژه بسیار پیچیدهای است. پرداختن به هر گونه فعالیتی فراتر از پیادهسازی خود نرمافزار بانکداری متمرکز، پیچیدگی پروژه را افزایش میدهد و در نتیجه احتمال شکست هم افزایش مییابد. منظور از فعالیتهای فراتر از هسته بانکداری متمرکز، مواردی مانند اینهاست:
• تغییر ساختار ترازنامه بانک
• تغییر در کانالهای بانکداری غیرحضوری به ویژه اینترنتبانک و همراهبانک
• تعریف لایههای جدید یکپارچهسازی فنی در زیرساخت پشتصحنه بانک
• راهاندازی یک مرکز داده جدید
• برونسپاری وظایف عملیاتی حوزه فناوری بانک
تجربه نشان داده که اگر دامنه پروژه خود را محدود نسازید، ریسک شکست پروژه بسیار افزایش خواهد یافت. محدودکردن پیچیدگیهای پروژه و انجام فعالیتهای مختلف به صورت تدریجی و در قالب پروژههای مختلف که زمانبندیهای تحویل متفاوتی دارند، به شکل قابل توجهی نرخ موفقیت در حوزه پروژههای فناوری بانک را افزایش خواهد داد.
۲- زمانبندی پروژه: برنامه پروژه خود را بررسی کنید و مطمئن شوید که همه موعدهای زمانی پروژه بهدرستی در کل برنامه زمانی پروژه جای گرفتهاند تا پروژه در زمان مقرر به اتمام برسد. برای این منظور محاسبه زمانبندی را از آخر پروژه به اول پروژه انجام دهید و در این کار به نکات زیر توجه کنید:
• توجه به زمانبندی راهاندازی و تحویل: به تجربه میتوان گفت حداقل به دو هفته زمان برای راهاندازی و تحویل پروژه در قالب روش «انفجار بزرگ (بیگبنگ)» از زمان نهاییشدن پیادهسازی و استقرار تمام زیرساختها در محیط عملیاتی تا راهاندازی نهایی، نیاز است. در صورتی که برنامه شما بهگونهای است که دادههای ایستا مثلا نام و نام خانوادگی، شماره ملی، شماره حساب و… مشتریان و دادههای تراکنشی بانک را به صورت جداگانه اما یکباره (در لحظهی بیگبنگ) به سامانه جدید بانکداری متمرکز، مهاجرت دهید یا حتی به روشهای پیچیدهتری مانند «پردازش موازی» فکر میکنید، حتما به زمان بیشتری برای انجام فرایند راهاندازی و تحویل نیاز دارید. لحظه بیگبنگ میتواند در نیمهشب جمعه یعنی زمانی که هنوز اولین روز کاری هفته شروع نشده و اغلب کسبوکارها هم تعطیل هستند، اتفاق بیفتد.
• آزمونهای مهاجرت داده: از زمانی که مهاجرت دادهها به صورت رسمی آغاز میشود؛ یعنی زمانی که همه دادهها نسخهبرداریشده و فرایندهای تحول پایگاه داده قدیمی به جدید نیز طراحی شدهاند، تا زمانی که سامانه جدید شروع به کار کند، حداقل به ۷ تا ۱۰ بار تکرار چرخه مهاجرت نیاز است؛ شامل استفاده آزمایشی از پایگاه داده جدید در تعطیلات آخر هفته. چنین فرایندی بین ۶ تا ۹ ماه زمان لازم دارد تا به مرحلهای برسیم که کیفیت دادهها قابل قبول باشد و همه مغایرتهای ترازنامه بانک در دو سامانه قدیمی و جدید حل شده باشند یا اینکه در حد قابل پذیرش توسط حسابرسان بانک قرار گیرند. در چنین زمانی فرایند راهاندازی و تحویل نهایی میتواند آغاز شود.
• اجرای مهاجرت دادهها: فرایند اجرایی مهاجرت دادهها که شامل استخراج دادهها، تحول و اصلاح دادهها مطابق نیازهای سامانه جدید و بارگذاری دادهها در پایگاه دادههای جدید است، از نظر تعریف دامنه پروژه شامل فعالیتهایی چون تعریف دامنه اجرایی مهاجرت دادهها (چه سرفصل دادهای باید مهاجرت یابد) و نسخهبرداری از دادهها و نقشههای ارتباطی آنها (کدام سرفصل دادهای باید از پایگاه داده منبع به کدام سرفصل دادهای از پایگاه داده مقصد مهاجرت یابد) در مرحله اول و خود عملیات اجرایی مهاجرت و آزمونهای «یونیت تست» و « کارکردی» در مراحل بعدی میشود. انجام موفق عملیات مهاجرت به زمانی حدود ۹ تا ۱۲ ماه نیاز دارد تا بتوان پس از آن آزمونهای مهاجرت دادهها را آغاز کرد.
• آزمون پذیرش و یکپارچهسازی: بسیاری از کارکردهای سامانه بانکداری متمرکز جدید میتوانند به صورت جداگانه مورد آزمون قرار گیرند؛ اما در پایان فرایند مهاجرت، باید همه اجزای این سامانه را در قالب یک کلِ یکپارچه نیز مورد ارزیابی قرار داد تا بتوان از کارکرد درست فرایندهای حسابداری و حسابرسی، بهروزرسانی روزانه ترازنامه بانک و مدیریت گردش حساب مشتری که شامل گزارشدهیهای روزانه، ماهانه و موردی هم میشود، اطمینان حاصل کرد. برای این منظور به زمانی بین ۴ تا ۶ ماه پس از پایان پیادهسازی کامل نرمافزار بانکداری متمرکز نیاز است که شامل آزمونهای نهایی کارکردی رابطهای نرمافزاری درونبانکی و برونبانکی و آزمونهای مهاجرت دادهها هم میشود که نتیجه آن، فراهم شدن مجموعهای از دادههای مفید برای انجام آزمون پذیرش و یکپارچهسازی خواهد بود.
در مجموع باید گفت اگر به دنبال کاهش زمان انجام فعالیتهای بالا نسبت به تجربه بهینه توضیح دادهشده در هر بخش باشید، خود را در معرض بالاترین سطح ریسک شکست قرار میدهید. بنابراین اگر به شما گفته شد که با بهرهگیری از روشهای توسعه و استقرار چابک نرمافزار میتوان این زمانها را کاهش داد، حتما با عینک بدبینی به پیشنهاد دریافتشده بنگرید!
۳ – حجم کار: لازم است اطمینان حاصل کنید که کلیه فعالیتهای اجرایی را در برنامه پروژه در نظر گرفتهاید و در زمان اجرا هم فعالیتها در محدوده مجاز کیفی و کمّی مطابق برنامه پروژه انجام میشوند.
برای این منظور به نکات زیر توجه کنید:
• حجم کار پیادهسازی: تعداد «موارد اصلاحی» شناساییشده بین محصول مورد نظر با محصول پیادهسازیشده یا به عبارتی دیگر، بهروزرسانیهای موردی نرمافزار برای رفع مشکلات نرمافزار نمیتواند بیشتر از حجم کار «نفرـ روز» تخمینزدهشده برای این بخش از پروژه باشد. تجربه میگوید پیادهسازی یک مورد اصلاحی شناساییشده، به صورت متوسط حداقل یک نفرـ روز زمان لازم دارد. با این حال لازم است توجه کنید که تعداد موارد اصلاحی قابل رفع در قالب یک پروژه پیادهسازی نرمافزاری و در نتیجه حجم نفرـ روز کار به صورت منطقی نمیتواند بیش از ۵۰۰ مورد اصلاحی یا ۱۰ هزار نفرـ روز باشد.
• حجم کار مهاجرت دادهها: خودکارسازی مهاجرت دادهها شامل فعالیتهایی چون تعریف محدوده مهاجرت، نسخهبرداری از دادهها و اجرای عملیات مهاجرت و سپس انجام آزمونهای مورد نیاز میشود. بر اساس تجربه حجم کار فرایند تصحیح اشتباهات در دادههای مهاجرتدادهشده نمیتواند زیر ۱۰۰۰ نفرـ روز باشد. بر اساس نوع فیلدهای دادهای و حجم دادههای مهاجرتیافته ممکن است حتی به حجم کار بیشتری هم نیاز باشد. به علاوه باید همین میزان حجم کار (۱۰۰۰ نفرـ روز) را برای اصلاحات مورد نیاز دادهها در لایه کسبوکار شامل تمیزسازی دادهها، مهاجرت دستی، تصحیح اشتباهات و پشتیبانی از عملیات مهاجرت از منظر ذینفعان کسبوکار بانک در نظر بگیرید. اینها مواردی هستند که معمولا فراموش میشوند.
• حجم کار یکپارچهسازی: حداقل بین ۵۰ تا ۱۰۰ درصد حجم کار پیادهسازی باید به صورت جداگانه برای فعالیتهای مربوط به یکپارچهسازی در نظر گرفته شود که شامل «ایجاد رابطهای نرمافزاری میان بخشهای مختلف نرمافزار بانکداری متمرکز و سایر نرمافزارهای درون و بیرون بانک» و «انجام تنظیمات لازم در نرمافزارهای موجود برای هماهنگسازی نرمافزار بانکداری متمرکز» میشود. بدین ترتیب میتوانیم اطمینان حاصل کنیم که اتصال میان نرمافزار بانکداری متمرکز و نرمافزارهای درون و بیرون بانک، بهدرستی برقرار شده است.
• حجم کار مدیریت زیرساختها و محیط عملیاتی: حداقل بین ۵ تا ۱۰ درصد حجم کار پیادهسازی باید به صورت جداگانه برای فعالیتهای مربوط به آمادهسازی، مدیریت و نگهداشت زیرساختها، ایجاد محیط عملیاتی برای اجرای نرمافزار بانکداری متمرکز، اجرای «بیلد»های آزمایشی نرمافزار و مدیریت پیکربندی و تغییرات مربوط به این حوزه در نظر گرفته شود.
• حجم کار آزمونها: مجموع کل حجم کار برای انجام آزمونهای نرمافزاری شامل: آزمون پذیرش و یکپارچهسازی میشود؛ اما «یونیت تست» و آزمونهای داخلی مد نظر واحد فناوری اطلاعات بانک را در بر نمیگیرد، آزمونهای مهاجرت داده شامل استفاده آزمایشی از پایگاه داده جدید در تعطیلات آخر هفته و آزمونهای راهاندازی و تحویل نهایی که بانک را از کارکرد صحیح و اثربخش نرمافزار بانکداری متمرکز پس از تحویل نهایی مطمئن میسازند، حداقل ۴۰۰۰ نفرـ روز زمان لازم دارد. اگر یک بانک بخشی از یک گروه مالی باشد، با توجه به نیاز به مدیریت ریسکهای ارتباط با سایر سامانههای گروه و همچنین ممیزیهای فرابانکی، زمان آزمونهای نهایی میتواند تا ۸۰۰۰ نفرـ روز افزایش یابد.
• حجم کار تحول کسبوکار: آمادهسازی کاربران فعال در لایه کسبوکار بانک و کل سازمان اعم از صف و ستاد برای موفقیت پروژه پیادهسازی نرمافزار بانکداری متمرکز بسیار کلیدی است و نیازمند یک استراتژی ترکیبی شامل برنامههای ارتباطی و برنامههای آموزشی است. به علاوه فرایندها و ساختار سازمانی هم باید بر حسب نیاز بازطراحی یا اصلاح شوند. در عین حال تطبیق یافتن با الزامات قانونی شامل تطبیق با عناوین و محتوای اصول قانونی حاکم بر فعالیت بانکداری و دریافت تأییدیههای لازم از رگولاتورهای بانکداری نیز موضوع مهم دیگری است که باید به آن توجه شود. بنابراین باید به صورت جداگانه برای این مجموعه فعالیتها زمانی بین ۲۰ تا ۳۰ درصد زمان پیادهسازی در نظر گرفته شود.
• حجم کار مدیریت پروژه: حداقل ۱۰ درصد زمان اضافی نسبت به کل پروژه را به عنوان سربار زمانی مربوط به فعالیتهای مدیریت پروژه، مدیریت جریان کار و فعالیتهای دفتر مدیریت پروژه در نظر بگیرید.
• حجم کار مدیریت برنامه: اگر برای اجرای همزمان پیادهسازی نرمافزار بانکداری متمرکز در بیش از یک بانک/ کشور یا اجرای همزمان پروژه پیادهسازی نرمافزار بانکداری متمرکز و تحول کانالهای دسترسی بانکداری برنامهریزی میکنید، باید بین ۱۰ تا ۱۵ درصد زمان اضافی نسبت به کل پروژه را به عنوان سربار زمانی مربوط به فعالیتهای مربوط به مدیریت برنامه در نظر بگیرید. در واقع مدیریت برنامه در زمانی لازم است که بیش از یک مرحله تحویل و راهاندازی نهایی یا بیش از یک پروژه در دست اجرا وجود داشته باشند. بنابراین اگر یک پروژه فقط یک نقطه تحویل و راهاندازی نهایی دارد، نیازی به فعالیتهای مدیریت برنامه است.
اگر تخمین حجم کاری پروژه همزمان پیادهسازی نرمافزار بانکداری متمرکز شما چیزی کمتر از موارد توضیح داده شده در بالاست، بهتر است نگران باشید چون پروژه شما بهشدت در معرض ریسکهای اجرایی است. به همین دلیل، اگر کسی به شما گفت که حداقل بخشی از این موارد، توسط نیروها و منابع داخلی بانک انجام میشود که کاملا قابل مدیریت هستند تا تأخیری در کار اتفاق نیفتد، هزینه اضافی هم برای پروژه در بر نداشته باشند و در نتیجه جای هیچگونه نگرانی نیست، بهتر است تنها به او لبخند بزنید. هر مدیر با تجربهای میداند تمام فعالیتها لازم است بدون توجه به هزینهداشتن یا نداشتن آنها برای پروژه، بهخوبی برنامهریزی و مدیریت شوند.
۴- نظارت بر پیشرفت پروژه: اطمینان حاصل کنید که تیم مدیریت پروژه شما مفهوم «پیشرفت پروژه» را بهدرستی درک کردهاند. اینکه چه دستاوردهایی در یک دوره زمانی مشخص مثلا هفته یا ماه حاصل شدهاند. ارزیابی پیشرفت میتواند با ابزارهایی نظیر تحلیل «دستاوردها/ منابع خرجشده»، «نمودارهای گرافیکی خرجکرد منابع» و «ارزیابی میزان تحقق تحویلدادنیها» انجام شود. بدون مستندسازی آنچه باید در یک دوره زمانی حاصل شود تا هدفهای مورد نظر به دست آیند و همچنین بدون مستندسازی آنچه در آن دوره زمانی واقعا بهدستآمده، پروژه شما قطعا در معرض ریسک شکست خواهد بود. اگر کسی به شما گفت «همه چیز مرتب است» و هیچ مدرکی برای اثبات درستی این جمله به شما ارائه نداد، من فکر میکنم بهترین زمان برای نگرانی فرا رسیده است! میتوان به ریسکهای دیگری هم برای پروژههای همزمان پیادهسازی نرمافزار بانکداری متمرکز اشاره کرد؛ اما موارد توضیح دادهشده در این مقاله مهمترین موارد هستند. در هر حال توصیه جدی نهایی این است که تمرکز روی تعریف درست «دامنه»، «زمانبندی»، «حجم کار» و سپس نظارت بر پیشرفت پروژه بهترین ابزارهایی هستند که میتواند دیدگاه درستی را در مورد وضعیت مناسب یا نامناسب پروژه شما در اختیارتان بگذارند.