Как повысить ваши шансы на успех при внедрении процессов. Практические рекомендации

Существуют различные источники знаний о лучших практиках в области управления ИТ-услугами, которые содержат рекомендации и требования, применение и соответствие которым поможет обеспечить предоставление качественных ИТ‑услуг. Наиболее распространёнными и широко используемыми источниками являются библиотека ITIL, семейство публикаций COBIT и стандарты серии ISO 20000.

Несмотря на то, что многие процессы достаточно подробно описаны в нескольких источниках, проекты по их внедрению на практике не всегда приносят ожидаемые результаты, а время и ресурсы оказываются потрачены впустую. В чём же причина?

Во-первых, рекомендации лучших практик могут быть реализованы различным образом, и они обязательно должны быть адаптированы с учётом специфики конкретной организации, включая сферу деятельности, размер, территориальную распределённость, корпоративную культуру, стиль руководства и другие факторы. То есть одного только формального соответствия рекомендациям или требованиям какой-либо библиотеки или стандарта недостаточно.

Во-вторых, прохождение обучения и успешная сдачи сертификационных экзаменов не гарантируют, что вы сможете успешно внедрить процессы управления ИТ-услугами, поскольку знание рекомендаций и ключевых аспектов организации процессов ещё не означает умение применить их в контексте конкретной организации. Пробел в этом направлении призвана исправить одна из недавних публикаций AXELOS – ITIL Practitioner, которая, хотя и предлагает ряд практических инструментов, всё же не является исчерпывающей.

Конечно, внедрение каждого процесса имеет свои тонкости и нюансы, но можно выделить несколько общих рекомендаций, основанных на практическом опыте, следование которым позволит повысить шансы на успех при реализации проектов по внедрению процессов управления ИТ-услугами.

Рекомендация 1. Заручитесь поддержкой заинтересованных сторон

Внедрение или модификация процессов управления почти всегда требует изменения привычных подходов к работе, а также выполнения новых видов деятельности. Люди, как правило, негативно относятся к подобным изменениям, а новые виды деятельности воспринимаются как ненужная дополнительная работа, без которой прекрасно раньше обходились.

Это создаёт препятствия при проектировании и внедрении процесса. Чтобы преодолеть эти препятствия, необходимо провести анализ заинтересованных сторон и их приоритетов и показать всем стейкхолдерам преимущества и выгоды от внедрения процесса для всей организации и конкретно для каждого из них, а также объяснить, какова их роль на каждом из этапов внедрения процесса. При этом важно получить поддержку как высшего руководства, так и рядовых сотрудников.

Рекомендация 2. Не начинайте с нуля

При разработке процессов можно встретить две крайние точки зрения:

• «Лучшие практики для нас не применимы» – наша организация уникальна, и нам нужно разработать свои уникальные процессы с нуля.
• «Начнём все с чистого листа» – наши прежние подходы неэффективны, нужно внедрить «правильные» подходы, описанные в авторитетных источниках.

На самом деле, крайне редко какая-либо из этих точек зрения действительно является верной.

Если описание процесса из ITIL не подходит для вашей организации в чистом виде, это не значит, что нужно полностью отказаться от следования его рекомендациям. В действительности довольно трудно будет найти организацию, для которой рекомендации идеально подошли без необходимости адаптации. Тем не менее, часто гораздо быстрее и эффективнее адаптировать рекомендации лучших практик с учётом специфики вашей организации, чем разработать собственный процесс с нуля. Зачем изобретать колесо?

При этом у большинства ИТ-организаций уже есть сложившиеся процессы, они могут быть как задокументированы и управляемы, так и не формализованы. Имеющиеся практики и подходы, скорее всего, сформировались не случайно – обычно они учитывают особенности вашей организации. Поэтому при внедрении/модификации процессов важно понять, каковы положительные и отрицательные стороны применяемых подходов и какие из уже существующих практик можно использовать в новых процессах.

Рекомендация 3. Определите оптимальный целевой уровень зрелости

Несмотря на то, что уровень зрелости часто рассматривается как показатель эффективности организации процесса, самый высокий уровень зрелости необходим далеко не всегда, не всем и не для всех процессов. Как известно, процессы направлены на повышение вероятности достижения определённой цели. И чем выше оценивается негативное влияние в случае недостижения цели, тем более высокий уровень зрелости процесса необходим для того, чтобы минимизировать риски недостижения цели процесса. При этом надо учитывать и другие факторы, такие как ресурсы, необходимые для обеспечения более высокого уровня зрелости, уровень зрелости смежных процессов и организации в целом и т. д. На графике (рис. 1) схематично показано, как увеличиваются затраты на обеспечение более высокого уровня зрелости и как при этом снижаются риски процесса.

Рис. 1. Типовая зависимость уровня рисков и затрат от уровня зрелости процесса

При определении оптимального уровня зрелости важно учитывать как критичность процесса для бизнеса, так и ваши текущие возможности. Как правило, организации, которые добились высокого уровня зрелости своих процессов, делали это постепенно, шаг за шагом. Очень маловероятно, что вы сможете вывести зрелость своего процесса с первого уровня сразу на пятый или даже четвёртый. Скорее всего, это будут впустую потраченные время, ресурсы и нервы. И не факт, что вам это действительно нужно.

Рекомендация 4. Обеспечьте вовлечение людей, обладающих правом принимать решения

В процессную деятельность могут быть вовлечены сотрудники одного, нескольких, а иногда и всех подразделений организации. Таким образом, на этапе проектирования процесса необходимо учитывать интересы и мнения различных заинтересованных сторон, которые совпадают далеко не всегда. Часто не существует одного идеального варианта, который бы устроил всех, и приходится искать компромисс. Если на данном этапе решения по спорным вопросам не будут приняты на должном иерархическом уровне, впоследствии процесс придётся проектировать ещё раз.

Рекомендация 5. Обеспечьте механизм обратной связи

Вы можете спроектировать идеальный по вашему мнению процесс, но многие недостатки и возможности для совершенствования можно будет увидеть только после запуска процесса. При этом они не всегда заметны со стороны – для людей, не вовлечённых в определённую процессную деятельность, но очень хорошо видны исполнителям ролей в процессе. Поэтому очень важно наладить эффективный механизм обратной связи между участниками процесса и менеджером. Это будет способствовать идентификации возможностей для постоянного совершенствования процесса и позволит осуществлять более эффективное операционное и тактическое управление процессом.

Рекомендация 6. Продумайте процедуры внутреннего контроля

Как бы хорошо ни был спроектирован процесс с учётом самых передовых практик и особенностей организации, ценность этот процесс принесёт только в том случае, если он будет соответствующим образом выполняться участниками процесса. Чтобы этого добиться, при проектировании процесса необходимо предусмотреть процедуры внутреннего контроля, которые позволят менеджеру получить разумную степень гарантии надлежащего выполнения процесса. Чем более критичным является соблюдение порядка выполнения отдельных процедур процесса, тем более эффективными должны быть соответствующие процедуры внутреннего контроля При этом для некоторых видов деятельности могут применяться сразу несколько процедур внутреннего контроля. Важно обеспечить разумный баланс между основными и контрольными процедурами при проектировании процесса.

Рекомендация 7. Обеспечьте участников чёткими и понятными руководствами и инструкциями

При проектировании процесса рабочей группе может казаться очевидным, как именно должны выполняться те или иные процедуры процесса, и в результате они описываются с низкой степенью детализации. Однако участникам процесса, наоборот, часто необходимы достаточно подробные инструкции. Например, в процессной документации можно встретить описание примерно такого содержания: «жалоба пользователя регистрируется специалистом поддержки и назначается на владельца услуги». С одной стороны, всё понятно, а с другой – при выполнении этого вида деятельности у участников процесса может возникнуть ряд вопросов:

• По каким каналам может поступить жалоба от пользователя?
• Где диспетчер должен зарегистрировать жалобу и в какие сроки?
• Каким образом жалоба должна быть классифицирована и приоритизирована?
• Какая информация должна быть передана пользователю?
• Должен ли диспетчер предварительно запросить у пользователя дополнительную информацию?
• Как владелец услуги узнает, что поступила жалоба?
• В какой срок должна быть рассмотрена жалоба и реализованы меры реагирования?
• и т. д.

Очевидно, что если у участника процесса не будет чётких инструкций, он будет выполнять процедуры процесса таким образом, который кажется ему наиболее удобным, и, скорее всего, не так, как это задумывалось при проектировании процесса.

Подробные инструкции могут содержаться в различных процессных документах, при этом необязательно включать все детали в основной процессный документ – регламент или руководство по процессу. Частой практикой является создание иерархии документов, например:

• «Регламент процесса» – определяет цели, задачи, роли, процедуры, показатели процесса и т. д.
• «Порядок выполнения процесса» – детализирует порядок выполнения процедур процесса, описанных в регламенте.
• «Ролевые инструкции» – детализирует порядок выполнения процедур, в которые вовлечены отдельные роли в процессе.

При написании процессных документов важно помнить, для кого они предназначаются. Например, многие организации при разработке схем документов используют нотацию BPMN, которая имеет много плюсов, но впоследствии такие документы часто оказываются непонятны большинству участников процесса. Иногда использование простых блок-схем будет намного полезнее, чем использование специализированных нотаций.

Рекомендация 8. Проведите обучение сотрудников

Кажется очевидным, что, прежде чем начать работать в соответствии с разработанным процессом, нужно донести до людей, каким образом будет выполняться процесс и что требуется непосредственно от них. Но на практике этим пунктом часто пренебрегают. Важно помнить, что, помимо обучения непосредственно процессу, крайне желательно провести обучение, которое позволит участникам понять роль процесса для организации в целом, его место в системе управления, а также показать взаимосвязь отдельных видов деятельности с общей результативностью системы управления. Например, классификация инцидентов может восприниматься специалистом службы поддержки как рутинная и ненужная деятельность, и выполнять он её будет спустя рукава. Но если показать ему преимущества и ценность от этого для управления инцидентами и других связанных с ним процессов, он, скорее всего, подойдёт к этой задаче более ответственно.

Рекомендация 9. Выберите наиболее подходящий подход к автоматизации

Можно ли обойтись без автоматизации процесса? Можно, но это сложно.

Причём степень сложности сильно зависит от конкретного процесса и организации. Безусловно, процесс будет более эффективным, если деятельность будет полностью или частично автоматизирована. Можно выделить несколько основных подходов к автоматизации:

• использование подручных средств (Excel, SharePoint, Access и т. д.);
• разработка собственного средства автоматизации;
• использование бесплатно распространяемого ПО, которое чаще всего настраивается своими силами;
• использование специализированных ITSM-средств, настройка которых осуществляется обычно с помощью подрядчиков.

Выбор конкретного подхода в большинстве случаев требует анализа совокупности факторов, из которых основные – это (рис. 2):

• сроки;
• стоимость;
• функциональные возможности и возможности кастомизации.

Рис. 2. Три основных фактора выбора средства автоматизации

Как правило, решения, идеально отвечающего всем вашим запросам по этим трём факторам, не существует, и при выборе средства автоматизации приходится искать оптимальный баланс между ними. Важно также учитывать и дальнейшие перспективы развития системы управления, поскольку лучше сразу внедрить одно решение, которое будет использоваться ещё долгие годы, чем потратить ресурсы и время на внедрение решения, которого вскоре будет уже недостаточно.

***

Само собой, что приведённые выше рекомендации не являются новыми и исчерпывающими, они частично повторяют рекомендации книг ITIL и других источников. Однако, они действительно важны и, к сожалению, часто игнорируются в реальных проектах, поэтому мы постарались собрать их в одном месте и ещё раз напомнить всем об их значимости. Следование приведённым рекомендациям позволит повысить ваши шансы на успех при внедрении процессов управления ИТ.