У вас есть дорогая ИСУП, которую внедряли полгода. У вас есть регламенты, ради которых лучшие люди месяцами отрывались от работы, чтобы описать, как надо работать. Формально сделано всё, но проекты все равно живут своей жизнью, важные инициативы буксуют, а проблемы выявляются слишком поздно.

Причина проста. Регламенты, которые должны управлять проектами, на практике почти никто не использует – какие-то правила давно устарели, а какие-то погребены в недрах 200-страничного документа. ИСУП же автоматизирует лишь небольшую часть процессов: управление сроками, иногда деньгами и ресурсами, – оставляя за бортом риски, цели, ответственность, связи между проектами и т.д. 

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

В чём проблема ИСУП

Начнём с того, зачем ИСУП вообще нужна. У её внедрения три цели: доступ к информации, сокращение операционных ошибок и снижение трудоёмкости. И здесь важно сразу снять частое заблуждение: ИСУП не противостоит регламенту. Регламент – это набор правил и договорённостей: как мы взаимодействуем, кто за что отвечает, кто что должен делать. А ИСУП это вспомогательная учетная система, которая лишь частично поддерживает эти правила – позволяет легче их придерживаться, осуществляет автоматический контроль, запрещает нарушение части правил. 

Но есть проблемы:

• она отстаёт от правил. Правила управления меняются постоянно, а чтобы отразить изменение в ИСУП, требуется много времени и денег на доработку – поэтому система всегда не поспевает за эволюцией методологии.

• она не вмещает всю методологию. Существенная часть артефактов и инструментов всегда остаётся вне ИСУП. Чтобы собрать целостную картину, приходится сводить данные из разных документов, файлов и систем – единого представления в одном месте нет.

• она упирается в архитектуру. Развивать систему – добавлять новые объекты и логику управления ими – мешают архитектурные ограничения. То, за что когда-то ценили Jira – свободно развивать объектную модель (не только задачи, но и проекты, продукты, цели и т.д.) – ИСУП, как правило, полноценно не умеет. А доработка через интегратора выходит долгой и дорогой, а иногда и вовсе невозможной.

В чём проблема регламентов

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

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

Решение – DevOps для правил управления

Вот главная мысль, ради которой всё написано: проблема не в ИСУП и не в регламентах. ИСУП делает свою работу – учёт. Регламент делает свою – описывает правила. Проблема в том, что между ними нет слоя, который превращал бы правила в то, чем реально пользуются каждый день.

Этот недостающий слой я называю DevOps для правил управления. DevOps в ИТ связал разработку и эксплуатацию в один непрерывный поток, чтобы изменения быстро попадали в реальную работу. Здесь та же идея – только для методологии: убрать зазор между «правило записали» и «правилом пользуются на практике». Реализуется он как живая цифровая модель управления – описание системы управления через связанные между собой цифровые сущности в едином ИТ-продукте.

Живая цифровая модель позволяет:

1. Предоставлять быстрый доступ к нужной информации. Правило работает только тогда, когда любой участник за секунды находит своё: что делать на этой фазе, какой артефакт подготовить, кто за что отвечает, какие показатели с него спрашивают. Не листать 200 страниц и не идти к коллеге, а получить ответ под свою роль сразу. 

2. Проводить аудит, чтобы сохранять правила актуальными и работающими. Быстрый доступ бесполезен, если данные недостоверны и не соответствуют реальности. Поэтому в модель встроен функционал аудита: проверяет соблюдение правил и собирает обратную связь – что исполняется, что нет и почему. За счёт этого данные остаются актуальными и достоверными, а не превращаются в очередной устаревший регламент. 

3. Автоматически обновлять всю систему при внесении изменения. Поменяли одно правило – и это изменение расходится по всем связанным элементам. Не нужно переписывать регламент и заново внедрять – новое правило сразу встраивается в практику. Именно замкнутый цикл «правило – исполнение – аудит – обратная связь – обновление правила» и делает методологию живой, а не мёртвой.

Самое главное – модель позволяет прозрачно управлять тремя ключевыми областями, где чаще всего и возникают «слепые» зоны:

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

• учёт. Режим ранних сигналов: по каждому проекту видно, что идёт не так с точки зрения целей, показателей, контрольных точек, денег. Плюс связанность объектов – видно цели без проектов или проекты без целей, конфликтующие инициативы и соответствие приоритетам бизнеса;

• профиль риска. Не только риски проекта (отклонения, «красные» сигналы, дефицит ресурсов), но и процессные риски – несоблюдение процесса, которое иначе остаётся невидимым, как «ходить без каски», пока ничего не случилось.

Как это работает для каждой роли

Один и тот же инструмент отвечает на вопрос «за чем мне следить» по-разному – в зависимости от роли.

1) Собственник / генеральный директор.

Для первого лица система управления чаще всего чёрный ящик, и живая модель делает её видимой по трём направлениям.

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

Учёт. Режим ранних сигналов: по каждому проекту видно, что идёт не так по ключевым показателям, контрольным точкам, деньгам, – чтобы быстро решать, что остановить, что продолжить, где помочь, и не распылять внимание. Сюда же связанность объектов: видно цели без проектов, проекты без целей, конфликтующие инициативы и то, обеспечены ли приоритеты бизнеса нужными проектами.

Профиль риска. Видны не только риски содержания проектов (отклонения, «красные» сигналы, дефицит ресурсов), но и процессные риски – несоблюдение процесса, которое иначе остаётся невидимым, «как ходить без каски», пока ничего не случилось.

2) Директор по стратегии.

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

Модель показывает связь «стратегия – проекты» и подсвечивает разрывы, чтобы вовремя скорректировать стратегию или хотя бы вслух обозначить проблемы в её реализации.

3) Директор по трансформации / руководитель проектного офиса.

Новые правила вводятся приказом, не приживаются, через полгода всё откатывается. В модели можно вносить изменения в стандарт и выкатывать его волной на выбранные объекты и отслеживать приживаемость.

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

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

4) Руководитель проекта.

У руководителя проекта появляется чёткое понимание, кто и что должен делать: за что отвечает руководитель проекта, за за что отвечают другие. В модели можно открыть карточку своего объекта и увидеть все, что требуется: фазы, что требуется по событиям и артефактам. А также использовать базу знаний, чтобы взять инструкцию и образец артефакта. 

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

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

Три поколения методологий: где вы сейчас?

На мой взгляд, методология прожила два поколения. 

Сначала было поколение 1.0 – регламент обыкновенный. Текстовый документ, который написали и забыли: статичный, тяжёлый, устаревает быстрее, чем его согласуют. Итог – бюрократия и отрыв от реальности.

Потом организации стали создавать системы, описанные на унифицированном языке – например, аспекты, артефакты, события, роли, RACI (подробнее о моем подходе к сборке методологии читайте здесь). Уже лучше, но пропасть между «как надо» и «как на самом деле» все еще остается.

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

Коллеги, если у вас есть вопросы, задавайте! А еще жду вас в своем Телеграм канале «Андрей Малахов | От проектов к масштабу». Делюсь там клиентскими кейсами, работающими инструментами и мыслями о современном менеджменте.