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

Статьи 10 ноября 2022 Как мы на Яндекс Почту мигрировали: кейс ALP ITSM
ALP ITSM обеспечивает IT-поддержку компаниям разного масштаба — от небольших офисов с 20 сотрудниками до международных фастфуд-гигантов. Мы помогаем нашим клиентам находить выгодные IT-решения, подбираем и устанавливаем оптимальные сервисы. Но недавно мы сами оказались в ситуации, когда нужно было отказываться от привычных решений и искать новые варианты. Рассказываем, как наша компания численностью 120 сотрудников переходила на отечественный почтовый продукт и что из этого вышло.
Статьи 5 сентября 2022 Импортозамещение и локализация ИТ-инфраструктуры. Что общего? И в чем отличия?
В чем разница между импортозамещением и локализацией ИТ? Для каких компаний подходят эти две стратегии? Значит ли их реализация, что от иностранного софта и оборудования нужно будет отказаться полностью? Разобраться в теме помог Сергей Идиятов, руководитель направления консалтинга ALP ITSM.
Статьи 22 августа 2022 Топ-5 рекомендаций для CEO: как локализовать IT-инфраструктуру?
Для компаний с центральным офисом в зарубежных странах санкционный кризис стал серьезным испытанием. При сохранении бизнеса в России нужно выделить IT-инфраструктуру локального офиса и сделать ее независимой и автономной от глобальной компании, объявившей об уходе из РФ. Этот «развод по-итальянски» требует четкого плана, ресурсов и крепких нервов. Как минимизировать риски, рассказывает Сергей Идиятов, руководитель направления консалтинга ALP ITSM, сервисной IT-компании холдинга ALP Group.

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

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

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


Читайте далее: Неподходящий “размер” ИТ-процессов или их отсутствие — большой риск для СМБ. Как его предотвратить?


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

Прежде всего давайте определимся, что такое «зрелый процесс» и что мы имеем в виду под словом «практика» в данной статье. Для этого возьмем модель зрелости процессов (например, модель зрелости 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 сотрудников, либо они все территориально распределены. Чем их больше и чем труднее им взаимодействовать, тем меньше вероятность, что в их работе не будет различий, и тем меньше шансов стабильно получать ожидаемый результат.
  • Уходят ключевые специалисты, особенно, если они были «ходячими базами знаний». По сути именно на них и держатся практики.
  • Сам вид деятельности предполагает высокую текучку кадров. Здесь встаёт вопрос эффективности обучения сотрудников. Актуальная документация снижает трудозатраты на него и упрощает вхождение в курс дела. А своевременный контроль позволяет заблаговременно исправлять ошибки, не доводя до неприятных последствий.
  • Деятельность становится всё более разнообразной: растёт число обслуживаемых клиентов, оказываемых услуг, а с ними и количество критичных деталей. Чем больше вариативность, тем меньше вероятность отсутствия существенных различий в работе сотрудников и тем меньше шансов стабильно получать ожидаемый результат.

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

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


PCWeek

Свежие новости и статьи

Статьи 5 сентября 2022 Импортозамещение и локализация ИТ-инфраструктуры. Что общего? И в чем отличия?
В чем разница между импортозамещением и локализацией ИТ? Для каких компаний подходят эти две стратегии? Значит ли их реализация, что от иностранного софта и оборудования нужно будет отказаться полностью? Разобраться в теме помог Сергей Идиятов, руководитель направления консалтинга ALP ITSM.
Статьи 22 августа 2022 Топ-5 рекомендаций для CEO: как локализовать IT-инфраструктуру?
Для компаний с центральным офисом в зарубежных странах санкционный кризис стал серьезным испытанием. При сохранении бизнеса в России нужно выделить IT-инфраструктуру локального офиса и сделать ее независимой и автономной от глобальной компании, объявившей об уходе из РФ. Этот «развод по-итальянски» требует четкого плана, ресурсов и крепких нервов. Как минимизировать риски, рассказывает Сергей Идиятов, руководитель направления консалтинга ALP ITSM, сервисной IT-компании холдинга ALP Group.
Статьи 11 мая 2022 Не можно, а нужно: рассказываем, как безболезненно перенести IT-инфраструктуру компании в российское облако. Кейс ALP ITSM
За последние два месяца российские компании столкнулись с различными сложностями, в том числе по части IT. Среди них — остановка продажи нового ПО, невозможность оплаты услуг западных сервисов, повышение цен на оборудование и всевозможные блокировки. ALP ITSM помогает клиентам найти решения, чтобы обезопасить IT-инфраструктуру в нынешних условиях. Делимся опытом миграции из зарубежных облаков в российские.
Статьи 1 апреля 2022 Автоматизируй это! Четыре бизнес-процесса, где нельзя обойтись без Service Desk. Когда компания растет, увеличивается и количество запросов от пользователей. Однажды это превращается в «снежный ком»: техподдержка не справляется с потоком, заявки теряются, время обработки обращений все дольше, пользователи недовольны. Знакомая ситуация? Тогда нужно срочно внедрять ServiceDesk. Разбираемся, чем может помочь эта система, и какие направления стоит автоматизировать в первую очередь.