Тема, которую Игорь Фадеев поднял с своей недавней статье «Выход или результат? Ловушка, в которую попадают ITSM-новички» актуальна во многих областях аспектам разработки, предоставления и поддержки ИТ-услуг (и не только для новичков).
Давайте в дополнение к примерам, приведенным Игорем, посмотрим, в каких еще моментах на практике может оказаться важным понимать разницу между выходами (outputs) и результатами (outcomes).
Определение требований к услуге. Диалог об услуге с заказчиком.
Конечно же, в первую очередь это основа основ: договаривая с заказчиком, какой должна быть услуга, определяя требования к ней (как функциональные, так и нефункциональные), чтобы предложить то, что заказчику будет действительно ценно, нам нужно изучить, какие результаты он хочет достичь, и уже понимая их, определиться с выходами, которые должны получиться. Например, та же услуга электронной почты может варьироваться как по функционалу (наличием общих групповых ящиков или нет), так и по производительности (скорость передачи сообщений) или по объему потребления (сколько места на сервере выделено пользователям заказчика). Ведь только разобравшись, для достижения каких целей заказчик будет потреблять услугу, мы предложим ему наиболее подходящий вариант с точки зрения выходов, а значит, заказчик будет более доволен при потреблении услуги.
В дальнейшем при предоставлении услуги именно вопрос о достижении результатов должен быть одним из наиболее важных в диалоге владельца услуги с заказчиком, потому что это то, что ложится в основу удовлетворенности услугой).
Поддержка изменений
Еще один яркий пример — это проведение изменений. В тексте практики «Поддержка изменений” этому моменту специально уделено внимание, но иногда этот акцент теряется за всем остальным содержанием руководства.
Одним из главных критериев оценки изменения как успешного, будет не формальное достижение поставленной цели (например, добавить новую форму для выгрузки отчета из приложения), а достижение запланированного результата: позволяет ли эта новая форма выгрузки добиваться того, ради чего она вообще была внедрена.
И это значит, что всем участникам деятельности по обеспечению изменений – сотрудникам ИТ-поставщика – крайне важно понимать не просто «что должно измениться», а зачем, для чего задумано данное изменение. Это знание может помочь скорректировать состав участников оценки изменения (например, не забыть никого важного), правильнее определиться со сроками проведения изменения, принимать более корректные решения «на ходу», если во время реализации изменения что-то идет не так. То есть можно дать команде определенную свободу действий, потому что у нее появляется контекст для принятия обоснованных решений при отклонениях, а не слепое следование инструкции.
Определение сроков и влияния инцидентов и проблем
При решении инцидентов мы, конечно, понимаем, что хорошо бы устранить инциденты как можно скорее, но мы все же не волшебники и ресурсы у нас ограничены, так что нам приходится договариваться с заказчиком о некоторых допустимых сроках (определяя их как выходы услуги).
Как же подойти к определению таких сроков? Кто-то может предложить: «давайте зафиксируем с заказчиком таблицу, где срок решения будет зависеть от того, какой именно компонент услуги не доступен. Например, при предоставлении услуги автоматизации склада, мы обязуемся устранять инциденты со сканером штрих-кодов за 2 часа, а инциденты с принтером штрих-кодов – за 4 часа.
Но можно пойти по-другому, определяя сроки решения инцидента в зависимости от его влияния на результаты. Предположим, что автоматизация склада нужна заказчику для значительного роста прибыли, особенно в предпраздничные декабрьские недели. Тогда мы можем договориться с бизнесом о параметрах доступности функции сканирования в разные периоды года, и в дальнейшем определять сроки решения инцидентов со сканером, исходя из понимания, как эта поломка влияет на финансовые цели бизнеса. И это будет означать, что в пиковые периоды нам необходимо чинить или заменять сломанный сканер за полчаса, а спокойные периоды (например, в после праздничное затишье) может быть допустимо иметь запас в 4 часа (потому что влияние на результат – получение прибыли – будет разное).
Аналогично можно говорить и про управление проблемами, поскольку проблема – это причина инцидентов, и оттого влияние проблем напрямую связано с влиянием вызванных (или потенциально вызванных) ею сбоев. Очень часто влияние проблем так и считают, как сумму влияний связанных инцидентов. Значит, принимая решение о выборе проблемы, в анализ и решение которой мы сейчас готовы инвестировать ресурсы (бюджет, время специалистов), мы неизбежно должны оттолкнуться от корректного понимания влияния этой проблемы – и это именно влияния на результаты.
Управление сервисными конфигурациями
Разница выходов и результатов может проявиться и при определении охвата CMDB (базы данных управления конфигурациями). На наших курсах слушатели выполняют упражнение: они представляют себя менеджерами разных практик, которые приходят к менеджеру управления конфигурациями и озвучивают свои требования к информации CMDB. В ходе выполнения упражнения обнаруживается, что эффективнее высказывать требования не просто как «Мне нужны следующие атрибуты серверов», а «Мне нужно видеть связи серверов между собой, мне нужно уметь сортировать КЕ (конфигурационные единицы) по местоположению и т.д.» – т.е. то есть формулировать потребность, возникающую в их работе (будь то управлении инцидентами, мощностями, финансами, и любыми другими практиками). И тогда менеджер управления конфигурациями, имея экспертный опыт и зная существующие технические, бюджетные, ИБ и прочие ограничения, а также учитывая требования всех заинтересованных сторон (как потребность в результате), может спроектировать выходы (структуру CMDB) оптимально и целостно, удовлетворяя все потребности в рамках ограничений, а не метается из стороны в сторону, чтобы срочно добавить значение нового атрибута.
Вместо заключения
Перечисленный выше список частных примеров, конечно, может быть продолжен: аналогии мы можем найти и при выстраивании мониторинга, и при определении стратегии тестирования, и при формировании каталога услуг, и во многих других аспектах ITSM. Я надеюсь, эти примеры наглядно показывают, что, казалось бы, формальная терминология — например, разница между выходами (outputs) и результатами (outcomes) — имеет непосредственное практическое применение при предоставлении ИТ-услуг. Это значит, что разбираться в основах ITSM, важно всем ИТ-специалистам вне зависимости от их роли и специализации. Это база, без которой можно упустить много тонкостей при погружении в более в более узкие области ИТ-менеджмента.
