يجب الحفاظ على النار التي تحترق فيها.
V.O. Pelevin ، "الجيل ف"
مرحبا يا هبر! اسمي ألكسندر سولوفييف ، أنا رئيس قسم الدعم الفني لمراكز بيانات ميران.
قل لي ، هل حاولت كتابة الكتب المدرسية؟ انا لا. ومع ذلك ، فإن النص أدناه هو نوع من دليل التدريب لتنظيم الدعم الفني. كجزء من المقالة ، أود أن أخبركم عن الدعم الفني لمراكز بيانات ميران: أي نوع من "التروس" تدور ولماذا تدور بهذه الطريقة ، وليس غير ذلك.
لراحة القارئ ، سأقسم هذه المقالة إلى عدة أجزاء الدلالية.
- في البداية ، سنتحدث عن العناصر الأساسية لعمل TP - التوظيف ، ودورة حياة التطبيق ، وتحديد الأولويات.
- في الجزء الثاني ، سنتناول قضايا الحفاظ على معرفة مهندسي الدعم الفني على مستوى معين.
- في الجزء الثالث والأخير ، سنتحدث عن كيفية جعل كل ما سبق يعمل.
سأتحدث عن الدافع ، على وجه الخصوص ، غير المالي ، وكذلك سأقدم بعض النصائح حول تنظيم المكافآت والعقوبات للشركات.
أساسيات الدعم الفني
لتنظيم عمل الدعم الفني ، تحتاج إلى إجابة بعض الأسئلة البسيطة:
- يتطلب دعمًا لمنتج واحد (خدمة) أو يتعلق بدعم متعدد المنتجات ، أي دعم العديد من المنتجات المختلفة تماما؟
- ما SLA المطلوب لمكالمات الدعم الفني؟
- هل الدعم على مدار الساعة ضروري؟
أولا
يتطلب دعم Monoproduct عددًا أدنى من المتخصصين. على سبيل المثال ، إذا كنت تتوقع حوالي عشرة تطبيقات لكل نوبة عمل ، فيمكنك محاولة تحويل الدعم إلى مهندس متخصص.
يتطلب الدعم متعدد المنتجات إما اختيار متخصصي المنتجات ، أو فصل حركة المكالمات حسب التعقيد ، وهو ما يتم التعبير عنه في تنظيم العديد من خطوط الدعم.
لقد اتخذنا طريق تقسيم المهندسين وفقًا لمعرفتهم وكفاءاتهم إلى ثلاثة مكونات: خطوط الدعم الفني الأولى والإضافية والثانية.
في المرتبة الثانية
كلما كانت اتفاقية مستوى الخدمة أكثر صرامة ، كلما زادت موارد الشركة التي ستحتاج إلى الامتثال لها. هذه مجموعة متنوعة من الموارد: المهندسين المؤهلين ، وأنظمة المعلومات ، والمعدات ، والوثائق التنظيمية ، إلخ. النظر في مسألة الموظفين. للوفاء بمتطلبات اتفاقية مستوى الخدمة ، يجب أن يتناسب فريق العمل مع متوسط عدد مكالمات الدعم الفني ، مع مراعاة الوقت ومعايير الجودة.
بناءً على ما سبق ، فإن طاقم مهندسينا هو على النحو التالي:
• الخط الأول - 10 أشخاص ؛
• خط إضافي - 4 أشخاص ؛
• السطر الثاني - 5 أشخاص.
ثلث
الدعم الفني على مدار الساعة خدمة باهظة الثمن. سيتطلب الأداء العالي الجودة لهذه الخدمة في وضع 24 × 7 × 365 ما لا يقل عن 5 مهندسين ، وهذا في أبسط الحالات ، أي في حالة دعم منتج واحد. إذا كنت بحاجة إلى تنظيم دعم على مدار الساعة ، فلا تتردد في مضاعفة التكاليف في 5. ولكن أولاً وقبل كل شيء ، فكر فيما إذا كنت بحاجة إليها (هل يمكنك القيام بذلك بدون بوابة خدمة ذاتية ، وما إلى ذلك). إذا كنت لا تزال بحاجة لذلك ، فهل من الممكن الاستعانة بمصادر خارجية.
ماذا يفعل كل هؤلاء الناس؟
تتمثل مهمة مهندسي الخط الأول في معالجة نداء العميل بسرعة وكفاءة. يعني معالجة لتصنيف وإرسال إلى العمل بشكل صحيح.
بعد المعالجة ، يقوم مهندس الخط الأول إما بحل التطبيق من تلقاء نفسه ، إذا كان من قسم "القيام بذلك بسرعة ، هنا والآن" ، أو نقل التطبيق إلى سطر آخر إذا كان "لعب طويلاً" أو كان حول "أعطال".
تتمثل مهمة مهندسي الخطوط الإضافية في العمل مع التطبيقات التي تستغرق أكثر من يوم واحد لإكمالها.
تتمثل مهمة مهندسي الخط الثاني في استكشاف الأخطاء وإصلاحها بأسرع ما يمكن وحل التطبيقات المعقدة "هنا والآن".
أوضاع المهندس
الخط الأول : الجدول الزمني - 2/2 ، نوبات لمدة 12 ساعة من الساعة 8:00 صباحًا وحتى الساعة 8:00 مساءً
خط إضافي : الجدول الزمني - خمسة أيام ، 8 ساعات من 8:00 صباحًا ومن 12:00.
السطر الثاني : الجدول - 2/2 ، 12 ساعة من 8:00 حتي 20:00.
تتم المحافظة على جداول تحويل المهندس من خلال تقويم Google.
دورة حياة وحالة التطبيقات في TP
أسهل طريقة لتتبع دورة حياة التطبيق هي وفقًا لهذا المخطط:
سأشرح بشكل منفصل كل نقطة من النقاط.
- يتم الحصول على الحالة الجديدة بواسطة أي تطبيق تم استلامه من مصدر خارجي. تتمثل مهمة مهندس الخط الأول في معالجة الطلب الذي تم استلامه في البداية ونقله إلى المقاول.
- يتم تعيين الحالة المفتوحة للتطبيق عندما ينشغل أحد المتخصصين بالقرار.
- إذا تم تحديد التطبيق على أنه بريد مزعج ، فسيحصل على الحالة المحذوفة .
- إذا لم يكن التطبيق غير مرغوب فيه ، ولكنه لا يحتوي على نداء أساسي للدعم الفني ، فسيتم تعيين الحالة مرفوضة .
- يتم تعيين الحالة التي تم حلها للتطبيق بعد حل المشكلة / المشكلة وفقًا للأداء.
- الحالة المتوقفة تعني أن العمل في التطبيق قد تم تعليقه مؤقتًا بمبادرة من العميل أو بالاتفاق معه.
- يتم تعيين الحالة المغلقة بعد أن يرى العميل أن مهمته قد تم حلها بنجاح.
كتابة التطبيق
نوع التطبيق هو المعيار الأكثر أهمية. يحدد معدل التفاعل ووقت حل المشكلة المشار إليها في التذكرة. في ميران ، وفقا ل ITIL ، يتم تقسيم الطلبات إلى الأنواع التالية. أعطيهم حسب الأهمية:
حوادثتشمل الحوادث أعطال المعدات وأعطالها ، وكذلك أي أحداث أخرى تنطوي على تدهور كبير في جودة الخدمات. يتم تنفيذ التطبيقات من هذا النوع حسب الأولوية ولها الأسبقية على أنواع التطبيقات الأخرى. الحوادث فقط يمكن أن تكون لها الأسبقية على المعالجة.
أمثلة على الحوادث: عدم توفر الخدمة ، تعطل الأجهزة.RFS - طلب الخدمةيحتاج العميل إلى الخدمة كجزء من الخدمات المقدمة. لا يرتبط الطلب بالفشل أو الفشل في البنية التحتية لتكنولوجيا المعلومات. يتم تنفيذها على الفور في قائمة الانتظار العامة في حالة عدم وجود تطبيقات ذات أولوية.
مثال: طلب لإعادة تشغيل الخادم.RFC - طلب التغييرطلب تغيير في تكوين و / أو نطاق الخدمات المقدمة للعميل. يتم تحديد وقت المعالجة من قبل إدارة الشركة بشكل فردي بالاتفاق مع العميل.
أمثلة: طلب تبديل المعدات.طلب معلومات - طلب معلوماتتم طلب معلومات عن الخدمة ، بما في ذلك تقارير عن حجم استهلاك الطاقة ، وتقارير الخدمة ، إلخ. يتم تنفيذها على الفور في قائمة الانتظار العامة في حالة عدم وجود تطبيقات ذات أولوية.
يتم احتساب أولوية التطبيق ، التي تؤثر على سرعة رد الفعل والقرار ، على أساس المعلومات الواردة من العميل ، مع مراعاة عدد من القواعد والأوامر الداخلية. هناك أولويتان: الأولى والنهائية. يتم تعيين الأولوية الأولية وفقًا للعميل وتحدد سرعة معالجة الحوادث. يتم تحديد الأولوية النهائية من قبل المهندس بعد الانتهاء من العمل وتعكس المستوى الفعلي لتدهور الخدمات. في كثير من الأحيان هذه الأولويات ليست متساوية.
يتم تخصيص الأولويات على النحو التالي:
- تم تعطيل عمل قطاع الشبكة (مركز الاتصالات غير متوفر ، والمفتاح الأساسي غير متاح) - 40 ؛
- تدهور كبير في العديد من الخدمات المقدمة للعميل - 30 ؛
- تدهور كبير في إحدى الخدمات المقدمة للعميل - 20 ؛
- تدهور الخدمات ، التي ليس لها تأثير كبير على طبيعتها - 10 ؛
- لا يوجد تأثير على خدمات العملاء - 0.
أعتقد أن هذا يمكن أن ينتهي بسلاسة تحليل النظرية. خلف الكواليس ، سيكون هناك توقيت لردود الفعل على الحوادث والطلبات ، ومستويات التصعيد ، والتحفيز المالي وغيرها من المعلومات ، أكثر أو أقل من المعايير للشركات الأخرى. دعنا ننتقل إلى أشياء أكثر إثارة للاهتمام.
الحفاظ على المستوى المطلوب من المعرفة
في عمل خدمة الدعم الفني ، نسعى جاهدين لتنظيم كل ما يتم تنظيمه ، ليكون شفافًا للعميل ، وأيضًا لإضفاء الطابع الرسمي على أي معلومات قد تكون مفيدة وقابلة للتطبيق في المستقبل ورقمنتها. التغذية المرتدة من العملاء ، ومستوى معرفة موظفينا ، وإنجازاتهم وواجهاتهم - كل هذا يتم ترقيمه بدقة ، وتحليله ، وبالتالي يؤثر على قرارات الإدارة.
لعدة أيام عطلة ، قد يغير مهندس الدعم الفني بعض اللوائح ، وستظهر لوائح "تمهيدية" جديدة ، مما يعني أنه في بداية التحول ، من الضروري التحقق من أهمية معرفة المهندسين. يتم ذلك بمساعدة تقنية النمذجة الظرفية ، من خلال التدريب لحل المواقف التي تكون فيها المعرفة المحددة مطلوبة. نحن ندعو حالة واحدة القضية. في بداية التحول ، يتلقى المهندس جزءًا من العديد من حالات المستخدم. يتيح هذا النهج للمهندسين الحفاظ على المعرفة اللازمة في أذهانهم وتحديثها باستمرار. نتيجة لذلك ، تزداد جودة العمل. لتقليل الإجهاد ، يتم تحديد الموعد النهائي لحل حالات المستخدم في نهاية فترة التحول ، على الرغم من أنه في الواقع ما يكفي لعشر دقائق من اختصاصي.
ما هي بالضبط حالة المستخدم النموذجية تتكون من؟
هناك 4 كتل الدلالية في المجموع:
- كتلة المعلومات
أنه يحتوي على معلومات مفيدة تحتاج إلى التعلم. - حزمة كتلة
تتيح لك هذه الكتلة ربط المعلومات الجديدة بـ "نقل" هذه المعلومات في الذاكرة البشرية. - خيارات الإجابة
في الواقع ، هذا هو "نقل" المعلومات في الذاكرة. - رابط إثبات
رابط إلى مصدر موثوق حيث يمكنك معرفة هذه المعلومات.
هذا ما تبدو عليه حالة المستخدم القياسية على مثال المواد التاريخيةترتبط جميع كتل usercase في المعنى والموضوع. من الناحية المثالية ، يجب أن تحتوي كتلة المعلومات على تلميح لخيار الإجابة ، وللتوضيح ، تحتاج إلى فتح دليل تجريبي ودراسة تفصيلية للسؤال الذي يتم فحصه هناك.
من خلال تقديم هذه الممارسة ، صادفت لحظة واحدة غير سارة: لا توجد أداة كاملة واحدة في السوق تسمح لك بتخزين قاعدة معرفية ، وتوزع "حالات المستخدمين" بشكل ذكي على المستخدمين وتحقق من إجاباتهم.
حاليا نحن نستخدم مجموعة من الأدوات.
- Request Tracker (RT) - يحدد منطق تفاعل الأنظمة.
- "تقويم Google بواسطة API" يعطي "قائمة الموظفين" وعدد حالات المستخدم لكل منهم.
- توفر جداول بيانات Google معلومات لتشكيل حالة مستخدم.
في الواقع ، يعمل النظام على النحو التالي:
- يتم تشكيل قائمة من الموظفين المشاركين في تدريب المعرفة.
- لكل موظف ، يتم تعريف موضوعات حالات المستخدم.
- يتم إنشاء حالة المستخدم لكل موضوع ونقلها إلى الموظف.
- خلال يوم العمل ، يجب على المهندس حل جميع حالات المستخدم.
- يتم التحقق من الإجابات ، ويتم تخزين نتيجة التحقق من كل حالة المستخدم في النظام.
مهندس جيد يحل حالة مستخدم واحد في حوالي دقيقة. إن الغش و "العد" يمثل مشكلة كبيرة ، فقد اعتنينا بنظامنا لمكافحة الغش.
تذكر: لا تحاول بأي حال من الأحوال إدارة مستوى معرفة الموظفين في تلك الأقسام التي لا تتحكم فيها بالتحفيز.بندقية ، الببغاوات والدافع
تحدثت بتفاصيل كافية حول كيفية عمل خدمة الدعم الفني. يبقى أن نفهم نقطة مهمة أخرى: لماذا تعمل حتى؟ :)
كل شيء يقع على عمودين. هذه الركائز هي الدافع غير المالي والمالي.
وقال رجل العصابات الشهير آل كابوني: "بكلمة لطيفة وبندقية يمكنك تحقيق أكثر بكثير من مجرد كلمة لطيفة". للأسف ، في هذا الحافز المالي المجاز كلمة طيبة ، وغير المالية بالفعل مدفع "قديم جيد".
الدافع غير المالي
الركائز الثلاث للدوافع غير المالية: الجوع ، والبرد ، وموضوعية التقييم ، دليل على الاستحقاق ، وسهولة الإدارةيتفاعل أي شخص بشكل سلبي للغاية مع الغرامات التي يتم التعبير عنها بالمال ... ولكن لحسن الحظ ، يسهل عليهم القلق بشأن الغرامات في "الببغاوات". وفي الوقت نفسه ، الببغاوات ، إذا كنت تستطيع طهيها ، تحفز الموظفين بشكل كبير للغاية.
لقد اخترنا الجودة.
الببغاء مطفأ ، لكن من الناحية النظرية يمكنك اختيار شيء آخر. وقت الفراغ جيد لأننا نشعر به من قبل جميع الموظفين ، إنه مطلوب للهدف المقصود منه وليس هناك حاجة لشرح المرؤوسين ما هو وما هو. بادئ ذي بدء ، عند اختيار وحدة حساب ، ينبغي للمرء أن ينطلق من حقيقة أنه لا ينبغي أن يكون "حصان كروي في فراغ". يجب أن تكون الوحدة المحاسبية ملموسة للموظف.
في إطار الدوافع غير المالية ، لا يُحرم الموظفون من المال ، ولكن يُحرمون من إجازة ، وبالتالي ، فرصة استخدام فوائد الدوافع غير المالية. هذا غير سار ، لكن ليس مثل الغرامة: هناك حافز للنمو ، ولا يعاني ولاء الشخص للشركة. يتم تشجيع "مآثر" عن طريق إجازة. يمكن للموظف استخدام يوم العطلة للغرض المقصود منه: على سبيل المثال ، الاستلقاء في المنزل ، ولكن هذا ليس مثيرًا للاهتمام. من الممتع
أن تذهب إلى كازينو مع لعبة ورق و mademoiselle لتدفع بعض الوقت للأحداث المهمة بالنسبة لك أو لشركتك ، على سبيل المثال: الخدمات الطبية خارج VHI ، أو الحصول على شهادات احترافية ، أو حزم اللياقة البدنية أو الجولات السياحية ، أخيرًا.
الوقت الوحيد الذي يقضيه الإجازة مقارنة بالمال هو أن كل حالة استخدام ، سواء بشكل مباشر أو من الناحية النقدية ، تحتاج إلى التحقق بشكل منفصل من قبل السلطات ، وهو أمر غير مناسب دائمًا. سعر إجازة منا هو 3000 روبل ، قد يكون لديك أكثر أو أقل. الشيء الرئيسي هو الراحة المتبادلة من استخدام وحدة من الحوافز غير المالية.
اسمحوا لي أن أقدم لكم مثالاً حياً عندما يتم منح عمل معين بطريقة غير مالية.
لا يعد إعداد مستندات جيدة تحتوي على حالات مستخدمين لقاعدة المعرفة مهمة مثل العملية. كل شهر يظهر شيء جديد: العملاء ، المعدات ، البرامج. كل هذا ، للأسباب التي سبق ذكرها أعلاه ، يتطلب عناية ووثائق دقيقة.
إذا كنت في البداية عملت على تجميع هذه الوثائق بنفسي ، فإن نظام تجديد قاعدة المعرفة يعمل الآن بشكل شبه مستقل. مهمتي هي توجيه الموظفين في الاتجاه الصحيح ، ومنحهم ناقل حركة وتنفيذ مراقبة الخروج.
تُظهر تجربتي أن "سعر" مستند واحد جيد مزود بعدد كافٍ من حالات المستخدم هو ثلاثة أيام عطلة.
يتلقى المهندس إجازة لمدة يومين لمستند لا يتطلب تصحيحات مهمة.
يتلقى الشخص إجازة ليوم واحد إذا كانت هناك حاجة إلى العديد من التصحيحات ، ومن الأسهل إجراءها بنفسك من شرح كيفية القيام بذلك بشكل صحيح.
حاولنا إعطاء المزيد من الوقت لهذا العمل - من 10 أيام أو أكثر. لكن الممارسة أظهرت أن الكثير من المكافآت تتلاشى ، ولا يوجد عملياً أي شخص يريد الحصول عليها. لذلك ، من المهم عدم المبالغة في ترقية الموظفين. يمكن أن تجعلك جانبية في الطريق الأكثر غير متوقعة. التجربة ، ولكن القيام بذلك بعناية.
الدافع المالي
يكافأ كل تطبيق يكمله مهندس TP بالمكافآت. تتناسب قيمة المكافأة بشكل مباشر مع تعقيد التطبيق والمؤهلات المطلوبة لتنفيذه. يتم تحديد الراتب النهائي للمهندس من خلال مجموع هذه المكافآت. بطبيعة الحال ، في حالة تحقيق "ملتوية" للتطبيق ، المكافأة لأنها تحترق.
فارق بسيط آخر: راتب المهندس هو دائما في النطاق الذي يحدده موقفه. في الشهر الأكثر كسولًا ، لن يحصل الشخص على أقل من الحد الأدنى لهذا النطاق ، ولن يحصل على أكثر من الحد الأعلى في أكثرها إنتاجية. ومع ذلك ، لن يترك أحد مهانة: تتم معاقبة كل عضادات ، ويتم تشجيع المعالجة من خلال الدوافع غير المالية.
لتلخيص
لقد تبين أن المقال ضخم للغاية ، لكن هذا ليس مفاجئًا: لقد درسنا حياة الدعم التقني لميران بالكامل تقريبًا ، مع حذف أكثر التفاصيل مملة أو عامة. ومع ذلك ، إذا نسيت مع ذلك الكتابة عن شيء مثير للاهتمام بالنسبة لك ، أو أثناء القراءة كان لديك أسئلة تتعلق بتنظيم خدمة TP ، سأكون سعيدًا بالإجابة عليها في التعليقات.
المواد ذات الصلة