Меня зовут Сергей Колесников. И если оглянуться на мои 32 года в профессии, то можно сказать, что я был кем-то вроде ортопеда для бизнеса. Нет, не лечил людей, но "вправлял" вывихнутые процессы и подбирал "протезы" для хромающих компаний. Но самые важные вещи о своей профессии я понял, как ни странно, не из мира технологий, а из мира медицины.
Мое первое погружение в эту тему случилось на ОАО "Елатомском приборном заводе". Это производство, делающее сложную медицинскую аппаратуру для физиотерапии и не только. Там я и столкнулся с двумя идолами, на которых молится любой крупный бизнес: сертификатом ISO 9001 и толстенными папками со схемами в BPMN. И вот что меня тогда убило: я в них ничего не понял. Совсем. Это был какой-то личный когнитивный диссонанс: я мог часами разбираться в хитросплетениях проблем артроза у пожилых пациентов, но глядя на эти, вроде бы, простые картинки, я впадал в ступор.
А потом, уже управляя сетью ортопедических салонов "Здрава", я увидел ту же самую историю, но уже с живыми людьми. Они приходили к нам, когда все было совсем плохо. Когда суставы уже были ни к черту, а болезнь, которую можно было остановить 15 лет назад, добралась до финала. Наши приборы были для них не способом стать здоровее, а последним шансом хоть как-то ходить.
И бизнес, черт возьми, ведет себя точно так же. Он годами скрипит, хромает, но терпит. А когда становится совсем невмоготу, начинает в панике искать "доктора". И тут очень часто появляется бизнес-аналитик с баночкой пиявок под названием BPMN. Он их старательно прикладывает, рисует схемы, создает видимость лечения... а корень болезни в большинстве случаев, остается.
Давайте же разберемся, почему так.
Симптомы болезни: анатомия современного управленческого хаоса
Давайте препарируем то, что сегодня ошибочно называют "управлением". Это путь деградации, который проходит большинство компаний.
Уровень 1: Управление иллюзиями (BPMN).
Начнем с вершины заблуждения. Аналитики приносят вам красивые схемы в BPMN, которые, по идее, должны вносить ясность. На деле — они лишь запутывают. И причина проста: этот язык сделан без малейшего уважения к тому, как устроен наш мозг.
Информационная слепота: BPMN чудовищно перегружен. Стандарт предлагает нам выучить более сотни разных значков (¹). Это нереально. Научные работы в области когнитивной психологии, например, исследования Нельсона Коуэна, показывают, что наша рабочая память может одновременно удерживать в фокусе не более 4-5 элементов (²). А BPMN предлагает нам интеллектуальное жонглирование десятками. Мозг от такого просто отключается. Все эти значки похожи как две капли воды, и глаз их просто не различает (³). Неудивительно, что, по данным исследований, люди, не являющиеся гуру BPMN, ошибаются при чтении этих схем на 20-30% чаще, чем эксперты (⁴).
Паралич коммуникации: Но даже если бы схемы были понятны, они создают пропасть. Бизнес пытается говорить на BPMN. IT-отдел отвечает на своем "тайном" языке — UML. В итоге получается глухой телефон, в котором теряется половина смысла, а бизнес лишается рычагов управления (⁵).
Уровень 2: "Лоскутная автоматизация" (ERP/SAP) — научный взгляд.
Когда компания пытается навести порядок с помощью большой ERP-системы, она попадает в другую, хорошо изученную ловушку. Утверждение, что ERP — это "зоопарк в коробке", не просто метафора, это констатация архитектурного факта.
Принцип "функциональных колодцев": Классические ERP устроены как набор отдельных программ-модулей, каждая для своего департамента — финансов, склада, кадров. Они не способны видеть процесс целиком, от начала до конца, так как каждый модуль "знает" только свою часть работы.ediweb
Дорогостоящие "мостики":
Из-за этого, как отмечают исследователи, передача данных между отделами часто требует ручного труда или создания хрупких программных "мостиков", что ведет к ошибкам, задержкам и огромным расходам.itweek
Жесткость и зависимость: Любая попытка настроить такую систему под себя — это долгий и дорогой проект, а после его завершения компания оказывается на крючке у одного поставщика, теряя свободу маневра.digitalocean
Уровень 3: "Управление по бумажкам" — автоматизация бюрократии.
В самом простом случае компания внедряет 1С-Документооборот. Но это лишь автоматизация бюрократии. Мы начинаем управлять не реальной деятельностью, а движением документов. Как показывают методические материалы и описания проектов, такие системы фокусируются на маршрутах движения документов, а не на логике самого бизнес-процесса. Это приводит к информационной фрагментации и лишь закрепляет существующие ошибки, а не исправляет их.eawards.1c+1
Итог один: все эти ступени — хождение по кругу. Они не решают фундаментальную проблему, а лишь меняют форму хаоса.
Наследие: откуда растут ноги у настоящей эффективности
Чтобы понять, как выйти из этого тупика, нужно посмотреть назад. Советская научная школа 40-70-х годов была уникальной средой для рождения гениальных, системных идей.
Только представьте: в 60-е годы, когда на Западе интернет был лишь смутной идеей, академик Глушков предложил проект ОГАС (ru.wikipedia.org/wiki/ОГАС). Это была концепция единой компьютерной сети для управления всей экономикой СССР в реальном времени — с электронным документооборотом и безбумажными расчетами.wikipedia+1
В то же самое время Генрих Альтшуллер, проанализировав тысячи патентов, создал ТРИЗ (Теорию решения изобретательских задач) — по сути, алгоритм для совершения прорывов, который сегодня используют Samsung и Intel. Апофеозом этого подхода стал "Буран" — самый сложный в истории автоматический аппарат, чей полет управлялся тысячами безупречно работающих алгоритмов.vc
Что объединяет эти, казалось бы, разные проекты? Общая философия: стремление формализовать, упорядочить и сделать предсказуемым то, что кажется хаотичным — будь то экономика целой страны, процесс изобретения или управление космическим кораблем.
Именно из этой школы, из этого подхода, и родился язык ДРАКОН (drakon.su). Он был создан не для красоты, а для 100% понимания и надежности в проектах, где цена ошибки — катастрофа.wikipedia
Парадокс "прогрессивного консерватизма"
Почему же ОГАС был похоронен? Его погубила советская бюрократия, которая испугалась прозрачности и контроля (ogasdemo.ru/concept/istoriya/).ogasdemo
Прошли десятилетия. Роли сменились. "Эффективный менеджер" стал новым чиновником. Он так же боится настоящей прозрачности. BPMN и "зоопарк систем" стали для него идеальным прикрытием.
Я видел это своими глазами. В "СТО Фильтр" директор, очарованный "прогрессивной" IT-командой, выбрал путь "зоопарка". Прошло пять лет — воз и ныне там. В другой, белорусской компании, руководство, наоборот, испугалось прорывной идеи с ДРАКОНом и сделало ставку на тихого исполнителя с дипломом по BPMN.
Это парадокс "прогрессивного консерватизма". Руководитель, не зная о существовании реальных альтернатив, вынужден выбирать из того, что ему предлагают "эксперты". Он шарахается из стороны в сторону: то слепо доверяет модному и "прогрессивному", то консервативно держится за привычное. В обоих случаях он не управляет ситуацией, а плывет по течению, которое создают для него другие.
Три шага к выздоровлению: рецепт настоящего процессного управления
Так как же разорвать этот порочный круг? Путь к настоящему процессному управлению состоит из трех логичных шагов.
Шаг 1: Навести порядок в мыслях (ДРАКОН).
Первый шаг — перестать говорить на разных языках. Нужно внедрить единый, визуально понятный всем язык для описания процессов. ДРАКОН — идеальный инструмент, чтобы превратить хаос в головах в кристально чистые и однозначные схемы.drakonpro
Шаг 2: Навести порядок в системах (АСис).
Понятные схемы не так эффективны, если они исполняются в "зоопарке" из десятков программ. Платформа АСис (asys.ru), в отличие от SAP/ERP, построена не на "колодцах", а на единой метамодели. Она не автоматизирует хаос, а заменяет его целостным цифровым двойником вашей компании.asys+1
Шаг 3: Обрести интеллект (ИИ).
И вот когда у вас есть порядок и целостность, вы можете сделать решающий шаг — вплести внутрь этой системы Искусственный Интеллект. ИИ, получая на вход чистые и структурированные данные из АСис, превращается в настоящий "мозг" компании, который способен анализировать, прогнозировать и автоматизировать рутинные задачи.
Венец творения: управляемая холакратия
До сих пор мы говорили об отдельных компонентах. Но настоящая магия происходит, когда они объединяются. Эта связка — ДРАКОН + АСис + ИИ — это не просто набор инструментов. Это инженерный фундамент для построения настоящей, работающей холакратии.
Все управленцы сегодня мечтают о холакратии — гибкой системе, где нет начальников, а есть самоуправляемые команды. Но эта мечта всегда разбивалась о реальность: без жестких правил и инструментов холакратия превращается в анархию. Так вот, предлагаемая связка — это и есть тот самый набор правил и инструментов.rb+1
ДРАКОН — это "Конституция" холакратии. Это единый и понятный всем язык, на котором описываются "правила игры" — процессы и зоны ответственности. Он обеспечивает ту самую прозрачность, без которой холакратия невозможна.unisender
АСис — это "Государственный аппарат" холакратии. Это платформа, которая берет эту "конституцию" (ДРАКОН-схемы) и обеспечивает ее исполнение. Она становится единым планировщиком и контролером, гарантируя, что все самоуправляемые "круги" работают синхронно и не тянут компанию в разные стороны.
ИИ — это "Правительство" холакратии. Это интеллект, который, опираясь на "конституцию" и данные от "госаппарата", принимает тактические решения, находит "узкие места", оптимизирует ресурсы и предлагает новые, более эффективные "законы".
Важно понимать: максимальный, революционный эффект достигается только при объединении всех трех инструментов. Но даже внедрение одного из них уже дает колоссальный прирост эффективности на своем уровне.
Начните с ДРАКОНа — и вы получите ясность в процессах и коммуникации.
Внедрите АСис — и вы избавитесь от "зоопарка систем" и получите целостное управление.
Добавьте ИИ — и вы получите мощнейший инструмент для аналитики и оптимизации.
Эта связка — это эволюционный скачок, который позволяет построить бизнес-организм, о котором мечтали идеологи холакратии: гибкий, адаптивный и самоуправляемый, но при этом абсолютно прозрачный и нацеленный на результат.
Это недорого, потому что вы избавляетесь от "зоопарка". Это супер-эффективно, потому что вы управляете реальными процессами. И это прямой путь к созданию думающей, адаптивной компании.
Будущее управления уже здесь. Вопрос лишь в том, готовы ли вы его увидеть.
Доказательная база и полезные ссылки:
¹ ³ Moody, D. L. (2011). "Why a Diagram is Only Sometimes Worth a Thousand Words: An Analysis of the BPMN 2.0 Visual Notation". В этом анализе Муди идентифицирует более 100 уникальных символов в BPMN 2.0 и доказывает, что их визуальная схожесть ведет к ошибкам восприятия.
² Cowan, N. (2001). "The magical number 4 in short-term memory: A reconsideration of mental storage capacity". Фундаментальная работа в когнитивной психологии, показывающая, что реальная емкость рабочей памяти человека составляет 4±1 элемента.
⁴ Leopold, H., Mendling, J., & Günther, A. (2015). "What we can learn from Quality Issues of BPMN Models from Industry". Исследование, выявляющее массу проблем с качеством и пониманием BPMN-моделей в реальной практике.
⁵ Johansson, L. O., Wärja, M., & Carlsson, S. (2013). "An evaluation of business process model techniques...". Работа, отмечающая, что формальные нотации, такие как BPMN и UML, создают коммуникационный барьер между бизнесом и IT.
Официальный сайт языка ДРАКОН: drakon.su
Официальный сайт платформы АСис: asys.ru
Историческая справка о системе ОГАС (ru.wikipedia.org/wiki/ОГАС).
Историческая справка о системе ТРИЗ ( matriz.org).
Исследования проблем ERP-систем (Ощепков В.М., Лохматова В.А. "Проблемы внедрения ERP на предприятиях").
Комментарии (6)
zababurin
24.08.2025 14:06А сколько времени потребуется на внедрение ?
Например...
Я собрал проект на коленке тестовый(1 html страничка) тема сложная и не известная мне. Делел с помошью ии.
Пока собирал понял как часть работает.
ИИ уже больше на данный момент не может увеличивать объем странички. Она огромная.
Я делаю рефакторинг и разбиваю на компоненты. Приэтом появляются баги (рефакторинг с ии ужасная идея, лучше делать сразу правильно, но в начале не знаешь что такое правильно)
Но эти компоненты сами становятся огромными и я делаю структуру для не обработаной части первого html. Получается уже два набора компонентов. Одни в одном файле, вторые уже структурированные.
ИИ добавляет еще больше багов.
В итоге, страничку я первую собрал за 1 день, рефакторинг ее 2 недели.
Сейчас я следующий проект, есть еще одна страничка, я буду делать уже с учетом опыта, который получил. Думаю сокращу время до 1 недели.
К чему я это.
То что я описал, происходит на любых уровнях, не только в разработке. Этот кейс появляется, когда в начале результат который хочешь получить имеет очень большую неопределенность. Это какие то исследования, что то новое.
Какие инструменты есть в вашей системе, которые позволяют даже при высокой неопределенности, не уходить в рефакторинг, а позволять последовательно проводить анализ паралельно с синтезом полученных результатов ?
SergiiKol Автор
24.08.2025 14:06Здравствуйте! Спасибо вам огромное за такой глубокий и, самое главное, до боли знакомый каждому разработчику и аналитику комментарий. Ваша история про "коленочный проект" и последующий двухнедельный рефакторинг — это идеальная, просто хрестоматийная иллюстрация той самой проблемы, о которой я пытался рассказать в статье.
Вы абсолютно правы: эта беда — "сначала делаем, потом переделываем" — универсальна. Она возникает везде, где есть высокая неопределённость. Вы совершенно точно сформулировали главный вопрос: какие инструменты позволяют проводить анализ параллельно с синтезом, чтобы не увязнуть в бесконечном рефакторинге?
В связке, которую я предлагаю, за это отвечают все три компонента, но каждый на своём уровне.
1. ДРАКОН: "Прививка от рефакторинга" на уровне логики
Ваша проблема с ИИ, который "уже больше не может увеличивать объём странички", — это классический пример того, как сложность выходит из-под контроля. Вы интуитивно начали делать то, что ДРАКОН заставляет делать принудительно.
Принудительная декомпозиция: Правило "силуэт" в ДРАКОНе не дало бы вам создать одну огромную схему. Оно бы физически заставило вас сразу, на самом первом этапе, разбить большую задачу на маленькие, понятные куски (ваши "компоненты"). Вы бы не смогли нарисовать схему, которая не помещается на один экран.
Чёткие связи вместо "спагетти": ДРАКОН заставляет сразу продумывать, как эти "компоненты" будут общаться друг с другом. Вы бы не смогли просто накидать код, а потом думать, как его структурировать. Вы бы сначала нарисовали "скелет" взаимодействия, и только потом начали бы "наращивать мясо" на каждую кость.
То есть, ДРАКОН — это инструмент, который заставляет вас делать "правильно" с самого начала, даже когда вы ещё "не знаете, что такое правильно". Он не даёт неопределённости превратиться в хаос.
2. АСис: "Фундамент, который не надо перестраивать"
Представьте, что вы строите дом из LEGO.
Если у вас обычный набор, то каждая деталь уникальна. Вы построили стену, а потом решили сделать её шире — вам придётся всё разобрать и искать новые, подходящие детали. Это и есть ваш двухнедельный рефакторинг.
А теперь представьте, что у вас есть «волшебный» набор LEGO от АСис. В нём все кирпичики стандартные, 2х4. И все они умеют соединяться друг с другом без всяких хитрых переходников.
Вам не надо думать о деталях. Вы просто берёте готовые кирпичики и строите. Не нужно каждый раз изобретать новую деталь для новой задачи. Это и есть единая модель данных.
Всё подходит ко всему. Вы можете отломить кусок стены в одном месте и прилепить его в другом, и он идеально подойдёт. Связи между кирпичиками (компонентами) уже заложены в самой их природе.
То есть, АСис даёт вам такой набор «стройматериалов», с которым не нужно каждый раз всё перестраивать с нуля. Вы можете спокойно менять «комнаты» и достраивать «этажи», не боясь, что весь ваш «дом» развалится. Вы просто работаете с готовыми блоками, а не воюете с их несовместимостью.
3. ИИ: "Штурман, который видит рифы"
А Искусственный Интеллект в этой связке выступает в роли умного штурмана, который работает с уже структурированными данными.
Анализ "на лету": Получая данные из АСис в реальном времени, ИИ может сразу подсвечивать вам проблемы: "Смотри, вот этот компонент стал слишком сложным, его пора делить" или "Вот здесь у тебя намечается "узкое место", которое через неделю затормозит всю систему".
Помощь в синтезе: Он может не просто критиковать, а предлагать решения, основанные на анализе тысяч похожих ситуаций: "Судя по твоей ДРАКОН-схеме, вот этот новый компонент лучше всего построить вот по такому шаблону, который мы уже использовали в другом проекте".
Итог
Ваш вопрос — самый главный в современном управлении и разработке. И ответ, который предлагает моя система, таков:
ДРАКОН не даёт хаосу зародиться на уровне идеи.
АСис не даёт хаосу просочиться на уровень архитектуры.
ИИ помогает бороться с хаосом на уровне исполнения и эволюции.
Эта связка позволяет вам двигаться итерационно, постоянно анализируя и синтезируя, но при этом не проваливаясь в "долговую яму" рефакторинга. Вы строите систему из стандартных, предсказуемых блоков, и каждый новый блок делает систему не сложнее, а богаче.
SergiiKol Автор
24.08.2025 14:06Знаете, я тут перечитал наш с вами диалог и понял, что в своём первом ответе увлёкся объяснением "как", но совершенно упустил ваш самый главный и самый практический вопрос: "А сколько времени потребуется на внедрение?".
Это моё упущение, и вопрос настолько важный, что заслуживает отдельного, прямого ответа.
Ключевая идея здесь — вы не останавливаете завод на год, чтобы всё перестроить. Вы начинаете с самого больного места и получаете результат здесь и сейчас. Это эволюция, а не революция.
1. ДРАКОН: от пары дней до нескольких месяцев
Здесь всё зависит от масштаба задачи.Простой процесс с одним человеком: Описать его можно буквально за 1-2 дня.
Сложный процесс отдела: Если нужно опросить несколько человек и учесть много деталей, это займёт 1-2 недели.
Сквозной процесс всей компании: Описание "основного бизнес-процесса" — это уже серьёзная работа на 2-3 месяца, а то и больше.
И здесь важно понимать, как идёт сама работа. По моему опыту, эффективная сессия с одним человеком или группой над схемой — это 60-90 минут. Потом у всех начинается "плавление мозгов", и продуктивность падает до нуля. Нужен перерыв. Пытаться выжать больше за один присест — контрпродуктивно.
2. АСис: начинать можно почти с колёс
Внедрение этой системы — не классический долгий проект.Старт "в режиме творчества": Вам не нужно заранее строить шаблоны процессов. Можно зарегистрировать пользователей в облаке и начать работать в тот же день: ставить задачи, планировать результаты, общаться в мессенджере.
Параллельное создание процессов: Уже внутри работающей системы вы можете создать проект "Построение типовых процессов" и постепенно, без остановки основной деятельности, описывать и автоматизировать свои схемы.
То есть, формальное "внедрение" как таковое отсутствует. Вы начинаете пользоваться системой сразу, а порядок наводите постепенно.
3. ИИ: эффект гораздо быстрее, чем принято думать
Современные ИИ-модели не требуют полугодовой "раскачки" на идеально чистых данных.Первые подсказки — почти сразу: Как только в системе появляются первые структурированные задачи и данные (из ДРАКОНа и АСис), ИИ уже может начать находить простые зависимости и подсвечивать аномалии. Это вопрос нескольких недель, а не месяцев.
Значимый эффект — 1-3 месяца: Чтобы ИИ начал давать действительно ценные советы по оптимизации и прогнозированию, ему нужно накопить определённый объём данных. Но речь идёт скорее о 1-3 месяцах активной работы системы, а не о полугоде.
zababurin
24.08.2025 14:06А есть какие нибудь примеры посмотреть как это выглядит ?
Вы про холократию писали. Есть ли что то похожее на это ?
https://github.com/holacracyone/Holacracy-Constitution-5.0-RUSSIAN
JBFW
Вы рисуете правильную схему, выстраивание по ней взаимодействие, все работает как единый организм, а потом принимают закон, отсекающий четверть вашего бизнеса, но дающий новые возможности - и вы встраиваете костыль.
Потом ещё один. И ещё. И пару заплаток.
От первоначальной стройной схемы остаются обрубки, ведущие в никуда.
А в это самое время кто-то, у кого просто автоматизирована работа отдельных участков, что-то выбросил и что-то добавил, и у него все работает.
Классический выбор "монолит против микросервисов"
SergiiKol Автор
Здравствуйте! Спасибо вам огромное за этот комментарий. Вы попали в самую суть вечного спора и главную боль любого архитектора: стройность против гибкости. И ваша аналогия с «монолитом против микросервисов» — идеальна.
Вы абсолютно правы. Если понимать мою идею «единого организма» как создание жёсткого, монолитного монстра, то вы на 100% правы: первый же серьёзный внешний удар (новый закон, уход поставщика, смена технологии) заставит нас городить «костыли», и вся красивая схема рассыплется. Это путь в никуда.
Но дьявол, как всегда, в деталях. Когда я говорю о «едином организме», я имею в виду не монолит, а скорее экосистему.
Представьте себе не единый механизм, а муравейник. У него есть общая, понятная всем цель и единые правила взаимодействия (феромоны — наш аналог ДРАКОН-схем). Но при этом каждый муравей (или группа муравьёв) — это автономный «микросервис». Он выполняет свою чёткую функцию: одни строят, другие ищут еду, третьи защищают.
Что происходит, когда меняется внешняя среда? Например, старый источник еды исчез, но появился новый.
В «монолите» нам пришлось бы остановить и перестроить весь муравейник.
В «экосистеме» же группа «добытчиков» просто переключается на новую задачу. Они получают новую, простую и понятную «ДРАКОН-схему»: «Теперь ходим за едой не налево, а направо». Остальной муравейник продолжает работать как ни в чём не бывало. Связи между ними не рвутся, потому что они изначально гибкие и построены на общих правилах.
Моя идея не в том, чтобы зацементировать бизнес в одной идеальной схеме. А в том, чтобы описать на едином, понятном всем языке взаимодействие между отдельными, гибкими частями. И когда приходит время перемен, мы не ломаем всю систему, а просто достаём схему конкретного «микросервиса» (например, «Процесс работы с поставщиком N»), быстро её перерисовываем и запускаем в работу.
Ваш комментарий невероятно ценен, потому что он заставил меня лучше сформулировать свою мысль. Проблема не в «единой схеме», а в том, как мы её понимаем: как жёсткий чертёж или как гибкую карту взаимодействия автономных частей. Спасибо вам