Меня зовут Сергей Колесников. И если оглянуться на мои 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 на предприятиях").

Комментарии (2)


  1. JBFW
    24.08.2025 14:06

    Вы рисуете правильную схему, выстраивание по ней взаимодействие, все работает как единый организм, а потом принимают закон, отсекающий четверть вашего бизнеса, но дающий новые возможности - и вы встраиваете костыль.

    Потом ещё один. И ещё. И пару заплаток.

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

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

    Классический выбор "монолит против микросервисов"


    1. SergiiKol Автор
      24.08.2025 14:06

      Здравствуйте! Спасибо вам огромное за этот комментарий. Вы попали в самую суть вечного спора и главную боль любого архитектора: стройность против гибкости. И ваша аналогия с «монолитом против микросервисов» — идеальна.

      Вы абсолютно правы. Если понимать мою идею «единого организма» как создание жёсткого, монолитного монстра, то вы на 100% правы: первый же серьёзный внешний удар (новый закон, уход поставщика, смена технологии) заставит нас городить «костыли», и вся красивая схема рассыплется. Это путь в никуда.

      Но дьявол, как всегда, в деталях. Когда я говорю о «едином организме», я имею в виду не монолит, а скорее экосистему.

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

      Что происходит, когда меняется внешняя среда? Например, старый источник еды исчез, но появился новый.

      • В «монолите» нам пришлось бы остановить и перестроить весь муравейник.

      • В «экосистеме» же группа «добытчиков» просто переключается на новую задачу. Они получают новую, простую и понятную «ДРАКОН-схему»: «Теперь ходим за едой не налево, а направо». Остальной муравейник продолжает работать как ни в чём не бывало. Связи между ними не рвутся, потому что они изначально гибкие и построены на общих правилах.

      Моя идея не в том, чтобы зацементировать бизнес в одной идеальной схеме. А в том, чтобы описать на едином, понятном всем языке взаимодействие между отдельными, гибкими частями. И когда приходит время перемен, мы не ломаем всю систему, а просто достаём схему конкретного «микросервиса» (например, «Процесс работы с поставщиком N»), быстро её перерисовываем и запускаем в работу.

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