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

Типовые процессы и типовые внедрения (извините, наболело)

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

Вот что я думаю обо всех этих "типовых" прелестях (приглашаю к дискуссии). Объясняю себе это на примере компании N, которой надо организовать у себя процесс управления ... ну скажем изменениями (т.е. надо сделать так, чтобы сотрудники этой компании "с понедельника" начали вносить изменения в те или иные системы, услуги, продукты и прочее не абы как, а руководствуясь опредёленными правилами). Далее перечислены варианты решения задачи в порядке удаления от конечного результата (то есть фактической организации работы).

1. Типовое внедрение
Предполагает не только типовую модель процесса (что это такое смотрим ниже), но и типовое решение задачи совмещения процесса с данной конкретной компанией, то есть с организационной и географической структурой, персоналиями и их уровнем компетенции, системой стимулирования (или как чаще говорят "мотивации"), корпоративными стандартами (например, в области управления качеством или внутреннего контроля) и так далее. По определению типовое внедрение возможно только в такой компании, которая всеми своими перечисленными особенностями похожа на другую компанию, где такой процесс уже внедрен, то есть выполняется тиражирование. Как правило, это реалистично только при внедрении в группе компаний, состоящих из набора типовых предприятий, обладающих стандартной структурой. Например, группа электростанций в составе ТГК. Стандартный процесс управления изменения уже спроектирован и утвержден (в виде корпоративного стандарта), теперь мы организуем его исполнение на конкретной электростанции. Если всё пойдёт хорошо (будем оптимистами!), то компания Ni, которая входит в группу компаний N по результатам типового внедрения действительно имеет шанс решить поставленную задачу — организовать деятельность по управлению изменениями в соответствии с заданными правилами.

2. Типовой процесс
Правильнее было бы сказать "типовая модель процесса" (управления изменениями), которую еще только предстоит адаптировать к компании N и запустить в работу. Что включает в себя модель процесса? Как минимум:

  • определение цели, задач, области охвата (например, это управление изменениями в бизнес-системах, или ИТ-инфраструктуре, или и в том, и в другом, но не в бизнес-процессах и так далее);
  • определение последовательности действий и порядка взаимодействий (workflow процесса);
  • определение порядка контроля исполнения (а в хорошем случае также порядка оценки и совершенствования) и механизмов его реализации (метрики и отчетность, самопроверки и аудит, оперативный контроль линейного менеджмента, процедуры передачи смен и прочее);
  • определение ролей, RACI;
  • определение интерфейсов к другим процессам и видам деятельности.

Подчеркну, это минимум. Именно про типовые процессы во многом написаны книги ITIL (особенно это относится к ITIL v2). То есть наличие типовых моделей процессов не гарантирует ни уникальной компетенции команды внедрения (неважно со стороны консультантов или заказчика), ни тем более достижения результата — организации деятельности. Упрощённо говоря, типовой процесс это набор документов. Спросите себя, если бы в Вашей компании завтра появился набор бумаг по управлению изменениями (не стесняйтесь в фантазиях — 50 страниц, 100 страниц, 200?) этого было бы достаточно для того, чтобы изменения оказались под контролем, а Вы, как руководитель, обрели спокойный сон?

Я помню несколько компаний, в которых я и мои коллеги внедряли управление изменениями. Процесс был типовой, но после адаптации к конкретной компании получались довольно разные результаты. То есть если Вам предлагают (продают) типовые процессы, неплохо бы на берегу четко определиться, что Вы получите в результате? Неплохо также поинтересоваться что "умеет" предлагаемый Вам типовой процесс, так как на практике все знают, например, что есть стандартные изменения, но вот беда — стандартные изменения в магазинах не продаются, их надо разрабатывать. Внедряемый процесс управления изменениями определяет деятельность по стандартизации изменений? Если процесс списан с книжек ITIL, увы, скорее всего нет. Или, например, ролевая структура процесса пригодна к управлению изменениями в территориально распределенной компании? Список "или" легко можно продолжить.

Типовой процесс дальше от консалтинга и ближе к готовому продукту. С чего Вы начинаете выбор автомобиля? Правильно, с изучения и сравнения комплектаций! И не ожидайте, что продавец автомобиля заодно будет учить Вас безопасному вождению. Лучше уточнить: "Что я получу кроме автомобиля (стопки процессной документации)? Какие задачи я смогу решить?". Ответ скажет о продавце гораздо больше, чем предлагаемый ценник.

3. Типовая (коробочная) система автоматизации
Представляет собой конфигурацию системы автоматизации, которая содержит готовые элементы автоматизации процессов (схему workflow, роли и их полномочия, объекты с нужными связями и атрибутами, формы, правила бизнес-логики и прочее). Опасность заключается в том, что система сама по себе (даже очень мощная, гибкая, безопасная, удобная и масштабируемая) не "диктует" процесс (может быть только отдельные элементы, например — статусы запроса на изменение, набор приоритетов, полномочия в зависимости от роли и этапа обработки). И уж тем более система автоматизации не обеспечивает исполнения и контроль процесса.

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

 

Почему мы вообще об этом заговорили? Потому что практика показывает, что заказчики, всё чаще ожидают результат в виде организации работ, а подрядчики — предлагают типовую систему или в лучшем случае — типовой процесс. И при этом при организации проектов обе стороны используют одни и те же слова, названия одних и тех же процессов ITIL. Особенно комично это работает при проведении тендера, где постановка задачи практически отсутствует, разные подрядчики предлагают разные вещи, а выбор осуществляется исключительно по цене! ВавилонITSM...

«Управление проектами на основе PRINCE2»
Аккредитованный сертификационный учебный курс

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

  • Всё в точку. Даже не поспоришь 🙂

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

    «Референтный» — может быть, зачем велосипед изобретать, но «типовой» — не верю.


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

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

  • Рубрики

  •  
  • Авторы

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

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT