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

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

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

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

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

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

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

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

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

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

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

ИНТЕНСИВ С ТРЕНЕРОМ

Управление проектами на основе PRINCE2

Трёхдневный аккредитованный учебный курс