Тимур Гилязов, УК «Полюс»: НМД: Сжечь нельзя читать

До AI-трансформации бизнеса у внутренней нормативно-методической документации в компании было два основных потребителя:

1) Организация в целом: комплаенс, соответствие внутренних бизнес-процессов внешним требованиям, защита интересов организации в судах, прохождение контрольно-надзорных мероприятий, распределение функционала, полномочий и ответственности от генерального директора вниз по организационной структуре. НМД как безопасность и устойчивость организации.

2) Каждый сотрудник: эффективная «доставка» нормативно-методических требований компании до сотрудников, регулирование, увеличение скорости и снижение трудоемкости бизнес-процессов, требования к автоматизации, удобные путеводители и дайджесты. НМД как ясность – кто и что должен делать.

Теперь появляется третий потребитель:

3) Внутренний AI-агент (цифровой сотрудник): база знаний для обучения нейросетей или контекст, применительно к которому будут формироваться промпты для AI-агентов. НМД как AI-ready данные.

От разрозненных семейств документации к полной карте регуляций

Многие компании научились делать внутреннюю документацию простой и доступной. Как пример приведу проекты 2020 года – через тексты или через схемы процессов. Это позволило реализовать сценарий сотрудника-исполнителя «Я работаю как написано».

Сценарий методолога «Я пишу НМД с учетом смежных требований и выученных уроков, рисков, опыта»; сценарий архитектора «Благодаря НМД я заранее спроектировал все необходимые интеграции»; сценарий операционной эффективности «Благодаря НМД я оптимизировал скорость, трудоемкость, стоимость выполнения бизнес-процесса» – эти сценарии всегда казались очень привлекательными, правильными в теории, но очень трудоемкими, нереалистичными на практике.         

Думаю, чтобы реализовать данные сценарии, необходимо собрать вместе, проанализировать и увязать между собой не только регламенты, но все нормы, требования и правила (назовем их регуляции), прямо влияющие на работу сотрудников. Можем выделить 15 семейств документации:

Встаёт вопрос, как синхронизировать изменения всех семейств документации между собой? Ответ год назад был бы таким: «Невозможно и не стоит браться».

На сегодня созрел другой ответ: «AI-трансформация бизнеса – это новая реальность, в которой уже нет ограничений на большой объем, избыточную фрагментацию и низкую структурированность анализируемой информации».

От управления документами и процессами к управлению комплексной операционной моделью бизнеса

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

Бизнес-процессы:

Структура:

Персонал:

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

Нотации моделирования VS Свободный текст

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

Другая крайность в ad-hoc подходе к построению операционной модели «Есть проблема – решаем». Тогда количество противоречий в процессах нарастает как снежный ком и обычно звучит как «У нас огромная бюрократия» (противоречия между функционалом сотрудников и функционалом информационных систем, между полномочиями в должностных инструкциях и полномочиями в доверенностях, между ответственностью в картах КПЭ и ответственностью в протоколах совещаний).      

Сегодня появляется эффективный компромисс в объединении этих двух подходов – благодаря современным data science-технологиям теперь возможен мостик между разрозненным документированием снизу и системным видением операционной модели сверху.

В цене умелое сочетание разных управленческих компетенций и методологических подходов

Офисы крупных промышленных компаний населены аналитиками всех направлений. На рынке труда сформировались устойчивые профессиональные сообщества, к примеры такие:

Если соединить указанные компетенции в одном подразделении и спроецировать их на проектный, продуктовый и процессный подходы к управлению деятельностью компании, то, как мне кажется, мы получим идеального «методолога», «бизнес-архитектора», «технолога бизнес-процессов». Возможно, пришло время стирать границы между указанными управленческими компетенциями и методологическими подходами. Вместо «процессного офиса», «отдела стандартизации», «службы повышения операционной эффективности» формировать в компаниях «Центры комплексного управления операционной моделью».

Тимур Гилязов, начальник управления нормативно-методического обеспечения деятельности, УК «Полюс»