Курсы по изучению ITIL, ITSM-сертификация, описание программных средств управления ИТ-процессами открывают возможность изучить эту предметную область, чтобы качественно внедрять процессы управления ИТ. Однако не менее важно уметь управлять проектами внедр
Рынок ITSM-решений в России пока молод. Первые российские проекты в этой области появились в конце девяностых годов. Пионеров ITSM было не более десятка — в основном крупные финансовые/банковские структуры и телекоммуникационные компании. Говорить о наличии тенденции внедрения ИТ-процессов на российских предприятиях можно только начиная с 2004—2005 года. К настоящему времени большинство компаний прошло путь по внедрению нескольких процессов управления ИТ: как правило, процесс управления инцидентами и процессы управления конфигурациями и изменениями. К сожалению, опыт внедрения обычно остается уделом компании-заказчика и интегратора, участвовавших в данном проекте.
Преодолеть дефицит информации о накопленном опыте помогли бы курсы по обучению управлению ITSM-проектами, а также наличие библиотеки с описанием кейсов российских проектов.
Урок первый: «Объять необъятное»
Перед началом проекта устанавливаются его рамки: сроки, бюджет и т.д., формулируются цели и задачи. По мере осуществления проекта у предприятия появляются новые потребности, меняются требования к внедряемому процессу, что вполне закономерно, так как клиент по мере развития проекта развивается сам, меняется его уровень зрелости. В такой ситуации возникает искушение включить в рамки существующего проекта новые задачи. Обычно это приводит к потере фокуса проекта, срыву сроков, превышению бюджетов и т.д. Поэтому целесообразнее оформить новые задачи в виде самостоятельных подпроектов, взаимоувязанных с основным ITSM-проектом компании. Последовательность реализации новых подпроектов может зависеть от многих факторов, таких как финансирование и наличие свободных людских ресурсов, необходимых для выполнения проекта. Таким образом, проект ITSM — это комплекс проектов, которые нуждаются в централизованном управлении и координации.
Урок второй: «Центр ответственности за результат»
В большинстве случаев компании подходят к внедрению процессов управления и мониторинга сети и ИТ-инфраструктуры как к внедрению аппаратно-программной подсистемы, а не как к процессу. В результате она становится инструментом ИТ-специалистов, и они используют (или не используют) ее по своему усмотрению. Поскольку нет процесса, то нет и ответственных за результат, не определены роли и функции, которые должны выполнять те или иные ИТ-специалисты.
Предположим, у вас внедрены процесс управления инцидентами на базе какой-либо программной системы класса Service Desk и система отчетности и анализа эффективности ИТ-деятельности, которая использует в качестве источника данных базу данных программного продукта Service Desk. В компании начат проект по повышению уровня зрелости процесса управления инцидентами, влекущий за собой изменения на уровне структуры базы данных, в которой хранится информация о ИТ-деятельности. Если осуществляемый проект рассматривать обособленно от системы отчетности, то при сдаче в промышленную эксплуатацию новой версии процесса управления инцидентами система отчетности будет неработоспособной, поскольку она, в свою очередь, также требует внесения изменений в логику запросов, на основании которых строятся отчеты.
Для решения проблемы в компании необходимы две новые роли, которые и образуют центр ответственности: куратор проектов (или менеджер по портфельному управлению ITSM-проектами) и системный архитектор. На куратора ложатся административные функции координации работ по проектам, а системный архитектор несет ответственность за технический результат всех проектов в области систем управления ИТ.
Урок третий: «Используйте по назначению»
Очень часто на программное обеспечение пытаются возложить непрофильные задачи. Например, в ходе проекта управления изменениями автоматизировать на инструментах класса Help Desk и Service Desk задачи документооборота, касающегося ИТ. Целесообразнее для автоматизации ИТ-документооборота (согласования и утверждения заявок на закупку, права доступа, организации системы согласования по каким-либо ИТ-проблемам или смежным вопросам и т.д.) использовать соответствующие специализированные системы документооборота, которые могут быть интегрированы в систему автоматизации ИТ-процессов.
Также типичной является ситуация, когда компании неоптимально используют средства автоматизации. Ни для кого не секрет, что одну и ту же задачу на одном и том же программном средстве можно автоматизировать разными способами. Рассмотрим пример автоматизации каталога услуг на функциональном продукте HP Service Desk, который представлен тремя логическими модулями: Help Desk, Change Management и Service Level Management (SLM). Каталог услуг можно автоматизировать как на модуле Help Desk, так и на SLM. Технически было бы правильно использовать модуль SLM, так как он предполагает соответствующие связи, операции и прочее, применимые именно к услугам. Но на практике очень часто используют модуль Help Desk, на базе которого автоматизируют каталог услуг в виде обычного классификатора. Основная причина такого технически неверного решения — стремление сэкономить на стоимости лицензии SLM. Но на деле такая экономия оборачивается для клиента издержками будущих периодов. Ведь через какое-то время компания подойдет к внедрению процесса управления уровнем услуг и ей все равно придется приобретать соответствующие лицензии. Только при этом уже появляются расходы по миграции каталога услуг с Help Desk на модуль SLM. Кроме того, необходимо учесть издержки, связанные с внесением изменений во все процессы (поскольку они связаны прямо или косвенно с каталогом услуг), которые будут автоматизированы в компании на момент внедрения процесса управления уровнем услуг.
Следствие неоптимального использования программных инструментов — неэффективная работа процессов (низкая производительность, длительное время открытия новых форм заявок, инцидентов и т.д.).
Выбор программного обеспечения — это отдельная важная задача, к которой следует подходить комплексно, учитывая все аспекты и элементы будущей системы управления ИТ компании. Выбирая программный продукт, необходимо как минимум определить принципиальную архитектуру строящейся системы управления (централизованная или территориально распределенная), ее масштаб (внедрение систем управления промышленного масштаба наиболее оправданно в организациях, где численность ИТ-службы составляет несколько десятков специалистов), процессы управления ИТ, планируемые к внедрению в ближайшей и отдаленной перспективе. При этом нужно понять, требуется ли программный продукт для автоматизации процессов управления ИТ или есть потребность в автоматизации смежных областей (например, документооборота, бухгалтерии, закупок).
Бытует мнение, что проектируемая логика процессов управления ИТ отчуждаема от программных средств, на которых она впоследствии будет автоматизирована. Это действительно так, однако есть аспекты, связанные с выбором программного обеспечения, которые могут оказать существенное влияние как на выполнение проекта по внедрению процесса, так и на работу самого процесса. Любое программное обеспечение не только дает дополнительные возможности, но и вводит ряд ограничений и рисков. Выбор гибких и легко кастомизируемых программных средств грозит затягиванием проекта из-за постоянных доработок и повышает риски автоматизации неэффективных процессов. Использование же готовых продуктов с предопределенной логикой вынуждает ИТ-службу во многом отказаться от своей специфики и перестроить процессы в соответствии с лучшими мировыми практиками, что, с одной
стороны, может повлечь организационные риски, но, с другой, снижает риск переделки программного продукта под существующие неэффективные процессы.
Итак, прежде чем выбрать ту или иную систему, нужно четко сформулировать свои ожидания. В одной компании, например, ITIL/ITSM стойко ассоциируется с определенным программным продуктом: после его приобретения была поставлена задача настроить купленную систему для автоматизации существующего процесса поддержки пользователей. Таким образом, внедрение лучшего мирового опыта подменили внедрением инструмента без достаточной проработки процессной части. При этом существующий процесс поддержки пользователей слабо формализован, неэффективен и, естественно, не укладывается в функционал системы, которая ориентирована на автоматизацию процессов, спроектированных в соответствии с рекомендациями ITIL/ITSM.
Практика показывает, что выбор программных средств до начала ITSM-проекта позволяет учитывать их особенности (возможности, ограничения) при проектировании процессов. По крайней мере необходимо иметь представление о возможностях и ограничениях имеющихся на рынке программных продуктов. Иначе разработанная проектная документация с описанием логики процессов рискует так и остаться нереализованной.
Отметим также, что ограниченность функциональных возможностей программного обеспечения приводит к необходимости автоматизировать процессы управления ИТ посредством нескольких инструментов. Например, в настоящее время нет программного продукта, который был бы в состоянии автоматизировать две группы процессов управления ИТ, обеспечивающих поддержку ИТ-услуг и их предоставление.
Вот пример, показывающий, что для решения проблем порой необходимо использовать широкий арсенал средств. В финансовой компании на первом этапе внедрялся процесс управления инцидентами вместе с каталогом услуг. Внедрение каталога услуг на первом этапе (как части процесса управления уровнем сервиса) существенно повышает отдачу от процесса управления инцидентами. В качестве средства автоматизации был выбран продукт HP Service Desk (все три функциональных модуля). Для наполнения базы данных о персонале компании были задействованы бизнес-приложения Microsoft и SAP. Для наполнения CMDB в части информации о программно-аппаратных элементах рабочих станций использовался продукт Microsoft SMS, который охватил в общей сложности более 4 тыс. рабочих станций. Для наполнения данными о программно-аппаратных элементах сетевого оборудования использовался продукт HP Network Node Manager Advanced Edition, на базе которого развернута система мониторинга сети. На втором этапе внедрялись процессы управления конфигурациями и изменениями. Рассматривать внедрение данных процессов порознь в принципе нецелесообразно, так как база данных конфигурационных единиц (Configuration Management Data Base, CMDB) без процесса управления изменениями сохраняет свою актуальность только в течение суток.
Поскольку процессы управления конфигурациями и изменениями взаимосвязаны, встал вопрос об интеграции вновь внедряемых процессов с процессом управления инцидентами, что, в конечном счете, вылилось в пересмотр существующего процесса управления инцидентами и каталога услуг и повышения их уровня зрелости. В качестве средств нотификации, используемых во всех трех процессах управления, была задействована почтовая система.
Для согласования и утверждения ИТ-заявок (это часть процесса управления изменениями), было решено использовать систему документооборота компании.
Так как к началу работ второго этапа процесс управления инцидентами был формализован и автоматизирован, появилась необходимость повысить его уровень зрелости, то есть перевести в состояние «измеряемый и улучшаемый». Поэтому был начат отдельный подпроект по разработке системы метрик и ключевых показателей эффективности (KPI), на базе которых оценивалась эффективность процесса, ИТ-услуг, оказываемых потребителям, а также работа ИТ-групп, поддерживающих процесс управления инцидентами. В качестве средства автоматизации системы оценки эффективности был выбран продукт Westbury Service Desk Intelligence.
Урок четвертый: «Время — деньги»
Одна из финансовых компаний осознала необходимость организовать службу поддержки в соответствии с рекомендациями ITIL. Начался проект, пригласили высококлассных западных консультантов. Провели обследование, спроектировали логику процесса управления инцидентами, сформировали критерии выбора системы автоматизации процесса… и на этом остановились. Прошло два года. ИТ-руководство решило довести проект до логического завершения. В соответствии со сформулированными ранее критериями выбрали систему автоматизации, в бюджете ИТ нашли деньги на ее покупку и настройку. Техническим консультантам поставили задачу реализовать в системе логику, разработанную два года тому назад. В ходе выполнения работ по физическому проектированию, на этапах тестирования и опытно-промышленной эксплуатации выявляется разрыв между логикой, разработанной ранее, и текущими требованиями к процессу. Жизнь не стоит на месте, и за два года компания претерпела серьезные изменения. В результате внедрен процесс, который спроектирован без учета специфических текущих требований предприятия.
Урок пятый: «Больше информации»
Не требует доказательства утверждение, что хорошие коммуникации — один из обязательных факторов успеха любого проекта. Однако зачастую руководство ITSM-проектов со стороны предприятия недооценивает важность информационных мероприятий. Участники проекта, будущие пользователи системы, порой пребывают в полном неведении о целях проекта, ожидаемых результатах и т.д. Если ситуацию не изменить, то результаты проекта в лучшем случае будут восприняты настороженно, в худшем — просто саботироваться, поскольку людям свойственно неприятие перемен.
Урок шестой: «Остаться партнерами»
ITSM-проекты похожи на марафон: продолжительность каждого этапа может составлять от четырех месяцев до года. У проектной команды за это время накапливается и физическая, и моральная усталость. Зачастую ухудшаются личные отношения между командой компании-заказчика и субподрядчика. Стороны не желают идти на уступки, руководствуясь только формальными (договорными) обязательствами. Но на практике ни один договор не может вместить в себя все то множество деталей, из которых состоит проект. Нежелание идти на компромисс, на взаимные уступки приводит к усложнению отношений, их разрыву после очередного этапа работ и смене подрядчика.
Для обеспечения преемственности результатов работ потребуется обследование ранее внедренных процессов управления, что в конечном счете обернется потерей времени и денег.
Главный урок
Безусловно, приведенными выше примерами проектный опыт не может быть представлен в полной мере. Самый главный урок, который мы можем получить, — это наш собственный опыт. Обмен накопленными знаниями и опытом — вот что позволит избежать ошибок и сделает путь к внедрению ITSM-решений более предсказуемым, управляемым и лишенным неприятных сюрпризов.
Алексей Белей — руководитель отдела систем управления Energy Consulting, Beley_A@energy-consulting.ru
Ольга Чернова — руководитель ITSM-проектов Energy Consulting, Chernova_O@energy-consulting.ru