Продолжаем разговор с Ириной Курбатовой, директором техподдержки Облакотеки, о процессной документации. В прошлый раз говорили, как с ее помощью сохранять надежность сервиса. Сегодня — как повысить уровень зрелости.
⏪ Один из переводов цитаты Уинстона Черчилля звучит так: «Улучшаться — значит изменяться, быть совершенным — значит меняться постоянно». Но в обратную сторону этот тезис может уже не работать: меняться — не значит становиться лучше.
Процессная документация помогает бизнесу реализовывать не изменения ради изменений, а проводить такие улучшения, которые позволяют развиваться непрерывно.
❓Как это работает? Сначала направления, в которых компании важен предсказуемый результат, делят на процессы. Например, в облачной компании это запуск, изменение и обеспечение доступности услуг, поддержка пользователей и т.д.
Далее каждый процесс описывают, оценивают его текущее состояние и повышают уровень зрелости. Упрощенно говоря, каждый уровень зрелости отвечает на свои вопросы: «Кто/ где?», «Когда?», «Что конкретно/ как именно / сколько?», «Для кого/ зачем?» и, наконец, «Какие есть альтернативы?».
Задача процессной документации — сделать так, чтобы эта информация была доступна нужным людям в нужный момент и никто ничего не перепутал, не упустил. При этом результаты применения этой информации были предсказуемыми и успешными.
❓Что там должно быть? Процессная документация строится вокруг структуры, которую мы описывали в прошлом посте. Обязательным элементом будет схема процесса, где отображена последовательность действий и по каждому шагу указаны:
🧩 ответственный и исполнители;
🧩 что должно прийти «на вход» (информация, результаты предыдущих шагов);
🧩 инструменты и среды для работы;
🧩 требования (нормативы по срокам, инструкции, законодательство и тд);
🧩 результаты шага (отчет, доступный сервис и др.);
🧩 коммуникация.
❓А как на практике? Для примера посмотрим, как перечисленные атрибуты проявляются в процессе «Управление нештатными ситуациями» на шаге «Первичный анализ и эскалация».
Ответственный: дежурный инженер.
На вход: алерт мониторинга, сообщение от клиента.
Инструменты и среды: чат рабочей группы, система Helpdesk, среды управления инфраструктурой.
Требования состоят из сроков и минимально необходимых действий:
➡️ проверить состояние элементов инфраструктуры, связанных с алертом об отклонении от штатных параметров,
➡️ принять решение о необходимости эскалации на экспертную группу,
➡️ уложиться в срок до 6 минут.
Результаты: принято решение о необходимости эскалации; зафиксированы итоги первичной проверки (ключевой симптом, статус элементов инфраструктуры, связанных с алертом).
Коммуникация: информация по результатам передана в клиентский сервис и руководителям подразделений, чьи элементы инфраструктуры затронуты.
Будет ли документация торжественно называться «регламентом», или по-свойски «шпаргалкой», не так важно. Главное, чтобы все участники одинаково понимали: что от них ждут, в какой срок и с какими параметрами качества ⏩.
#Ирина_поддержи