Представляю перевод статьи Стюарта Рейнса «Прошлое и будущее Управления ИТ Услугами» («The Past and Future of IT Service Management» by Stuart Rance), опубликованную в блоге ITSM.Tools.
Статья носит обзорный характер и может быть интересна, как на начальном этапе погружения в ITSM за счет того, что дает направление движения, так и более опытным участникам процессов ITSM, давая возможность сравнить собственные ощущения с мнением довольно авторитетного специалиста и спикера мероприятий ITSM мира.
Предупреждение: статья явно продающая и, по скромному мнению переводчика, содержит в себе излишне восторженные оценки, которые могут не встречаться Вам в реальном мире и пагубно влиять на неокрепшие умы.
(Здесь и далее курсивом примечания переводчика.)
Я участвую в управлении ИТ-услугами (IT service management, ITSM) начиная с 1970-х и стал свидетелем множества изменений с тех пор. Это краткий сборник моих мыслей и наблюдений, чем ITSM был и чем, мне думается, будет в дальнейшем.
Моя работа в ИТ началась в конце 70-х. Я занимался поддержкой, восстанавливая оборудование, и достаточно долго развивался в направлении решения инцидентов и проблем широкого спектра аппаратного и программного обеспечения. Как и остальные, кто занимался схожими работами в ИТ, я ходил на множество учебных курсов, где изучал различные аппаратные и программные продукты и как их восстанавливать, но среди них не было программ по процессам, услугам или работе с заказчиками. Если кто-то спрашивал, чем я занимаюсь “по жизни”, я отвечал что-то вроде: «Чиню компьютеры» или «Решаю проблемы с компьютерами». В то время я ни разу даже не слышал об ITSM и, конечно же, не думал, что я делаю такие вещи, как Управление Инцидентами (Incident Management) или Управление Проблемами (Рroblem Мanagement).
В середине 1990-х, я наткнулся на ITIL (ведущий набор лучших практик для реализации ITSM), и это стало для меня откровением. Это было, как обнаружить семью, которую я никогда не знал. Я открыл для себя идеи для своей деятельности, такие как Управление Доступностью (availability management), Управление Непрерывностью Услуг (service continuity management), Управление Изменениями (change management) и Управление Проблемами (problem management). Теперь я имел набор шаблонов, которые мог использовать, чтобы добавить в свою работу больше последовательности и строгости. Также у меня теперь был сленг, облегчающий общение с коллегами и заказчиками.Я пошел курсы ITIL Foundation и ITIL Service Manager, а в конечном итоге стал ITIL инструктором, передающим эти великие идеи остальным людям, чтобы помочь им достигать карьерные цели.
В то время ITIL был более всего сфокусирован на процессах, и предоставлял набор идей для их создания. В компаниях, которые начинали использовать ITIL, команды поддержки ИТ прекращали жить от инцидента к инциденту, от аврала до аврала, определения важности проблемы по громкости крика обращающегося. Вместо этого они направили свою энергию на согласование уровня обслуживания со своими заказчиками. В результате теперь они были уверены, что уровни, которые они согласовали, используя идеи ITIL, помогают им создавать повторяемые процессы, и это, в свою очередь, позволяло им быть уверенными, что оговоренное обслуживание предоставляется систематически.
В 2007 годы вышел новый релиз ITIL. Самым большим изменением стала новая структура, построенная вокруг жизненного цикла услуг. Теперь стало проще понять, чем являются услуги, и больше стал фокус на их значимости для пользователей. Наибольший акцент делался на Стратегию (Service Strategy, SS) и Разработку Услуг (Service Design) и появилась целая книга о Непрерывном Улучшении Услуг (Continual Service Improvement, CSI). Также стало подразумеваться, что соблюдение SLA может не быть самым важным, что делает ИТ в организации. Было так обычным для нас поставлять SLA пока наши заказчики грустили, разочаровывались или бесились. Фокус на услугах и было тем в чем мы по факту нуждались. Нам пришлось понять наших заказчиков с пользователями и обеспечить им действительную ценность от наших сервисов.
Так я изменил свой подход к работе.
Я продолжал пытаться обеспечивать согласованные целевые показатели, но, когда обстоятельства вынуждают, я понял, что могу их игнорировать целевые показатели и фокусироваться на том, что заказчик действительно хочет. Важной вещью была удовлетворенность заказчика и опыт работы с заказчиком. Но, конечно, вести себя так стоит только, когда уместно, а это требует от ИТ организации в первую очередь зрелых процессов, а так же опытного штата сотрудников, который уверенно работает без жестких зависимостей от заведенных порядков и повторяемости процессов.
Многие считают преобразование от фокуса на процессах к фокусу на услугах крайне сложным. В ITSM остаются люди, уверенные в необходимости придерживаться SLA, даже когда это вредит их заказчикам. Я часто общался с такими людьми и один на один, и в социальных сетях, пытаясь убедить их отойти от очень старомодного процесс ориентированного подхода. Иногда мне это удавалось, но часто они продолжали работать без изменений, вызывая проблемы для своих заказчиков в любой отрасли.
Тем временем ITSM снова двигается вперед. Мир разработки программного обеспечения внедрил у себя идеи Agile и DevOps. Множество участников ITSM сообщества также признают, что тоже нуждаются в дальнейшем развитии, для предоставления бо’льшей ценности для своих заказчиков. Вот некоторые из вещей, которые, я думаю, повлияют на будущее ITSM. Здесь мне не хватит места, чтобы подробно изложить все идеи, но, надеюсь, что сказанного будет достаточно, чтобы подогреть ваш интерес и дать Вам самостоятельно побольше поизучать.
Agile
Манифест для гибкой (Agile) разработки программного обеспечения был опубликован в 2001 году. В нем подчеркивалась важность того, что:
— личности и их взаимоотношения важнее процессов и инструментов
— работающий программный продукт важнее полноты документации по нему
— сотрудничество с заказчиком важнее контрактных обязательств
— реакция на изменения важнее следованию планам
Результат этого гораздо более гибкий и быстрый подход, что дает колоссальные улучшения качества нового программного обеспечения, а также содействует возможности быстро реагировать на изменение бизнес нужд.
Некоторые идеи Agile сейчас применяются в ITSM. Они изменили представления о лучшем подходе к развертыванию и улучшению ITSM (нет больше многолетних ITSM проектов) и лучших способах поддержки заказчиков (люди и их взаимоотношения важнее процессов и инструментов).
Lean
Lean — это подход к управлению, который подчеркивает важность создания максимальной ценности для заказчика при минимальных затратах. Если Вы хотите узнать об этом больше, то можете найти статьи в интернете про производство по Lean, про разработку продуктов по Lean и про разработку программного обеспечения по Lean.
В контексте ITSM наиболее важные аспекты Lean:
— определение сквозной цепочки ценности, частью которой Вы являетесь
— гарантия, что все Ваши действия создают ценность для Заказчика
— устранение пустых затрат в любых действиях, уменьшение этапов процессов до максимальной простоты, необходимой для создания ценности.
Автоматизация
Автоматизация всегда была частью управления ИТ. Даже когда я начинал (в конце 1970-х), мы автоматизировали задачи везде, где только могли. Что же изменилось изменилось? Стали более доступны инструменты, обеспечивающие и облегчающие автоматизацию. Теперь вы можете автоматизировать почти все что угодно, если решите это делать.
Есть всего несколько вещей, которые не могут быть автоматизированы, потому что они требуют человеческой экспертизы, как части создания процесса. Мы можем автоматизировать все остальное, что мы способны делать, до тех пор пока:
— мы действительно понимаем, что и как делаем
— достаточно простые действия, которые можно легко документировать
— то, что случается часто и автоматизация может это усовершенствовать и улучшить
— автоматизация станет не способной заменить человеческую оценку по гибким правилами
DevOps
DevOps эксплуатирует идеи из Agile, Lean и автоматизации для улучшения прохода программного обеспечения из разработки к заказчикам. DevOps подчеркивает три направления:
Комбинации этих трех направлений с интенсивным сотрудничеством смежных команд и крайне высокий уровень автоматизации дает в результате максимально быстрое развертывание/внедрение нового и измененного софта с высокими гибкостью и удовлетворенностью пользователей.
DevOps обычно автоматизирует множество из задач, которые выполняют разработчики программного обеспечения, но он не включает в себя операционные аспекты разработки.
ITSM должен использовать это. Мы должны способствовать развитию новых идей и помогать обеспечивать, что значительное увеличение автоматизации рутинных операций не задевает оценку человека сквозь весь процесс.
Корпоративное Управление Услугами (Enterprise Service Management)
Множество идей, инструментов и процессов, которые используются в разработке и поддержке ITSM также полезны для поддержки не ИТ-услуг. Корпоративное Управление Услугами использует те же подходы для всей организации, включая управление возможностями, управление персоналом, юристов и любые другие подразделения, предоставляющие услуги.
Мы все нуждаемся в управлении инцидентами и проблемами, исполнении запросов на услуги и взаимодействии с заказчиками. Используя одни и тебе инструменты, процессы и подходы мы можем обеспечить общекорпоративные услуги.
Эффективное Общекорпоративное Управление Услугами это не только применение ITSM инструментов другими подразделениями, но и вовлечение сквозного для всей организации сотрудничества и обучения. Часто ИТ департамент может многому научить в предоставлении услуг.
ITIL Practitioner
Последние пополнение ITIL это Руководство Практика ITIL (ITIL Practitioner Guidance), вышедшее в январе 2016 года. Эта публикация поддерживает множество идей, описанных в данном блоге.
ITIL Practitioner излагает девять руководящих принципов:
Также обсуждаются три корневые компетенции:
И все это описывается в контексте Непрерывного Улучшения ИТ Услуг. Если Вы хотите узнать больше об ITIL Practitioner, я рекомендую прочитать руководство по ITIL Practitioner и пойти учебный курс. Также можете ознакомиться с ревью ITIL Practitioner от моего хорошего друга Стефена Манна (Stephen Mann).
ITSM помог ИТ организациям превратиться из провайдера технологий в провайдера создающих ценность услуг. И нельзя останавливаться, если мы будем решать проблемы 21 века методами 1990-х, то быстро станем неадекватны.
Каждый кто предоставляет или поддерживает ИТ услуги нуждается в использовании новых подходов и принятие новых идей, т.к. они повышают ценность услуг для заказчика.
Некоторые из концепций, о принятии которых вы могли бы задумываться, описаны в этом блоге, но еще существует множество других, которые также будут полезными.
Мне очень нравятся:
Вы можете узнать больше из текущих обсуждений этих тем в соцсетях:
Ну, и посещайте мероприятия, организуемые:
От себя добавлю пару ссылок на русскоязычные ресурсы на тему ITSM:
На этом все. Надеюсь чтение было полезным.
Спасибо за внимание, оставляйте свои оценки в комментариях.
Статья носит обзорный характер и может быть интересна, как на начальном этапе погружения в ITSM за счет того, что дает направление движения, так и более опытным участникам процессов ITSM, давая возможность сравнить собственные ощущения с мнением довольно авторитетного специалиста и спикера мероприятий ITSM мира.
Предупреждение: статья явно продающая и, по скромному мнению переводчика, содержит в себе излишне восторженные оценки, которые могут не встречаться Вам в реальном мире и пагубно влиять на неокрепшие умы.
(Здесь и далее курсивом примечания переводчика.)
Я участвую в управлении ИТ-услугами (IT service management, ITSM) начиная с 1970-х и стал свидетелем множества изменений с тех пор. Это краткий сборник моих мыслей и наблюдений, чем ITSM был и чем, мне думается, будет в дальнейшем.
Исключительно технический фокус в 1970-х
Моя работа в ИТ началась в конце 70-х. Я занимался поддержкой, восстанавливая оборудование, и достаточно долго развивался в направлении решения инцидентов и проблем широкого спектра аппаратного и программного обеспечения. Как и остальные, кто занимался схожими работами в ИТ, я ходил на множество учебных курсов, где изучал различные аппаратные и программные продукты и как их восстанавливать, но среди них не было программ по процессам, услугам или работе с заказчиками. Если кто-то спрашивал, чем я занимаюсь “по жизни”, я отвечал что-то вроде: «Чиню компьютеры» или «Решаю проблемы с компьютерами». В то время я ни разу даже не слышал об ITSM и, конечно же, не думал, что я делаю такие вещи, как Управление Инцидентами (Incident Management) или Управление Проблемами (Рroblem Мanagement).
ITIL в 1990-х
В середине 1990-х, я наткнулся на ITIL (ведущий набор лучших практик для реализации ITSM), и это стало для меня откровением. Это было, как обнаружить семью, которую я никогда не знал. Я открыл для себя идеи для своей деятельности, такие как Управление Доступностью (availability management), Управление Непрерывностью Услуг (service continuity management), Управление Изменениями (change management) и Управление Проблемами (problem management). Теперь я имел набор шаблонов, которые мог использовать, чтобы добавить в свою работу больше последовательности и строгости. Также у меня теперь был сленг, облегчающий общение с коллегами и заказчиками.Я пошел курсы ITIL Foundation и ITIL Service Manager, а в конечном итоге стал ITIL инструктором, передающим эти великие идеи остальным людям, чтобы помочь им достигать карьерные цели.
В то время ITIL был более всего сфокусирован на процессах, и предоставлял набор идей для их создания. В компаниях, которые начинали использовать ITIL, команды поддержки ИТ прекращали жить от инцидента к инциденту, от аврала до аврала, определения важности проблемы по громкости крика обращающегося. Вместо этого они направили свою энергию на согласование уровня обслуживания со своими заказчиками. В результате теперь они были уверены, что уровни, которые они согласовали, используя идеи ITIL, помогают им создавать повторяемые процессы, и это, в свою очередь, позволяло им быть уверенными, что оговоренное обслуживание предоставляется систематически.
ITIL 2007 edition
В 2007 годы вышел новый релиз ITIL. Самым большим изменением стала новая структура, построенная вокруг жизненного цикла услуг. Теперь стало проще понять, чем являются услуги, и больше стал фокус на их значимости для пользователей. Наибольший акцент делался на Стратегию (Service Strategy, SS) и Разработку Услуг (Service Design) и появилась целая книга о Непрерывном Улучшении Услуг (Continual Service Improvement, CSI). Также стало подразумеваться, что соблюдение SLA может не быть самым важным, что делает ИТ в организации. Было так обычным для нас поставлять SLA пока наши заказчики грустили, разочаровывались или бесились. Фокус на услугах и было тем в чем мы по факту нуждались. Нам пришлось понять наших заказчиков с пользователями и обеспечить им действительную ценность от наших сервисов.
Так я изменил свой подход к работе.
Я продолжал пытаться обеспечивать согласованные целевые показатели, но, когда обстоятельства вынуждают, я понял, что могу их игнорировать целевые показатели и фокусироваться на том, что заказчик действительно хочет. Важной вещью была удовлетворенность заказчика и опыт работы с заказчиком. Но, конечно, вести себя так стоит только, когда уместно, а это требует от ИТ организации в первую очередь зрелых процессов, а так же опытного штата сотрудников, который уверенно работает без жестких зависимостей от заведенных порядков и повторяемости процессов.
Многие считают преобразование от фокуса на процессах к фокусу на услугах крайне сложным. В ITSM остаются люди, уверенные в необходимости придерживаться SLA, даже когда это вредит их заказчикам. Я часто общался с такими людьми и один на один, и в социальных сетях, пытаясь убедить их отойти от очень старомодного процесс ориентированного подхода. Иногда мне это удавалось, но часто они продолжали работать без изменений, вызывая проблемы для своих заказчиков в любой отрасли.
Что дальше?
Тем временем ITSM снова двигается вперед. Мир разработки программного обеспечения внедрил у себя идеи Agile и DevOps. Множество участников ITSM сообщества также признают, что тоже нуждаются в дальнейшем развитии, для предоставления бо’льшей ценности для своих заказчиков. Вот некоторые из вещей, которые, я думаю, повлияют на будущее ITSM. Здесь мне не хватит места, чтобы подробно изложить все идеи, но, надеюсь, что сказанного будет достаточно, чтобы подогреть ваш интерес и дать Вам самостоятельно побольше поизучать.
Agile
Манифест для гибкой (Agile) разработки программного обеспечения был опубликован в 2001 году. В нем подчеркивалась важность того, что:
— личности и их взаимоотношения важнее процессов и инструментов
— работающий программный продукт важнее полноты документации по нему
— сотрудничество с заказчиком важнее контрактных обязательств
— реакция на изменения важнее следованию планам
Результат этого гораздо более гибкий и быстрый подход, что дает колоссальные улучшения качества нового программного обеспечения, а также содействует возможности быстро реагировать на изменение бизнес нужд.
Некоторые идеи Agile сейчас применяются в ITSM. Они изменили представления о лучшем подходе к развертыванию и улучшению ITSM (нет больше многолетних ITSM проектов) и лучших способах поддержки заказчиков (люди и их взаимоотношения важнее процессов и инструментов).
Lean
Lean — это подход к управлению, который подчеркивает важность создания максимальной ценности для заказчика при минимальных затратах. Если Вы хотите узнать об этом больше, то можете найти статьи в интернете про производство по Lean, про разработку продуктов по Lean и про разработку программного обеспечения по Lean.
В контексте ITSM наиболее важные аспекты Lean:
— определение сквозной цепочки ценности, частью которой Вы являетесь
— гарантия, что все Ваши действия создают ценность для Заказчика
— устранение пустых затрат в любых действиях, уменьшение этапов процессов до максимальной простоты, необходимой для создания ценности.
Автоматизация
Автоматизация всегда была частью управления ИТ. Даже когда я начинал (в конце 1970-х), мы автоматизировали задачи везде, где только могли. Что же изменилось изменилось? Стали более доступны инструменты, обеспечивающие и облегчающие автоматизацию. Теперь вы можете автоматизировать почти все что угодно, если решите это делать.
Есть всего несколько вещей, которые не могут быть автоматизированы, потому что они требуют человеческой экспертизы, как части создания процесса. Мы можем автоматизировать все остальное, что мы способны делать, до тех пор пока:
— мы действительно понимаем, что и как делаем
— достаточно простые действия, которые можно легко документировать
— то, что случается часто и автоматизация может это усовершенствовать и улучшить
— автоматизация станет не способной заменить человеческую оценку по гибким правилами
DevOps
DevOps эксплуатирует идеи из Agile, Lean и автоматизации для улучшения прохода программного обеспечения из разработки к заказчикам. DevOps подчеркивает три направления:
- Поток/Путь — понимание как вы приспосабливаетесь в сквозной цепочке ценностей, исключаете бутылочные горлышки, ограничивающие развитие
- Обратная связь — предоставление быстрой обратной связи для помощи в идентификации и устранении недостаточного качества как можно быстрее и с минимальными затратами
- Эксперименты и обучение — создание предположений и предсказаний, тестирование их, изучение и улучшение.
Комбинации этих трех направлений с интенсивным сотрудничеством смежных команд и крайне высокий уровень автоматизации дает в результате максимально быстрое развертывание/внедрение нового и измененного софта с высокими гибкостью и удовлетворенностью пользователей.
DevOps обычно автоматизирует множество из задач, которые выполняют разработчики программного обеспечения, но он не включает в себя операционные аспекты разработки.
ITSM должен использовать это. Мы должны способствовать развитию новых идей и помогать обеспечивать, что значительное увеличение автоматизации рутинных операций не задевает оценку человека сквозь весь процесс.
Корпоративное Управление Услугами (Enterprise Service Management)
Множество идей, инструментов и процессов, которые используются в разработке и поддержке ITSM также полезны для поддержки не ИТ-услуг. Корпоративное Управление Услугами использует те же подходы для всей организации, включая управление возможностями, управление персоналом, юристов и любые другие подразделения, предоставляющие услуги.
Мы все нуждаемся в управлении инцидентами и проблемами, исполнении запросов на услуги и взаимодействии с заказчиками. Используя одни и тебе инструменты, процессы и подходы мы можем обеспечить общекорпоративные услуги.
Эффективное Общекорпоративное Управление Услугами это не только применение ITSM инструментов другими подразделениями, но и вовлечение сквозного для всей организации сотрудничества и обучения. Часто ИТ департамент может многому научить в предоставлении услуг.
ITIL Practitioner
Последние пополнение ITIL это Руководство Практика ITIL (ITIL Practitioner Guidance), вышедшее в январе 2016 года. Эта публикация поддерживает множество идей, описанных в данном блоге.
ITIL Practitioner излагает девять руководящих принципов:
- Концентрироваться на ценности (Focus on value)
- Работать на людей (Design for experience)
- Отталкиваться от того, как есть сейчас (Start where you are)
- Работать системно (Work holistically)
- Двигаться маленькими шажками (Progress iteratively)
- Наблюдать в месте использования (Observe directly)
- Быть понятным (Be transparent)
- Сотрудничать (Collaborate)
- Делать проще (Keep it simple)
Также обсуждаются три корневые компетенции:
- Метрики и процесс измерения
- Коммуникации
- Организация Управления Изменениями
И все это описывается в контексте Непрерывного Улучшения ИТ Услуг. Если Вы хотите узнать больше об ITIL Practitioner, я рекомендую прочитать руководство по ITIL Practitioner и пойти учебный курс. Также можете ознакомиться с ревью ITIL Practitioner от моего хорошего друга Стефена Манна (Stephen Mann).
В заключении
ITSM помог ИТ организациям превратиться из провайдера технологий в провайдера создающих ценность услуг. И нельзя останавливаться, если мы будем решать проблемы 21 века методами 1990-х, то быстро станем неадекватны.
Каждый кто предоставляет или поддерживает ИТ услуги нуждается в использовании новых подходов и принятие новых идей, т.к. они повышают ценность услуг для заказчика.
Некоторые из концепций, о принятии которых вы могли бы задумываться, описаны в этом блоге, но еще существует множество других, которые также будут полезными.
Мне очень нравятся:
- Канбан — метод управления разработкой/производством, основанный на принципе “точно в срок”,
- Cobit 5 — сборник практик/рекомендаций по Руководству ИТ для создания ценности Бизнесу,
- Resilia — сборник практик и система сертификации специалистов по управлению информационной безопасностью от AXELOS
Вы можете узнать больше из текущих обсуждений этих тем в соцсетях:
Ну, и посещайте мероприятия, организуемые:
От себя добавлю пару ссылок на русскоязычные ресурсы на тему ITSM:
- сайт itSMF Russia
- страница на facebook itSMF Russia
- архив вебинаров на темы ITSM от Cleverics (одного из лидеров российского ITSM конcалтинга и обучения)
- новостной портал, блоги практиков и обсуждение вопросов ITSM от того же Cleverics
На этом все. Надеюсь чтение было полезным.
Спасибо за внимание, оставляйте свои оценки в комментариях.
Поделиться с друзьями