Большинство из тех, кто только приступает к изучению ITSM, надеется найти универсальные источники знаний, дающие рецепты быстрого и полного внедрения процессов управления ИТ-услугами. Более опытные товарищи, равно как и грамотные консультанты подсказывают новичкам: готовых рецептов не существует, изменение работы ИТ-подразделения – кропотливая и трудоёмкая задача, в каждом случае решаемая по-своему
erid: LjN8KXX2o ИТ Медиа
Реклама
Большинство из тех, кто только приступает к изучению ITSM, надеется найти универсальные источники знаний, дающие рецепты быстрого и полного внедрения процессов управления ИТ-услугами. Они ищут шаблоны документов, планов, регламентов, а также преднастроенные системы автоматизации, не требующие большой доработки и предоставляющие всю нужную функциональность «из коробки». Более опытные товарищи, равно как и грамотные консультанты подсказывают новичкам: готовых рецептов не существует, изменение работы ИТ-подразделения – кропотливая и трудоёмкая задача, в каждом случае решаемая по-своему.
Однако два известных ITSM-эксперта из Нидерландов, Ян ван Бон и Вим Ховинг, утверждают, что разработали универсальный метод организации всех основных процессов управления ИТ почти в любой компании за очень короткий срок. Давайте разберёмся.
Обилие знаний
Принято считать, что история ITSM началась в 80-х годах прошлого века (см., к примеру, интервью Джона Стюарта). За тридцать лет в области управления и контроля информационных технологий возникло множество так называемых источников знаний. Некоторые из них претендуют на звание стандартов, другие – методологий, иные именуют себя сборниками лучших (иногда – хороших) практик. К наиболее известным можно причислить библиотеку ITIL (IT Infrastructure Library), стандарт ISO/IEC 20000, а также:
COBIT (ранее эта аббревиатура расшифровывалась как Control Objectives for Information and Related Technology),
ASL (Application Services Library),
BiSL (Business Information Services Library),
USMBoK (Universal Service Management Body of Knowledge),
MOF (Microsoft Operations Framework),
HP Reference Model,
ITUP (IBM Tivoli Unified Process),
...
Перечисленные своды знаний отличаются назначением, областями охвата, детальностью изложения, процессными моделями и многими другими характеристиками, но схожи, как минимум, в одном – почти все они теми или иными словами призывают адаптировать изложенные рекомендации при применении в конкретной компании (известная мантра «adapt before adopt»). Такой совет звучит достаточно разумно, и некоторые ИТ-подразделения пытаются использовать его при организации своей работы. Однако так поступают не все.
Многие ИТ-руководители для решения своих управленческих задач стараются подобрать какую-либо одну методологию в надежде, что она позволит устранить максимальное число имеющихся болевых точек. Согласитесь, было бы очень удобно взять с полки одну книжку, желательно не очень объёмную, в которой прочесть: какие ИТ-процессы следует организовать, как эти процессы должны быть устроены, как взаимодействовать между собой, как измеряться, контролироваться и управляться, и так далее. Такой подход позволил бы не тратить время на доскональное изучение всех имеющихся сводов знаний, а время на такое изучение можно потратить значительное – одна лишь библиотека ITIL состоит из пяти книг, каждая по 250-400 страниц английского текста.
Такой подход позволил бы сэкономить немалые денежные средства на найм консультантов, которые не разрабатывали бы многостраничные документы, планы, регламенты, процедуры, рабочие инструкции и проч., и проч.
Такой подход позволил бы избежать сложностей с выбором и конфигурированием системы автоматизации ИТ-деятельности, ведь многие ITSM-системы были бы уже настроены на правильные процессы. Наконец, такой подход позволил бы внедрить все процессы максимально быстро, упростив освоение ИТ-сотрудниками новых практик работы – вот же книжка, одна-единственная, в ней всё написано, бери и делай!
(Справедливости ради следует отметить, что в поисках «серебряной пули» замечены не только ИТ-руководители, но и ИТ-консультанты, уже по своим соображениям пытающиеся найти универсальный сборник рецептов и убедить клиентов работать именно по нему.)
Известные мне инициативы подобного рода заканчивались весьма плачевно. Да, получить осязаемые результаты «внедрения» в виде набора документов, изданных приказов и распоряжений, установленной и «включённой» системы автоматизации удавалось многим. А вот изменить практику работы ИТ-отдела, сделать его более эффективным, повысить качество предоставляемых ИТ-услуг – к сожалению, нет.
Таким образом, в среде тех, кто уже попробовал применять принципы ITSM на практике, сложилось мнение, что универсальных и готовых решений не существует, и каждая организация должна искать свой путь, вбирая всё лучшее (или хотя бы всё подходящее) из множества источников знаний, выстраивая свой собственный проект трансформации ИТ и набивая собственные шишки. А над теми, кто всё ещё смеет утверждать, что процессы управления ИТ можно организовать в любой компании совершенно одинаковым образом, да ещё за весьма короткий срок, принято снисходительно посмеиваться: пороху, дескать, не нюхали, оттого и смелые такие. Либо же это разговоры представителя какого-либо вендора программного обеспечения, в их среде пообещать внедрить десяток процессов за три месяца – обычное дело. Запускаешь setup.exe, и вуаля! Понятно, что такие утверждения даже и обсуждать не стоит.
Так было, пока голландцы не изобрели колесо заново.
Встречайте, The ISM Method
ISM – это сокращение от Integrated Service Management, интегрированного управления услугами. Метод же авторы определяют как систематическую технику, состоящую из способа размышлений, способа моделирования, способа работы, способа управления и способа поддержки. Во вводимом авторами понятийном аппарате термин «метод» явно и чётко отличается от терминов «модель» и «практика»: модель – это схематичное и часто упрощённое отображение или видение реальности, а практика – способ работы, используемый для выполнения определённой задачи. Следует отметить, что определению терминов авторы The ISM Method уделяют самое пристальное внимание, подходя к этому вопросу намного тщательнее, чем принято в настоящее время в отрасли. Например, зачастую помимо определения какого-либо понятия даётся объяснение, почему это определение именно таково и почему определения этого же термина в других сводах знаний никуда не годятся.
Авторами The ISM Method являются Ян ван Бон и Вим Ховинг. Первый из них хорошо знаком всем профессионалам ITSM, интересующимся международной жизнью. Ян занимается управлением ИТ с 1989 года, а с начала 90-х годов является активным участником ITSM-сообщества. Он выступил одним из создателей и руководителей itSMF Нидерландов, отвечал за преобразование этого форума в профессиональную организацию. Создал и руководил глобальным комитетом по публикациям в itSMF International, организовал десятки семинаров, конференций и других мероприятий. В 1996 году основал собственную компанию Inform-IT, которая в последующие годы с помощью международной команды из тысяч авторов и рецензентов издала более 80 книг на 16 языках. Также с 1996 года Ян является бессменным редактором международного ITSM Portal, ведущего источника знаний отрасли. Ян впервые посетил Россию в 2013 году, выступив ключевым спикером на IT Management Forum. Читатели могут ознакомиться с интересным интервью Яна ван Бона.
Вим Ховинг известен широкой публике несколько меньше. С 1986 он занят в информационных технологиях, при этом с 1990 – на руководящих позициях. В 1998 году совместно с Яном ван Боном основал компанию BHVB, с тех пор полностью посвящает себя развитию и внедрению управления ИТ-услугами. Накапливаемый опыт позволил ему разработать модель The ISM Framework, которая впоследствии и стала The ISM Method.
Собственно, история создания The ISM Method приведена на следующей иллюстрации:
Авторы утверждают, что модель ISM была ими разработана в 1996 году как рабочий инструмент для крупного заказчика – компании Unisource, совместного предприятия KPN Netherlands, Swiss Telecom и Telia. C 1998 по 2003 годы модель использовалась в качестве референтной для различных проектов внедрения ITIL, последним из которых был проект в Министерстве сельского хозяйства Нидерландов. Результаты этого проекта позволили преобразовать ISM из референтной модели в модель для внедрения (application framework). Дальнейшее развитие ISM случилось в 2007 году в виде дополнения всем необходимым, чтобы модель стала методом (согласно определению, данному выше). Результаты применения метода были обобщены, и с 2010 года The ISM Method приобрёл современный вид и состав и используется разными компаниями для организации управления ИТ-услугами.
В состав The ISM Method входит несколько компонентов.
Во-первых, это документы, описывающие процессы, а именно: процессная модель, подробные описания каждого процесса, процедуры, отчёты, описания ролей, схема взаимодействия процессов, глоссарий терминов и определений, матрицы определения приоритетов, шаблоны форм, шаблоны для разработки SLA, заготовки для выполнения анализа рисков и так далее.
Во-вторых, установленная и настроенная современная BPM-система (либо донастроенная BPM-система, уже имеющаяся в компании), содержащая полные и детальные описания всех процессов в виде интерактивного web-инструмента.
В-третьих, аналогичным образом применённая ITSM-система (новая или имеющаяся), сертифицированная компанией BHVB и поддерживающая работу описанных процессов наилучшим образом.
В-четвёртых, методика внедрения и применения всего этого в компании.
В-пятых, участие консультантов и аналитиков компании BHVB, либо её партнёра, в поэтапном изменении работы ИТ-подразделения.
Поэтапное изменение проводится по чётко определённому, стандартному графику проекта, основные этапы которого приведены на иллюстрации ниже:
На этапе подготовки разрабатываются обоснование проекта, фиксирующее цели, задачи и результаты, которых необходимо достичь, документ инициации проекта PID (Project Initiation Document) в соответствии с методологией PRINCE2, а также план проекта. Дополнительно к этому проводится так называемый ISM Scan – процедура оценки и документирования текущего состояния управления в ИТ-подразделении.
На этапе установки проводится обучение ключевых участников проекта, анализируются предоставляемые ИТ-услуги, особенности организации, затем принимаются ключевые решения в трёх основных областях: процессы, персонал, технологии. После этого компании передаются документы, описывающие The ISM Method, устанавливаются и настраиваются BPM-система и ITSM-система, публикуются описания процессов и процедур, проводится обучение сотрудников.
Начиная с этапа внедрения, ИТ-подразделение выполняет работу в новых системах и по новым процессам, под контролем и при участии консультантов, а для менеджеров процессов и других руководителей организуются коучинг-сессии. Основные задачи данного этапа – добиться полноценной работы новых процессов и закрепить изменение.
Примечательно, что этап по сути состоит из нескольких циклов PDCA (Plan, Do, Check, Act), двух или трёх, в зависимости от организации. Непосредственно при переходе от этапа установки к этапу внедрения создаётся первый отчёт, фиксирующий состояние ИТ-управления на данный момент и определяющий цели на ближайшие три месяца. Цели назначаются по тем же трём основным областям: процессы, персонал, технологии. Определяются шаги и мероприятия по достижению поставленных целей. Консультанты помогают ИТ-сотрудникам выполнять сформулированные задачи, а через три месяца проводится оценка достижений, при которой выбираются цели на следующий период аналогичной длительности. Таким образом, этап внедрения занимает либо шесть, либо девять месяцев. Этап завершается повторной процедурой оценки и документирования состояния, ISM Scan, что позволяет выявить изменения и подготовить план дальнейших улучшений.
Этап использования означает отказ от постоянного и плотного участия консультантов, так как к этому моменту сотрудники уже могут самостоятельно исполнять ИТ-процессы и управлять ими. Декларируется поддержка клиентской организации в случае необходимости, а также включение её в ISM-сообщество для постоянного обмена знаниями.
Консультанты и ИТ-руководители, принимавшие участие в ITSM-проектах, скорее всего, согласятся, что приведённое выше описание стандартного проекта применения The ISM Method не выглядит откровением. Схожие этапы и действия выполняются и в обычных ITSM-проектах – разве что обязательное применение BPM-системы, да два ISM Scan’а являются интересными особенностями. За счёт чего же авторы The ISM Method предполагают добиваться существенно лучших результатов, чем в среднем по отрасли?
Почему оно должно взлететь
Первое, что следует отметить – далеко не все проекты, и даже не большинство, выполняются по схожей методике. Да, компания HP за последнее десятилетие намеренно или невольно сделала очень большую и значимую работу по просвещению ITSM-консультантов в России: выходцы из ITSM-департамента HP Россия, как правило, остаются в отрасли, занимая ведущие должности в различных компаниях, продолжая использовать передовые методики, схожие с The ISM Method, при выполнении своих работ. Но в общей массе проектов «внедрения ITIL» такой чёткий, структурированный и логичный подход встречается достаточно редко. Многие из тех компаний, что называют себя ITSM-консультантами, на самом деле работают по методикам, сделанным на коленке после опыта первых, зачастую не очень успешных проектов. ИТ-сотрудники, применяющие ITSM в своих компаниях, и вовсе лишены каких-либо методических материалов по внедрению и располагают лишь самими источниками знаний вроде ITIL и COBIT, а указанные источники содержат весьма скудную информацию про применение их самих в реальной жизни.
В традиционных проектах существенное время (недели и даже месяцы) тратится на разработку, документирование, обсуждение и согласование описаний процессов, политик, процедур. Участники таких проектов как со стороны консультанта, так и со стороны клиента не всегда хорошо обучены и не всегда разбираются в управлении ИТ – говоря откровенно, слабо подготовлены. В долгих дискуссиях и циклах согласования результат получается неоптимальный. Применяя же отлаженным способом хорошо проработанную модель, ИТ-подразделение может достичь большего за счёт концентрации не на процессной модели или описании конкретного процесса, а на особенностях выполнения данного процесса в своей организации. Процессы определены заранее, их перестраивать и долго обсуждать незачем.
Кстати, об определённых заранее процессах. Модель состоит из шести процессов, приведённых на иллюстрации ниже:
Каждый из них, включая управление качеством и управление конфигурациями, описан в виде составных частей (процедур), каждая процедура чётко документирована (как правило – до шагов порядка выполнения работ, workflow), каждый шаг каждой процедуры также определён. В модели приводится достаточно убедительное обоснование именно такого её вида и состава. Таким образом, процессная модель в The ISM Method – это не наброски отдельных размышлений про те или иные практики управления ИТ, а целостная, чёткая, детальная, непротиворечивая и обоснованная процессная модель. Степень её документирования высока.
Отсюда ещё один важный аспект, влияющий на успех всего мероприятия по внедрению The ISM Method – любая рабочая инструкция или практика, которую ИТ-организация желает «встроить» в применяемую схему работы, найдёт своё место в заданной архитектуре процессной модели. Придумывать модель уже не требуется, она готова. Необходимо найти то место в ней, в которое данная практика может быть помещена наилучшим образом.
Те, кто прослушал учебный курс «Основы ITIL», заметят, что процессная модель The ISM Method сильно упрощена. Где в ней, к примеру, известное всем управление проблемами? Управление релизами? Управление каталогом услуг? Где остальные двадцать с лишним процессов?! Действительно, авторы сознательно идут на упрощение, считая его важным слагаемым успеха в деле построения управления ИТ. Сложные процессные модели могут быть исключительно полными, но они никогда не работают на практике. Авторы оставляют задачу их изобретения научно-исследовательским институтам, безнадёжно оторванным от реальной жизни, но не ИТ-подразделениям, которым необходимо получить работающий инструмент.
Однако не следует считать, что если какого-то важного процесса нет в приведённой выше схеме, то связанная с ним деятельность выпадает из поля зрения. В частной беседе Ян ван Бон привёл мне следующий пример развлечения по-голландски: после проекта внедрения The ISM Method консультанты могут подойти к любому ИТ-сотруднику и спросить, что именно он делает в данный момент времени и в рамках какого именно процесса действует. Либо сотрудник обоснованно отнесёт своё занятие к одному из шести организованных в ИТ процессов, либо он заполняет заявление на отпуск без содержания.
Такое упрощение, поддержанное серьёзными размышлениями о самом необходимом, позволяет ИТ-сотрудникам легче понять и запомнить модель, а ИТ-руководителям – сконцентрироваться не на бесконечном объяснении процессов и их взаимодействии, а на трансформации ИТ-управления из состояния «как было» в состояние «как надо». Известно, что во многих случаях, особенно в крупных организациях, организационные изменения не проходят легко и просто, поэтому ценный ресурс – время ИТ-руководителя – следует направлять не на обучение ИТ-персонала новым терминам и фокусам, а на проведение и закрепление организационного преобразования.
Важным является и ещё одно отличие, декларируемое авторами: довольно часто внедрение, скажем, ITIL, начинается с одного процесса. Чаще всего – что-то связанное с поддержкой пользователей: управление инцидентами и Service Desk. Разработать и запустить такой процесс совсем не сложно, и после первого положительного опыта ИТ-руководитель задумывается о продолжении. Какой процесс выстраивать следующим? Почему именно его? Как он будет взаимодействовать с ранее разработанным процессом, не нарушит ли его деятельность, не придётся ли перепроектировать то, что уже вроде бы успешно работает? Такой подход встречается сплошь и рядом. Некоторые профессиональные организации, такие как itSMF, даже проводят отраслевые исследования, в которых задают респондентам вопрос об оптимальной, на их взгляд, последовательности внедрения процессов управления ИТ. Разумеется, можно и так делать, однако почему-то найти ИТ-подразделение, где организовано более трёх-четырёх реально работающих процессов, очень сложно. Стандарт управления ИТ-услугами ISO/IEC 20000 чётко определяет, что начинать нужно с построения системы управления. Такой же подход «сверху вниз» используют и авторы The ISM Method: они идут не от отдельных советов и рекомендаций ITIL к целостной картинке, а от заданной, уже разработанной системы управления к детализации отдельных процессов и процедур. Из этого есть два важных следствия.
Во-первых, понимание картины целиком и одновременная организация всех шести процессов повышают вероятность того, что в ИТ-подразделении заработает что-то помимо управления инцидентами. Во-вторых, по большому счёту становятся не такими важными практики, используемые «внизу»: можно найти хорошие рекомендации в ITIL, можно – в COBIT, можно – в MOF… Как говорится, соль и перец добавить по вкусу.
В заключение рассмотрения «доказательной базы», приводимой авторами в защиту преимуществ The ISM Method, следует отметить и стандартизацию. Декларируется, что раз цели данного ИТ-отдела такие же, как и любого другого ИТ-отдела, то и исполняемые процессы должны быть одинаковыми. То есть все, кто применяют The ISM Method, делают это одинаково. Тогда исчезает зависимость от конкретного консультанта, зато появляется возможность общения с товарищами в других компаниях, также применяющих The ISM Method. Авторы упоминают уже работающее ISM-сообщество в Голландии. Возможно, раз метод настолько стандартизован, то его адепты могут получать новые версии нормативных и организационных документов по мере их разработки.
Стоит ли верить большим обещаниям?
Как это часто бывает с громкими заявлениями, претендующими на роль той самой «серебряной пули», скепсис по отношению к The ISM Method, конечно же, присутствует, несмотря на достаточно убедительные аргументы авторов в поддержку утверждения «ITIL не работает, а The ISM Method – ещё как».
Из текста предыдущего раздела данной статьи может сложиться впечатление, что я каким-либо образом заинтересован «продать» The ISM Method как лекарство от головной боли ИТ-руководителя или ИТ-консультанта. Следует подчеркнуть, что на момент написания этой статьи я не веду проектов или учебных курсов по ISM, не оказываю каких-либо иных услуг, связанных с ISM. Я ни разу не пробовал применять ISM и не знаю о фактических результатах каких-либо применений – я ориентируюсь только на то, что мне известно от авторов метода. Необходимо отметить, что The ISM Method – закрытый коммерческий продукт, и просто так (в отличие от ITIL, COBIT, MOF, ISO/IEC 20000 и так далее) получить его невозможно.
И вот что я могу сказать: если бы я узнал о подобном методе, разработанном, скажем, малоизвестной компанией или экспертом с не очень большой практикой, я, наверное, и внимания на метод не обратил бы – мало ли на рынке громких заявлений? Но Ян ван Бон обладает достаточно большим авторитетом в моих глазах, чтобы я задумался: этот парень глупостей раньше не говорил, на моей памяти никогда никому ничего «не впаривал», имеет колоссальный опыт общения с лучшими из лучших, сформировал свои чёткие и обоснованные убеждения и готов отстаивать их перед самыми именитыми экспертами отрасли. Похоже, что именно это и привело к изучению мной The ISM Method, а затем – к написанию данной статьи.
Получается, что однозначного ответа на вопрос «верить или нет» на данный момент у меня нет. Но я точно буду наблюдать за новостями про The ISM Method, за примерами применения, за отзывами и мнениями на ITSM-рынке.
