Управление черными ящиками

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

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

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

Но в то же время такой подход запросто может привести к тому, что практики управления и контроля разных команд разойдутся настолько, что целостность процесса окажется под угрозой. Вот лишь несколько примеров возможных в такой ситуации неприятностей:

  • Процедуры внутри команды требуют от системы автоматизации функциональности, не востребованной общим процессом. Не получая этой функциональности в общей системе, группа начинает использовать свои внутренние инструменты для регистрации и контроля работ;
  • Отчетность о работе группы, полученная в процессе, и собственная отчетность группы могут давать разную информацию, что становится поводом для конфликтов;
  • Несмотря на формальное следование общему процессу, сотрудники и руководители группы ориентируются в своей работе на собственные процедуры и правила, в команде формируется и развивается подход "мы и они", противопоставляющий группу и других участников процесса во главе с его менеджером. 

Насколько актуальна описанная ситуация, приходилось ли вам управлять процессом в подобных условиях? Есть ли проблема, или описанные трудности искусственны и на самом деле никому не мешают? Если такая проблема есть, приходилось ли вам встречать красивые решения для нее?

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

Узнайте больше!

Комментарии и мнения

  1. Vladimir Lyaleko

    В нашей компании, мы выступаем черным ящиком как для некоторых наших заказчиков, так и наши подрядчики выступают чёрным ящиком для нас.

    Указанные в первом и втором буллите неприятности действительно случались. Приходилось разрабатывать механизмы интеграции систем автоматизации ITSM процессов и внедрять гибкую систему корпоративной отчетности.

    Третий буллит тоже всегда присутствует, только негативных последствий подхода «мы и они» я не заметил. Если есть соглашения между «ими и нами», если входы и выходы нашей деятельности соответствуют ожиданием, то в подобном разделении не вижу ничего плохого. И даже не представляю как может быть иначе, когда черный ящик есть, а разделения нет... получается это не такой уж и чёрный ящик 🙂

    1. Роман Журавлёв Автор

      Если черные ящики существуют в рамках единого процесса, имеющего целью причинение какой-то пользы заказчикам, культура «мы и они» может вести к тому, что цели общего процесса будут вторичны для живущих в ящиках людей, и они будут ориентироваться не на общий результат процесса, а на свои локальные задачи. Когда это так в отношениях между разными службами компании, а тем более между компаниями, в этом нет большой беды. Но когда такая ситуация развивается в рамках одного департамента, это (1) затрудняет управление департаментом и (2) затрудняет достижение общих целей. Мне так кажется. Это по третьему пункту.

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

      1. Vladimir Lyaleko

        В моем примере речь идет именно о разных компаниях(в основном) и о разных службах в рамках одной компании, например о ЦОВ и департаменте продаж, которые работают с CRM решением. Поэтому конечно в этих компаниях \ службах свои ITSM или любые другие практики, свои средства автоматизации и так далее. Не сразу понял, что в топике речь идет именно про разные команды одного департамента сорри.

        Однако в рамках одного департамента возможна похожая ситуация. Вспоминается случай несколько лет назад, когда мы пришли в отдел разработки банка и попытались «обратить их» в ITSM. Последствия были печальны 🙂 У коллег давно устоявшиеся стандарты работы и своя горячо любимая jira. Не хочется говорить как они эксплуатацию называли, «мы и они» это самый мягкий вариант.

        В итоге был разработан протокол взаимодействия с разработкой, включающий в себя интеграцию систем. Любые попытки этот черный ящик сделать «прозрачным» приводили к негативным последствиям.

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

  2. Grigory Kornilov

    1. •Отчетность о работе группы, полученная в процессе, и собственная отчетность группы могут давать разную информацию, что становится поводом для конфликтов;

    Предлагаю посчитать black-box как внутреннего сервис провайдера с OLA. А раз есть OLA, то на основе KPI по OLA и строиться отчетность, только ее надо ведь было согласовать.

    И уже не важно, что за отчеты используются владельцем black-box перед кем-то еще.

    Конфликт возникает, когда black-box не соблюдает один этот OLA, но реализует value для руководства в чем-то другом. И это вопрос распределения ресурсов и пересмотр\пересогласование и тп OLA.

    2. Минус black-box обычно в том, что трубно оценить\обсудить вопросы изменений\модернизаций. Они делают так и только так, причины этого скрыты от внешнего анализа.

    1. Роман Журавлёв Автор

      Про OLA все не так просто (www.realitsm.ru/2012/06/ola-la/).

      Главное «непросто» — в том, что, похоже, надо выбирать: или OLA (SLA с внутренним субподрядчиком), или сквозной процесс с единым центром управления. И если нужен сквозной процесс, то, похоже, надо не соглашения согласовывать, а детализировать процедуры в сквозном процессе.

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
17
Учебный курс:
Основы DevOps 
ДЕК
20
ДЕК
20