IT

Приемане на инциденти и ескалация

Технологичните инциденти навлизат през различни канали и губят сериозност, собственост и дисциплина за ескалация по време на реакция.

Бизнес проблем

Технологичните инциденти навлизат през различни канали и губят сериозност, собственост и дисциплина за ескалация по време на реакция.

Какво виждат отборите

  • Работно изчакване между получаване на инцидент и валидиране на засегнатата услуга.
  • Собствениците възстановяват състоянието от Generic webhook и Jira.

Защо се случва

  • Няма споделено състояние, обхващащо Generic webhook, Jira, Slack.
  • Правилата за решение и изключение се прилагат непоследователно.

Защо става скъпо

  • Капацитетът се изразходва от координиране и преработка.
  • Късните изключения отслабват видимостта и качеството на услугата.

Бизнес резултати

  • По-кратък цикъл на задача за създаване след инцидент
  • По-малко изключения за предаване и липсваща информация
  • Изчистете собствеността от получаване на инцидент, за да създадете задача след инцидент
  • Подлежащи на проверка решения и възстановяване

Измерими KPI

  • Време за изпълнение: Изминало време от получаване на инцидент до създаване на задача след инцидент.
  • Степен на ръчна намеса: Дял на артикулите, които се нуждаят от лице извън определените условия за преглед.
  • Изключение възраст: Време неразрешените изключения остават без завършено действие.
  • Процент на успешно завършване: Дял на валидни елементи от работния процес, завършващи без отказ на терминала.

Как работи работният процес

  1. Получаване на инцидент — Приемете и идентифицирайте приемането на инцидента и задействането на ескалацията. Обща уебкукичка
  2. Валидирайте засегнатата услуга — Изпълнете валидиране на засегнатата услуга с валидирани примерни данни и резултат, който може да се провери. Обща уебкукичка
  3. Приложете правилата за строгост — Изпълнете прилагане на правила за строгост с валидирани примерни данни и резултат, който може да се провери. Джира
  4. Задайте собственик на инцидента — Изпълнете присвояване на собственик на инцидент с валидирани примерни данни и резултат, който може да се провери. Отпуснатост
  5. Уведомете отговарящите — Изпълнете отговорите за уведомяване с валидирани примерни данни и резултат, който може да се провери. Обща уебкукичка
  6. Ескалиране с времето — Изпълнете ескалация по време с валидирани примерни данни и резултат, който може да се провери. Джира
  7. Рекордна резолюция — Изпълнете резолюция на записа с валидирани примерни данни и резултат, който може да се провери. Отпуснатост
  8. Създаване на задача след инцидент — Изпълнете задача за създаване след инцидент с валидирани примерни данни и подлежащ на проверка резултат. Обща уебкукичка
  9. Одит и актуализация на KPI — Поддържайте резултата от изпълнението, фактите от одита и събитията за измерване на работния процес. Магазин за екзекуции SEIDO

Интеграции и собственост

  • Обща уебкукичка: Предоставете информация за работния процес
  • Джира: Търсене и актуализиране на контекста
  • Отпуснатост: Получаване на контролиран резултат

Човешка отговорност: Собственик на ИТ услуги

Отказ и възстановяване

Общият webhook временно не е наличен.

Повторен опит с ограничено експоненциално забавяне; запазете изпълнението и го преместете в инспектируемата опашка за отказ след лимита.

Необходимите данни за проверка на засегнатата услуга са неправилно формирани или липсват.

Спрете действията надолу по веригата и покажете липсващите полета, изходните доказателства и коригиращите действия на посочения проверяващ.

Тригерът или събитието на доставчика се доставят повече от веднъж.

Върнете съществуващото изпълнение, идентифицирано от ключа за идемпотентност, и не повтаряйте бизнес действия надолу по веригата.

Човешкото решение изтича преди завършване.

Ескалирайте до конфигурирания заместител, запазете оригиналната заявка и запишете както изтичането, така и преназначаването.

Кога не трябва да се изгражда това

  • Месечният обем е твърде малък, за да оправдае интегрирането на Generic webhook, Jira, Slack.
  • Съществуваща конфигурирана платформа вече обработва приемането и ескалацията на инциденти с подходяща собственост и докладване.
  • Няма надежден източник на данни или поддържан API достъп.
  • Никой собственик на бизнес няма правомощия да определя решенията и правилата за изключения.

Свързани работни процеси

Интелигентно входящо маршрутизиране на потенциални клиентиПотенциалните клиенти пристигат чрез несвързани формуляри, входящи кутии и кампании и се присвояват твърде бавно или на грешен собственик.Квалификация на водещи клиенти и работен процес за приспособяване към акаунтаТърговските представители прекарват ценно време ръчно в проучване на перспективи, които не отговарят на търговския профил.Откриване на продажби към структуриран CRMВажни детайли от обаждания за откриване и бележки не достигат до CRM последователно, което отслабва проследяването и прогнозирането.