47 дней на согласование одного изменения. Так работает типичный крупный завод. Потом кто-то предлагает то же самое — и цикл начинается заново.
Это не проблема людей. Это проблема способа работы: регламенты в Word, знания в головах, связи между документами — только если помнишь, что они есть. Люди уходят — память уходит вместе с ними.
Мы попробовали другой путь. Ассоциация цифрового кибернетического управления (АЦКУ) — молодая организация, и с первого дня мы строим её как код: принципы, знания, навыки, контент — всё в виде текстовых файлов с историей изменений, всё связано между собой. Не потому что модно, а потому что по-другому уже не успеваем.
Две недели практики. Вот что из этого получается.
Что значит «организация как код»
Код в данном случае — не строчки на Python. Это любой текстовый файл, который хранится в системе контроля версий (Git). Каждый файл показывает, кто его создал, когда и зачем менял. Любое решение можно отмотать назад, любой документ связан с другим.
Программисты так управляют своими проектами десятилетиями. Идея простая: если это работает для миллионов строк кода — почему бы так же не управлять компанией?
Что такое АЦКУ
Ассоциация цифрового кибернетического управления объединяет три контура промышленного производства: машиностроение, промышленное строительство и эксплуатацию. Задача — создать цифровой слой, который связывает все три контура через данные об изделии.
Три контура — три мира. Машиностроительный завод создаёт изделие. Строительная площадка встраивает его в объект. Эксплуатация обслуживает и ремонтирует. Сегодня данные об одном и том же насосе живут в трёх разных системах, и ни одна не знает, что происходит в двух других. АЦКУ замыкает контур.
Организация находится на стадии становления. Нет унаследованных систем, нет десятилетий бумажных регламентов, нет инерции «мы всегда так делали». Это преимущество: можно строить правильно с первого раза.
Как пришли к этому
Подход возник не на пустом месте. За ним стоят 40 лет эволюции — в архитектуре предприятий, в разработке и в том, как мы работаем с информацией.
Архитектура: от серверов к смыслу
В 1980-х архитектура предприятия описывала серверы и базы данных. Архитектор нарисовал схему — и она устаревала через месяц. К 2000-м добавились бизнес-процессы и оргструктура, к 2010-м — большие данные и машинное обучение, к 2020-м — цифровые двойники и облачные платформы. Ландшафт стал необозримым.
И тогда произошёл сдвиг: фокус архитектуры сместился с технологий на бизнес-способности. Не «какие у нас серверы», а «что организация умеет и как создаёт ценность». Показатели, сервисы, бизнес-модели, способности, знания — вот из чего состоит архитектура предприятия теперь.
Параллельно менялась разработка. От водопада и монолитов — через гибкие методы и микросервисы — к коротким циклам и мелким независимым компонентам. Каждое десятилетие — декомпозиция на уровень мельче.
Как код поглощал одну область за другой
А потом программисты совершили тихую революцию. Они поняли, что текстовые файлы с историей изменений работают лучше, чем ручные настройки и интуиция.
Сначала как код стали описывать серверы — и они перестали ломаться от человеческих ошибок. Потом настройки приложений — и их стало можно откатить. Потом конвейеры сборки, документацию, архитектуру. Каждый раз — одна и та же логика: перенос области из «в головах и Word» в текст с историей изменений. Версионирование, воспроизводимость, прослеживаемость.
Следующий шаг — описать как код саму организацию. Не только IT-отдел, не только процессы — а всё: принципы, знания, навыки, контент, задачи. Этот подход уже обсуждают на Хабре и Hacker News, но практических реализаций мало. Мы — одна из них.
Два тренда сошлись в одной точке. Архитектура предприятия перешла от технологий к бизнес-способностям. «Всё как код» доказало, что текст с историей изменений работает лучше, чем Word и совещания. Организация как код — пересечение этих трендов: способности организации описаны как версионированные, связанные, машиночитаемые артефакты.
Почему именно сейчас
Четыре условия совпали одновременно.
Инструменты стали доступны всем. Git, Markdown — стандартный набор, не требующий лицензий. Это как Google Docs, только с историей изменений и связями между документами.
Появились ИИ-помощники, но они требуют машиночитаемости. ИИ-агент может читать текстовые файлы, находить связи, проверять факты, писать черновики. Но для этого организация должна быть описана в формате, который ИИ понимает. PDF и сканы — не понимает. Структурированный текст — понимает. AI-ready — это свойство организации, не свойство ИИ.
Рост компаний убивает устную память. Три человека держат всё в головах. Тридцать — уже нет. Каждый уход эксперта — невосполнимая потеря.
Удалёнка разрушила неявные связи. Когда все в одном офисе, можно подойти и спросить. Когда распределены — нужен явный механизм передачи контекста.
Семь принципов
Мы сформулировали семь правил, по которым живёт организация как код. Не из воздуха — из практики и кибернетики.
1. Всё с историей изменений. Любой документ можно отмотать назад. На вопрос «кто изменил это правило и почему?» — всегда есть ответ.
2. Всё прослеживается. Каждое решение восходит к принципу, каждый документ — к методологии. Нет «висящих» артефактов без обоснования.
3. Связи явные. Организация держится не отдельными файлами, а связями между ними. Ссылка в каждом документе показывает, откуда он вырос и на что влияет.
4. Машиночитаемость. Структурированный текст, который ИИ-агент может читать и понимать. Не PDF, не скан, не устная договорённость.
5. Воспроизводимость. Шаблон + формализованный процесс = новый элемент создаётся по образцу. Масштабирование через шаблоны, а не через совещания.
6. Близость к контексту. Правило живёт рядом с тем, к чему относится. Не «документация в одной папке, работа — в другой», а всё в одном месте.
7. Одна версия правды. Файл в системе — одновременно и регламент, и актуальное состояние. Нет расхождения между «как написано» и «как на самом деле».
Кибернетика — не абстракция, а фундамент
Принципы — не выдумка. За ними стоит теория, которая работает с 1950-х.
Закон необходимого разнообразия (Эшби, 1956): управляющая система должна уметь не меньше, чем управляемый объект. Если организация решает разнотипные задачи — ей нужен набор разнотипных навыков. Фактчекинг, исследование, рефлексия, контент — каждый покрывает свой класс задач.
Модель жизнеспособной системы (Бир, 1972): организация жизнеспособна, если воспроизводит пять функций — операции, координацию, контроль, интеллект и политику. В нашем случае: задачи — это операции, связи между документами — координация, правила проверок — контроль, база знаний — интеллект, принципы — политика.
Рекурсия: каждый навык — мини-организация со своим контекстом и обратной связью. Навык используется другим навыком — и эта зависимость описана явно.
Организация как код естественным образом воспроизводит кибернетические закономерности. Они не придуманы — они фундаментальны для любой жизнеспособной системы.
ИИ-агент — администратор, не начальник
В нашем случае доступ к знаниям организации идёт через ИИ-агента. Он не принимает решений за людей. Он администратор: читает правила, проверяет факты, обновляет документы, формирует контент.
Навыки агента — это навыки организации. Когда агент проверяет факт — он следует алгоритму, который принадлежит организации, а не ему лично. Когда пишет пост — применяет стилистику, выработанную коллективом. Сменился агент — навыки остались. Сменилась платформа — навыки остались. Организация владеет своими навыками, а не арендует их у ИИ.
Обычно ИИ в промышленности работает с внешними данными: показания датчиков, отчёты, логи. У нас ИИ работает с внутренними сущностями самой организации — принципами, знаниями, архитектурой. Не внешний консультант, а штатный сотрудник.
Что это даёт на практике — наш опыт
Две недели. Рано для выводов — но разница уже видна.
Скорость. Навык — формализованный алгоритм работы — создаётся за час по шаблону. Без шаблона — неделя. Сейчас в организации 13 навыков: от фактчекинга до рефлексии.
Память. Каждый инсайт, каждый опыт — в репозитории. Не в почте эксперта, не в его голове. За две недели — 18 формализованных знаний и одна рефлексия, которая обновила правила работы.
Контент из данных. План на 150 публикаций сформировался из пробелов в реестре сущностей. Ни одного голосования, ни одного совещания.
Фактчекинг как процесс. Каждый пост проходит семь этапов проверки, минимум два источника на факт. Не «ну вроде похоже на правду», а формальный чеклист.
Связность, которую можно проверить. Аудит обнаружил 27 документов без связей с принципами — исправили за один проход. В классической организации такой аудит занял бы месяцы.
ИИ-агент как штатный сотрудник. Читает навыки, проверяет факты, публикует посты. Человек принимает решения, агент исполняет. Это работает только потому, что организация описана машиночитаемо.
Этапы развития
Организация, построенная как код, проходит несколько этапов зрелости.
Этап 0 — идеология. Есть гипотеза, нет артефактов. Репозиторий создан, но почти пустой. Решения — по интуиции.
Этап 1 — структура. Появляется скелет: принципы, архитектура, первые навыки и знания. Организация описала себя, но живёт в основном в головах основателей.
Мы здесь. Апрель 2026.
Этап 2 — рутина. Процессы работают регулярно, ИИ-агент выполняет рутину, человек — только согласовывает. Фактчекинг, рефлексия, аудит — по расписанию, не по настроению.
Этап 3 — масштабирование. Организация растёт, структура не ломается. Новый участник входит через репозиторий, не через устный онбординг. Новый продукт — шаблон + заполнение + связи, не проект с нуля.
Этап 4 — автономия. Организация диагностирует и лечит себя. Уход основателя не разрушает её — знания и процессы в репозитории. Новая команда поднимает контекст за дни, не за месяцы.
Каждый этап — рост доверия к коду как носителю организации. Гипотеза → описали себя → заработало → масштабируется → живёт самостоятельно.
Ограничения — честно
Не заменяет культуру. Можно написать в правилах «осмысленные сообщения об изменениях» — но если культура позволяет писать «fix», никто не запретит. Код — инструмент, не панацея.
Требует дисциплину. Каждый документ нужно связать, каждый индекс обновить. Без этого система деградирует.
Порог входа. Не каждая организация готова к Git-first подходу. Если регламенты в Word и это работает — не ломайте. Но если уже ломается — вот альтернатива.
Мы в начале пути. Две недели практики. Гипотеза подтверждается, но не доказана.
Итог
Организация как код — это не технология, а способ мышления: всё, чем является организация, можно описать, связать, отследить и проверить. Как текст с историей изменений.
Infrastructure as Code прошла путь от экзотики до стандарта за пять лет. Organization as Code — в начале этого пути. Мы тоже в начале — но строим правильно с первого дня.
47 дней на согласование. Снова и снова. Может, пора попробовать по-другому?
*Справка: история концепции «всё как код»
Everything as Code (EaC) — признанный индустриальный стандарт. AWS определяет его как практику применения принципов версионирования, тестирования и развёртывания ко всем аспектам жизненного цикла. Концепция развивалась поэтапно, поглощая одну область за другой.
Infrastructure as Code (2014–2017). Серверы, сети, хранилища описываются кодом вместо ручной настройки. Terraform, Ansible, Puppet. Источник: Morris K. — Infrastructure as Code (O'Reilly, 2016).
Configuration as Code (2015–2018). Параметры приложений и окружений выносятся в версионированный код. Смена конфигурации = коммит, не вход на сервер. Источник: CloudBees — EaC.
Pipeline as Code (2016–2019). CI/CD-конвейеры описываются декларативно (Jenkinsfile, GitLab CI, GitHub Actions), не через UI. Конвейер = файл в репозитории, изменение процесса сборки = pull request. Источник: GitHub Actions.
Documentation as Code (2017–2020). Документация пишется в Markdown/AsciiDoc, хранится рядом с кодом, автособирается. Не Word в сетевой папке. Источник: Write the Docs — Docs as Code.
Architecture as Code (2020–2024). Архитектура описывается формальными моделями: C4, Mermaid, ADR. Диаграммы генерируются из кода, архитектурные решения = Markdown-файлы с контекстом. Источник: MATISSE-KDT/arxiv 2025.
Organization as Code (2024 — настоящее время). Сама организация — принципы, знания, навыки, контент, задачи — описывается как версионированные, связанные, машиночитаемые артефакты. На Хабре 1Форма трактует OaC как описание подразделений через исполняемые сервисные контракты. На Hacker News обсуждают декларативное описание компании через Terraform/Pulumi.
Каждый этап — перенос очередной области из ручного управления в код. Логика одна: версионирование → воспроизводимость → автоматизация → прослеживаемость.
Источники
«Эволюция подходов в управлении ИТ-ландшафтом на основе бизнес-способностей» — видео
Morris K., Infrastructure as Code (O'Reilly, 2016)
1Форма, «Organization as Code»
АЦКУ — Ассоциация цифрового кибернетического управления. Про АЦКУ будет отдельная публикация.