كم مرة قابلت مدراء التطبيق الذين يرغبون في التعامل مع حل الحوادث؟
علاوة على ذلك ، هناك تدفق كبير للحوادث على السطر الثاني من الدعم هو ما يسمى بحوادث العمل ، أي الحوادث المرتبطة بانتهاك منطق عملية العمل في الخدمة ، أو مع الإجراءات غير الصحيحة من قبل المستخدم.
تمكنا من إزالة هذه الوظيفة من السطر الثاني قدر الإمكان ، ونقلها إلى فريق منفصل تم تجميعه من موظفي خط الدعم الفني الأول.
سنخبرك بكيفية قيامنا بذلك وما الصعوبات التي واجهناها في هذه المقالة.
تقليديًا ، كان السطر الثاني من الدعم الفني ينخرط في حل الحوادث على الأنظمة ، تلك التي تقدم الدعم للخدمة نفسها ، وتؤدي إعدادات تهيئة المنتج ، وبيئات الاختبار ، ومراقبة النظام ، وتثبيت التصحيحات ، والمشاركة في نوبات عند الطلب ، إلخ. وغالبًا ما كان يصاحب حل الحوادث في هذه الفرق "مبدأ متبقٍ" (ما لم يكن هذا بالطبع حادثًا ذا أولوية حرجة) ، ومع ذلك ، فإنهم في معظم الحالات يتناسبون مع اتفاقيات مستوى الخدمة المعينة.
مع إدراك أن العديد من الحوادث (وعلى مقدمة الأنظمة - خلف كل منها) قد تكون مشكلة عميل البنك ، فقد قررنا تقليل وقت تنفيذ هذه الطلبات إلى الحد الأدنى ، لكننا لم نبدأ بزيادة عدد فرق الدعم ، ولكن من خلال تحليل كل مرحلة من مراحل هذه العملية.
تم بناء عملية الدعم التقليدية في البنك وفقًا للمخطط الكلاسيكي وبدا الأمر على النحو التالي
الشكل 1. مخطط تنظيم عملية الدعم (كان)تم توزيع الطلب عبر الخطوط الأولى والثانية والثالثة من الدعم ، بالنسب التالية: 15:75:10.
السطر الأول - مكتب الخدمة - تلقي المكالمات وتوجيهها وتوجيهها باستخدام قنوات الاتصال التالية:
- الهاتف - 8 ٪ من إجمالي عدد المكالمات
بوابة الخدمة الذاتية - 83 ٪ من إجمالي عدد المكالمات
البريد الإلكتروني - 4 ٪ من إجمالي عدد المكالمات
دردشة بوت في فايبر و Telegram - 5 ٪ من المجموع
يتناول السطر الأول أيضًا حل الحوادث عن بُعد في محطات عمل المستخدمين ، مما يوفر الوصول إلى أنظمة معلومات البنك. كتبت عن عمل هذه الوحدة في مقالة منفصلة -
رابط هناالسطر الثاني - فرق صيانة برامج التطبيق + البنية التحتية + DBA + ... ،
الخط الثالث هو فرق التطوير.
نظرًا لأن الأنظمة المصرفية متكاملة مع بعضها البعض ، فإن وقوع حادث في أحد الأنظمة يكون غالبًا نتيجة لحدوث خطأ في نظام آخر. وتظهر الأخطاء في "أنظمة النسخ الاحتياطي" بشكل أساسي على "الواجهة" ، مما يؤثر بشكل مباشر على المستخدمين.
يتطلب تحديد السبب الجذري للحدوث في هذه الحالة مشاركة عدة فرق مرافقة ، ونتيجة لذلك ، سلسلة من التوجيهات.
أخذ عينة من الحوادث لعدة أشهر وتحليل دورة حياتها ، اكتشفنا أنهم يقضون معظم حياتهم في طابور ، في انتظار تحليل لفريق دعم الخط الثاني (أحيانًا ما يصل إلى 80 ٪) ، بشكل دوري ، مع إعادة التعيين بين الفرق وفترة طويلة المراسلات في نص الطلب.
في عملية تحليل هذه الحوادث وتحليلها ، اكتشفنا أنه لحل أخطاء التكامل ، يحتاج الزملاء إلى معلومات من أنظمة التكامل المجاورة (سجلات ، تحليل التأثير ، وما إلى ذلك) ، والتي يتحولون إلى بعضها البعض ، حوادث التوجيه.
من أجل تقليل وقت حل الحوادث ، كمشروع رائد ، قررنا إنشاء فريق متكامل
متعدد الوظائف من موظفي الخط الأول والثاني لحل الحوادث في الأنظمة الأمامية للبنك - الخدمات المصرفية عبر الإنترنت ، والخدمات المصرفية عبر الهاتف المحمول ، وخدمات إرسال الرسائل (الرسائل القصيرة والدفع) + الواجهة الرئيسية - نظام مكتب البنك.
هذا الأمر متوسط بين الخطين الأول والثاني - سطر واحد ونصف الدعم ، والذي أطلقنا عليه "الخط الأمامي".
بالفعل في مرحلة تشكيل هذا الفريق ، واجهنا بعض الصعوبات ، بما في ذلك من جانب مديري الخط الثاني ، وبالتالي فإن نقل موظف واحد إلى هذا المشروع من كل نظام يعني انخفاضًا في رأس مال الفريق الحالي. ولم يكن موظفو الخط الثاني أنفسهم ، الذين كان من المفترض أن يشاركوا في البرنامج التجريبي ، حريصين على الغطس في حل الحوادث.
من خلال المفاوضات التكرارية ، تمكنا من الاتفاق على أن المهمة الرئيسية للمشاركين في الخط الثاني في هذا المشروع هي تدريب موظفي الخط الأول ، وإنشاء قاعدة معرفية مشتركة ، وبناء عمليات التفاعل الداخلية ، وتوفير الوصول اللازم ، ثم العودة تدريجياً إلى الانقسامات.
كان موقع موقع Frontline هو مركز تكنولوجيا المعلومات التابع للبنك في أوبينسك.
كانت التشكيلة الأولى لخط الدعم الواحد ونصف على النحو التالي:
- اثنين من موظفي الدعم السطر الأول
- اثنين من موظفي مجموعة دعم نظام المكتب الأمامي
- اثنين من موظفي مجموعة دعم الخدمات المصرفية عبر الإنترنت والخدمات المصرفية عبر الهاتف المحمول
- موظف واحد في مجموعة دعم خدمات معلومات العملاء (sms & push)
كان التركيز الرئيسي للفريق على 3 مؤشرات:
- سرعة - يجب حل 70 ٪ من الطلبات التي تلقاها الفريق في أكثر من 8 ساعات عمل
- الكمية - لا يمكن للفريق توجيه أكثر من 20٪ من الطلبات إلى خط الدعم الثاني
- الجودة - يجب ألا تتجاوز نسبة الحوادث التي اكتشفها المستخدمون 3٪
التين. 2 خط المواجهة عملية التعامل مع الحوادث
كانت الصعوبة التالية التي واجهناها في بداية الطيار هي عدم وجود فريق في فهمنا الأولي ، إن وجد.
على الرغم من حقيقة أن موظفي Frontline كانوا في مكان قريب في نفس الغرفة ، لم تكن هناك محاولات للتبديل إلى الوظيفة المتبادلة وتبادل الخبرات والتفاعل الكبير في الداخل. كان كل مشارك ، كما كان من قبل ، يركز على حل الطلبات من خلال نظامه ، ونتيجة لذلك - كان شخص ما "تناثرت" مع الحوادث ، وكان شخص ما أكثر حرية.
تقرر "تغيير الأنظمة" داخل الفريق ، على سبيل المثال ، بحيث لم يعد ممثل الدعم المصرفي عبر الإنترنت يحل الحوادث على نظامه ، ولكن بدأ بمعالجة طلبات نظام المكتب الأمامي ، وبدأ ممثل دعم نظام المكتب الأمامي في حل الحوادث على خدمات الإعلام ، إلخ. د.
لماذا؟
- حاول الوصول إلى العالمية بحيث يمكن للموظفين التبديل بين حوادث الأنظمة المختلفة ، وبالتالي توزيع الحمل بالتساوي على جميع المشاركين ؛
- تزويد الأطفال بمعرفة كافية بالأنظمة ذات الصلة التي ستساعدهم على تحديد سبب خطأ الاندماج بسرعة ؛
- تأسيس التواصل داخل الفريق ؛
جعل الحسابات اللازمة ، وفرت الوصول إلى سجلات التطبيق وقاعدة البيانات ، وأكثر من ذلك! :)
في البداية ، تم تخفيض دقة الحادث. من الواضح أنه عندما لا تعرف تعقيدات النظام ، وتحتاج أيضًا إلى حل الحوادث المتعلقة به ، فإن هذه ليست مهمة سهلة. لكن الرجال بدأوا يلجأون إلى بعضهم البعض طلبًا للمساعدة ، ودراسة وتحديث قاعدة المعارف العامة ، وتدريجيًا سارت الأمور.
وأيضًا ، بدأنا كل يوم في تنظيم مواقف صغيرة في بداية كل يوم عمل ، بالقرب من الأوراق التي نلصقها على الجدران ومؤشرات يومية. ناقشناها وانتهينا منها بعلامة ، ونفرح في تنفيذها أو نناقش سبب الفشل ، إذا لم نتمكن من تحقيقها.
بعد ذلك ، بالطبع ، استبدلنا أوراق الورق هذه بلوحات معلومات على الإنترنت.
شكل 3 - لوحة معلومات الكفاءة في الخطوط الأماميةمن الضروري هنا أن نقول "شكرًا" خاصًا لرئيس فريق الدعم لنظام المكتب الأمامي للبنك ، الذي تولى القيادة وطور تطوير الفريق من الداخل - أليكس ، شكرًا لك! :)
في الشهرين الأولين ، لم يتمكن الفريق من التعامل مع الأهداف المحددة ، كانت العملية التدريبية مستمرة ، وتم تحديث قاعدة المعرفة.
بدءًا من الشهر الثالث للمشروع التجريبي ، بدأنا في التلاؤم مع الأهداف ، وبعد 6 أشهر بدأنا في تجاوزها.
الشكل 4. مشروع فرونت لاين التجريبي ، المؤشرات الأولىسرعان ما أصبح من الواضح أن الطيار "انطلق" بنجاح ، وكان من المستحسن توسيع نطاق المشروع.
تدريجيا ، بدأنا في إضافة كفاءات في الأنظمة الأخرى إلى الفريق ، وسحب موظفي الخط الثاني وإضافة موظفين من مكتب الخدمة.
تدريجيا ، تحولنا إلى "T - وظيفة مشتركة" ، عندما تم تعيين كل مشارك نظام رئيسي واحد ونظامين متجاورين.
التين. 4 إحصاءات مقارنة لعام 2018 في وقت حل الطلبات بين فرق تتبع Frontline و السطر الثانيفي عام 2018 ، أغلق فريق Frontline حوادث أكثر من أي وحدة مرافقة أخرى في البنك. لقد تجاوز الشباب الأهداف المحددة بشكل كبير ، حيث أظهروا مرة أخرى أن العمل الجماعي والكفاءات متعددة الوظائف يمكن أن يحققوا نتائج مهمة.
بالنسبة لخط الدعم الثاني ، "Frontline" اليوم عبارة عن "درع" يمكن الاعتماد عليه ، مما يقلل بشكل كبير من تدفق المكالمات الواردة إليهم.
الشكل 5: عدد ونسبة الحوادث التي تم حلها في الخط الأمامي (الشكل - Team1) فيما يتعلق بالحوادث التي تم حلها في السطر الثاني لجميع أنظمة البنكاليوم ، جميع المشاركين في فرونت لاين هم موظفون من مكتب الخدمة يقومون بحل الحوادث على أنظمة الواجهة الرئيسية للبنك ، لتحقيق الأهداف المحددة.
أيضًا ، "Frontline" هي الخطوة التالية لموظفي مكتب الخدمة في سلم حياتنا المهنية ، قبل الانتقال إلى خط الدعم الثاني.