Эссе о реальном рациональном решении написано и размещено в вашем блоге.
Зачем я решил моделировать ROSECO перед её переходом к AI-driven company
Одним из моих реальных решений, в котором я могу проследить применение материалов руководства «Рациональная работа», стало решение создать модель организации ROSECO для последующего перехода к AI-driven company. Этот проект одновременно рабочий и учебный: я рассчитываю улучшить деятельность компании и на конкретном материале научиться выбирать понятия, строить описания, формировать объяснения и обсуждать решения с другими участниками.
Моё решение состояло в том, чтобы подготовить первую статическую модель организации, проверить её полезность и постепенно развивать на основе практического применения. На совещании с Анной и Владимиром 11 сентября я прямо сформулировал цель: построить AI-driven company. При этом я уточнил первоначальную формулировку AI-first: ROSECO уже существует, у неё есть сложившиеся способы работы, поэтому речь идёт о преобразовании действующей организации.
Для такого преобразования необходимо понимать, какие результаты компания создаёт, кто и в каком качестве участвует в работе, какими методами пользуется и от чего зависит получение результата. Модель должна помочь выбирать и согласовывать изменения.
Основанием для решения была задача сохранять и укреплять позиции ROSECO через повышение ценности для заказчика. На встрече с Анной 9 сентября мы обсуждали возможность предлагать заказчикам больше вариантов проектных решений и улучшать взаимодействие специалистов. Использование ИИ представлялось средством такого изменения, а ожидаемый эффект ещё предстояло проверить.
В той беседе я привёл конкретный пример: архитектор обсуждал изящное конструктивное решение покрытия здания, а конструктор подготовил вариант, который архитектор воспринял как превращение здания в ангар. При этом у меня не было оснований считать участников непрофессиональными. Эпизод показывал проблему согласования замысла и результата между специалистами. Он не доказывал единственную причину сбоя, но давал основание внимательнее рассмотреть требования, передачи работ и промежуточные согласования.
Моё объяснение можно восстановить следующим образом. Результат компании зависит от того, как связана работа разных участников. Чтобы обоснованно выбирать места применения ИИ, нужно описать эти связи и условия получения результата. Проверяемая модель позволит давать ИИ содержательный контекст, исследовать возможные улучшения и видеть, каких данных для вывода пока не хватает. Поэтому моделирование имеет смысл как подготовка к управляемым изменениям компании.
Выбор онтологии происходил при подготовке и пересмотре первых описаний ROSECO. Мне требовалось определить, какие типы объектов и отношений нужно различать, чтобы обсуждать организацию достаточно точно.
Для этой задачи я выбрал представление организации через цели, роли, методы, работы, рабочие продукты, ресурсы и связи между ними. В модель также вошли проекты, подразделения, информационные системы, источники и наблюдения. Такое представление позволяет переходить от общего вопроса «как устроена компания» к конкретным: какой результат должен появиться, какая работа для этого нужна, кто её выполняет, на каком основании и что подтверждает её завершение.
Существенную роль здесь сыграли FPF и соответствующие DPF. Они не являются готовой онтологией ROSECO и не содержат фактов о нашей компании. Однако содержащиеся в них различения и принципы дают основания для построения онтологии и проверки её корректности. FPF помогал удерживать общие различения, а DPF — уточнять их применительно к организационным изменениям, разработке методов, управлению операциями и другим предметным областям.
Результат этой работы хорошо виден в переходе от первой ролевой модели к версии 0.2. Были явно разделены должность, роль и назначение: должность обозначает место в организационной структуре, роль — функцию в определённом контексте, назначение — связь конкретного исполнителя с этой ролью и периодом. Наличие должности само по себе не доказывает ни компетентность, ни полномочия, ни выполнение конкретной работы.
Аналогично были разделены метод, описание метода, план и выполненная работа. Регламент свидетельствует о наличии описания способа работы, но не подтверждает, что конкретная работа действительно выполнена по нему. Создание продукта, его передача, проверка и приёмка тоже требуют отдельных свидетельств.
Эти различения важны для последующей автоматизации. Если смешать роль с должностью, легко начать обсуждать замену сотрудника целиком, не разобравшись в составе его работ. Если смешать описание метода с его исполнением, можно приписать организации практику, которая существует только в документе.
Онтология получила конкретное воплощение в описаниях ROSECO, каталоге ролей и схеме связанных объектов. Для проектного производства была выделена цепочка от проекта и этапа до работы, результата, передачи, исполнителя, трудозатрат, ожидания и блокировки. Она задаёт, какие сведения нужно собирать для анализа причин задержек.
Отдельным решением стало хранение утверждений вместе с источниками, периодом действия и статусом проверки. Фактическое состояние, нормативные требования и желаемое будущее состояние разделяются. Это позволяет проверять, что именно описывает модель: наблюдаемую работу, установленное правило или предложение по изменению.
При этом я не считаю первый результат завершённым описанием компании. На совещании 11 сентября я специально пояснил, что показанный пример был учебным и его даже рано уверенно называть MVP. Он демонстрировал, как может выглядеть модель, но не содержал всего необходимого. Для меня это существенная часть рационального подхода: различать наличие наглядного прототипа и готовность рабочего продукта.
Паспорт проекта задаёт способ проверки полезности модели. Первые сценарии — поиск возможного ограничения выпуска, определение данных для раннего выявления перегрузки ключевых специалистов и оценка соответствия лида портрету идеального клиента.
В паспорте записан и критерий продолжения: хотя бы два из трёх сценариев должны давать полезный, проверяемый ответ и экономить пользователю не менее тридцати минут на аналитический цикл. Это условие проверки, а не уже достигнутый результат. Если оно не выполняется, следует пересмотреть состав данных и первый срез модели.
Совещания с Анной и Владимиром стали примером аргументированной коммуникации, в которой исходное решение получило уточнения.
На встрече 9 сентября Анна указала, что конкурентоспособность и дополнительная ценность для заказчика пока сформулированы слишком общо. Нужно определить, за счёт чего мы собираемся улучшать положение компании, и перевести это в конкретные действия. Она также подчеркнула необходимость общего пространства данных: материалы должны быть доступны участникам, чтобы они могли продолжать работу друг друга.
На встрече 11 сентября Владимир представил подготовленную структуру совместной работы и предложил разместить модель компании в общем репозитории контекста как основание для последующих проектов. Мы обсудили различие между обменом результатами и контекстом работы и хранением исходных корпоративных документов. Это уточнило требования к инфраструктуре: для разных материалов нужны определённые места хранения и правила доступа.
Особенно показательным оказался вопрос Владимира о том, какую проблему мы хотим решить установкой инструмента на сервер с удалённым доступом. Я предложил этот вариант как гипотезу, которую нужно проверить. После его вопроса я уточнил свою потребность — разделение личной и корпоративной работы — и признал, что общий репозиторий может позволить решить её без предложенной схемы. Здесь объяснение помогло вернуться от выбранного средства к задаче и пересмотреть первоначальное предположение.
Другой важный эпизод касался описания инфраструктуры. Владимир спросил, можно ли использовать уже имеющийся перечень оборудования. Я пояснил, что документ составлялся для тендерных целей и сам по себе недостаточен для понимания архитектуры. Поэтому мы выделили отдельную работу: описать существующую инфраструктуру, целевое состояние и необходимые изменения. Один и тот же объект может иметь разные описания, и пригодность описания зависит от вопроса, на который мы хотим ответить.
Анна также показала зависимость между первым пилотом — навигатором по регламентам — и общей моделью компании: подбор документов по ролям требует согласованного описания самих ролей. Поэтому мы подтвердили параллельное развитие пилота и модели. Её вопрос о политике использования ИИ привёл к явному уточнению: целевое описание должно включать права доступа, типы данных и допустимые места их обработки. Я признал, что в показанном примере модели этого ещё нет.
Владимир, со своей стороны, отметил, что предлагаемые ИИ варианты архитектуры сильно зависят от сформулированных целей. Он поставил и более глубокий вопрос: куда будут направлены ресурсы сотрудников, высвобождаемые автоматизацией? На встрече мы не дали на него содержательного ответа. Для меня это остаётся важным ограничением объяснения: автоматизация отдельных работ ещё не определяет, каким образом компания использует полученные возможности.
Обсуждение завершилось конкретизацией следующих действий: передать модель в совместное пространство, помочь Анне настроить доступ, исследовать варианты хранения данных и подготовить описание текущей и целевой инфраструктуры. Были обозначены исполнители и сроки. Стенограмма фиксирует эти договорённости, но сама по себе не подтверждает их выполнение.
Рациональность принятого решения я вижу в том, что оно опирается на явные различения, проверяемое описание и объяснение ожидаемой пользы, допускающее критику и пересмотр. Работа с онтологией помогает точнее видеть устройство компании. Модель делает эти представления доступными другим участникам. Обсуждение обнаруживает неполноту объяснения и превращает общую цель в следующие действия. Именно эту связь между мышлением, коммуникацией и изменением реальной организации я учусь выстраивать в проекте ROSECO.