Если в рамках практики «управление проблемами» вы идентифицируете только одну корневую причину (root cause) для каждой проблемы, то вы упускаете множество возможностей для совершенствования.
У одного из моих клиентов возникла проблема, которая вызывала множество инцидентов. Они провели исследование и выявили корневую причину. По их мнению, это была ошибка в программном приложении, разработанном внутри компании. Они устранили ошибку и закрыли проблему.
Это типичная ситуация, которую я наблюдаю в управлении проблемами, и на первый взгляд, она выглядит нормально. Но на самом деле это недостаточно хорошо, потому что вам нужно задавать много неудобных вопросов, если вы хотите понять, что на самом деле произошло.
Тщательное исследование требует ответов на неудобные вопросы
Тщательное исследование этой проблемы подразумевало бы множество неприятных вопросов, таких как:
- Почему программное обеспечение изначально было неверным?
- Была ли спецификация корректной?
- Была ли это простая ошибка в кодировании?
- Было ли нарушено понимание бизнес-процесса?
- Правильно ли разработчик понимал, как пользователь будет взаимодействовать с программным обеспечением?
- Имел ли разработчик программного обеспечения всю необходимую информацию?
- Имел ли разработчик программного обеспечения правильные навыки и опыт?
- Почему ошибка в программе не была обнаружена до развертывания?
- Был ли проведён обзор кода (per review)? Был ли коллега, проводивший проверку, компетентен и имел достаточный опыт? Имел ли он необходимую информацию?
- Проводилось ли тестирование? Соответствовала ли среда для тестирования назначению? Был ли охват тестирования достаточным?
- Почему так долго происходило выявление проблемы после первых инцидентов?
- Были ли у сотрудников поддержки необходимые навыки и знания для выявления проблем?
- Помогал ли инструментарий, используемый поддержкой, в выявлении нескольких связанных инцидентов?
- Существовал ли процесс обзора инцидентов для обеспечения выявления проблем? Был ли этот процесс эффективным?
- Почему так долго проводилась диагностика проблемы после ее выявления?
- Были ли люди с необходимыми навыками и знаниями доступны для участия в диагностике проблемы?
- Была ли вся необходимая информация для диагностики проблемы доступной в нужное время и в нужном места место?
- Имела ли проблема адекватный приоритет относительно прочей работы?
- Почему проблема после ее выявления привела к такому ущербу для бизнеса?
- Был ли задокументировано удовлетворительное обходное решение (workaround)?
- Были ли будущие инциденты, требующие того же обходного решения, быстро и последовательно выявлены?
- Было ли обходное решение применено быстро и эффективно после каждого инцидента?
- Кто-то проверял обходное решение после его использования для того, чтобы понять, как его можно улучшить?
- Почему так долго происходила поставка исправления программного обеспечения в среду промышленной эксплуатации?
- Были ли доступны соответствующие ресурсы для разработки и тестирования решения?
- Был ли этот процесс приоритизирован соответствующим образом по сравнению с другой работой?
- Были ли в процесс тестирования и развёртывания решения ненужные задержки?
Сколько причин имеет одна проблема?
Вопросы, перечисленные выше – это типичные вопросы, которые вы должны задать, чтоб понять:
- Почему проблема возникла
- Почему проблема имела такое влияние
- Как минимизировать вероятность того, что подобные отклонения будут приводить к проблемам в будущем.
Факт заключается в том, что почти любая проблема имеет множество причин. Некоторые из них могут быть связаны с технологиями (как, например, ошибка в программном обеспечении или неисправный ноутбук), и “информация и технологии” действительно являются одним из аспектов управления услугами, выделенных ITIL® 4. Но есть еще три аспекта управления услугами, которые вам следует учитывать, если вы хотите тщательно исследовать причины проблем. Потому что причины могут быть связаны с аспектом “организация люди” (навыки, компетентность, знания), “потоки ценности и процессы” (разработка, тестирование, управление инцидентами) или даже “партнеры и поставщики” (контракты, отношения).
Первый шаг к совершенствованию – знать, что нужно совершенствовать
Когда вы воспринимаете решение проблем как выявление “корневой причины”, вероятно, вы обнаружите технологическую неисправность, исправите ее и остановитесь. Если вы придерживаетесь такого подхода, то есть вероятность, что вы не заметите других вещей, которые работают не так хорошо, как могли бы, и, следовательно, вы упустите множество возможностей для улучшения и снижения количества и влияния проблем, с которыми вы столкнётесь в будущем.
Что хуже всего, если вы не уделяете время для выявления своих собственных слабостей, вы легко можете оказаться в бесконечном и ненужном цикле устранения одной “корневой причины” за другой.
Ведите реестр совершенствования и убедитесь, что каждое исследование проблемы проводится тщательно, учитывая все аспекты управления услугами. Когда вы используете этот подход, каждое исследование выявит множество возможностей для совершенствования, которые вы можете выявить и зарегистрировать. Решение о том, инвестировать ли необходимые ресурсы для их реализации, можно принимать позже, но после того, как они были выявлены и приоритизированы, по крайней мере, вы знаете, что это и оценили потенциальный вред, который они могут нанести, если остаются нерешенными.
Как можно выявить причины проблем?
Существует множество различных методов для выявления причин проблем. Я написал блог под названием “7 способов диагностирования ИТ-инцидентов и проблем” (англ.), в котором описаны некоторые из более популярных методов. Вот краткое резюме, если у вас нет времени читать блог.
- Подход Ричарда Фейнмана: Запишите проблему; очень хорошо подумайте; запишите ответ.
- Анализ временной последовательности: Составьте список всего, что произошло, в хронологическом порядке; ищите паттерны.
- Метод решения проблемы Кепнера-Трего: Документируйте проблему в терминах “Что”, “Где”, “Когда” и “Масштаб”; выявите то, что работает, а также то, что не работает; перечислите различия и изменения; определите возможные причины; подтвердите истинную причину.
- Диаграммы Ишикавы или “рыбий скелет”: Постройте диаграмму, на которой показаны все возможные причины, дающие вклад, и связи между ними.
- Поддержка, сосредоточенная на знаниях: Накопление и управление информацией как часть рутины обработки инцидентов.
- Роение (swarming): Сотрудничайте, а не эскалируйте.
- Standard+case (англ.): Различайте рутинную работу и более сложные ситуации.
Еще два метода, которые я также нахожу полезными:
- Спросите друга: Не работайте только в одиночку, общайтесь со своими коллегами и используйте их знания и опыт. Вы можете назвать это “неформальным свормингом (роение)”.
- «5 почему»: Этот метод из методологии Lean настоятельно рекомендует многократно задавать вопрос “почему?”, вместо того чтобы принимать очевидную корневую причину.
Конечно, вы можете выбирать не только один из этих методов, но и использовать комбинацию из них в зависимости от вашей ситуации.
Итог
Если ваше управление проблемами выявляет только одну корневую причину для каждой проблемы, вы упускаете множество возможностей для совершенствования. Вы можете использовать модель «Четыре аспекта управления услугами», описанную в ITIL 4, чтобы ваше исследование проблем охватывало все аспекты управления услугами: «организации и люди», «партнеры и поставщики», «потоки ценности и процессы», «информация и технологии». Это, в свою очередь, поможет обеспечить то, что в рамках решения проблем вы устраняли не только техническую “корневую причину”, но также способствовали культуре постоянного совершенствования, выявляя отклонения, которые могут быть добавлены в ваш реестр постоянного совершенствования.
- Разобраться с управлением проблемами (problem management) – курс “VAP: Управление поддержкой ИТ-услуг” (https://edu.cleverics.ru/vap-support)
- Проверить, удалось ли разобраться с управлением проблемами и другим областями поддержки ИТ-услуг – экзамен на русском языке “Proven Practices Expert: IT Services Support” (https://edu.cleverics.ru/proven-practices-expert-it-services-support-management)
