Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

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

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

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

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

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

  • Dmitri Kudryavtsev

    Проблема есть. Красивого решения не нашел. Сейчас изучаю все, что могу найти по теме управления аутсорсингом, т.к. проблема именно с ним.

  • Vladimir Lyaleko

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

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

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

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

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

      • Vladimir Lyaleko

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

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

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

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

  • Grigory Kornilov

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

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

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

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

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

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

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

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


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

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT