Что такое управление проблемами и как перестать чинить одно и то же

Зачем управление проблемами

ПроблемаПроблемаПричина одного или нескольких инцидентов.ITIL — это причина одного или нескольких инцидентовИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами, которая ещё не установлена 1. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 управления проблемами существует ради одного: уменьшить число и тяжесть будущих инцидентов. Не восстановить работу — восстановление остаётся за INCУправление инцидентами, — а сделать так, чтобы восстанавливать пришлось реже.

Из этой цели следует всё остальное устройство практики, и главное здесь — разный способ измерения. Управление инцидентами меряется временем: чем быстрее вернули услугуУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation, тем лучше. Проблемы временем не меряются. Расследование может занять месяц — и это не провал, если за месяц причину действительно нашли и закрыли. Смешение двух мер — самая частая и самая дорогая ошибка при постановке практики: как только на расследование причин ставят срок из соглашения об уровне услугСоглашение об уровне услугЗаписанная договорённость поставщика и заказчика: что даёт услуга, когда доступна и как быстро её восстановят.ITIL 4: практическое руководство Service Level Management и книга ITIL Foundation, 5.2.15.1; ГОСТ Р ИСО/МЭК 20000-1-2021, пункты 3.2.16, 3.2.20, 3.2.21, 7.5.4, 8.3.2–8.3.4; FitSM-0, FitSM-1 (PR2), FitSM-2 (PR2), шаблон и образец SLA из FitSM-4; MOF 4.0, глоссарий; itSMF, «Введение в ИТ Сервис-менеджмент», 2003; Ami Nahari, «Secrets of Service Level Management», TSO, 2013; Молоткова, Сахаров, «Качество услуг ИТ-аутсорсинга», 2008; «Аутсорсинг в стратегии современного бизнеса», 2019; альманах itSMF России, 2015; «Свободный ITIL» Елхимова; Брукс, «Метрики для управления ИТ-услугами» (SLA), расследование превращается в формальность.

Отсюда же неудобная новость для того, кто эту практику внедряет. Управление проблемами не окупается быстро. Первые несколько месяцев видно только затраты: люди тратят время на разбирательства вместо того, чтобы закрывать заявки. Отдача приходит позже и видна в управлении инцидентами: число инцидентов падает, а хвалят службу поддержкиСлужба поддержки (service desk)Единая точка контакта между теми, кто пользуется ИТ-услугами, и теми, кто их предоставляет: сюда приходит обращение и здесь оно должно быть зафиксировано.ITIL 4, практическое руководство Service Desk; MOF 4.0. Практика, у которой нет отдельного владельца и отдельной меры, в этот момент тихо умирает.

ITIL называет цель практики так: сократить вероятность и влияние инцидентов, выявляя их фактические и потенциальные причины и управляя обходными решениями и известными ошибками 1. ГОСТ Р ИСО/МЭК 20000-1 требует того же, но обязанностью: организация должна выявлять причины инцидентов, определять действия по их устранению и вести известные ошибкиИзвестная ошибкаПроблема с установленной причиной, для которой есть обходное решение.ITIL 4. COBIT 2019 говорит то же третьими словами: выявлять и классифицировать проблемы и их корневые причины, устранять в срок, чтобы инциденты не повторялись, и давать рекомендации по улучшению 5.

Инциденты закрывают, чтобы максимально быстро вернуть работоспособность сервису. Проблемы закрывают, чтобы возвращать её приходилось реже. Один и тот же человек не может делать и то, и другое в один и тот же момент.

Когда практика работает

Практика считается работающей не по наличию регламента и не по числу заведённых записей, а по трём результатам, которых либо добились, либо нет. К ним стоит возвращаться по ходу чтения: почти каждый следующий раздел объясняет, как добиться одного из них.

Повторяющиеся инциденты перестают повторяться. Как проверить: известна доля инцидентов, привязанных к проблемам, и по каждой закрытой проблеме видно, как снизилось число повторяющихся инцидентов. Пока эта связь не считается, результата не видно — практика работает вхолостую, даже если записи ведутся исправно.

У первой линииПервая линияСпециалисты, принимающие обращения и решающие типовое по базе знаний.Разбор практики управления инцидентами на портале есть чем закрыть инцидент, пока причина не устранена. Как проверить: обходное решение записано и доступно тому, кто принимает обращение, а не лежит в переписке. Обходное решениеОбходное решениеСпособ снизить или устранить последствия инцидента, когда полного решения ещё нет.ITIL 4, практическое руководство по управлению инцидентами, о котором знают только трое, — не результат практики, а личное знание троих.

Причины ищут не только после аварий. Как проверить: часть проблем заведена по итогам анализа накопленных данных, а не по факту громкого сбоя. Если все записи в журнале проблем заведены после крупных инцидентов, практика реактивна целиком, и потолок её — не допустить повторения того, что уже случилось.

Эти признаки удобны тем, что видны в работе: по каждому можно ответить «да» или «нет», не открывая регламент. Развёрнутая шкала — ниже, в разделе про зрелость.

Что входит и что рядом

Половина споров про управление проблемами — это спор о границе с управлением инцидентами, и проводят её каждый по-своему. Ниже она проведена явно, со ссылкой, куда идти за тем, что осталось снаружи 1 2.

Отдельно про три границы, которые чаще всего стирают.

Проблема и инцидент. Инцидент — событие, проблема — причина. Разница не терминологическая: у них разные цели, разные сроки и, как правило, разные ответственные. Признак того, что граница стёрта, узнаваем: в журнале проблем лежат записи, заведённые в тот же час, что и инцидент, и закрытые в тот же день. Это не проблемы, это переименованные инциденты.

Проблема и дефект. Не всякая причина инцидента — проблема в смысле этой практики. Разницу хорошо проводит рабочий регламент финансового ведомства штата Оклахома 2. Дефект — это когда система работает ровно так, как её спроектировали, а спроектировали неудачно. Чинить нечего: сломанного нет. Менять надо конструкцию, а это запрос на изменение, а не устранение проблемы. Практика управления проблемами занимается тем, что сломалось, а не тем, что изначально сделано не так.

Проблема и известная ошибка. Это не два разных объекта, а два состояния одного. Проблема становится известной ошибкой в момент, когда установлена причина или найден обходной путь — то есть когда появилось что предъявить первой линии 1 3. Организации, которые заводят их как разные сущности в разных списках, получают два расходящихся реестра и ни одного полного.

Что на входе и что на выходе

Предыдущий раздел отвечает на вопрос, где у практики граница. Этот — на другой: откуда в неё приходит работа и куда уходит результат.

Разница не словесная. Управление конфигурациями лежит рядом с проблемами — соседняя практика, только и всего. Но оно их ещё и питает: без состава услуги и связей между элементами причину ищут наугад. Соседство и питание — отношения разные. Соседа достаточно не трогать; без того, кто даёт данные, практику не запустить вовсе.

Списки ниже собраны по таблицам входов и выходов практического руководства 1. Каждая строка — не наше рассуждение, а то, что названо ключевым входом или выходом одного из четырёх процессов практики.

Что из этого следует. Управление проблемами не запускается изолированно, и видно это не из общих слов, а из списка: без записей об инцидентах нечего анализировать, без состава услуги некуда смотреть, без управления изменениями некому устранять найденную причину. Организация, у которой работает половина этого списка, получит журнал проблем, но не практику.

Обратное тоже верно и утешительнее: каждая связь — это то, чего у соседей уже можно попросить. Данные наблюдения, соглашения об уровне услуг и база знаний обычно есть задолго до того, как кто-то заводит управление проблемами.

Как это работает

Практика раскладывается на семь шагов. Порядок обязателен: каждый следующий имеет смысл только после предыдущего.

Цвет шага: приём, учёт, работа с обращением техническая работа проверка, разбор, улучшение

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

Обходное решение появляется раньше устранения, и это норма. Найденный обходной путь не закрывает проблему — запись остаётся открытой, а сам путь записывается в неё 2. Организация, где обходное решение считается закрытием, получает предсказуемый результат: журнал проблем пуст, а инциденты повторяются с прежней частотой.

Устранение идёт только через изменение. Правка в рабочей среде, сделанная расследующим инженером «пока помню», — это неучтённое изменение со всеми его последствиями. ГОСТ ставит это требованием: решение проводят через принятый порядок управления изменениями 4, и практика CHNКонтроль изменений здесь не бюрократическое препятствие, а единственный способ не породить новый инцидент устранением старого.

Закрытие проверяется, а не объявляется. При закрытии сверяют, что запись содержит полную историю событийСобытиеИзменение состояния, замеченное мониторингом.ITIL 4, и обновляют состояние известной ошибки 2. Отдельно описывается, что делать, если инциденты пошли снова: при тех же условиях проблема открывается заново, при других — заводится новая 2. Правило простое, но без него журнал проблем за год превращается в набор записей с непонятной судьбой.

Жизненный цикл проблемы: состояния и переходы

Схема выше показывает работу — кто что делает и в каком порядке. Здесь показано другое: в каких состояниях бывает сама запись и что переводит её из одного в другое. Это разные вопросы, поэтому и рисуются они по-разному.

Проблема и что с ней путают

Четыре пары, которые смешивают чаще всего. Разница в каждой не филологическая: от неё зависит, кто берётся за работу и с каким сроком.

Проблема и инцидент. Инцидент — незапланированное прерывание услуги или снижение её качества. Проблема — причина одного или нескольких инцидентов, ещё не установленная 1. Практический признак простой. Можете назвать причину — у вас уже не проблема, а известная ошибка. Восстанавливаете работу — вы в инциденте.

Проблема и известная ошибка. Известная ошибка — проблема с установленной причиной или найденным обходным путём 1 3. Заводить известную ошибку надо, как только понятно, в чём проявляется проблема, даже если причина ещё не найдена, — чтобы новые инциденты сразу опознавались и привязывались к записи 2. Организации, которые ждут установленной причины, теряют главную пользу реестра.

Проблема и запрос на изменение. Если система работает как спроектирована, а спроектирована неудачно, это не проблема, а требование на доработку 2. Разница видна по вопросу «что мы вернём»: в проблеме возвращают то, что раньше работало; в доработке делают то, чего не было.

Проблема и риск. Риск — то, что может случиться. Проблема — то, что уже проявилось инцидентами, причина которых не установлена. Практика RSKУправление рисками работает с первым, эта — со вторым. Смешение даёт журнал проблем, наполовину состоящий из опасений.

Классификация и приоритет

Проблемы размечаются теми же кодами, что и инциденты, — и это условие связности: без общих кодов нельзя привязать проблему к породившим её инцидентам и к затронутой услуге 2.

Приоритет проблемы складывается из тех же двух осей, что и у инцидента, но с обязательной третьей поправкой.

Влияние — сколько людей и функций затронуто. В том же регламенте 2 шкала из трёх ступеней. Низкое — один-два человека: услуга деградировала, но держится в пределах соглашения. Среднее — несколько человек на одной площадке, услуга вышла за пределы соглашения. Высокое — все пользователи услуги: затронуто несколько подразделений либо услуга недоступна снаружи 2.

Серьёзность — насколько человек ограничен в работе. Три ступени: низкая — не может выполнять часть обязанностей; средняя — не может выполнять критичные по времени функции; высокая — услуга или её значимая часть недоступна 2.

Поправка на частоту. Вот чем приоритет проблемы отличается от приоритета инцидента: у проблемы обязательно учитывается частота и суммарное влияние порождённых ею инцидентов 2. Проблема, дающая по одному мелкому инциденту в день, может стоить дороже той, что один раз дала крупный.

Именно поправка на частоту связывает практику с деньгами. Пример из того же документа хорошо показывает, почему нужны обе оси: сбой у одного человека, который считает зарплату, останавливает одного пользователя — а без ведомости остаются все, кому она нужна 2. Одной шкалы для такого случая не хватает.

Реактивная и проактивная работа

Практика делится на две составляющие, и в большинстве организаций живёт только первая.

Реактивная начинается после того, как инциденты уже случились. Источники записей здесь такие: служба поддержки заподозрила неустановленную причину и завела запись, техническая группа при разборе инцидента обнаружила, что за ним стоит проблема, средства наблюдения выявили неисправность, которая ещё не дала сбоя 2.

Проактивная начинается с анализа накопленных данных ради поиска причин, которые ещё не проявились 1 2. Это работа с данными, а не с обращениями, и в этом её организационная сложность: у неё нет входящего события, которое заставит кого-то ею заняться. Реактивную работу приносит служба поддержки; проактивную не приносит никто.

Отсюда практический вывод, стоящий дороже любого регламента: проактивная работа существует только тогда, когда для неё выделено время в расписании и назван ответственный. Попытки завести её как «делайте, когда будет свободная минута» кончаются одинаково: свободной минуты не бывает.

Простейший способ начать — регулярный разбор накопленного за период по одному вопросу: какие обращения повторялись чаще всего и что их объединяет. Инструмента и бюджета для этого не нужно, а первые записи проактивных проблем появятся через месяц.

Известные ошибки и обходные решения

Реестр известных ошибок — самый недооценённый результат практики. Он же — то единственное, что первая линия получает от управления проблемами напрямую и немедленно.

Что в нём лежит. Запись содержит признаки, по которым ошибку узнают, перечень инцидентов, которые она порождает, и ссылку на обходное решение, если оно найдено 2. Признаки важнее причины: первая линия ищет по симптому, а не по корневой причине.

Когда заводится. Как только диагностика продвинулась достаточно, чтобы понимать, в чём проблема, — даже если причина ещё не установлена 2. Ждать полной ясности значит терять недели, в течение которых те же инциденты разбираются с нуля каждым, кто их получил.

Чем отличается от базы знаний. Реестр известных ошибок отвечает на вопрос «это уже известно, и вот что с этим делать сейчас», база знаний KNWУправление знаниями — на вопрос «как вообще выполняется эта работа». Их часто держат в одном инструменте, и это нормально, но смысл записей разный: известная ошибка живёт до устранения причины, знание живёт постоянно.

Что портит реестр. Чаще всего — записи без признаков: причина описана, а узнать её по симптому нельзя. Следом — обходные решения, устаревшие после устранения причины и никем не удалённые: первая линия применяет их к новым инцидентам и делает хуже. Реже, но тяжелее всего — доступ: реестр, лежащий в инструменте расследующей группы, до первой линии не доходит и пользы не приносит.

Кто участвует

Роли расписаны по двум источникам — процессным документам, а не учебникам, и в этом их ценностьЦенностьПольза и выгода, которые сторона получает от услуги; величина субъективная.ITIL 4, книга ITIL Foundation: в них названо, кто именно что делает 2 3.

Одно правило из этого регламента 2 стоит вынести отдельно, потому что оно решает самую частую организационную беду практики: владение проблемой остаётся за одной функцией, куда бы проблема ни передавалась по ходу работы 2. Передаётся работа, не ответственность. Там, где это правило не записано, проблема, ушедшая к третьей линии, теряется вместе с третьей линией.

Второе правило — оттуда же: делегирование не снимает ответственности с того, кто за действие отвечает 2. Правило кажется само собой разумеющимся ровно до первого случая, когда проблему передали поставщику и на этом успокоились.

Регулярные встречи

У практики есть ритм, и своды его описывают. При внедрении он пропадает первым: регламент пишут, календарь не пишет никто.

Регулярных ритуалов три 1.

Пересмотр открытых проблем. Команда возвращается к тем, по которым решения пока нет: изменились ли обстоятельства, не появилось ли постоянное решение, не пора ли менять подход к снижению влияния. Периодичность не назначена: её задаёт подход, согласованный по каждой проблеме, или то, что показывает наблюдение.

Пересмотр известных ошибок. Отдельно от предыдущего и с другой целью: убедиться, что рекомендованные обходные решения ещё работают и что постоянного решения по-прежнему нет. Обходное решение устаревает молча, вместе с версией системы, для которой было написано.

Разбор инцидентов профильной командой. Команда, отвечающая за систему, услугу или продукт, регулярно просматривает записи об инцидентах в своей зоне и заводит проблему, когда видит основание. Это и есть проактивное выявление в действии. Без назначенного разбора оно не работает: закономерности в свободное время не ищут.

Четвёртая встреча приходит со стороны инцидентов. Менеджер инцидентов вместе с владельцами услуг разбирает выбранные случаи — крупные, не уложившиеся в срок или все за период 1. Для управления проблемами это главный поставщик поводов, и попасть на этот разбор важнее, чем завести свой.

Пятое — не встреча, а требование. ГОСТ обязывает в заранее назначенные сроки разбирать, результативно ли устраняются проблемы, и показывать это в отчётности 4. Интервал организация назначает сама, но наличие интервала проверяется.

Что должно быть в записи проблемы

Состав записи — не бюрократия, а условие того, что через полгода запись можно прочитать. Ниже перечень из процессного документа, дополненный тем, что показывает практика 2.

Обязательно с самого начала. Отметка даты и времени заведения — без неё невозможны ни контроль, ни эскалация. Перекрёстная ссылка на инциденты, породившие запись, — и относящиеся к делу подробности, скопированные из них: услуга, оборудование, описание, приоритет и категория, а также всё, что уже пробовали сделать при восстановлении 2.

По ходу расследования. Ход диагностики записывается тогда, когда он идёт, а не восстанавливается по памяти при закрытии. Это то же требование, что и в управлении инцидентами, и нарушается оно так же часто.

Обходное решение — отдельным полем. Не в переписке, не в комментарии, а там, откуда его берёт первая линия 2.

При закрытии. Проверка, что запись содержит полную историю событий; если нет — запись дополняется, а не закрывается 2. Обновление состояния связанной известной ошибки. Закрытие связанных инцидентов, которые ещё открыты.

Чего в записи быть не должно: срока из соглашения об уровне услуг. Тот же регламент говорит об этом прямо: целевые уровни привязаны к инцидентам и запросам, к управлению проблемами целевых сроков нет 2. Проставленный срок превращает расследование в отчётность.

Чем автоматизируется

Инструмент здесь закрепляет тот порядок, который есть, и не создаёт того, которого нет. Проверить готовность просто: если у вас нет ответа на вопрос «кто владеет проблемой», система этого ответа не даст.

Что от инструмента действительно нужно, в порядке важности:

Связь записей. Проблема должна связываться с инцидентами, изменениями и известными ошибками, и связь должна быть двусторонней — из инцидента видно проблему, из проблемы список инцидентов. Без этого не считается ни один показатель из следующего раздела.

Общие справочники с управлением инцидентами. Одни коды категорий, одни шкалы влияния и серьёзности 2. Разные справочники в двух практиках означают, что связать данные нельзя даже технически.

Доступ первой линии к обходным решениям. Поиск по признакам, а не по номеру записи.

Выгрузка для анализа. Проактивная половина практики — это работа с накопленными данными. Если данные нельзя выгрузить и посмотреть срезами, проактивной работы не будет независимо от намерений.

Чего от инструмента ждать не стоит: он не назначит владельца, не выделит время на расследование и не помешает закрыть проблему обходным решением. Все три — организационные решения, и принимаются они до покупки.

Подборки решений здесь пока нет намеренно. Три карточки, собранные по коду практики из двух общих ITSM-внедрений, — это не подборка для управления проблемами, а тег, унаследованный от соседней практики. Появится, когда будут разобраны внедрения, где проблемами занимались отдельно, — со своими карточками и проверенными источниками.

Как измерять

Метрика не стоит сама по себе. Сначала определим, что должно быть, чтобы практика работала, и только потом — чем это проверяется. Такие условия называют факторами успеха. У управления проблемами их два 1.

Выявлять проблемы и понимать их влияние на услуги. Организация должна знать ошибки в своих продуктах: они порождают инциденты и бьют по качеству. Проверяется тремя величинами — сколько проблем выявлено за период и с каким влиянием; сколько инцидентов пришло без связи с известной ошибкой; сколько инцидентов потребовали срочного расследования причины 1. Вторая и третья растут, когда практика опаздывает: причину начинают искать в момент аварии, а не до неё.

Оптимизировать устранение проблем и снижение их влияния. Устранить все причины не удаётся почти никогда, но выявление без устранения почти ничего не стоит. Здесь меряется обратная сторона — сколько инцидентов предотвращено устранением причины; сколько решено средствами, найденными при расследовании; сколько известных ошибок остаётся открытыми 1. Подход к снижению влияния положено взвешивать по стоимости, риску и качеству услуги: «устранять всё» правильным ответом здесь не считается.

Дальше идёт то, чего в ITIL нет, а в процессных документах есть: рабочая разбивка показателей по трём группам. Первая говорит о нагрузке, вторая о работе процесса, третья о результате. Хвалиться принято первой, а отвечать надо третьей.

Нагрузка — сколько работы пришло. Общее число проблем, разбивка по стадиям (заведено, в работе, закрыто), сколько накопилось нерешённых, число и доля крупных проблем 2. Эти цифры отвечают на вопрос «сколько», а не «хорошо ли», и сами по себе ничего не доказывают.

Работа процесса — не застревает ли. Сколько проблем завели, сколько известных ошибок установили, сколько инцидентов привязано к проблемам, сколько решений отклонили, сколько изменений породило проблемы, сколько проблем устранили изменениями 3. Две цифры отсюда встречаются в отчётах реже всего, а говорят больше остальных: число отклонённых решений показывает, насколько качественно расследуют, а число проблем, порождённых изменениями, — насколько честно работает CHNКонтроль изменений.

Результат — стало ли меньше инцидентов. Готовой формулы не даёт ни один источник, и это честно: результат считается по вашим данным. Рабочий способ — по каждой закрытой проблеме сравнить частоту связанных инцидентов до устранения причины и после. Сумма этих разниц за квартал и есть то, ради чего практика существует.

Отдельная мера, которую стоит завести всем: доля инцидентов, привязанных к проблемам. Она отвечает на вопрос, ведётся ли связь вообще. Ноль означает, что практика живёт отдельно от управления инцидентами, и остальные показатели тогда не считаются.

У показателя должно быть два числа, а не одно. Целевое — куда идём, и опасное — при каком значении пора вмешиваться. Брукс задаёт обе границы у каждой своей метрики 7, и для доли непривязанных инцидентов это цель 25% при тревоге в 40%. Мера та же, что и абзацем выше, только с обратной стороны: три четверти инцидентов должны выходить на какую-то проблему. Рядом ещё три пары. Открытых проблем одновременно — 25 при тревоге в 40. Не решённых в срок — 2 при тревоге в 5. Среднее время закрытия — 3 при тревоге в 5, и единица тут намеренно не названа: часы, дни или минуты выбирает организация, а держать надо соотношение.

Числа эти к вам не переезжают. Брукс приводит их образцами для настройки под свою модель работы; переносится привычка держать у метрики обе границы, а не одну.

Среднее время закрытия умеет обманывать. Когда закрывают проблему, висевшую полгода, среднее подскакивает — и выглядит это как ухудшение ровно в тот момент, когда случилось лучшее за полгода. Брукс советует считать среднее без того, что не удавалось решить дольше месяца 7, а долгие случаи разбирать отдельно и поштучно.

Как это выглядит на панели. Показатели выше собраны в готовую панель менеджера практики: связь с инцидентами, закрытые устранением причины, известные ошибки без обходного решения и открытые проблемы в порядке того, сколько инцидентов породила каждая. Числа там пример, а не чьи-то настоящие данные, — панель по управлению проблемами. Там же разобрано, что на панель не ставят и почему.

Не всякий полезный показатель годится в сводный отчёт. Пять категорий инцидентов, по которым за период было больше всего обращений, Брукс называет информативной внутренней метрикой и прямо оговаривает: в консолидированные показатели она не идёт 7. Команде она подсказывает, куда копать дальше, а в отчёте наверх превращается в повод для выводов, которых из неё не следует: верхние категории тем и велики, что они массовые, а не потому, что там хуже всего.

У решения проблемы есть цена, и её тоже меряют. У метрики «затраты на решение проблемы» целевое значение задано не числом, а условием: решение должно окупаться; опасное — когда затраты перевалили за выгоду 7. Само же решение, тратить ли деньги на устранение причины, принимается не здесь, а в CHNКонтроль изменений: управление проблемами показывает цену вопроса, а разрешает расход другая практика.

ITIL предлагает и сводный показатель продуктивности практики, но за формулой отсылает к отдельному руководству по измерению и отчётности и сразу оговаривает: единственно верного набора показателей нет, он строится от стратегии услуг и целей организации 1. Оговорка стоит того, чтобы её повторить, — она снимает соблазн взять чужой набор целиком.

Про отчётность из процессных документов: отчёты по стадиям делаются ежемесячно с квартальными сводками, а разбор открытых проблем высшего приоритета — еженедельно 2. Ежедневная отчётность по проблемам смысла не имеет: за день в этой практике не происходит ничего, что стоило бы отдельного взгляда.

Зрелость управления проблемами

✕

Где ломается чаще всего

Семь мест, в которых практика разваливается. Порядок — по частоте, с которой это встречается.

Проблемы заводит и расследует тот же человек, что закрывает инциденты. Инциденты всегда срочнее. Расследование откладывается на «после», и «после» не наступает. Лечится не уговорами, а выделенным временем в расписании.

Запись закрывают обходным решением. Работа обойдена, инциденты закрываются, причина осталась. Журнал проблем выглядит здоровым. Признак — короткое среднее время жизни записи при том, что число инцидентов не падает.

Связь с инцидентами не ведётся. Записи есть, привязки нет. Никакой показатель результата не считается, и через полгода практика не может показать ни одной цифры в свою пользу — со всеми последствиями при обсуждении бюджета.

Реестр известных ошибок не доходит до первой линии. Знание есть, применить его некому. Проверяется одним вопросом к оператору: где вы смотрите, известна ли уже эта ошибка.

Практика реактивна целиком. Все записи заведены после громких сбоев. Потолок такой практики — не допустить повторения того, что уже случилось; всё, что ещё не случилось, вне поля зрения.

Устранение проходит мимо изменений. Инженер правит рабочую среду по ходу расследования. Иногда это порождает новый инцидент, и связь с правкой уже не восстановить.

Крупные проблемы не разбираются. Разбор после крупного сбоя либо не проводится, либо заканчивается протоколом. Выводы не доходят ни до изменений в системах, ни до правил наблюдения. Разбор, после которого не появилось ни одной записи в IMPПостоянное улучшение, проведён впустую.

Как менялись стандарты

Практика старше большинства сводов, и её описание заметно менялось трижды.

Вторая редакция ITIL развела управление инцидентами и управление проблемами как разные области ответственности и ввела рекомендацию о явной границе между ними: если служба поддержки не может решить инцидент, он передаётся в управление проблемами 3. Терминология того времени отличается: в процессных документах эпохи встречается «известная проблема» там, где сейчас говорят «известная ошибка», а сама практика описывается как надстройка над разбором инцидентов 3. Читая документы тех лет, эту разницу стоит держать в голове.

Третья редакция закрепила разделение реактивной и проактивной работы и вывела реестр известных ошибок в самостоятельный объект со своим жизненным циклом. Регламент финансового ведомства штата Оклахома, написанный в 2011 году, следует уже этой логике 2: там есть и деление на две половины, и отдельный реестр, и правило о владении 2.

Четвёртая редакция переписала практику как деятельность, а не как процесс с жёсткой последовательностью шагов, и сместила акцент на управление обходными решениями и известными ошибками наравне с устранением причин 1. Формулировка цели стала шире: не «устранить причины», а «сократить вероятность и влияние инцидентов».

ISO/IEC 20000-1 в редакции 2018 года (у нас — ГОСТ Р ИСО/МЭК 20000-1—2021) требований к устройству процесса не предъявляет. Он задаёт результат: причины выявляются, действия определяются, известные ошибки ведутся, решения доводятся до изменений 4. Для того, кто готовится к сертификации, это удобнее ITIL: проверяется не соответствие описанию, а наличие работающего механизма.

COBIT 2019 держит практику в цели DSS03, по-русски — управление проблемами, и раскладывает её на пять шагов: выявить и классифицировать, расследовать и установить причину, завести известные ошибки, устранить и закрыть, вести проактивную работу 5. Там же назван и результат, которого ждут: рост доступности, соблюдение уровня услуг, снижение затрат и числа операционных проблем.

Отдельно стоит посмотреть, как за те же годы менялись документы одной организации. То самое ведомство штата, чей процессный регламент 2011 года описан выше, сегодня называется иначе и держит по этой практике собственный стандарт на две страницы 6. Устройства процесса в нём нет вовсе. Есть определения, требование вести записи о проблемах в системе и единый почтовый адрес для тех, у кого доступа к системе нет. Есть обязанность документировать расследования и доводить их результаты до подведомственных организаций. И есть ссылка на статьи закона штата, которыми стандарт введён.

Движение то же, что и у ISO/IEC 20000: от описания порядка к требованию результата. Развёрнутый регламент с ролями и матрицами превратился в короткий нормативный текст, а описание того, как именно работать, ушло в систему и в рабочие инструкции. Для читателя, который собирает свои документы, это подсказка о том, что писать в регламенте, а что оставить настройке инструмента.

Где описано

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

Что обязательно по стандарту

ITIL описывает, как эту практику обычно устраивают. ГОСТ — что в ней обязано быть. Разница практическая: по ITIL вас никто не проверит, по стандарту проверят.

Пункт 8.6.3 «Управление проблемами» короткий, и в нём нет ни одного «следует» — только «должен» 4:

• анализировать данные и тенденции по инцидентам ради выявления проблем, устанавливать корневые причины и определять действия против повторения;
• проводить проблему через состояния — зарегистрирована и классифицирована, расставлена по приоритету, эскалирована при необходимости, урегулирована, если возможно, закрыта;
• актуализировать записи с указанием предпринятых действий;
• проводить изменения по политике изменений — у устранения причины нет отдельного упрощённого пути;
• регистрировать известные ошибки, а когда причина найдена, но проблема не устранена, определять действия по снижению её влияния;
• держать информацию об устранении доступной для других видов деятельности по управлению услугами;
• разбирать результативность по расписанию и отражать её в отчётности.

Чего стандарт не требует — и это важнее списка. Ни ролей, ни менеджера проблем, ни линий поддержки, ни сроков, ни формы записи, ни отдельного инструмента. Всё перечисленное организация выбирает сама, и на аудите этого не спросят.

Одна оговорка про перевод. В пункте стоит «расширены, если необходимо»; в исходном тексте стандарта — escalated, то есть эскалированы. Формулировку ГОСТа мы приводим как есть, потому что цитируем действующий документ, но читать её надо как эскалациюЭскалацияПередача инцидента тем, у кого больше компетенции, либо уведомление руководителя об угрозе срока.Разбор практики управления инцидентами на портале.

Проекты внедрения

Каждый разобранный проект открывается своей страницей: что болело, что сделали, что получилось и отдельно — что не получилось. Остальные проекты по этой практике — в каталоге проектов.

Материалы по теме

Что почитать дальше

Начинать стоит с INCУправление инцидентами: управление проблемами без работающего управления инцидентами нечем кормить — не будет ни повторяющихся обращений, по которым видна проблема, ни данных для анализа.

Следом — CHNКонтроль изменений: устранение причины идёт только через изменение, и практика, в которой изменения не контролируются, будет порождать новые проблемы быстрее, чем закрывать старые.

Третьим — KNWУправление знаниями: реестр известных ошибок и база знаний живут рядом, и решать, что где лежит, лучше до того, как оба списка наполнятся.

Для проактивной половины пригодится REPИзмерение и отчётность: она вся построена на анализе накопленных данных, и без нормальных срезов делать её нечем.