РусEng
IT Аутсорсинг Новости Процессы vs Практики. А может всё и так хорошо?
Следить за новостями

Будьте в курсе IT событий

Подпишитесь на новости прямо сейчас

Процессы vs Практики. А может всё и так хорошо?

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

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

Всё это справедливо и для управления информационными технологиями (ИТ), однако здесь речь идет об ИТ-процессах, охватывающих различные аспекты управления и развития корпоративной ИС. Но вот вопрос: нужно ли беспокоиться и срочно строить формализованные ИТ-процессы, если в компании их нет? Или можно работать на уровне вышеупомянутых островков организованности (практик), экономя при этом время и деньги, не прибегая к услугам дорогостоящих консультантов и направляя активность своих сотрудников на более важные дела?

Что такое хорошо и что такое плохо?

Прежде всего давайте определимся, что такое «зрелый процесс» и что мы имеем в виду под словом «практика» в данной статье. Для этого возьмем модель зрелости процессов (например, модель зрелости ITIL, так как мы говорим об ИТ-процессах) и посмотрим на описание уровней зрелости. Можно использовать любую другую хорошо зарекомендовавшую себя модель зрелости процессов (COBIT, CMMI, ISO/ IEC 15504, BPMM и т.д.), если Вы с ней лучше знакомы. Детали описания будут немного отличаться, но существенные моменты всей цепочки рассуждений не изменятся.

Итак, модель ITIL выделяет шесть уровней зрелости:

В дальнейшем процессами мы будем называть уровни зрелости от 3 до 5, а практиками — уровни зрелости от 0 до 2 согласно модели зрелости процессов. При этом для уровней 0 и 1 вероятность получения нужного результата очень мала, поэтому можно говорить о «предпрактиках».

Обратите внимание, что для практик характерна слабая предсказуемость результатов. Это обусловлено целым рядом факторов.

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

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

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

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

Как определить достаточно ли компании практик?

Давайте проведем небольшое тестирование. Возьмем ITIL-процесс «Управление изменениями» (Change Management), целью которого является обеспечение оперативного выполнения ИТ-изменений при минимальных негативных последствиях (сбои, простои, потеря данных и т.д.)

В качестве примера сосредоточимся на выполнении в рамках этого процесса т. н. значительных изменений (Significant Changes). Такие изменения надо либо выполнять хорошо, либо не выполнять вообще. Ведь вряд ли кто-то захочет ощутить на собственном опыте печальные последствия неудачного обновления, например, прошивки основного маршрутизатора (corerouter) — с «шашкой наголо» и без создания резервной копии. Итог этого — простой на несколько часов всей компании из-за недоступности Интернета (электронной почты, онлайн-банкинга, облачной телефонии и пр.) сулит действительно большие неприятности и незадачливому администратору, и всей организации.

Чтобы не попасть в такую ситуацию, надо:

  1. Продумать и подготовить план выполнения изменения.
  2. Продумать и подготовить план возврата к исходному состоянию.
  3. Согласовать оба плана со всеми заинтересованными сторонами (например, владельцами затрагиваемых изменением систем, руководителями подразделений, техническим директором и т.д.).
  4. Уведомить о проведении изменения всех пользователей, которых оно затронет.
  5. По результатам изменения проверить работоспособность системы и актуализировать документацию.

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

Если в обоих случаях Вы уверенно отвечаете «Да», то выполнение данной деятельности (в нашем случае это изменения в ИТ) на уровне практик вполне допустимо. Подобным же образом проанализируйте остальные области ИТ (управление инцидентами, проблемами, заявками и т. д.). И не забудьте периодически возвращаться к этому тесту. Это позволит не упустить переломный момент и понимать, насколько ситуация изменилась.

Когда начинать беспокоиться?

Обычно работа на уровне практик начинает давать сбои, если выполнено любое из следующих условий:

В таких случаях велик соблазн сказать: «Чтобы свести на нет данные риски необходимо внедрить процессы». Однако, обычно, такие начинания заканчиваются созданием нежизнеспособной формализации процессов, которая остаётся только на бумаге. И это происходит не из-за отсутствия компетенций или опыта. А потому что формализация («внедрение») процессов — не конец, а только начало настоящего внедрения процессного подхода в практику работы организации. Это как выполнять зарядку или ходить к стоматологу — не так сложно заставить себя сделать это один-два раза, но весь смысл как раз в регулярности.

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

Источник: PC Week/RE

Дата публикации: 22 июня 2016

Яндекс.Метрика

Закрыть