در ژوئن ۲۰۱۲، یک اختلال نرمافزاری در گروه رویال بانک اسکاتلند، خدمات RBS ،NatWest و Ulster Bank را برای میلیونها مشتری مختل کرد. بیش از ۶.۵ میلیون مشتری در بریتانیا تحت تأثیر قرار گرفتند. بعضی نتوانستند اقساط و پرداختهای خود را بهموقع انجام دهند، برخی در خارج از کشور به پول نقد دسترسی نداشتند و تعدادی از شرکتها نیز در پرداخت حقوق کارکنان خود با مشکل روبهرو شدند. اختلال در برخی سامانهها چند روز و در Ulster Bank تا هفتهها ادامه داشت و بانکها در ادامه بیش از ۷۰ میلیون پوند برای جبران خسارت مشتریان پرداخت کردند.
شش سال بعد، بانک TSB تجربه مشابهی را از مسیری متفاوت پشت سر گذاشت. در آوریل ۲۰۱۸، اطلاعات مشتریان به یک بستر فناوری جدید منتقل شد، اما بستر جدید بلافاصله با مشکلات جدی روبهرو شد و خدمات شعب، تلفنبانک، بانکداری آنلاین و همراهبانک را مختل کرد. بخش قابلتوجهی از ۵.۲ میلیون مشتری TSB تحت تأثیر قرار گرفتند، برخی مشکلات تا ماهها ادامه داشتند و بانک بیش از ۳۲ میلیون پوند برای جبران خسارت پرداخت کرد.
بخوانید: چطور در بحران همچنان حق انتخاب داشته باشیم
در ایران نیز میتوان همین فاصله میان بازگشت فنی خدمات و پایان واقعی بحران را مشاهده کرد. پس از اختلالات گسترده در خدمات بانکی، حتی با بازگشت سامانهها به وضعیت عادی، همچنان نیاز به اطلاعرسانی درباره امنیت اطلاعات، وضعیت حسابها و دارایی مشتریان و پاسخگویی نسبت به پیامدهای اختلال وجود دارد. این مرحله دیگر صرفاً درباره روشنشدن سامانهها نیست؛ بلکه درباره بازگرداندن اطمینانی است که مشتری پس از تجربه بحران به آن نیاز دارد.
این تجربهها یک تفاوت مهم را نشان میدهند. ممکن است سامانه دوباره در دسترس باشد، اما تراکنشهای نیمهتمام هنوز تعیین تکلیف نشده باشند. ممکن است مشتری دوباره بتواند از خدمت استفاده کند، اما دربارۀ امنیت پول یا توان بانک برای مدیریت بحران همچنان تردید داشته باشد.
در نتیجه، پایان بحران را نمیتوان فقط با زمان بازگشت فناوری سنجید. بازیابی سامانه، بازیابی فرایند و بازیابی اعتماد سه بخش مرتبط از یک مسیرند و لزوماً همزمان اتفاق نمیافتند.
چهار گفتوگو با علی اخوان، محمودرضا فرهادی، محمد فرجود و صدرا بابایی، بخشهای مختلف این مسئله را روشن میکنند؛ از تشخیص خدمات حیاتی و اختیار تصمیمگیری تا آمادگی نیروی انسانی، یادگیری از رخداد و نقش ارتباطات در حفظ اعتماد.
تداوم بر اساس خدمت سنجیده میشود
در گزارشهای فنی، پایان یک اختلال معمولاً زمانی ثبت میشود که سامانه دوباره در دسترس قرار گرفته باشد. این معیار ضروری است، اما تجربه مشتری را بهطور کامل توضیح نمیدهد. اگر اپلیکیشن فعال باشد اما مشتری نتواند انتقال وجه را کامل کند، تراکنش قبلی او بلاتکلیف مانده باشد یا به بخشی از حساب دسترسی نداشته باشد، از نگاه او خدمت هنوز به وضعیت عادی برنگشته است.
بخوانید: تداوم در دل اختلال
رویکردهای جدید تداوم نیز به همین دلیل واحد تحلیل را از تجهیزات و سامانهها به خدمات مهم کسبوکار منتقل کردهاند. در این نگاه، باید مشخص شود کدام خدمات در صورت اختلال میتوانند به مشتری یا بازار آسیب جدی وارد کنند و چه میزان اختلال در آنها قابلتحمل است.
این تغییر نگاه در بانکداری اهمیت ویژهای دارد. مشتری به سرور، رابط برنامهنویسی یا پایگاه داده نیاز ندارد؛ نتیجه میخواهد. میخواهد پول منتقل کند، خرید انجام دهد یا به منابع مالیاش دسترسی پیدا کند. ممکن است بیشتر اجزای فناوری سالم باشند، اما خرابی یک جزء کوچک مانع کاملشدن این مسیر شود.
علی اخوان: اهمیت خدمت را اثر توقف آن تعیین میکند
علی اخوان، مدیرعامل تکنوتجارت و رئیس کمیسیون فینتک سازمان نظام صنفی رایانهای، تداوم را از زاویه جایگاه خدمات مالی در زندگی مردم و فعالیت کسبوکارها میبیند.
«بانک را نمیشود مثل یک کسبوکار معمولی دید که اگر خدمتی امروز ارائه نشد، مشتری بتواند دو روز دیگر برایش مراجعه کند. خدمات بانکی بهصورت شبانهروزی در جریاناند و زندگی مالی مردم و فعالیت بسیاری از کسبوکارها به آنها وابسته است. برای همین، وقتی از تداوم صحبت میکنیم، نباید فقط ببینیم کدام سامانه برای خود بانک مهم است. باید ببینیم توقف یک خدمت در بیرون از بانک چه اثری میگذارد.»
از این زاویه، حیاتیبودن یک فرایند را تعداد سامانههای درگیر یا هزینۀ زیرساخت آن تعیین نمیکند. ممکن است خدمتی از نظر فنی سادهتر باشد، اما توقفش تعداد زیادی از مشتریان یا کسبوکارهای وابسته را با مشکل روبهرو کند.
تداوم در مسیر کامل ارائه خدمت
یک خدمت بانکی معمولاً از چند مرحله تشکیل شده است. برای انتقال پول، فقط فعالبودن اپلیکیشن کافی نیست. احراز هویت، حساب مشتری، شبکه، کنترلهای امنیتی و چند بخش دیگر باید کنار هم کار کنند تا فرایند کامل شود.
بخوانید: تداوم، فراتر از مرز سازمان
بنابراین تداوم فرایند حیاتی یعنی بانک بداند یک نیاز مشتری از ابتدا تا انتها به چه فناوریها، افراد و تصمیمهایی وابسته است و اگر بخشی از این مسیر از دسترس خارج شد، حداقل چه سطحی از خدمت باید باقی بماند.
این نگاه تفاوت میان «سلامت سامانه» و «ادامه خدمت» را روشن میکند. ممکن است داشبوردهای فنی وضعیت مناسبی نشان دهند، اما اگر مشتری نتواند نتیجه مورد انتظارش را دریافت کند، مسئلۀ تداوم هنوز حل نشده است.
محمودرضا فرهادی: در بحران باید اولویتها روشن باشند
محمودرضا فرهادی، از مدیران حوزه کسبوکار بانکی، تداوم را به تصمیمگیری در شرایطی پیوند میدهد که اطلاعات کامل در دسترس نیست.
«در بحران ممکن است واقعاً ندانید پنج دقیقه بعد چه اتفاقی میافتد. اولین کار این است که چیزهایی را که میدانیم از چیزهایی که هنوز دربارهشان اطمینان نداریم جدا کنیم و بر همان بخشی تمرکز کنیم که در اختیار خودمان است. بعد باید ببینیم با شرایط موجود یک ماه، دو ماه یا سه ماه چقدر قدرت ادامهدادن داریم و چه نیروها و قابلیتهایی را حتماً باید حفظ کنیم.»
همین منطق درباره فرایندهای بانکی نیز کاربرد دارد. باید از قبل مشخص باشد کدام فرایند باید تقریباً بدون تغییر ادامه پیدا کند، کدام خدمت میتواند با ظرفیت محدودتری ارائه شود و کدام فعالیت را میتوان موقتاً کنار گذاشت.
بحران همچنین با سرعت فرایندهای معمول سازمان حرکت نمیکند. گاهی لازم است یک خدمت فوراً متوقف شود یا مسیر دیگری جای آن را بگیرد. اگر چنین تصمیمی مجبور باشد تمام مراحل عادی تأیید را طی کند، ممکن است زمان مناسب برای واکنش از دست برود.
برنامه تداوم فقط نباید بگوید چه کاری باید انجام شود؛ باید روشن کند چه کسی اجازه انجام آن را دارد و در غیاب او چه کسی جانشین است.
صدرا بابایی: آمادگی باید پیش از بحران آزموده شود
صدرا بابایی، مدیرعامل شرکت فناوری همراه پیدا، بر فاصله میان داشتن برنامه و توان اجرای واقعی آن تأکید دارد.
«اینکه یک برنامه تداوم داشته باشیم با اینکه واقعاً بتوانیم آن را اجرا کنیم فرق دارد. قبل از بحران باید مشخص باشد حداقل چه خدماتی باید برای مشتری باقی بمانند، چه کسی مسئول ادامه آنهاست و اگر مسیر اصلی از کار افتاد، مسیر جایگزین واقعاً کار میکند یا نه. این چیزها را نمیشود برای اولینبار وسط بحران امتحان کرد.»
به گفته بابایی، تمرین سناریو نیز باید برای پیدا کردن ضعفها انجام شود، نه برای اثبات آمادهبودن سازمان. ارزش تمرین در این است که نشان دهد کدام فرض جواب نمیدهد، کدام مسیر جایگزین قابل اتکا نیست و چه مسئولیتی همچنان مبهم است.
نیروی انسانی بخشی از معماری تداوم است
هیچ برنامهای بدون انسان اجرا نمیشود. حتی دقیقترین دستورالعملها در نهایت به افرادی وابستهاند که باید زیر فشار تصمیم بگیرند، اطلاعات را منتقل کنند و با واحدهای دیگر هماهنگ شوند.
آمادگی نیروی انسانی فقط آموزش فنی نیست. هر فرد باید بداند در بحران چه نقشی دارد، چه اطلاعاتی برای تصمیم نیاز است، از چه کسی دستور میگیرد و در غیاب فرد اصلی چه کسی جای او را میگیرد. به همین دلیل، وابستگی به افراد، دانش و اختیار آنها باید در همان نقشهای دیده شود که فناوری و فرایند در آن دیده میشوند.
محمد فرجود: بحران باید به یادگیری سازمانی تبدیل شود
محمد فرجود، رئیس کمیسیون بانکداری دیجیتال سازمان نظام صنفی رایانهای تهران، تداوم را به یادگیری از رخدادها پیوند میدهد.
«هیچوقت نمیتوانیم فرض کنیم احتمال حمله یا اختلال به صفر میرسد. باید از قبل گزینه دوم و سوم داشته باشیم، اما مسئله فقط داشتن مسیر جایگزین نیست. بعد از هر بحران باید دقیق بررسی کنیم چه چیزی جواب داد و چه چیزی جواب نداد.»
از این منظر، بازیابی به معنای بازگشت صرف به وضعیت قبل نیست. اگر سازمان همه چیز را دقیقاً مانند گذشته بازسازی کند، ضعفهای قبلی را نیز بازمیگرداند. هر بحران باید چیزی به سازمان اضافه کند: خدمت بازگردد، تجربه ثبت شود و آنچه کار نکرده اصلاح شود.
بازیابی فرایند، پایان کامل بحران نیست
حتی زمانی که مشتری دوباره بتواند کارش را انجام دهد، ممکن است اثر دیگری از بحران باقی بماند: کاهش اعتماد.
این مسئله در بانکداری حساستر است، چون مستقیماً با پول، اطلاعات و امنیت مالی مشتری ارتباط دارد. اگر مشتری در زمان اختلال توضیحی دریافت نکرده باشد یا از وضعیت دارایی خود مطمئن نباشد، بازگشت سامانه بهتنهایی نگرانی او را برطرف نمیکند.
رخداد TSB نمونه روشنی است. مشکل فناوری در نهایت برطرف شد، اما رسیدگی به پیامدهای آن برای مشتریان ماهها ادامه یافت. در ایران نیز بانک پاسارگاد پس از اعلام رفع عمده اختلالها، مشخصاً درباره امنیت اطلاعات و دارایی مشتریان توضیح داد. یعنی پس از بازگشت سامانهها هنوز باید به پرسشی پاسخ داده میشد که صرفاً فنی نبود: آیا میتوان همچنان به وضعیت بانک اطمینان داشت؟
ارتباط شفاف، بخشی از مدیریت بحران است
بابایی بر همین بخش تأکید میکند: «در بحران فقط این مهم نیست که تیمهای فنی چه کاری انجام میدهند. باید از قبل معلوم باشد چه کسی با مشتری حرف میزند، چه چیزی را میگوید و اطلاعات از چه مسیری منتشر میشوند. اگر سازمان سکوت کند، این فضا خالی نمیماند.»
بنابراین ارتباطات بحران نباید فعالیتی باشد که پس از پایان مشکل فنی آغاز شود. سازمان باید از قبل بداند چه کسی مسئول اطلاعرسانی است، چه اطلاعاتی را میتوان منتشر کرد، پیام از چه کانالی ارسال میشود و چه زمانی باید بهروزرسانی بعدی در اختیار مشتری قرار گیرد.
اخوان نیز حفظ اعتماد را به آمادگی سازمان و کیفیت ارتباط با مشتری مرتبط میداند. مشتری باید احساس کند بانک از شرایط آگاه است، مسئولیت وضعیت را پذیرفته و برای حل آن اقدام میکند.
بازیابی اعتماد هم باید سنجیده شود
ارزیابی پس از بحران معمولاً با شاخصهای فنی آغاز میشود: مدت قطعی، زمان بازیابی یا نرخ موفقیت تراکنش. این اطلاعات لازماند، اما تمام اثر بحران را نشان نمیدهند.
اگر اعتماد نیز بخشی از تداوم باشد، باید نشانههای آن پس از بحران دنبال شوند. افزایش تماس با مرکز پشتیبانی، تعداد شکایتها، خروج منابع، کاهش استفاده از خدمت یا ریزش مشتری میتوانند نشان دهند که اثر بحران هنوز پایان نیافته است.
در نتیجه، داشبورد تداوم نباید فقط وضعیت فناوری را نمایش دهد؛ باید نشان دهد کسبوکار و مشتری تا چه اندازه به شرایط عادی بازگشتهاند.
بحران بانکی سه سطح بازیابی دارد
تجربههای این مقاله نشان میدهند بازگشت از یک بحران بانکی را میتوان در سه سطح دید:
- بازیابی سامانه زمانی رخ میدهد که زیرساخت و فناوری دوباره قابل استفاده باشند.
- بازیابی فرایند زمانی کامل میشود که مشتری بتواند نیاز اصلی خود را از ابتدا تا انتها انجام دهد و فعالیتهای نیمهتمام نیز تعیین تکلیف شده باشند.
- بازیابی اعتماد زمانی رخ میدهد که مشتری دوباره اطمینان پیدا کند بانک شرایط را مدیریت میکند و دارایی و اطلاعات او در معرض خطر نیستند.
فاصله میان این سه سطح همیشه کوتاه نیست. اگر سازمان فقط زمان بازگشت سامانه را اندازه بگیرد، ممکن است خیلی زود بحران را پایانیافته بداند؛ در حالی که مشتری هنوز در مرحله بازیابی فرایند یا اعتماد قرار دارد.
تداوم به یک روش منسجم نیاز دارد
نقطه شروع طراحی تداوم باید خودِ خدمت باشد، نه فهرست سامانهها و تجهیزات. ابتدا باید روشن شود مشتری در یک فرایند حیاتی دقیقاً چه کاری میخواهد انجام دهد و توقف آن تا چه مدت قابلتحمل است. بعد میتوان دید این خدمت برای کاملشدن به چه فناوریها، افراد، تصمیمها و ارتباطاتی وابسته است.
این زاویه، ضعفهایی را آشکار میکند که در یک بررسی صرفاً فنی دیده نمیشوند. ممکن است بیشتر سامانهها فعال باشند، اما یک وابستگی کوچک کل فرایند را متوقف کرده باشد. ممکن است مسیر جایگزین وجود داشته باشد، اما کسی اختیار فعالکردن آن را نداشته باشد. یا خدمت دوباره برقرار شده باشد، اما مشتری هنوز نداند برای تراکنش ناموفقش چه اتفاقی افتاده است.
تجربه بحرانهای واقعی میتواند برای شناخت همین نقاط ضعف به کار رود. تراکنشهای بلاتکلیف، تصمیمهای دیرهنگام، مسیرهای جایگزین ناموفق یا موج شکایت پس از بازگشت سامانه، فقط پیامد یک رخداد نیستند؛ میتوانند الگوهایی از ضعف ساختاری باشند.
اینجاست که فقدان یک روش منسجم آشکار میشود؛ روشی که تجربه رخدادهای گذشته را به آمادگی واقعی تبدیل کند. چنین روشی باید بتواند از بحرانها یاد بگیرد، الگوهای تکرارشونده را شناسایی کند و بعد بسنجد آیا همان ضعفها امروز نیز در خدمات حیاتی سازمان وجود دارند یا نه.
این روش باید هر خدمت را از ابتدا تا انتها ببیند: مشخص کند چه بخشهایی برای ادامه آن ضروریاند، چه نقاطی میتوانند کل مسیر را متوقف کنند، چه سطحی از اختلال قابلتحمل است، چه کسی اختیار تغییر نحوه ارائه خدمت را دارد و ارتباط با مشتری چگونه باید مدیریت شود.
آزمون نیز باید جزئی از همین روش باشد. اگر یک سناریو نشان دهد تصمیم دیر گرفته میشود، مسیر جایگزین کار نمیکند یا مشتری اطلاعات کافی دریافت نمیکند، همان نقطه باید وارد برنامه اصلاح شود. در این صورت، هر آزمون و هر بحران میتواند شناخت سازمان از تداوم را دقیقتر کند.
آنچه کم است یک ابزار یا سند دیگر نیست؛ جای یک روش روشن و منسجم خالی است که خدمت، فناوری، انسان، تصمیم و اعتماد را در یک مسیر واحد ببیند، از تجربه اختلالهای واقعی یاد بگیرد و پیش از بحران نقاط آسیبپذیر را پیدا و اصلاح کند.
در بانکداری، بازگشت سامانه فقط یکی از مراحل بازگشت است. تداوم زمانی کامل میشود که خدمت دوباره قابل استفاده باشد و مشتری نیز دلیل کافی برای اعتماد دوباره به بانک داشته باشد.
علاقهمندان برای آشنایی بیشتر با این رویکرد به تداوم و مواجهه کسبوکارها با شرایط عدمقطعیت، میتوانند به وبسایت خانه تکنوکراتها و کانال آپارت مراجعه کنند.