НовостиСобытияКонференцииФорумыIT@Work
Идеи и практики автоматизации:

Блог

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

Дмитрий Толоконников
22.06.2016 12:02:39

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

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

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

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

Прежде всего давайте определимся, что такое «зрелый процесс» и что мы имеем в виду под словом «практика» в данной статье. Для этого возьмем модель зрелости процессов (например, модель зрелости 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) — с «шашкой наголо» и без создания резервной копии. Итог этого — простой на несколько часов всей компании из-за недоступности Интернета (электронной почты, онлайн-банкинга, облачной телефонии и пр.) сулит действительно большие неприятности и незадачливому администратору, и всей организации.

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

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

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

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

Обычно работа на уровне практик начинает давать сбои, если выполнено любое из следующих условий:
• В одной деятельности занято более 10 сотрудников, либо они все территориально распределены. Чем их больше и чем труднее им взаимодействовать, тем меньше вероятность, что в их работе не будет различий, и тем меньше шансов стабильно получать ожидаемый результат.
• Уходят ключевые специалисты, особенно, если они были «ходячими базами знаний». По сути именно на них и держатся практики.
• Сам вид деятельности предполагает высокую текучку кадров. Здесь встаёт вопрос эффективности обучения сотрудников. Актуальная документация снижает трудозатраты на него и упрощает вхождение в курс дела. А своевременный контроль позволяет заблаговременно исправлять ошибки, не доводя до неприятных последствий.
• Деятельность становится всё более разнообразной: растёт число обслуживаемых клиентов, оказываемых услуг, а с ними и количество критичных деталей. Чем больше вариативность, тем меньше вероятность отсутствия существенных различий в работе сотрудников и тем меньше шансов стабильно получать ожидаемый результат.

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

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

Комментариев: 4

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

Donat Lipkovsky
23.06.2016 11:19:37

Пока всё чётко и добавить нечего. Думаю коментарии появятся, как раз при продолжени темы, когда перейдём к конкретике.

24.06.2016 14:10:30

Donat, спасибо. В продолжении темы буду стараться сохранить чёткость.

28.06.2016 08:56:42

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

29.07.2016 12:56:21

Александр, спасибо за комментарий. Прошу прощения за долгий ответ.

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

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

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

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

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

А в руках руководителя, скажем так, не очень компетентного и не слишком верно оценивающего качество управления и успешность своей организации в условиях рынка, любая управленческая методика может превратиться в маразм. Это относится не только к процессам или другим уже существующим моделям управления, но и к той новой (гипотетической) модели, о необходимости которой Вы говорите в своем комментарии. Словом, заставь дурака Богу молиться, он и лоб расшибет.

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

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии