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