Слово «бизнес-процесс» давно и прочно вошло в обиход любого управленца, однако каждый понимает его по-своему. В некоторых организациях под этим термином подразумевают сложные формализованные алгоритмы, подробно описывающие, когда и что нужно делать, какие решения принимать и как все это контролировать для своевременного достижения поставленных целей.
Но гораздо чаще под термином «бизнес-процесс» скрывается повседневная деятельность сотрудников, выполняющих работу в привычном для себя русле, без оглядки на какие-либо регламенты и инструкции. А между этими крайностями лежит самая распространённая ситуация «Как-то так…». В этой ситуации актуального целостного описания всей последовательности работ и единого подхода к их организации нет, но существуют его фрагменты, порой многочисленные и хорошо проработанные. И мало кто знает, как, что и когда делать за пределами этих островков организованности.
Всё это справедливо и для управления информационными технологиями (ИТ), однако здесь речь идет об ИТ-процессах, охватывающих различные аспекты управления и развития корпоративной ИС. Но вот вопрос: нужно ли беспокоиться и срочно строить формализованные ИТ-процессы, если в компании их нет? Или можно работать на уровне вышеупомянутых островков организованности (практик), экономя при этом время и деньги, не прибегая к услугам дорогостоящих консультантов и направляя активность своих сотрудников на более важные дела?
Читайте далее: Неподходящий “размер” ИТ-процессов или их отсутствие — большой риск для СМБ. Как его предотвратить?
Что такое хорошо и что такое плохо?
Прежде всего давайте определимся, что такое «зрелый процесс» и что мы имеем в виду под словом «практика» в данной статье. Для этого возьмем модель зрелости процессов (например, модель зрелости ITIL, так как мы говорим об ИТ-процессах) и посмотрим на описание уровней зрелости. Можно использовать любую другую хорошо зарекомендовавшую себя модель зрелости процессов (COBIT, CMMI, ISO/ IEC 15504, BPMM и т.д.), если Вы с ней лучше знакомы. Детали описания будут немного отличаться, но существенные моменты всей цепочки рассуждений не изменятся.
Итак, модель ITIL выделяет шесть уровней зрелости:
- Уровень 0 – деятельность отсутствует или полностью хаотична. Результаты деятельности непредсказуемы.
- Уровень 1 – начальная стадия: нет единого подхода к выполнению работы. Каждый исполнитель решает самостоятельно, как именно ее выполнять. Деятельность не измеряется. А результаты слабо предсказуемы.
- Уровень 2 – повторяемая деятельность: определены цели и задачи, есть частичная документация, некоторая автоматизация и измерение. Вырабатывается общий подход к работе, но он всё ещё заметно отличается от сотрудника к сотруднику. Результаты деятельности в определенной степени можно предсказать.
- Уровень 3 – формализованная деятельность: различия подхода к работе от сотрудника к сотруднику минимальны, документация актуальна, деятельность регулярно измеряется и анализируется, выполняются попытки работать на упреждение. Результаты обычно предсказуемы.
- Уровень 4 – управляемая деятельность: деятельность выполняется в соответствии с планом, документация актуальна и защищена от неавторизованного изменения, акцент делается на упреждение (планирование ресурсов, обучение сотрудников, управление рисками и т.д.). Результаты практически всегда предсказуемы, ошибки и исключения редки.
- Уровень 5 – постоянно улучшаемая деятельность четвертого уровня. Работы не просто стабильно и точно выполняются, происходит регулярный анализ и оптимизация производительности и рациональности деятельности.
В дальнейшем процессами мы будем называть уровни зрелости от 3 до 5, а практиками — уровни зрелости от 0 до 2 согласно модели зрелости процессов. При этом для уровней 0 и 1 вероятность получения нужного результата очень мала, поэтому можно говорить о «предпрактиках».
Обратите внимание, что для практик характерна слабая предсказуемость результатов. Это обусловлено целым рядом факторов.
Во-первых, все люди разные, у каждого свой профессиональный опыт, наработанные приёмы и «фишки». И по умолчанию каждый сотрудник будет работать так, как он привык.
Во-вторых, описывающая единый прозрачный подход документация либо полностью или частично отсутствует, либо не актуальна или находится неизвестно где. В итоге нет удобного и надежного инструмента для распространения информации «Как правильно?».
В-третьих, контроль ошибок не производится, либо его результаты не фиксируются. Достигнутые договоренности остаются на словах или в электронной почте и при обучении нового сотрудника оказываются забытыми. Итог: новые и имеющиеся сотрудники раз за разом наступают на одни и те же грабли.
Таким образом вся организационная составляющая ложится на плечи непосредственных исполнителей. Кажется, что это беда. Но нет, это не всегда плохо.
Как определить достаточно ли компании практик?
Давайте проведем небольшое тестирование. Возьмем ITIL-процесс «Управление изменениями» (Change Management), целью которого является обеспечение оперативного выполнения ИТ-изменений при минимальных негативных последствиях (сбои, простои, потеря данных и т.д.)
В качестве примера сосредоточимся на выполнении в рамках этого процесса т. н. значительных изменений (Significant Changes). Такие изменения надо либо выполнять хорошо, либо не выполнять вообще. Ведь вряд ли кто-то захочет ощутить на собственном опыте печальные последствия неудачного обновления, например, прошивки основного маршрутизатора (corerouter) — с «шашкой наголо» и без создания резервной копии. Итог этого — простой на несколько часов всей компании из-за недоступности Интернета (электронной почты, онлайн-банкинга, облачной телефонии и пр.) сулит действительно большие неприятности и незадачливому администратору, и всей организации.
Чтобы не попасть в такую ситуацию, надо:
- Продумать и подготовить план выполнения изменения.
- Продумать и подготовить план возврата к исходному состоянию.
- Согласовать оба плана со всеми заинтересованными сторонами (например, владельцами затрагиваемых изменением систем, руководителями подразделений, техническим директором и т.д.).
- Уведомить о проведении изменения всех пользователей, которых оно затронет.
- По результатам изменения проверить работоспособность системы и актуализировать документацию.
Глядя на этот план, задайте себе два контрольных вопроса для самопроверки. Первый: «Каждый мой сотрудник, участвующий в выполнении изменения, точно знает, что нужно делать, и практически всегда всё делает правильно?» Второй: «Риски невелики и уменьшать их нецелесообразно?»
Если в обоих случаях Вы уверенно отвечаете «Да», то выполнение данной деятельности (в нашем случае это изменения в ИТ) на уровне практик вполне допустимо. Подобным же образом проанализируйте остальные области ИТ (управление инцидентами, проблемами, заявками и т. д.). И не забудьте периодически возвращаться к этому тесту. Это позволит не упустить переломный момент и понимать, насколько ситуация изменилась.
Когда начинать беспокоиться?
Обычно работа на уровне практик начинает давать сбои, если выполнено любое из следующих условий:
- В одной деятельности занято более 10 сотрудников, либо они все территориально распределены. Чем их больше и чем труднее им взаимодействовать, тем меньше вероятность, что в их работе не будет различий, и тем меньше шансов стабильно получать ожидаемый результат.
- Уходят ключевые специалисты, особенно, если они были «ходячими базами знаний». По сути именно на них и держатся практики.
- Сам вид деятельности предполагает высокую текучку кадров. Здесь встаёт вопрос эффективности обучения сотрудников. Актуальная документация снижает трудозатраты на него и упрощает вхождение в курс дела. А своевременный контроль позволяет заблаговременно исправлять ошибки, не доводя до неприятных последствий.
- Деятельность становится всё более разнообразной: растёт число обслуживаемых клиентов, оказываемых услуг, а с ними и количество критичных деталей. Чем больше вариативность, тем меньше вероятность отсутствия существенных различий в работе сотрудников и тем меньше шансов стабильно получать ожидаемый результат.
В таких случаях велик соблазн сказать: «Чтобы свести на нет данные риски необходимо внедрить процессы». Однако, обычно, такие начинания заканчиваются созданием нежизнеспособной формализации процессов, которая остаётся только на бумаге. И это происходит не из-за отсутствия компетенций или опыта. А потому что формализация («внедрение») процессов — не конец, а только начало настоящего внедрения процессного подхода в практику работы организации. Это как выполнять зарядку или ходить к стоматологу — не так сложно заставить себя сделать это один-два раза, но весь смысл как раз в регулярности.
А вот о том, как упростить эту работу и что нужно для создания жизнеспособных процессов, давайте поговорим в следующий раз.
