![[info]](http://l-stat.livejournal.com/img/community.gif?v=92.1){kind=small}
![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
Давайте попробуем разобраться вместе.
Таким образом, ключевые рекомендации к внедрению процесса управления событиями можно свести к следующему:
• При определении охвата процесса всегда нужно понимать, что первична информация о состоянии сервисов, влияние ресурсов на состояние сервисов отслеживается с помощью сервисно-ресурсной модели;
• Не нужно пытаться объять необъятное, начинать внедрение следует с IT-сервисов высокой степени критичности, для которых имеются хоть какие-то SLA, пусть и не утвержденные, или хотя бы устные договоренности с бизнесом об их уровнях и критериях оценки;
• Необходимо полностью исключить возможность ввода в эксплуатацию ресурсов и сервисов, без решения о необходимости их мониторинга и определения его параметров;
• Всегда нужно настраивать двустороннюю связь между управлением событиями и управлением инцидентами, а систему мониторинга интегрировать с Service Desk;
• Однотипные события должны обрабатываться по типовым схемам, которые должны быть доступны для персонала Service Desk;
• Инструмент мониторинга выбирается, исходя из задач IT-службы, а не наоборот.
Ну и, наконец, даже успешно внедрив управление событиями, не стоит останавливаться на достигнутом – систематический анализ и постоянное улучшение должны стать неотъемлемой частью процессной деятельности.
Возможно, весь этот "сериал" кому-то показался констатацией очевидных фактов, но, тем не менее, хорошо работающие системы мониторинга в сочетании с эффективной организацией управления событиями встречаются гораздо реже, чем могли бы при выполнении правил, сформулированных выше.
В целом ясно, что инновации должны повышать эффективность предприятия. Но и внедрение новых технологий направленно именно на это. В чем же корневое отличие?
Мое мнение такое: инновацией можно называть эффективную существенную модификацию процессов с применением передовых подходов в производстве, образовании и науке.
Наука - в широком смысле - дает перспективное направление, создает новшество. Образование доводить его до умов задействованных людей, производит диффузию знаний между наукой и производством. Производство претворяет новшество в жизнь и обеспечивает отдачу, повышает эффективность в производстве/бизнесе. Если одно из звеньев отсутствует, инновацией, думаю, это назвать нельзя.
Недавно в беседе со своим руководителем Владимиром Трухиным я был поставлен в тупик простым вопросом: "А может ли сервисный инцидент (те инцидент, вызванный неспособностью пользователя ВОСПОЛЬЗОВАТЬСЯ услугой) трактоваться как запрос на обслуживание с формулировкой "Запрос на восстановление услуги" и не противоречит ли это ITIL?"
Вначале это было воспринято мной как ересь и, чтобы укрепиться в вере, я обратился к первоисточнику. В книге Service Operation в разделе 4.3 библиотеки ITIL написано "The term ‘service request’ is used as a generic description for many different types of demands that are placed upon the IT organization by the users", если перевести близко к тексту, то "Термин 'запрос на обслуживание' используется в качестве общего описание различных типов запросов, с которыми пользователи обращаются к (размещают в) ИТ". В той же книге в Service Operation разделе 4.2 написано "In ITIL terminology, an ‘incident’ is defined as an unplanned interruption to an IT service or reduction in the quality of an IT service or a failure of a CI that has not yet impacted an IT service (for example failure of one disk from a mirror set)" и опять же в близком переводе это звучит как "В терминологии ITIL "инцидент" определяется как незапланированный перерыв в предоставлении ИТ-услуги или снижение качества ИТ-услуги или отказ CI, который еще не повлиял на ИТ-услугу".
Так что же из этого следует? А следует по моему мнению, что да, такая трактовка возможна и не противоречит ITIL. То есть картина мироздания получается следующей:
1. Все обращения пользователей, в том числе сервисные инциденты, оформляются как запросы на обслуживание.
2. Все инфраструктурные инциденты, те инциденты, связанные с работой инфраструктуры, оформляются как просто инциденты, и к ним привязываются все обращения пользователей, связанные с невозможностью воспользоваться услугой.
А есть ли преимущества у такого подхода? Мне кажется, что могут быть следующие возможные преимущества:
1.Более наглядный каталог услуг и статистика видов обращений по каждой услуге, в том числе затруднений с использованием услугой у пользователей
2.Понятие "инцидент" более драматизируется, более четкое разделение ответственности между поддержкой и службами, отвечающими за работу инфраструктуры
3.Первая линия поддержки часто испытывает трудности с привязкой сервисного инцидента к конкретному сбойному CI, это лучше получается у специалистов второй линии и при инцидентах, связанных с работой инфраструктуры.
Какие будут мнения, уважаемые коллеги?
Нельзя не сказать еще и о такой специфически российской проблеме, как выбор инструмента мониторинга. Очень часто этот выбор обусловлен одним единственным критерием – стоимостью. Нужно ли говорить, что подстройка процессов под средство автоматизации в организации с количеством пользователей IT-услуг больше сотни вряд ли может привести к чему-то хорошему. В лучшем случае будут использоваться только те возможности системы мониторинга, которые не противоречат сложившейся в организации практике управления, а в худшем – получится картина, описанная в самом начале. Не нужно пытаться выстроить задачи под возможности систем мониторинга, это не ERP, они не настолько дороги и глобальны, чтобы уменьшать издержки таким образом. В большинстве случаев самописная система, построенная в соответствии с бизнес-логикой организации в разы эффективнее самой навороченной и дорогой от известного вендора, но неправильно или не полностью внедренной.
У меня однозначного определения/ответ нет. Так как, в моем понимании есть сервис, а есть СЕРВИС. В случае маленького сервиса, вам предлагается "что-то" и вы сами решаете нужно "оно" вам или нет (почта, печать, интернет....). А вот в случае же большого СЕРВИСА, кто-то за ваши деньги предлагает вам серьезное или даже решающее содействие в решении вашей персональной задачи или проблемы.
Пример:
1. Почта, интернет, печать, видео-конференции, софт1, софт2 и т.п., закрепленные в Каталоге ИТ-услуг, который вывешен на корпоративном интернет-портале с полным описанием параметров цены, условий, обязательств - это сервисы с "маленькой" буквы
2. Проактивная и повседневная работа ИТ-службы над повышением результативности и рациональности конкретной бизнес-деятельности (бизнес-подразделения, бизнес-функции, бизнес-процесса) за счет подбора и применения совокупности эффективных, экономичных и надежных информационных технологий (куда могут в том числе войти и почта и софт и т.п.) - это СЕРВИС с "большой" буквы
Что-то мне подсказывает, что обсуждение нюансов поддержки маленького сервиса настолько отвлекает на себя внимание ITSM-сообщества, что большой СЕРВИС вынужден добиваться к себе внимания при помощи конкурирующих методологий (того же CobiT)
ITIL шагает по планете. Ежемесячно растет количество сертифицированных специалистов на всех континентах планеты. Или почти на всех …
Пингвины в Антарктике, если верить статистике, с завидным постоянством игнорируют не только сертификацию ITIL Intermediate, но даже ITIL Foundation. Количество кандидатов на сертификацию в этом перспективном регионе стабильно держится на нулевой отметке ...
– COBIT 5: Enabling Information (в разработке)
– COBIT 5 Implementation
Пока могу поделиться только субъективными ощущениями от описания процессов.
Издание 4 версии для меня было разочарованием, я ожидал бОльшего, не было чувства новизны, не было видно идеи - зачем понадобилось выпускать НОВУЮ версию (кроме коммерческих интересов). Здесь же явно заметно, что были переосмыслены методологии управления (management) и руководства (governance), а также сервисного управления вплоть до сервисной стратегии. Одним из явных свидетельств является появление нового домена: Evaluate, Direct and Monitor.
Преобразования явны достойны НОВОЙ версии. И это - замечательно!
Продолжаем.
Довольно часто в разных организациях можно наблюдать следующую картину: в понедельник утром внезапно выясняется, что какой-нибудь важный для бизнеса сервис не подает признаков жизни. В ходе расследования инцидента выясняется, что новый сервис был введен в эксплуатацию, а вопрос, нуждаются ли его компоненты в мониторинге, и каковы параметры последнего ни с кем, ввиду вечной спешки, даже не обсуждался. В результате из-за пустяковой неисправности, которая случилась в пятницу вечером и могла быть исправлена дежурной сменой за пару минут, пара часов времени, миллионы нервных клеток и кило репутации IT-службы были потрачены утром понедельника совершенно непродуктивно.
А ведь для предотвращения подобных ситуаций не нужна высокая степень зрелости процесса управления релизами (особенно, если этого процесса вообще нет), достаточно для начала просто регламентировать ввод в эксплуатацию новых сервисов и их компонентов и обязать ответственных за их эксплуатацию предоставлять метрики и их пороговые значения для мониторинга. Разумеется, в третьей версии ITIL предлагается пойти еще дальше и учитывать требования управления событиями еще при проектировании сервисов, и с этим трудно спорить, но будем реалистами: в наших условиях это скорее относится к совершенствованию уже внедренного и хорошо работающего процесса.
- На основе спецификации проектных решений сформировать критерии оценки результатов внедрения ИТ-процессов (документы, политики и процедуры, цели и задачи, показатели и метрики, компетенции и роли, ресурсы, входы/выходы, менеджмент качества и т.п.).
- Разложить сформированные критерии оценки по атрибутам уровней зрелости CobiT.
- Подготовить на основе ISO 15504-3 частную методику оценки зрелости процессов с использованием подготовленных критериев оценки. ISO 15504-3 органично дополняет CobiT в части унификации правил измерения процессов (гарантирует сопоставимость результатов измерения от разных оценщиков).
- Получить от внутренних или внешних аудиторов экспертное заключение о том, адекватна ли наша методика целям сбалансированной и сопоставимой оценки процессов и на какой уровень зрелости мы в своем проекте замахиваемся (он и будет целевым уровнем зрелости для проекта). А заодно узнаем их независимое экспертное суждение о достаточности проектных решений.
- Выстроить на языке уровней зрелости измеряемую тактику внедрения проекта от текущего уровня зрелости к целевому. Такую тактику особенно полезно выстраивать в территориально-распределенной среде, в которой есть разные по значимости и специфики функций объекты ИТ-управления, для которых может оказаться целесообразным снизить планку требований (понизить целевой уровень)
- Возможность формирования оценки в цифрах: Где хотели оказаться и где фактически оказались, а также какие именно несоответствия нам помешали достигнуть целевого уровня.
- Согласованную с внешними и внутренними аудиторам шкалу и методику оценки наших процессов управления, что позволит выстроить с ними конструктивную модель взаимоотношений
- Методологическую основу для внутрифирменного бенчмаркинга, когда мы можем сравнивать различные ИТ-подразделения по единым критериям оценки и результаты сравнения формализовать в цифрах (кто у нас отстает, а у кого лучшие результаты для тиражирования опыта)
- Возможность формализовать оценку надежности внешних поставщиков (надежность поставщиков), а также сравнивать себя с другими организациями (меряться рейтингами)
- Получить апробированную методику оценки, достойную для формирования на ее основе внутрифирменного или отраслевого стандарта оценки процессов ИТ-управления.
Первые грабли на которые я наступил на моих первых шагах в ИТ лежали зубцами вверх . Мне повезло. Я был тогда не очень высок, я имею ввиду не был высоким начальником, и удар пришелся в воздух повыше лба. Свист рассекаемого воздуха был внушительным и запомнился на всю жизнь.
( А было это так... )
Управление ИТ активами - тема, которая многим компаниям стала интересна, и которая еще обострилась по результатам бывшего финансового кризиса. Т.к. для многих ИТ руководителей обострился вопрос "... куда уходят деньги...". Многие попросили от своих подчиненных обоснования расходов на ИТ. Но у многих не было отлаженного процесса отслеживания финансовых потоков и управление затратами на ИТ активы. Кризис заставил четче считать деньги и многие были вынуждены сокращать расходы ни ИТ. Только как это грамотно сделать без ущерба для основной деятельности организации? Также обострился вопрос стыковки с российской бухгалтерией, которая живет по своим законам, не ведомым ИТ персоналу.
Жизнь познакомила меня с этой темой и с теоретической точки зрения и с практической, на базе внедрения элементов "теории" для Российской действительности. Чем и хочу поделиться и призвать коллег поделиться своим опытом по данной теме:
По теории (совсем кратко):
Существует несколько различных источников знаний, обобщающих мировой опыт по этой теме.
Хотелось бы выделить 2 источника, применение которых на практике, по моему опыту, позволяют построить достаточно целостное решение по управлению ИТ активами компании:
* всеми любимый ITIL, который охватывает вопрос управления ИТ активами, но в основном в разрезе, необходимом и достаточном для обеспечения эксплуатации и управления сервисами
* ассоциация IAITAM (и библиотека книг IBPL)
Охватывает вопрос построения управления активами HW и SW на протяжении всего жизненного цикла от планирования закупки, эксплуатации до вывода из эксплуатации. Основной ориентир - отслеживание всех финансовых вопросов по каждому ИТ активу, применение данного подхода позволяет посчитать TCO и отслеживать ROI по ИТ активам.
Из практики, могут быть различные пути познания темы ITAM, хочу поделиться, с чем мне удалось познакомиться:
* был опыт внедрения ITAM в организации, которая ничего не знала про ITSM. Они сильно зависели от поставщиков и им было интересно отслеживать все финансовые потоки с поставщиками услуг, планирование закупок оборудования, расходы на эксплуатацию, расходы и финансовые потери при выводе из эксплуатации. Внедрив ITAM ( на базе IBPL) они получили ясную прозрачную картину и по каждому ИТ активу могли понять его текущую стоимость.
* Также был опыт общения с корпорацией, в которой уже были внедрены различные ITSM процессы от INC до SLM, которые полноценно работают и приносят свои результаты, обеспечивая бизнес. Они пришли к необходимости внедрения ITAM для обеспечения финансовой прозрачности по каждому ИТ активу, чтобы понимать из чего реально складываются расходы по каждому сервису.
По моему мнению, грамотное объединение практик, изложенных в ITIL и в IBPL, позволит найти целостное решение по управлению ИТ активами различного типа (HW+SW+Сервисы) на протяжении всего их жизненного цикла, что позволит получить прозрачную картину управления финансами по каждому сервису. Также это позволит измерить вклад каждого ИТ актива в результаты бизнеса, в ценность, которую обеспечивает бизнес.
Для многих эта тема является новой и не познанной. И возможны разные пути и подходы к ее решению. Все подходы имеют свои преимущества и имеют право на жизнь. Каждому ИТ руководителю, столкнувшемуся с такой задачей, хотелось бы понять, "какой вариант для меня будет лучше?".
Понять, как лучше идти, можно анализируя практику, понимая изначальную постановку задачи, выбранный путь ее решения, полученные результаты и подводные камни, которые были на пути.
Прошу вас поделиться своим практическим опытом и своим видением по данной теме.
Продолжение...
Очень часто (особенно в российских организациях) системы мониторинга внедряются «снизу» без связи с сервисами, то есть, при определении корректного уровня фильтрации событий внедренцы смотрят на проблему с ресурсной точки зрения, с позиции системного администратора. А эта позиция специфична: у администратора свои критерии работы ресурса, которые весьма часто сводятся к триггеру «работает – лежит». А об уровне сервиса, например, администратор ничего не знает, и далеко не всегда это его вина. В итоге получается, что с точки зрения админа сервер работает, а пользователи почему-то обрывают телефон IT-директора.
Для того чтобы корректно определить уровень фильтрации событий, нужно начинать с сервисов: ведь именно их состояние является первичным. Состояние сервисов обусловлено состоянием ресурсов, которые используются для их предоставления, а между собой сервисы и ресурсы, как известно, связаны через сервисно-ресурсную модель. Таким образом, без тесной связи с другими процессами ITSM внедрение управления событиями не имеет практического смысла, если, конечно, система мониторинга не является самоцелью.
Важнейшим процессом, обеспечивающим успех в управлении событиями, является управление конфигурациями. Именно здесь создается сервисно-ресурсная модель, и определяются зависимости сервисов от ресурсов. Без понимания этих зависимостей невозможно правильно ответить на основной вопрос о необходимом уровне фильтрации событий.
Со степенью зрелости управления конфигурациями связана еще одна распространенная ошибка при внедрении систем мониторинга. Используя терминологию менеджмента, можно назвать это попыткой «проглотить слона целиком» (вместо того, чтобы нарезать). Часто при внедрении пытаются настроить мониторинг сразу всех сервисов и систем, не оценив предварительно объем работ и требуемые ресурсы. Это приводит к тому, что на определенном этапе ресурсы на проект начинают выделяться по остаточному принципу, а сроки сдвигаются в сторону светлого будущего, которое, понятно, при таком подходе вряд ли когда-нибудь наступит.
Возможно, многие из вас наслышаны об этой игрушке. Многие играли или играют до сих пор. Многие ненавидят ее – или потому что сами тратят на нее слишком много времени, или потому что из-за нее другие люди не успевают вовремя сделать необходимые вещи.
Если вам еще не знаком этот timekiller – то, наверное, лучше и не надо с ним знакомиться (особенно, если вы подвержены игромании). А главное – дальше читать бесполезно. А вот тем, кто приложил руку к битве птиц и зеленых свиней, будет интересно узнать, что тщательный анализ lessons learnt от игры прекрасно применим к внедрению сервис-менеджмента в организации (и не только).
( Знаком ли я с Angry Birds? КОНЕЧНО! )В последнее время все чаще и чаще встречаются проекты, где на основе ITIL внедряется управление сервисами в компании вообще. Прямо так: организуется единая диспетчерская служба и она начинает принимать запросы на услуги относительно любого направления в компании.
Действительно жизнь подсказывает интересную идею – зачем внедрять кучу координационных ресурсов только для ИТ, когда их можно использовать на всю компанию? Ведь и маркетинг и юристы и бухгалтерия и остальные тоже оказывают услуги для бизнеса. Да и инциденты решают, что уж тут говорить;)
Так вот бизнес, особенно в условиях кризиса, и требует – раз уж нужен сервисный подход, так и распространить его на всех!
В этом смысле сервисный подход во многом становиться похож на проектный подход. Ведь проектный подход тоже в основном не имеет специфики относительно направления проекта. Ну может быть только относительно специфических рисков в каждом виде деятельности…
ссылки по теме:
Официальный сайт: usmbok.org
Обзор USMBOK: http://www.styrnov.ru/blog/usmbok/
Какие мысли на этот счет? Поддерживаете тенденцию?
