مرحبا بالجميع! اسمي أليكسي فولكوف. بالتعاون مع زميلي ، المطور Alexander
Solovyov (
alsov ) ، نقوم بتقديم خدمات الويب الداخلية في DataLine. في هذا الخريف ، أطلقنا مكتب خدماتنا ليحل محل BMC Remedy. سأخبرك في منشور ما عن سبب رفضنا للحل الجاهز وفعلنا كل شيء بأنفسنا.
في المتوسط ، يذهب 450 طلبًا إلى مكتب الخدمة يوميًا.ماذا العلاج لا يرجى لنا؟
لقد بدأت ممارسة العلاج فورًا تقريبًا عندما وصلت إلى DataLine. بعد محاولات متكررة للانتهاء من مهامنا ، قررنا إنشاء مكتب خدمتنا. فيما يلي قائمة غير مختصرة بالأسباب التي دفعتنا إلى التخلي عن نظام طلب إجراء علاج من BMC:
واجهة غير مريحة. لتسجيل طلب ، خذه إلى العمل ولاحظ إذنه ، كان علينا أن نجعل 100500 نقرات.
صفحة مع الحادث. خذ على الأقل الحقول لمحتوى الرسالة التي يلزم فتحها في نافذة خاصة.
يجب فتح سلسلة كاملة من علامات التبويب لكتابة حل أو إعادة توجيه الحادث إلى منفذ آخر.التكامل مع واجهات العميل الأخرى وأي تحسينات اقترح حتى تلك الرقصات مع الدف. البرمجيات الاحتكارية ، لم يكن هناك مجال للمناورة تقريبًا. كانت الثغرات الوحيدة هي خدمات الويب التي عرفت كيفية التواصل مع علاج ، لكنها كانت مزاجية للغاية وغير مستقرة. لقد فعلنا بعض الأشياء يدويًا تمامًا وبدقة: أتذكر كيف قمنا بتهيئة تحميل التقارير عن الحوادث بمساعدة مختارات من قاعدة البيانات.
بالطبع ، كان هناك طريقة أخرى: لتوظيف المقاول وتحقيق أي نزوة. في ذلك الوقت ، كان هناك متعاقد واحد فقط في السوق لهذا البرنامج ، وكان على علم به. يجري تعديل عمليات الإنتاج ، وستكون هناك حاجة باستمرار إلى التحسينات. مع وضع ذلك في الاعتبار ، تبين أن السعر غير إنساني وبدأ في 5 ملايين.
لا تراخيص كافية. مرة واحدة في فجر DataLine ، اشترينا 100 ترخيص. منذ ذلك الحين ، نمت الشركة بشكل كبير. التراخيص كانت تتنافس. على نحو متزايد ، نشأت مواقف عندما اضطر مهندس إلى الانتظار حتى يتم إصدار الرخصة من أجل البدء في أداء وظيفته. في الواقع ، كان هذا القشة الأخيرة.
إصلاح جميع الإجراءات الحادث . أردنا أن ينعكس كل ما يتعلق بالدعم الفني لعملائنا في مكتب الخدمة. علاج ، في الواقع ، فقط الطلبات المسجلة. تم تنفيذ كل العمل الحقيقي بشأن الحادث في مراسلات البريد ، عن طريق الهاتف ، في غرفة التدخين - في أي مكان ، ولكن ليس في علاج. خاصة إذا كان تطبيقًا معقدًا وشارك فيه متخصصون من عدة أقسام. لقد قاموا بحل المشكلة ، لكن لم يكن هناك أي أثر لذلك في علاج. ونتيجة لذلك ، تم توثيق الحادث في شظايا ، وأحيانا لم يظهر على الإطلاق في علاج. كان من الصعب للغاية السيطرة على أي شيء وفهمه وتحليله.
مكتب الخدمة 2.0
وكانت وظائف علاج سهلة ليحل محل. تتمثل المهمة الرئيسية لمكتب الخدمة الجديد في سحب جميع أنشطة الدعم الفني إلى "نافذة واحدة": جهات الاتصال ومراسلات العمل والمستندات. أردنا الحصول على نوع من تسجيل كل ما يحدث بعد أن يرسل العميل طلبًا إلينا للحصول على الدعم. على طول الطريق ، أردنا أتمتة العديد من الأشياء من أجل تقليل الحمل على السطر الأول من الدعم والقضاء على العامل البشري إلى أقصى حد.
فيما يلي أهم الوظائف التي قمنا بتنفيذها في مكتب الخدمة الجديد:
نقل الحادث. نتلقى في كثير من الأحيان تطبيقات معقدة ، والتي يتم تنفيذها في سلسلة من المتخصصين من مختلف الإدارات. من أبسط ، تطبيق للوصول الفعلي إلى المعدات في مركز البيانات. أولاً ، يقوم المرسل بكتابة تصريح مرور ، ثم يقوم بتمرير بيانات العميل ورقم المرور إلى المهندس المناوب الذي يلتقي ويرافق العميل في مركز البيانات. هناك طلبات تعمل باستمرار على 5 أقسام.
بالنسبة لجميع هذه الحالات ، ظهر زر "إرسال" منفصل في الواجهة.
المراسلات مع العميل والزملاء. هذه الوظيفة هي فقط للتأكد من أن المراسلات الخاصة بالحادث لا "تتسرب" إلى البريد وأن تاريخ الاتصال بكامله قد تم حفظه معنا.
حتى الآن ، كل شيء في أضيق الحدود. تتمثل الخطط في إنشاء محرر نص كامل مع القدرة على تنزيل الملفات ، الجداول ، إلخ.
تاريخ التعيينات وتاريخ جميع أنشطة الحادث. تساعدك علامات التبويب هذه في حل المشكلات المثيرة للجدل والتحقيقات الداخلية. في الوقت الحالي ، أقوم بتنزيل تقارير من السجل لمراقبة عدد المرات التي يرتكب فيها المرسلون الأخطاء عند تعيين حادث لمجموعة ملف تعريف.
هذه هي قصة مواعيد الحادث الداخلي "إقالة موظف".
تاريخ الحادث. هنا سنواصل إحضار الجمال ، لكن المهمة الرئيسية قد تم حلها بالفعل - يتم تسجيل كل شيء.مراقب. يحدث أنه في خطاب التطبيق ، يقوم العميل بتثبيت نسخة من الأشخاص المهتمين في نسخة. سوف يظهر كل هؤلاء الرفاق في علامة التبويب "المراقبون" ومراقبة تنفيذ هذا التطبيق. سوف يتلقون دقات حول حالة الطلب ، إذا رغبوا في ذلك ، فسيكونون قادرين على التواصل مع الدعم الفني لدينا. هذه الوظيفة داخل الشركة مطلوبة أيضًا: يمكن لمديري الخدمات أن يتناسبوا مع أي طلب من عملائهم ومراقبة تنفيذه.
يمكن تعديل قائمة المراقبين: حذف وإضافة مراقبين جدد.
أنماط الحادث. هناك الكثير من الاستفسارات النموذجية. من أجل عدم ملء طلب للحصول على تصريح أو تنظيف القمامة عشرات المرات في اليوم ، أضفنا القدرة على إنشاء قوالب الحوادث. كل ما تحتاجه هو النقر فوق الزر "إنشاء حادث" ، وسيتم فتح قالب تم تعبئته مسبقًا مع المنفذ المحدد ، والنوع والأولوية والحالة.
هناك العديد من التطبيقات المتكررة بشكل منتظم في عمل مراكز البيانات: الجولات والاختبارات والفحوصات الخاصة بالمعدات الهندسية وفقًا لقوائم الفحص ، وما إلى ذلك. لهذا الغرض ، يتم إعداد حوادث السيارات ، والتي تقع تلقائيًا في جهاز التعقب بتردد معين.
تحليلات. لم تكن هناك أدوات تحليل مدمجة في علاج ، لا يمكن تفريغ أي شيء بالأدوات العادية. قدمنا هنا لتفريغ كل شيء وكل شيء لمزيد من التحليل. على سبيل المثال:
- عدد الطلبات في اليوم الواحد ؛
- سرعة الاستجابة
- التأخير في الطلبات ؛
- أنواع الطلبات
- التحميل من قبل الإدارات.
- المرسلين العمل ؛
- تواتر ونوعية المشاكل الناشئة في سياق العملاء ؛
- تبعيات مختلفة ، على سبيل المثال ، سرعة التنفيذ على نوع الطلب.
بعد ذلك بقليل ، نريد إنشاء لوحات معلومات مع المخططات والرسوم البيانية ، حتى يتسنى لنا الحصول على صورة عما يحدث في الدعم الفني دون أي تفريغ وسحر في Excel.
يمكن إنشاء التقارير مباشرة في مكتب الخدمة باستخدام المرشحات.
تفريغ البيانات في أشكال مختلفة.
يمكنك تحديد الحقول التي سيتم عرضها في التحميل.API للتكامل مع الخدمات الداخلية الأخرى. من طريقة بسيطة: يقوم مكتب الخدمة بسحب المعلومات من الدلائل مع قائمة بالشركات العميلة والعقود وقائمة بالخدمات المطلوبة والأشخاص المسؤولين الذين يمكنهم إرسال الطلبات. في السابق ، كان عليك أولاً التحقق من ملف منفصل لتحديد ما إذا كان الكاتب عميلًا وما إذا كان يمكنه كتابة طلبات من الشركة.
"تجاوز الالتفاف في الخدمة" هو آخر من خدماتنا الداخلية ، حيث أصبح مكتب الخدمة قادرًا الآن على التفاعل. هذه قائمة تدقيق إلكترونية ، يقوم فيها ضباط الخدمة ومهندسو الصيانة بفحص مراكز البيانات عدة مرات في اليوم بحثًا عن الأعطال والاضطرابات. مثال على ذلك: أثناء الالتفاف ، تعثر المضيف على مكتب العميل مع معدات مثبتة بشكل غير صحيح. يقوم ببساطة بتقديم ملاحظة مقابلة في برنامج Bypass ، ويتم تلقائيًا وصول حادثة تتعلق بالمشكلة إلى مكتب الخدمة. يمضي المضيف على طول الطريق الالتفافي ، وبدأ بالفعل حل مشكلة الاستقبال.
يمكن إنشاء حادث لأي من عناصر قائمة الاختيار.
نموذج لحادث داخل برنامج تجاوز. فوق حوادث شنق في العمل على نفس الكائن.على الأشياء الصغيرة. جميع أنواع الطلبات الأكثر شيوعًا التي نعرضها على صفحة الواجهة. بعد اختيار إحدى الأولويات ، يرى المستخدم الموعد النهائي وشريط التقدم ، مع توضيح مقدار الوقت المتبقي لديه لتنفيذ الحادث.
التنفيذ
أثناء العملية التجريبية ، قمنا باختبار مكتب العمل على التطبيقات الداخلية. حوالي شهر تدربوا في أقسام AXO ، بناء رأس المال ، وإدارة الإنتاج والخدمات. واصلت التطبيقات الخارجية والتطبيقات من الإدارات الأخرى للذهاب من خلال الانتصاف.
ثم اتفقنا مع ثلاثة عملاء لتشغيل معالجة التطبيقات الخارجية. هذا هو المكان الذي حدثت فيه المشاكل الأولى.
عندما بدأوا للتو في إنشاء مكتب خدمة جديد ، أعربت عن تقديري للأمل في أن يتمكن محلل البريد الإلكتروني لدينا من تسجيل الطلبات ونشرها من خلال الإدارات المتخصصة وإرسال رسائل حول نفس المشكلة في حادثة واحدة. في المستقبل ، كان هذا يعني التخلي عن المرسلين بشأن معالجة الطلبات المكتوبة. في Remedy ، اعتاد الناس للغاية على الاعتماد على المراسلات البريدية ؛ كان هناك أكثر مما توقعنا. فشل المحلل اللغوي في اختبارات الاختبار: فقد يخلط الأقسام عند تقديم طلب ، وقام بتسجيل رسائل جديدة في حادث مفتوح بالفعل كحوادث جديدة. كانت هناك صعوبات أكثر تافهة: لم يتمكن المحلل من قراءة الرسالة التي جاءت من البريد مع الشهادة ؛ لم أفهم الترميز غير القياسي وأرسلت النص من الأسئلة.
اضطررت لإضافة العمل اليدوي - ظهرت غرفة التحكم. هذا هو المطهر لجميع التطبيقات التي جاءت إلى
support@dtln.ru . من هناك ، يقوم المرسلون بتوزيع التطبيقات يدويًا حسب الإدارة.
على جانب العميل ، بقي منطق التفاعل مع الدعم الفني كما هو ، ولم يتغير سوى مظهر الإيقاعات. في الأيام الأولى ، كان هناك عدة تراكبات معهم ، ويرجع ذلك أساسا إلى تفاصيل الاتصال غير صحيحة في الدلائل. لذلك كان لدى أحد العملاء 23 شخصًا مسئولًا وجميعهم لديهم بريد إلكتروني مشترك واحد ، مثل info @. قام مكتب الخدمة بإخطار الجميع بكل طاعة ، وتحقيق المعدل اليومي لمدة ساعة من خلال البريد الوارد في صندوق البريد هذا.
ما التالي؟
في المستقبل القريب -
التكامل مع حسابي . سيتم عرض جميع المراسلات وسجل الاتصال في ملف تعريف العميل. من الناحية النظرية ، هذه فرصة لاستبعاد البريد من التواصل مع الدعم الفني وأخيراً سحب العميل إلى واجهة الويب الخاصة بنا. دعونا نرى كيف يأخذ الجذر في الحياة.
تنفيذ تطبيق معلمات . هناك استعلامات تحتوي على العديد من المعلمات والقيم ، ومن المهم عدم خلط أي شيء بها. على سبيل المثال ، عندما يطلب العميل إضافة موارد افتراضية إلى التجمع أو إنشاء أجهزة افتراضية بأحجام معينة. لمثل هذه الحالات ، نخطط لإنشاء مُنشئ ذي معلمات. سيتم تحليل طلبات العميل المستلمة تلقائيًا عن طريق البريد. سيتم استخدامه بواسطة المرسلين عند قبول الطلبات عبر الهاتف.
هذا هو ما يشبه ترتيب المعلمات.تقييم الدعم الفني. سيئ السمعة "تقييم خدمتنا على نطاق من خمس نقاط" مع القدرة على الكتابة في شكل حر ، كل ما يفكر العميل حول خدمتنا.
نريد تطوير
غرفة Dispatch ذاتها ، التي نشأت كعكاز لمساعدة محلل البريد ، في مكان عمل متكامل تمامًا
للمرسل (AWP) . يجب على المرسل الآن أن يبحث في واجهات مختلفة (محاسبة المعدات ، قائمة بالأشخاص المسؤولين ، خدمات العملاء) لجمع المعلومات اللازمة عن العميل. في AWP ، سيكون كل شيء في نافذة واحدة: حوادث العملاء ، جهات الاتصال ، العقود ، الخدمات المطلوبة ومعاييرها ، إلخ.
حسنًا ، لا تفقد الأمل في
التوزيع التلقائي للتطبيقات حسب الإدارة . نحن الآن نفكر في استخدام نظام الهاشتاج لمحلل البريد الإلكتروني.
***
يعمل مكتب الخدمة في وضع القتال منذ نوفمبر ، وقد رأيت طوال هذا الوقت زيادة مطردة في عدد الحوادث (+ 40٪) ، ويرجع ذلك أساسًا إلى الطلبات الداخلية. أجرؤ على أن آمل أن يكون هذا بسبب حقيقة أن مكتب الخدمة الجديد أكثر ودية من جميع النواحي ، وتوقفت الطلبات عن تجاوزه.
ربح آخر من مكتب الخدمة الجديد هو المرونة. لقد قمنا بالفعل بتقديم العديد من الحلول المخصصة للعملاء الفرديين من أجل الاندماج مع مكاتب الخدمة الداخلية الخاصة بهم أو ببساطة التكيف مع عمليات الإنتاج الخاصة بهم. في السابق ، قد يستغرق الأمر شهورًا وملايين ، ولكن الآن كل ما نحتاج إليه هو خطاب إلى مطورك و1-2 أسابيع حسب تعقيد المهمة.