تخيل أنك تتصل بالسؤال إلى مركز الاتصال بالبنك واحصل على إجابة واحدة. ثم وصل إلى نقطة البيع ، لكن المعلومات التي تم الحصول عليها مسبقًا غير مهمة. للتأكد من أن هذه الاختلافات مضمونة لتجنبها ، قررنا ترك الحل الحالي الذي تم إنشاؤه على البنك في SharePoint ومعالجة جميع المحتوى ومصادر البيانات المحددة والمستهلكين وإعادة تجميع جميع المعلومات اللازمة في نظام جديد لإدارة المعرفة - وهو نفسه لجميع الإدارات. في هذا المنصب سوف نشارك تجربتنا.
بيان المشكلة واختيار الحل
بادئ ذي بدء ، يجب توحيد جميع المعلومات المتعلقة بخدمة العملاء ومنتجاتنا وخدماتنا. تاريخيا ، تم تخزين المعرفة في ثلاث قواعد معرفة كبيرة تم إنشاؤها في أوقات مختلفة ، في الواقع ، في بنوك مختلفة. في الوقت نفسه ، كان أحد المتطلبات الرئيسية القدرة على توفير كميات مختلفة من البيانات - على سبيل المثال ، لنقاط البيع و ATP (مركز الاتصال). في الحالة الأولى ، تكون المعلومات التفصيلية مهمة: عندما يأتي الأشخاص إلى الإدارات غير المتصلة بالإنترنت ، فإنهم يتوقعون سماع كل التفاصيل حول القضايا ذات الاهتمام. في الحالة الثانية ، على العكس من ذلك ، المعلومات الموجزة كافية - الشيء الرئيسي هو أن يتم توفيرها بسرعة وبشكل واضح.
كانت المهمة معقدة بسبب حقيقة أن لدينا ما يصل إلى ستة عملاء داخليين. وبالتالي ، أنواع مختلفة من المتطلبات. كل شخص لديه معايير مختلفة فيما يتعلق بالوظائف والأداء والدعم. على سبيل المثال ، وجود SSO ، التكامل مع Active Directory ، إلخ. كانت قدرات التنفيذ السريع للفريق مهمة. توقعنا أن النظام الجديد سوف يقلل من وقت الخدمة لـ 25 ٪ من المكالمات إلى مركز الاتصال بنسبة 5 ثوان. وسوف يقلل أيضا من وقت التدريب. في السابق ، تم إنفاق 3٪ من إجمالي وقت العمل عليها - وعندما يتعلق الأمر بأكثر من 30،000 عامل ، فإن النفقات الكبيرة تذهب.
بالإضافة إلى ذلك ، خلال المشروع ، كان VTB في مرحلة دمج بنكين كبيرين في هيكله ، وكان عملاء النظام المستقبلي في شبكات فرعية مختلفة ، في قطاعات مختلفة. يجب الجمع بين كل هذا وتوفيره للموظفين الذين يعملون مع النظام ، والوصول من البداية إلى النهاية ، مع الأخذ في الاعتبار الأدوار ، ومستويات مختلفة من الوصول إلى المعلومات ، وما إلى ذلك. كان مطلوبًا لحل العديد من مشكلات البنية الأساسية الإضافية.
نضع جميع المتطلبات والمعايير اللازمة في جدول تسجيل واحد. لقد بحثنا في جميع الحلول الرئيسية الموجودة في السوق ، الروسية والأجنبية على حد سواء ، وحملنا أجزاء من المحتوى الخاص بنا فيها ، وقمنا بتقييم ما نجح. وفي النهاية ، استقرنا على نظام موحد لإدارة المعرفة من منارة KMS. مع المقدمة ، ساعدنا فريق DIS Group الذي يقدم منارة KMS في السوق الروسية.
2500 مقال في 16 قالبًا لـ 60 ألف مستخدم
هناك كيانان رئيسيان في نظامنا الجديد لإدارة المعرفة - "القالب" و "المقالة". مقالة هي صفحة رسمية مع المعلومات. تبدو المقالة نفسها مختلفة لجميع مجموعات دور المستخدم (موظفو البنوك). يتم تشكيل المجموعات اعتمادًا على الانتماء التنظيمي أو الوظيفي أو التجاري للموظفين.
بعد تحليل المحتوى الذي لدينا ، أدركنا أننا نتعامل مع 2500 مقالة. هذا البحر من المعلومات اللازمة ليتم تقسيمها إلى الحد الأدنى لعدد القوالب. علاوة على ذلك ، يجب أن تحتفظ المقالات بالمرونة الموضحة أعلاه. كان هناك الكثير من العمل اليدوي على إنشاء القوالب والتنسيق والمصالحة. لكن في النهاية ، تمكنت من تلبية 16 نموذجًا - بالنسبة لـ 2500 مقال ، فهذا مستوى جيد من التنظيم.
العمل على المحتوى
يتم توزيع 16 قالبًا في ثلاث مجموعات من مديري المحتوى. المجموعة الأولى هي المسؤولة عن المحتوى المرتبط بمركز الاتصال. والثاني هو للمنتجات والخدمات والمعلومات ذات الصلة. الثالث هو كتلة المحتوى من وحدة التشغيل (DOPB) ، مكتبنا الخلفي. بالإضافة إلى ذلك ، لدينا وحدة منهجية تعمل على مستوى البنك. تمر جميع معلومات البنك تقريبًا عبره ، كما هو الحال من خلال عامل تصفية ، ونتيجة لذلك ، تبقى المعلومات التي يجب وضعها في قاعدة المعرفة فقط.
ناقشنا تقسيم أكثر تعقيدا. الفكر لإدخال "أصحاب" المجموعات المسؤولة عن العملية والنظام. ناقشنا موقف "رئيس التحرير" ، الذي سيتحقق من جميع التغييرات. لكن في النهاية ، قررنا التركيز على ثلاث مجموعات ، حيث إن المحتوى منقسم تمامًا بينهما.
تسمح لك KMS Lighthouse ببناء عدة مستويات من التنسيق بسرعة ، لكننا قررنا عدم تعقيد هذا النظام ، وعلى مستوى مديري المحتوى أنشأنا مستويين - أولئك الذين يكتبون وأولئك الذين ينشرون. في المستوى الأخير ، يبرز المسؤولون عن جميع المحتويات في مجموعتهم. صحيح أن السؤال الذي يطرح نفسه هنا هو صناعة مواد عن المبيعات الناجحة لقسم الأغذية ، لكنهم قرروا حتى الآن ترك كل شيء كما هو.
وبالتالي ، يمكن تطوير قاعدة المعرفة دون تأخير. لنفترض أن قسم الأغذية يريد نشر معلومات حول منتج جديد على الفور. يرسل طلبًا عبر البريد إلى مدير المحتوى: "الزملاء ، نحتاج إلى نشر هذه المقالة هنا." بعد النشر من خلال آليات التعليق ، تجري التحسينات: في مكان ما ، قد لا تكون المعلومات كافية ، في مكان ما لا يتوافق شيء ما مع القالب. وهلم جرا حتى الوحدة ومدير المحتوى راضيا. الآن نحن نقدم فقط العناصر اللازمة لهذا التفاعل: الإخطارات والمسوحات ونماذج الموافقة. إذا كانت المقالة التي يتم إنشاؤها تغطي مناطق مجموعات مختلفة من مديري المحتوى ، فسيصبح الجميع مسؤولين عن علامة التبويب الخاصة بهم.
يتم تخصيص خادم تطبيق منفصل لمديري المحتوى ، حيث يمكنك تعديل المقالات أو إنشاء مقالات جديدة باستخدام القوالب الموجودة. هنا يمكنك سحب الإحصائيات اللازمة لاستعلامات البحث وأهمية الإجابات والتحويلات وما إلى ذلك. لا يمكن تغيير المقالات فحسب ، بل يمكن تحسينها أيضًا - على سبيل المثال ، إنشاء علامات وصفية لتحسين البحث. بالإضافة إلى ذلك ، يمكن تحسين البحث عن طريق إضافة بعض المقالات بالقوة إلى استفسارات معينة. يسمى هذا "اختيار المحرر" ؛ عند البحث ، يرى المستخدم هذه المواد في عمود منفصل.
قاعدة البحث
في SharePoint ، اعتاد الناس على هيكل شجرة تقديم المعلومات والتفاعل مع علامات التبويب. تتضمن KMS Lighthouse استخدام البحث الكامل. عندما يعمل 60 ألف مستخدم مع النظام (بمعدل حوالي 1600 مرة واحدة) ، يجدر التفكير في موازنة التحميل. الآن KMS Lighthouse يعمل على 10 خوادم. كل نشر اثنين من الأجهزة الافتراضية. حفنة من 20 الأجهزة الافتراضية تعمل. بينهما هو موازن البنك.
يعتمد البحث على ثلاثة محركات بحث تقوم بفهرسة جميع المحتويات. يتم إنشاء فهارس البحث مع مراعاة الطلبات الواردة وتكرارها. تعتمد أهمية الإجابات وموقعها في نتائج الإخراج على هذا. تقوم Lighthouse بتحليل الطلبات ويمكنها تقديمها في صورة 16 تقريرًا مختلفًا ، بمساعدة مديري المحتوى الذين يعملون على ملء النظام.
ميزات إضافية
جميع الموظفين الذين يعملون مع النظام ينقسمون إلى حوالي 35 مجموعة دور. كل لديه حق الوصول إلى أجزاء معينة من المقالات. يمكن أن يكون المستخدم في عدة مجموعات - ثم يرى المحتوى لجميع هذه المجموعات في وقت واحد.
يتم دمج المجموعات مع بوابات البريد الإلكتروني والرسائل النصية القصيرة. عند العمل مع عميل بنكي ، يمكن للموظف إرسال المعلومات اللازمة إليه بسرعة - على سبيل المثال ، أثناء الاستشارة الهاتفية مباشرة. إذا ، بالطبع ، يمكن إرسال المعلومات ؛ مقالات حول الكشف (ومقبولية الطباعة) تشير إلى سمات فردية. لا حاجة لإعادة كتابة ونسخ أي شيء لصق.
يتم دمج Yandex.Maps أيضًا في قاعدة المعرفة ، والتي من خلالها يرى الموظفون مدى انشغال بعض الإدارات. يتم تحديث المعلومات كل نصف ساعة. لذلك ، بعد تحديد الأقسام التي يمكن للعميل الحصول عليها أو تلك الخدمة ، يمكن للموظفين تقديم النصح حول المكان الذي من الأفضل معالجته بالضبط لتوفير الوقت.
تم دمج KMS Lighthouse مع نظام الواجهة الأمامية الخاص بنا ويمكن جلبه مباشرة إلى واجهة التطبيق المصغّرة. في ذلك ، يمكنك تقديم طلب سريع والانتقال على الفور إلى المقالة - كما هو الحال في أي محرك بحث.
هذه هي الطريقة التي يتم بها تنظيم قاعدة معارفنا الجديدة. نحن الآن بصدد الانتهاء منه ونتوقع ألا يقدّر الموظفون فحسب بل عملاء VTB أيضًا التأثير الإيجابي لتنفيذ منارة KMS.
في الختام ، نريد أن نشارك فرحتنا. في يناير ، تم الإعلان عن مشروع ويكيبيديا للأعمال الخاص بنا هذا العام وفقًا لمدير المعلومات العالمي. سنبقيك على اطلاع ونخبرك بما هو جديد نربطه به وكيف يساعده في العمل.