Полет на Луну на одной заправке (Часть 3)
Наверное, пора закруглять тему, поднятую в частях №1 и №2. А то дискуссия развернулась философская и я уже почти забыл, зачем все начал. А идея была предложить свой взгляд на будущее управления информационными технологиями, будущее ITSM.
Итак, все вроде хорошо? Технологии повзрослели и окрепли. Не нужно прилагать сверхусилия для обеспечения надежности и производительности компьютерных систем. Каждый способен дома собрать вычислительную сеть, которая 10-15 лет назад и не снилась профессионалам. Сейчас, например, у меня дома дисковый массив емкостью, которой не было в у меня не было в корпоративной сети еще семь лет назад.
Но полной идилии в отношениях бизнеса с информационными технологиями не наступает! В начале 2000-ых случились разочарования от дот-комов. Сейчас же не приносят ожидаемых преимуществ облачные технологии и SaaS-ы. Почему?
На мой взгляд технические аспекты сейчас опережают уровень культуры в ИТ среде. Опережают уровень управленческой культуры, уровень сервисного менталитета. То есть мы сейчас не имеем адекватного инструмента (мозга, если хотите), который бы был способен управлять сложным организмом, который сейчас представляют собой информационные технологии. Инструмента, который позволил реализовать весь скрытый в них потенциал. (Проблема то, кстати более глобальная, я о ней говорил еще в 2008 году на конференции по Открытых систем по ИТ-сервис менеджменту. На мой взгляд и современный экономиеских кризис произошел из-за того, что мировая экономика отрастила тело динозавра, а мозг остался с грецкий орех. А сегодня эту же мысль обсуждали на конференции "Роль хайтека в будущем России".)
Какой выход? Здесь скорее не выход, здесь путь. И этим путем многие уже давно идут. Это путь, связанный с реализацией сервисного подхода к ИТ управлению, подход, который был инициирован созданием библиотеки ITIL. Собственно, ITIL и появился из-за того, что ИТ-шники не знали, что делать с теми приложениями, которые разрабатывал бизнес, а потом отдавал в ИТ подразделения для обеспечения их эксплуатации. Как обеспечить доступность, производительность, непрерывность? Особенно, если это уже разработано не тобой, и эксплуатационные аспекты не учитывались в необходимой мере в момент создания. Как организовать восстановление в случае возникающих сбоев? Как корректно проводить изменения?
Все это отразилось в структуре процессов, описанных в ITIL 1-ой версии. Затем было лучше и понятней структурировано во 2-ой версии библиотеки. Помните, какие основные тактические процессы были? Управление доступностью, мощностями, непрерывностью. А Service Level Management представлялся как процесс-посредник, этакий парламентер. И все! Не было и намека в них на то, как понять, что нужно бизнесу от информационных технологий? Как продемонстрировать и сгенерировать добавленную ценность?
Ну если честно, то намек то был. Однако, подавляющим большинством ИТ-специалистов и консультантов остались недооцененными книги: "Understanding and Improving" из ITIL v.1 и "The Business Perspective" из ITIL v.2. В них было сформулировано много передовых идей, которые тогда большинством воспринимались как бесполезная философия.) Собственно, многие идеи из этих книг вошли сейчас в том "Service Strategy", входящий в состав ITIL v.3. Что симптоматично, новая версия ITIL и сейчас многими воспринимается как излишне сложная и "водянистая". Хотя именно в ней, на мой взгляд, и содержаться идеи, крайне необходимые современным технологиям. Идеи которые позволят динозавру - информационным технологиям вырастить мозг с размерами больше, чем грецкий орех.
В результате, основными процессами в Системе управления ИТ сервисами станут процессы позволяющие управлять ценностью, а не только лишь гарантировать их доступность, производительность, безопасность, то что мы преимущественно имеем в настоящее время.
Именно эти процессы управления должны дополнить технологии, типа SaaS, так, чтобы потребитель, например,мог так же просто послать запрос в Service Desk сообщая о своих потребностях, как сейчас он обращается с информацией об инциденте. А ему уже подберут необходимый сервис, стандартный или специально созданный, определят оптимальный уровень этого сервиса и помогут его лучшим образом потреблять.
Итак, все вроде хорошо? Технологии повзрослели и окрепли. Не нужно прилагать сверхусилия для обеспечения надежности и производительности компьютерных систем. Каждый способен дома собрать вычислительную сеть, которая 10-15 лет назад и не снилась профессионалам. Сейчас, например, у меня дома дисковый массив емкостью, которой не было в у меня не было в корпоративной сети еще семь лет назад.
Но полной идилии в отношениях бизнеса с информационными технологиями не наступает! В начале 2000-ых случились разочарования от дот-комов. Сейчас же не приносят ожидаемых преимуществ облачные технологии и SaaS-ы. Почему?
На мой взгляд технические аспекты сейчас опережают уровень культуры в ИТ среде. Опережают уровень управленческой культуры, уровень сервисного менталитета. То есть мы сейчас не имеем адекватного инструмента (мозга, если хотите), который бы был способен управлять сложным организмом, который сейчас представляют собой информационные технологии. Инструмента, который позволил реализовать весь скрытый в них потенциал. (Проблема то, кстати более глобальная, я о ней говорил еще в 2008 году на конференции по Открытых систем по ИТ-сервис менеджменту. На мой взгляд и современный экономиеских кризис произошел из-за того, что мировая экономика отрастила тело динозавра, а мозг остался с грецкий орех. А сегодня эту же мысль обсуждали на конференции "Роль хайтека в будущем России".)
Какой выход? Здесь скорее не выход, здесь путь. И этим путем многие уже давно идут. Это путь, связанный с реализацией сервисного подхода к ИТ управлению, подход, который был инициирован созданием библиотеки ITIL. Собственно, ITIL и появился из-за того, что ИТ-шники не знали, что делать с теми приложениями, которые разрабатывал бизнес, а потом отдавал в ИТ подразделения для обеспечения их эксплуатации. Как обеспечить доступность, производительность, непрерывность? Особенно, если это уже разработано не тобой, и эксплуатационные аспекты не учитывались в необходимой мере в момент создания. Как организовать восстановление в случае возникающих сбоев? Как корректно проводить изменения?
Все это отразилось в структуре процессов, описанных в ITIL 1-ой версии. Затем было лучше и понятней структурировано во 2-ой версии библиотеки. Помните, какие основные тактические процессы были? Управление доступностью, мощностями, непрерывностью. А Service Level Management представлялся как процесс-посредник, этакий парламентер. И все! Не было и намека в них на то, как понять, что нужно бизнесу от информационных технологий? Как продемонстрировать и сгенерировать добавленную ценность?
Ну если честно, то намек то был. Однако, подавляющим большинством ИТ-специалистов и консультантов остались недооцененными книги: "Understanding and Improving" из ITIL v.1 и "The Business Perspective" из ITIL v.2. В них было сформулировано много передовых идей, которые тогда большинством воспринимались как бесполезная философия.) Собственно, многие идеи из этих книг вошли сейчас в том "Service Strategy", входящий в состав ITIL v.3. Что симптоматично, новая версия ITIL и сейчас многими воспринимается как излишне сложная и "водянистая". Хотя именно в ней, на мой взгляд, и содержаться идеи, крайне необходимые современным технологиям. Идеи которые позволят динозавру - информационным технологиям вырастить мозг с размерами больше, чем грецкий орех.
В результате, основными процессами в Системе управления ИТ сервисами станут процессы позволяющие управлять ценностью, а не только лишь гарантировать их доступность, производительность, безопасность, то что мы преимущественно имеем в настоящее время.
Именно эти процессы управления должны дополнить технологии, типа SaaS, так, чтобы потребитель, например,мог так же просто послать запрос в Service Desk сообщая о своих потребностях, как сейчас он обращается с информацией об инциденте. А ему уже подберут необходимый сервис, стандартный или специально созданный, определят оптимальный уровень этого сервиса и помогут его лучшим образом потреблять.
Comments