Спасибо за ваш комментарий - он очень содержательный и показывает, что вы глубоко разбираетесь в теме. Вы правы : инструмент сам по себе не решает проблему управления. Если руководитель не готов вникать в логику процессов, ни ДРАКОН, ни BPMN не спасут. Именно поэтому я в статье подчёркиваю: ДРАКОН - это не ИС, а часть замкнутого цикла управления, где схема становится поводом для принятия решений.
Теперь по пунктам.
1. BPMN интуитивно понятен? Для кого-то - да. Особенно если человек работает с ним годами. Но в моей практике бизнес-владельцы и руководители отделов не читают BPMN без перевода. Они доверяют аналитику, но не видят своих собственных процессов. А в ДРАКОНе они описывают самостоятельно, потому что его структура ближе к естественному мышлению. Я не утверждаю, что BPMN плох - он просто решает другую задачу: документирование для IT, а не совместное проектирование с бизнесом.
2. Про стоимость владения Вы абсолютно правы: Camunda Modeler бесплатен. В статье я действительно смешал моделирование и исполнение - это моя ошибка, и я благодарен, что вы её указали. Однако даже при использовании только редактора BPMN (без BPMS), компании всё равно нанимают full-time аналитика, потому что бизнес не может работать с этой нотацией напрямую. В случае с ДРАКОНом координатор (часто внутренний сотрудник) помогает руководителю оформить его знания - и дальше схема живёт внутри компании без постоянного привлечения экспертов. Экономия здесь не в лицензиях, а в снижении зависимости от внешних специалистов.
3. McKinsey (2025) Цифры 20-30% - это обобщение нескольких источников, включая отчёт Process Excellence Network (2024), BCG и внутренние исследования наших партнёров. Прямой ссылки на McKinsey с такой формулировкой действительно нет - я допустил упрощение для наглядности. Спасибо, что обратили внимание: в будущих редакциях уточню источник или уберу упоминание.
4. «Зачем новое колесо?» Потому что старое не катится по грязи реального бизнеса. BPMN отлично работает в корпорациях с процессным офисом, но в среднем бизнесе (50–1000 чел.) важна скорость, вовлечённость и минимальная бюрократия. ДРАКОН - не конкурент BPMN, а альтернатива на этапе до технической реализации: когда нужно быстро, вместе с владельцем процесса, понять, что делать, прежде чем решать, как это автоматизировать.
Благодарю Вас за столь глубокий и стратегический взгляд! Ваш комментарий - это не просто "накипь", а точнейший диагноз системного кризиса, который я наблюдал в каждой компании, с которой работал. И он поразительным образом описывает мою собственную эволюцию.
Вы абсолютно правы во всех четырех тезисах, и мои статьи - это тактическое подтверждение вашей стратегической концепции:
Про "точку бифуркации" и "дохлых лошадей" - я видел это в каждой компании:
"BPMN чудовищно перегружен. Стандарт предлагает нам выучить более сотни разных значков... А BPMN предлагает нам интеллектуальное жонглирование десятками. Мозг от такого просто отключается" [1]
"ERP-система - это как хирургический скальпель. В руках опытного хирурга... но сам по себе скальпель никого не лечит. Если ваши бизнес-процессы - это клубок неформальных договоренностей, то новая система этот клубок не распутает. Она его усилит и забетонирует" [2]
Про сопротивление революции - я прошел это на собственной шкуре:
"Стратегический уровень так и не был принят высшим руководством... Мне удавалось добиваться ROI 137% на отдельных процессах, но когда я пытался говорить о смене парадигмы управления в масштабах всей компании, я упирался в стену непонимания" [1]
"В СТО Фильтр директор, очарованный 'прогрессивной' IT-командой, выбрал путь 'зоопарка'. Прошло пять лет - воз и ныне там" [3]
Про саботаж IT-отрасли - это моя ежедневная боль:
"Бизнес-модель франчайзинга '1С'... Чувствуете, где заложен конфликт интересов? '1С' продает 'коробки', а не успех" [2]
"Встроенный BPM в '1С' - это не фундамент для построения адаптивной, процессно-ориентированной компании. Это удобный 'таск-менеджер' для автоматизации примитивных административных маршрутов" [2]
Про "автоматизацию хаоса" - это было моим кошмаром:
"Попытка автоматизировать то, что и так работает криво, закрепляя в коде лишние согласования и дублирующие друг друга действия" [2]
"Мы уже поняли простую истину: покупка нового софта не решит проблемы, если сами бизнес-процессы не организованы. Автоматизация хаоса - это просто оцифровка беспорядка" [2]
Мой тактический ответ через ДРАКОН стал "шлюзом" в вашу стратегию, но я понял, что этого недостаточно. Именно поэтому я являюсь соратником Олега Захарчука и платформы АСис, находясь в прямой связи с разработчиком.
Платформа АСис - это тот самый стратегический ответ на все четыре проблемы, которые вы обозначили:
В своих статьях я прихожу к тому же выводу, что и вы:
"Платформа АСис, в отличие от SAP/ERP, построена не на 'колодцах', а на единой метамодели. Она не автоматизирует хаос, а заменяет его целостным цифровым двойником вашей компании" [3]
"Эта связка - ДРАКОН + АСис + ИИ - это инженерный фундамент для построения настоящей, работающей холакратии" [3]
Таким образом, ваша стратегическая концепция и моя тактическая практика сошлись в одной точке:
Вы дали диагноз и стратегический императив. Я предлагаю тактический инструмент (ДРАКОН) для "первой помощи" бизнесу. А платформа АСис предлагает готовую технологическую основу для полномасштабного перехода на новую парадигму.
Я понимаю, что мои отдельные победы с ДРАКОНом были лишь симптоматическим лечением. Настоящее исцеление бизнеса требует именно того системного подхода, который предлагает АСис и который вы так точно описали.
Именно поэтому я не просто сторонний наблюдатель, а соратник этой платформы. Потому что только такие целостные решения способны сломить сопротивление системы и дать бизнесу шанс на выживание в новых условиях.
Спасибо за честную и профессиональную полемику. Действительно, наше расхождение - не в «процентах», а в самих типах проблем, с которыми приходится сталкиваться в разных отраслях и культурах управления.
Ваш опыт с производственными «пожарами» - крайне показателен для промышленности, где кризисы часто возникают из-за объективных внешних факторов: санкций, сбоев поставок, износа оборудования. В таких условиях ключевым инструментом нередко становится экстренное управление, быстрое принятие решений, иногда - «ручное» вмешательство без длительной формализации. Методологии вроде Lean, ISO 9000, IATF 16949 и технологические карты здесь доказали свою эффективность и поддерживаются всей структурой предприятия.
В моём опыте, связанного преимущественно с IT и корпоративным управлением, действительно преобладают «туманные» ситуации: размытые зоны ответственности, недооформленные процессы, расслоение на неформальные договорённости и устные сценарии. Инструменты визуализации типа ДРАКОН или BPMN хорошо работают именно там, где процессы не описаны - для согласования действий, выявления пробелов, фасилитации диалога между отделами.
Но важно признать - именно контекст определяет инструмент:
Если речь идёт о классическом внешнем кризисе - перебои, санкции, ломка производственной цепи - формальные схемы и визуализация вторичны, приоритет за экстренными мерами, директивным управлением и поддержкой нормативных стандартов.
Если речь о внутреннем недопонимании, затяжных конфликтах между отделами либо корпоративной «невидимости» процессов, то визуализация или совместная разработка схем часто помогает прояснить зоны ответственности и снизить накал противоречий.
В производстве многоуровневые стандартные методы работают, потому что годы практики отшлифовали их под реальные боли отрасли. В IT или в гибких B2B-структурах порой не хватает даже элементарной согласованности, а потому схемы вроде ДРАКОН становятся временным «протезом», но не заменой для настоящей системы управления качеством и операциями.
Поэтому на практике мой совет прост: сначала честная диагностика - какая у нас ситуация? Фундаментальные внешние ограничения? Хронический конфликт целей? Или же туманная неясность? И только после этого - выбор подхода: стандарты ISO/Lean для систем с устоявшейся структурой, визуализация и фасилитация - для гибридных и рассогласованных систем.
Спасибо за остроумную и профессиональную дискуссию - такие споры не дают расслабиться и расширяют взгляд на реальную природу организационных болей.
Спасибо за это уточнение. Вы подняли дискуссию на принципиально новый уровень, и я с вами полностью согласен в основной premise.
Вы абсолютно правы: если фундамент - система управления - треснул или изначально был построен на устаревших принципах, то никакое «описание» этого кривого фундамента не выровняет здание. Максимум - позволит аккуратнее спотыкаться на ровном месте.
Вы ставите вопрос о разных уровнях проблем и решений:
Стратегический / Парадигмальный уровень (разработка «Теории относительности» для бизнеса). Это уровень создания и радикального переосмысления таких систем, как Lean, TOC, Agile. Здесь работают гении, исследователи и архитекторы бизнес-процессов. Инструмент здесь - глубокий анализ, научный метод, прорывные идеи. Ни ДРАКОН, ни BPMN на этом уровне не работают - они для этого и не создавались.
Тактический / Операционный уровень (применение законов физики для расчета моста). Это уровень внедрения, адаптации и ежедневного исполнения этих парадигм. Вот здесь языки визуализации и находят свою нишу.
Моя статья и мой инструмент — про второй уровень. Про то, как донести гениальную, но сложную «Теорию относительности», до рядового инженера, технолога и кладовщика так, чтобы они ее не только поняли, но и смогли применить без искажений.
Таким образом, вы правы в главном: ДРАКОН - не замена Lean или ISO. Это - «переводчик» и «усилитель» их принципов на операционном уровне.
И ваша оценка в 95/5% вероятно, точна для промышленности. Я благодарен вам за эту корректировку. Она заставляет задуматься: возможно, IT-консультант, предлагающий «описание», должен начинать с вашего вопроса: «А ваша система управления в принципе адекватна текущим вызовам? Или нам нужно начинать не с описания, а с проектирования нового фундамента?».
Спасибо, что своим комментарием вы превратили узкотехническую дискуссию в стратегическую. Это бесценно.
Вы правы: диагностика должна быть первой. И если она показывает, что вы в ситуации пожара, токсичной среды или тотального хаоса - метод интервьюирования и ДРАКОН становятся не просто бесполезными, а опасными. Такие условия требуют совершенно иного подхода.
Но в подавляющем большинстве случаев - в тех 95% бизнеса, где система не понятна, а подразделения воюют из-за недопонимания - отказ от AS-IS равносилен работе с закрытыми глазами. Это самый быстрый путь от хаоса к порядку.
Моя логика теперь выглядит так:
Диагностика: что у нас? Пожар, туман или токсин?
Выбор метода: если туман → ДРАКОН, если пожар → диктатура, если токсин → внешний аудит.
Действие:
Для тумана: кристаллизация знания через визуализацию
Для пожара: тушение кризиса немедленными решениями
Для токсина: очищение культуры от источника давления
Если изучают к примеру инфекционные болезни, то вольно-невольно начинают получать сведения о том, как они распространяются, что их усиливает.
Всё верно многих евангелистов это серьёзно беспокоит. Но беспокойство в основном сконцентрировалось на Китайской программе. Не вижу вариантов международного контроля в данной ситуации бешенной гонки... Между США и Китаем. И к тому же правители на старушке Терре полностью сумашедшие и похожи на правителей Торманса из Ефремова.
Спасибо за статью. Отлично описана ситуация когда ресурсы руководство выделить не готово в принципе. Честно говоря не удивительно, много людей попадают постоянно в такую ситуацию. По моему скромному мнению с руководством надо договариватся на берегу, то есть это проблема что вы сами не видели к чему это всё приведет (я про результат), теперь у вас есть бесценный опыт, кейс и всё в итоге у вас будет хорошо. Чего вам и желаю.
Спасибо за вопрос. Он настолько важен, что сердиться на него - бессмысленно. Вы абсолютно правы в главном: слепое следование догме «сначала опиши AS-IS» - это прямой путь к автоматизации хаоса.
Я использую ДРАКОН не как религию, а как инструмент. Это язык, рожденный в Институте Пилюгина для космической программы «Буран», где цена ошибки - катастрофа. Его сила - в принудительной ясности. Но никакой язык не отменяет необходимости думать.
Вы спрашиваете, где описание «как есть» - вредная трата времени. Вот три реальных кейса из моей практики:
Когда описывать нечего. Компания после ухода ключевых сотрудников. Процессы живут в головах двух стажеров. Любое интервью фиксирует «карту пустоты». Вместо этого мы сразу строили TO-BE - простой и рабочий MVP, который и стал новой реальностью.
Когда описание - самообман. Процесс давно стал ритуалом. На интервью вам рисуют красивую формальную схему, а реальная работа идет по негласным договоренностям. Описание такого AS-IS - это легитимация вранья. Мы шли другим путем - «теневым аудитом», наблюдая и фиксируя реальность, а не слова.
Когда нужен скачок, а не шаг. Компания кардинально меняет бизнес-модель. Изучение того, как они копали ямы лопатами, бесполезно для проектирования экскаватора. Здесь нужен чистый лист, а не ремонт старого фундамента.
Так зачем тогда вообще нужно описание?
Не для того, чтобы слепо верить интервью и фиксировать хаос. А для того, чтобы создать общую зону модернизации.
Когда начальник отдела видит свой процесс, выложенный на лаконичной схеме ДРАКОНа, происходит "чудо": он САМ начинает видеть свои же косяки. Проблема, которая была смутным ощущением в его голове, становится осязаемой и неустранимой. Это запускает правильный импульс - не «давайте задокументируем этот бардак», а «так, сейчас же все переделаем!».
Вывод прост. Не язык определяет метод, а задача определяет инструмент.
В 95% случаев бизнес - это «туман», где описание AS-IS - единственный способ этот туман развеять и начать диалог.
В 5% случаев - это «пожар» или «революция», где нужно не описывать, а тушить и строить.
Ваша критика бьет точно в цель: догматики, продающие описание как панацею, действительно опасны. Но отказ от диагностики под предлогом «здесь хаос» - это капитуляция. Истина, как всегда, в компетенции различать, где ты находишься - в тумане или в горящем здании.
Отличное обострение. Вы затронули серьёзный философский вопрос.
Но чтобы объяснить мою позицию - давайте сначала договоримся об определениях.
Что такое ХАОС? Наиболее рабочим определением можно считать то, что следует из работ Генриха Миллера:
«Хаос - это не отсутствие порядка. Это порядок, который человек не может удержать в сознании».
(Напомним: кратковременная память вмещает 7±2 элемента. Превысите - и мозг перестаёт видеть систему, включая импровизацию и «обходные пути».)
Из вашего комментария следует:
«Описывать ХАОС, чтобы потом “управлять” ХАОСОМ - так себе результат», «Это манипуляция».
Вы справедливо замечаете:
«Без компетенции гармонизации процессов любой язык визуализации - обезьяна с гранатой!»
Я с вами полностью согласен.
Но позвольте задать встречный вопрос: → Как приобрести эту компетенцию - не описав хаос сначала?
Нельзя гармонизировать то, что существует лишь в виде
тумана взаимных претензий,
скрытых устных договорённостей,
«исторически сложившихся» костылей,
и вечного диалога: «Я думал, ты сделал».
Что происходит при описании в ДРАКОНе?
Мы не превращаем хаос в космос автоматически. Но описание становится зоной модернизации: → Мы кристаллизуем хаос в набор конкретных, видимых проблем. → Осознав процесс, мы уже не можем считать его хаосом- это карта.
Пусть мутная. Пусть неполная. Но - карта. А с картой можно:
увидеть, где слабые зоны,
понять, где точки приложения силы,
договориться - не в пустоте, а над одной схемой.
Понятый хаос перестаёт быть хаосом.
Почему ДРАКОН, а не BPMN?
Не потому, что BPMN «плох». А потому, что он часто фиксирует сложность- и остаётся в зоне ответственности аналитика. ДРАКОН же - построен на законах когнитивной эргономики (Миллер, Хик, гештальт) - принудительно вскрывает нестыковки и делает их очевидными для всех:
для менеджера,
для кладовщика,
для программиста,
для руководителя.
Это - не документация. Это фасилитация диалога.
Итог
Ваша критика абсолютно верна - если считать описание конечной точкой.
Но в моём подходе - она отправная. → Сначала - диагноз (карта «как есть»), → Потом - лечение (гармонизация «как будет»).
Без первого - второе действительно превращается в шаманство.
Рекомендации из 2 ключевых шага, чтобы процессы начали работать:
Рисуем реальность, а не идеал Не "как должно быть", а "как есть - со всеми костылями и обходными путями". Когда в одной из компаний описали реальный процесс приёма клиента, выяснилось: 40% заказов ждали кладовщика больше 15 минут, а менеджеры часто "думали за других". Схема стала объективным зеркалом - с картинкой нельзя спорить. (ну и как вы наверное уже догадались, возникнет вопрос так дальше жить нельзя, быстрее всего немного позднее возникнет новая схема "как будет" )
Чёткие точки передачи ответственности В схеме указываем не просто "передать", а "Иван должен подтвердить выполнение в течение 1 часа". Это убирает "я думал, ты сделал" - теперь есть чёткий критерий: "не получил подтверждение → процесс прерван".
Этих двух шагов достаточно, чтобы процессы перестали быть фикцией. Вы создаёте прозрачность, где работать по схеме становится проще, чем в хаосе.
Согласен, вопрос сложный. Дело не в Драконе, а в подходе. Проблема ваших кейсов: процессы есть, но они не работают в реальности.
Дракон помогает потому, что: Вместо текстовых инструкций - визуальная схема, где видно ВСЕ условия и решения. Все участники процесса смотрят на одну схему, а не интерпретируют каждый по-своему. На схеме сразу видно, где зоны ответственности и точки передачи
В вашем случае с 50 сотрудниками: когда человек "тупит" с инструкцией, в Драконе он видит не текст, а наглядный маршрут со всеми "если/то". Он просто не сможет затупить :)
В случае с 100 сотрудниками в Битрикс: схема прекращает споры "кто виноват", потому что все видят единую логику процесса.
Предложение: возьмите один проблемный процесс и опишите его в Драконе вместе с сотрудниками. Уже на этом этапе станет ясно, где именно система ломается. Это не про еще больше документов, а про то, чтобы наконец сделать процессы понятными.
Вы смешиваете фундаментальную науку и прикладные испытания.
1. Когнитивная эргономика - это точная наука. Её законы подтверждены тысячами экспериментов:
Миллер (1956) - объём рабочей памяти
Хик (1952) - время реакции при выборе
Гештальт-психология (1920-е) - принципы восприятия форм
Паронджанов не изобретал эти законы - он применил их к проектированию языков. Требовать новых исследований для ДРАКОНа - как требовать перепроверки законов физики для каждого нового самолёта.
2. Лабораторией ДРАКОНа стали критические системы:
«ДРАКОН разработан совместно Роскосмосом и РАН как обобщение опыта создания корабля "Буран"... Успешно используется в проектах "Морской старт", "Фрегат", "Протон-М"» (Паронджанов, раздел о практическом применении)
В таких проектах не используют непроверенные методы. Факт успешного применения в системах с нулевой терпимостью к ошибкам - лучшее доказательство эффективности.
3. Ваш запрос игнорирует главное: ДРАКОН - это инженерная реализация известных законов. Как самолёт строится на законах аэродинамики, так ДРАКОН построен на законах когнитивной науки. И так же, как самолёт летает без "слепых испытаний против воздушных шаров", ДРАКОН работает в реальных проектах.
Вы продолжаете мыслить в парадигме старого подхода. Паронджанов прямо отвечает на ваш вопрос:
«Пересечения линий? - боже упаси! ... ДРАКОН выгодно отличается тем, что его графический узор имеет строгое математическое и когнитивно-эргономическое обоснование и подчиняется жестким и тщательно продуманным правилам»
Ваше требование "показать все связи на одном чертеже" — это и есть тот самый визуальный хаос, против которого борется ДРАКОН.
ДРАКОН не показывает связи - он показывает архитектуру. Если у вас множество разнородных обращений к БД - значит, у вас архитектурная проблема, и ДРАКОН принуждает вас решить её через:
Четкие интерфейсы (иконы-вставки)
Декомпозицию (отдельные силуэты)
Явные контракты между модулями
Вместо хаотичной "паутины связей" вы получаете систему с прозрачными взаимодействиями - именно то, что нужно для реальной разработки, а не для создания "красивых, но бесполезных схем".
Прямые ответы на ваши вопросы уже даны в книге Паронджанова.
На ваш первый вопрос о «понимании без надписей» автор поясняет:
«Синтаксис ДРАКОНА запрещает любые двусмысленности. Алгоритм должен быть записан так, чтобы его правильность проверялась автоматически, взглядом»
то есть гарантируется именно структурная, а не семантическая ясность.
На второй вопрос о «неявных циклах» в книге указано:
«Любое нарушение логической целостности становится зрительно очевидным... ДРАКОН не позволяет ошибке спрятаться в хаосе».
Ваши возражения не опровергают ДРАКОН — они иллюстрируют его принцип: он не исправляет логику, но принудительно делает архитектурные flaws визуально кричащими.
Вывод: ДРАКОН это философия «когнитивного щита», а не «серебряной пули».
Спор сводится не к тому, какой инструмент «круче». Речь о выборе парадигмы. BPMN и подобные нотации стремятся к максимальной гибкости, рискуя породить визуальный хаос, который мозг не может обработать без перегрузки. ДРАКОН сознательно жертвует этой гибкостью, навязывая железную дисциплину, которая защищает интеллект разработчика.
Он не обещает найти все ошибки. Он создает среду, в которой ошибкам негде спрятаться среди хаоса линий и неявной логики. Он не заменяет мышление - он его структурирует, освобождая ментальные ресурсы для решения по-настоящему сложных семантических проблем, а не для расшифровки лабиринта. Требовать от него невозможного значит не понимать его главной цели: не нарисовать «всё как есть», а принудительно привести мысль к ясности, сделав сложное - обозримым, а запутанное - структурированным.
Научная основа: когнитивная эргономика - это и есть наука, а не обещание магии
Вы требуете слепых рандомизированных исследований с сотнями участников как единственное доказательство эффективности ДРАКОНа. Это серьёзная методологическая ошибка, выдающая непонимание того, на чем реально основан инструмент.
ДРАКОН - это не фармацевтический препарат, который нужно испытывать на тысячах пациентов. Это инженерное применение давно установленных законов когнитивной науки.
Паронджанов не изобретал новую магию. Он впервые системно применил к проектированию алгоритмических языков фундаментальные, воспроизведенные в тысячах экспериментов принципы работы человеческого мозга:
Закон Миллера (объем рабочей памяти): Человек может одновременно удерживать 7±2 объекта. Сложная BPMN-диаграмма с десятком пересекающихся потоков легко превышает этот лимит. ДРАКОН, через силуэты и ветки, дробит информацию на «когнитивно усваиваемые» порции.
Закон Хика (время принятия решения): Время выбора растет с увеличением числа вариантов. Хаотичная схема предлагает мозгу десятки «вариантов» для отслеживания. Упорядоченная структура ДРАКОНа с главным маршрутом и правилом «чем правее - тем хуже» радикально сокращает это время.
Гештальт-принципы (прегнантность): Мозг бессознательно ищет простые, упорядоченные, замкнутые формы. Хаос пересекающихся линий в BPMN нарушает эти принципы. Силуэты ДРАКОНа - это и есть «хорошая форма», которую мозг схватывает мгновенно.
Требовать от ДРАКОНа новых масштабных исследований - все равно что требовать от создателей самолета заново доказывать закон Бернулли. Принципы, на которых он построен, доказаны, проверены и являются краеугольным камнем современной психофизики и эргономики.
Более того, «лабораторией» ДРАКОНа стали проекты, где цена ошибки была жизнью или национальной безопасностью - «Буран», «Морской старт». Масштабное «исследование» уже было проведено - успешным функционированием этих систем. В таких условиях не опираются на «маркетинговый буллшит», а используют только то, что гарантированно снижает когнитивную нагрузку и минимизирует риск ошибки.
Таким образом, научность ДРАКОНа - не в обещании волшебства, а в строгом следовании известным законам работы мозга, которые были проигнорированы при создании многих других, более «гибких» нотаций.
Запрет пересечений - это не ограничение, это принуждение к ясности через эргономическую дисциплину
Вы утверждаете, что запрет пересечений лишает возможности наглядно показывать взаимосвязи. Это ключевое заблуждение, проистекающее из привычки работать в хаотичной среде. ДРАКОН меняет саму парадигму: он жертвует ложной, поверхностной «наглядностью» паутины связей в пользу глубокой, архитектурной ясности.
Представьте два подхода к описанию одного сложного процесса, например, обработки заказа, где несколько подсистем обращаются к единой базе данных:
Подход BPMN («паутина»): Вы рисуете несколько потоков, которые пересекаются, чтобы соединиться с одним объектом «База данных». Да, связь «наглядна». Но что вы видите? Вы видите проблему, а не ее решение. Эта паутина не отвечает на критически важные вопросы: в какой последовательности происходит доступ? Где точки конфликта? Каков протокол взаимодействия? Схема превращается в лабиринт, где мозг вынужден вручную, в сукцессивном режиме, отслеживать каждую линию, чтобы понять общую картину. Это и есть та самая «когнитивная перегрузка», против которой борется Паронджанов.
Подход ДРАКОНа («архитектурный чертеж»): Запрет пересечений принуждает вас к декомпозиции и созданию интерфейсов.
Вы не можете просто провести линию. Вы должны создать четко обозначенную икону-вставку (например, «Выполнить запрос к БД»).
Эту икону вы не «привязываете» куда попало, а включаете в логически завершенный маршрут.
Если обращений много и схема усложняется, ДРАКОН-методология заставляет вас вынести работу с базой данных в отдельный силуэт - самостоятельный, законченный алгоритм с четкими входами и выходами.
Что вы получаете в итоге? Вы получаете не красивую, но бесполезную картинку связей, а архитектурный проект системы. Вы видите не «что связано», а «как организовано взаимодействие». Вместо хаотичной паутины — набор модулей с прозрачными интерфейсами. Это уже не просто схема, это модель решения, а не модель проблемы.
Этот запрет - краеугольный камень философии ДРАКОНа: «Любая сложность, которую нельзя изобразить без хаоса, должна быть перепроектирована». Это не ограничение творчества. Это высочайшая требование к инженерной дисциплине, которое превращает визуальный хаос в структурированное знание, пригодное для безошибочного понимания и реализации.
Спасибо за ваш комментарий - он очень содержательный и показывает, что вы глубоко разбираетесь в теме. Вы правы : инструмент сам по себе не решает проблему управления. Если руководитель не готов вникать в логику процессов, ни ДРАКОН, ни BPMN не спасут. Именно поэтому я в статье подчёркиваю: ДРАКОН - это не ИС, а часть замкнутого цикла управления, где схема становится поводом для принятия решений.
Теперь по пунктам.
1. BPMN интуитивно понятен? Для кого-то - да. Особенно если человек работает с ним годами. Но в моей практике бизнес-владельцы и руководители отделов не читают BPMN без перевода. Они доверяют аналитику, но не видят своих собственных процессов.
А в ДРАКОНе они описывают самостоятельно, потому что его структура ближе к естественному мышлению. Я не утверждаю, что BPMN плох - он просто решает другую задачу: документирование для IT, а не совместное проектирование с бизнесом.
2. Про стоимость владения Вы абсолютно правы: Camunda Modeler бесплатен. В статье я действительно смешал моделирование и исполнение - это моя ошибка, и я благодарен, что вы её указали. Однако даже при использовании только редактора BPMN (без BPMS), компании всё равно нанимают full-time аналитика, потому что бизнес не может работать с этой нотацией напрямую.
В случае с ДРАКОНом координатор (часто внутренний сотрудник) помогает руководителю оформить его знания - и дальше схема живёт внутри компании без постоянного привлечения экспертов. Экономия здесь не в лицензиях, а в снижении зависимости от внешних специалистов.
3. McKinsey (2025) Цифры 20-30% - это обобщение нескольких источников, включая отчёт Process Excellence Network (2024), BCG и внутренние исследования наших партнёров. Прямой ссылки на McKinsey с такой формулировкой действительно нет - я допустил упрощение для наглядности. Спасибо, что обратили внимание: в будущих редакциях уточню источник или уберу упоминание.
4. «Зачем новое колесо?» Потому что старое не катится по грязи реального бизнеса. BPMN отлично работает в корпорациях с процессным офисом, но в среднем бизнесе (50–1000 чел.) важна скорость, вовлечённость и минимальная бюрократия. ДРАКОН - не конкурент BPMN, а альтернатива на этапе до технической реализации: когда нужно быстро, вместе с владельцем процесса, понять, что делать, прежде чем решать, как это автоматизировать.
Ещё раз спасибо за конструктивную критику.
Благодарю Вас за столь глубокий и стратегический взгляд! Ваш комментарий - это не просто "накипь", а точнейший диагноз системного кризиса, который я наблюдал в каждой компании, с которой работал. И он поразительным образом описывает мою собственную эволюцию.
Вы абсолютно правы во всех четырех тезисах, и мои статьи - это тактическое подтверждение вашей стратегической концепции:
Про "точку бифуркации" и "дохлых лошадей" - я видел это в каждой компании:
Про сопротивление революции - я прошел это на собственной шкуре:
Про саботаж IT-отрасли - это моя ежедневная боль:
Про "автоматизацию хаоса" - это было моим кошмаром:
Мой тактический ответ через ДРАКОН стал "шлюзом" в вашу стратегию, но я понял, что этого недостаточно. Именно поэтому я являюсь соратником Олега Захарчука и платформы АСис, находясь в прямой связи с разработчиком.
Платформа АСис - это тот самый стратегический ответ на все четыре проблемы, которые вы обозначили:
В своих статьях я прихожу к тому же выводу, что и вы:
Таким образом, ваша стратегическая концепция и моя тактическая практика сошлись в одной точке:
Вы дали диагноз и стратегический императив. Я предлагаю тактический инструмент (ДРАКОН) для "первой помощи" бизнесу. А платформа АСис предлагает готовую технологическую основу для полномасштабного перехода на новую парадигму.
Я понимаю, что мои отдельные победы с ДРАКОНом были лишь симптоматическим лечением. Настоящее исцеление бизнеса требует именно того системного подхода, который предлагает АСис и который вы так точно описали.
Именно поэтому я не просто сторонний наблюдатель, а соратник этой платформы. Потому что только такие целостные решения способны сломить сопротивление системы и дать бизнесу шанс на выживание в новых условиях.
Источники:
[1] "От Intel 086 до нейросетей: исповедь охотника за бизнес-процессами"
[2] "Миллионы на ветер: как не купить IT-систему, которая вас разорит"
[3] "Почему ваш бизнес хромает: история одного IT-ортопеда"
Спасибо за честную и профессиональную полемику. Действительно, наше расхождение - не в «процентах», а в самих типах проблем, с которыми приходится сталкиваться в разных отраслях и культурах управления.
Ваш опыт с производственными «пожарами» - крайне показателен для промышленности, где кризисы часто возникают из-за объективных внешних факторов: санкций, сбоев поставок, износа оборудования. В таких условиях ключевым инструментом нередко становится экстренное управление, быстрое принятие решений, иногда - «ручное» вмешательство без длительной формализации. Методологии вроде Lean, ISO 9000, IATF 16949 и технологические карты здесь доказали свою эффективность и поддерживаются всей структурой предприятия.
В моём опыте, связанного преимущественно с IT и корпоративным управлением, действительно преобладают «туманные» ситуации: размытые зоны ответственности, недооформленные процессы, расслоение на неформальные договорённости и устные сценарии. Инструменты визуализации типа ДРАКОН или BPMN хорошо работают именно там, где процессы не описаны - для согласования действий, выявления пробелов, фасилитации диалога между отделами.
Но важно признать - именно контекст определяет инструмент:
Если речь идёт о классическом внешнем кризисе - перебои, санкции, ломка производственной цепи - формальные схемы и визуализация вторичны, приоритет за экстренными мерами, директивным управлением и поддержкой нормативных стандартов.
Если речь о внутреннем недопонимании, затяжных конфликтах между отделами либо корпоративной «невидимости» процессов, то визуализация или совместная разработка схем часто помогает прояснить зоны ответственности и снизить накал противоречий.
В производстве многоуровневые стандартные методы работают, потому что годы практики отшлифовали их под реальные боли отрасли. В IT или в гибких B2B-структурах порой не хватает даже элементарной согласованности, а потому схемы вроде ДРАКОН становятся временным «протезом», но не заменой для настоящей системы управления качеством и операциями.
Поэтому на практике мой совет прост: сначала честная диагностика - какая у нас ситуация? Фундаментальные внешние ограничения? Хронический конфликт целей? Или же туманная неясность? И только после этого - выбор подхода: стандарты ISO/Lean для систем с устоявшейся структурой, визуализация и фасилитация - для гибридных и рассогласованных систем.
Спасибо за остроумную и профессиональную дискуссию - такие споры не дают расслабиться и расширяют взгляд на реальную природу организационных болей.
Спасибо за это уточнение. Вы подняли дискуссию на принципиально новый уровень, и я с вами полностью согласен в основной premise.
Вы абсолютно правы: если фундамент - система управления - треснул или изначально был построен на устаревших принципах, то никакое «описание» этого кривого фундамента не выровняет здание. Максимум - позволит аккуратнее спотыкаться на ровном месте.
Вы ставите вопрос о разных уровнях проблем и решений:
Стратегический / Парадигмальный уровень (разработка «Теории относительности» для бизнеса). Это уровень создания и радикального переосмысления таких систем, как Lean, TOC, Agile. Здесь работают гении, исследователи и архитекторы бизнес-процессов. Инструмент здесь - глубокий анализ, научный метод, прорывные идеи. Ни ДРАКОН, ни BPMN на этом уровне не работают - они для этого и не создавались.
Тактический / Операционный уровень (применение законов физики для расчета моста). Это уровень внедрения, адаптации и ежедневного исполнения этих парадигм. Вот здесь языки визуализации и находят свою нишу.
Моя статья и мой инструмент — про второй уровень. Про то, как донести гениальную, но сложную «Теорию относительности», до рядового инженера, технолога и кладовщика так, чтобы они ее не только поняли, но и смогли применить без искажений.
Таким образом, вы правы в главном: ДРАКОН - не замена Lean или ISO. Это - «переводчик» и «усилитель» их принципов на операционном уровне.
И ваша оценка в 95/5% вероятно, точна для промышленности. Я благодарен вам за эту корректировку. Она заставляет задуматься: возможно, IT-консультант, предлагающий «описание», должен начинать с вашего вопроса: «А ваша система управления в принципе адекватна текущим вызовам? Или нам нужно начинать не с описания, а с проектирования нового фундамента?».
Спасибо, что своим комментарием вы превратили узкотехническую дискуссию в стратегическую. Это бесценно.
Вы правы: диагностика должна быть первой. И если она показывает, что вы в ситуации пожара, токсичной среды или тотального хаоса - метод интервьюирования и ДРАКОН становятся не просто бесполезными, а опасными. Такие условия требуют совершенно иного подхода.
Но в подавляющем большинстве случаев - в тех 95% бизнеса, где система не понятна, а подразделения воюют из-за недопонимания - отказ от AS-IS равносилен работе с закрытыми глазами. Это самый быстрый путь от хаоса к порядку.
Моя логика теперь выглядит так:
Диагностика: что у нас? Пожар, туман или токсин?
Выбор метода: если туман → ДРАКОН, если пожар → диктатура, если токсин → внешний аудит.
Действие:
Для тумана: кристаллизация знания через визуализацию
Для пожара: тушение кризиса немедленными решениями
Для токсина: очищение культуры от источника давления
Спасибо за принципиальную критику...
Всё верно многих евангелистов это серьёзно беспокоит.
Но беспокойство в основном сконцентрировалось на Китайской программе.
Не вижу вариантов международного контроля в данной ситуации бешенной гонки...
Между США и Китаем.
И к тому же правители на старушке Терре полностью сумашедшие и похожи на правителей Торманса из Ефремова.
Спасибо за статью. Отлично описана ситуация когда ресурсы руководство выделить не готово в принципе. Честно говоря не удивительно, много людей попадают постоянно в такую ситуацию.
По моему скромному мнению с руководством надо договариватся на берегу, то есть это проблема что вы сами не видели к чему это всё приведет (я про результат), теперь у вас есть бесценный опыт, кейс и всё в итоге у вас будет хорошо. Чего вам и желаю.
Спасибо за вопрос. Он настолько важен, что сердиться на него - бессмысленно. Вы абсолютно правы в главном: слепое следование догме «сначала опиши AS-IS» - это прямой путь к автоматизации хаоса.
Я использую ДРАКОН не как религию, а как инструмент. Это язык, рожденный в Институте Пилюгина для космической программы «Буран», где цена ошибки - катастрофа. Его сила - в принудительной ясности. Но никакой язык не отменяет необходимости думать.
Вы спрашиваете, где описание «как есть» - вредная трата времени. Вот три реальных кейса из моей практики:
Когда описывать нечего. Компания после ухода ключевых сотрудников. Процессы живут в головах двух стажеров. Любое интервью фиксирует «карту пустоты». Вместо этого мы сразу строили TO-BE - простой и рабочий MVP, который и стал новой реальностью.
Когда описание - самообман. Процесс давно стал ритуалом. На интервью вам рисуют красивую формальную схему, а реальная работа идет по негласным договоренностям. Описание такого AS-IS - это легитимация вранья. Мы шли другим путем - «теневым аудитом», наблюдая и фиксируя реальность, а не слова.
Когда нужен скачок, а не шаг. Компания кардинально меняет бизнес-модель. Изучение того, как они копали ямы лопатами, бесполезно для проектирования экскаватора. Здесь нужен чистый лист, а не ремонт старого фундамента.
Так зачем тогда вообще нужно описание?
Не для того, чтобы слепо верить интервью и фиксировать хаос. А для того, чтобы создать общую зону модернизации.
Когда начальник отдела видит свой процесс, выложенный на лаконичной схеме ДРАКОНа, происходит "чудо": он САМ начинает видеть свои же косяки. Проблема, которая была смутным ощущением в его голове, становится осязаемой и неустранимой. Это запускает правильный импульс - не «давайте задокументируем этот бардак», а «так, сейчас же все переделаем!».
Вывод прост. Не язык определяет метод, а задача определяет инструмент.
В 95% случаев бизнес - это «туман», где описание AS-IS - единственный способ этот туман развеять и начать диалог.
В 5% случаев - это «пожар» или «революция», где нужно не описывать, а тушить и строить.
Ваша критика бьет точно в цель: догматики, продающие описание как панацею, действительно опасны. Но отказ от диагностики под предлогом «здесь хаос» - это капитуляция. Истина, как всегда, в компетенции различать, где ты находишься - в тумане или в горящем здании.
Отличное обострение. Вы затронули серьёзный философский вопрос.
Но чтобы объяснить мою позицию - давайте сначала договоримся об определениях.
Что такое ХАОС?
Наиболее рабочим определением можно считать то, что следует из работ Генриха Миллера:
(Напомним: кратковременная память вмещает 7±2 элемента. Превысите - и мозг перестаёт видеть систему, включая импровизацию и «обходные пути».)
Из вашего комментария следует:
Вы справедливо замечаете:
Я с вами полностью согласен.
Но позвольте задать встречный вопрос:
→ Как приобрести эту компетенцию - не описав хаос сначала?
Нельзя гармонизировать то, что существует лишь в виде
тумана взаимных претензий,
скрытых устных договорённостей,
«исторически сложившихся» костылей,
и вечного диалога: «Я думал, ты сделал».
Что происходит при описании в ДРАКОНе?
Мы не превращаем хаос в космос автоматически.
Но описание становится зоной модернизации:
→ Мы кристаллизуем хаос в набор конкретных, видимых проблем.
→ Осознав процесс, мы уже не можем считать его хаосом- это карта.
Пусть мутная. Пусть неполная. Но - карта.
А с картой можно:
увидеть, где слабые зоны,
понять, где точки приложения силы,
договориться - не в пустоте, а над одной схемой.
Понятый хаос перестаёт быть хаосом.
Почему ДРАКОН, а не BPMN?
Не потому, что BPMN «плох». А потому, что он часто фиксирует сложность- и остаётся в зоне ответственности аналитика.
ДРАКОН же - построен на законах когнитивной эргономики (Миллер, Хик, гештальт) - принудительно вскрывает нестыковки и делает их очевидными для всех:
для менеджера,
для кладовщика,
для программиста,
для руководителя.
Это - не документация. Это фасилитация диалога.
Итог
Ваша критика абсолютно верна - если считать описание конечной точкой.
Но в моём подходе - она отправная.
→ Сначала - диагноз (карта «как есть»),
→ Потом - лечение (гармонизация «как будет»).
Без первого - второе действительно превращается в шаманство.
Рекомендации из 2 ключевых шага, чтобы процессы начали работать:
Рисуем реальность, а не идеал
Не "как должно быть", а "как есть - со всеми костылями и обходными путями". Когда в одной из компаний описали реальный процесс приёма клиента, выяснилось: 40% заказов ждали кладовщика больше 15 минут, а менеджеры часто "думали за других". Схема стала объективным зеркалом - с картинкой нельзя спорить.
(ну и как вы наверное уже догадались, возникнет вопрос так дальше жить нельзя, быстрее всего немного позднее возникнет новая схема "как будет" )
Чёткие точки передачи ответственности
В схеме указываем не просто "передать", а "Иван должен подтвердить выполнение в течение 1 часа". Это убирает "я думал, ты сделал" - теперь есть чёткий критерий: "не получил подтверждение → процесс прерван".
Этих двух шагов достаточно, чтобы процессы перестали быть фикцией. Вы создаёте прозрачность, где работать по схеме становится проще, чем в хаосе.
Согласен, вопрос сложный. Дело не в Драконе, а в подходе. Проблема ваших кейсов: процессы есть, но они не работают в реальности.
Дракон помогает потому, что: Вместо текстовых инструкций - визуальная схема, где видно ВСЕ условия и решения. Все участники процесса смотрят на одну схему, а не интерпретируют каждый по-своему. На схеме сразу видно, где зоны ответственности и точки передачи
В вашем случае с 50 сотрудниками: когда человек "тупит" с инструкцией, в Драконе он видит не текст, а наглядный маршрут со всеми "если/то". Он просто не сможет затупить :)
В случае с 100 сотрудниками в Битрикс: схема прекращает споры "кто виноват", потому что все видят единую логику процесса.
Предложение: возьмите один проблемный процесс и опишите его в Драконе вместе с сотрудниками. Уже на этом этапе станет ясно, где именно система ломается. Это не про еще больше документов, а про то, чтобы наконец сделать процессы понятными.
Приветствую :)
6 статей в серии...
Неужели маловато будет?
Вы правы - это вопрос инженерной дисциплины.
Паронджанов:
Ваш подход: «Описать систему как есть»
Подход ДРАКОНа: «Спроектировать систему как должно быть»
20 обращений к БД в одном модуле - не техническая деталь. Это архитектурное нарушение, которое ДРАКОН делает видимым.
Инженер не рисует трещины в конструкции - он проектирует так, чтобы их не было.
Спасибо за дисскурсию, на все ваши вопросы Владимир Даниелович Паронджанов давно дал ответы в своей книге "Как улучшить работу ума".
Вы смешиваете фундаментальную науку и прикладные испытания.
1. Когнитивная эргономика - это точная наука.
Её законы подтверждены тысячами экспериментов:
Миллер (1956) - объём рабочей памяти
Хик (1952) - время реакции при выборе
Гештальт-психология (1920-е) - принципы восприятия форм
Паронджанов не изобретал эти законы - он применил их к проектированию языков. Требовать новых исследований для ДРАКОНа - как требовать перепроверки законов физики для каждого нового самолёта.
2. Лабораторией ДРАКОНа стали критические системы:
В таких проектах не используют непроверенные методы. Факт успешного применения в системах с нулевой терпимостью к ошибкам - лучшее доказательство эффективности.
3. Ваш запрос игнорирует главное:
ДРАКОН - это инженерная реализация известных законов. Как самолёт строится на законах аэродинамики, так ДРАКОН построен на законах когнитивной науки. И так же, как самолёт летает без "слепых испытаний против воздушных шаров", ДРАКОН работает в реальных проектах.
Вы продолжаете мыслить в парадигме старого подхода. Паронджанов прямо отвечает на ваш вопрос:
Ваше требование "показать все связи на одном чертеже" — это и есть тот самый визуальный хаос, против которого борется ДРАКОН.
ДРАКОН не показывает связи - он показывает архитектуру. Если у вас множество разнородных обращений к БД - значит, у вас архитектурная проблема, и ДРАКОН принуждает вас решить её через:
Четкие интерфейсы (иконы-вставки)
Декомпозицию (отдельные силуэты)
Явные контракты между модулями
Вместо хаотичной "паутины связей" вы получаете систему с прозрачными взаимодействиями - именно то, что нужно для реальной разработки, а не для создания "красивых, но бесполезных схем".
Прямые ответы на ваши вопросы уже даны в книге Паронджанова.
На ваш первый вопрос о «понимании без надписей» автор поясняет:
то есть гарантируется именно структурная, а не семантическая ясность.
На второй вопрос о «неявных циклах» в книге указано:
Ваши возражения не опровергают ДРАКОН — они иллюстрируют его принцип: он не исправляет логику, но принудительно делает архитектурные flaws визуально кричащими.
Вывод: ДРАКОН это философия «когнитивного щита», а не «серебряной пули».
Спор сводится не к тому, какой инструмент «круче». Речь о выборе парадигмы. BPMN и подобные нотации стремятся к максимальной гибкости, рискуя породить визуальный хаос, который мозг не может обработать без перегрузки. ДРАКОН сознательно жертвует этой гибкостью, навязывая железную дисциплину, которая защищает интеллект разработчика.
Он не обещает найти все ошибки. Он создает среду, в которой ошибкам негде спрятаться среди хаоса линий и неявной логики. Он не заменяет мышление - он его структурирует, освобождая ментальные ресурсы для решения по-настоящему сложных семантических проблем, а не для расшифровки лабиринта. Требовать от него невозможного значит не понимать его главной цели: не нарисовать «всё как есть», а принудительно привести мысль к ясности, сделав сложное - обозримым, а запутанное - структурированным.
Научная основа: когнитивная эргономика - это и есть наука, а не обещание магии
Вы требуете слепых рандомизированных исследований с сотнями участников как единственное доказательство эффективности ДРАКОНа. Это серьёзная методологическая ошибка, выдающая непонимание того, на чем реально основан инструмент.
ДРАКОН - это не фармацевтический препарат, который нужно испытывать на тысячах пациентов. Это инженерное применение давно установленных законов когнитивной науки.
Паронджанов не изобретал новую магию. Он впервые системно применил к проектированию алгоритмических языков фундаментальные, воспроизведенные в тысячах экспериментов принципы работы человеческого мозга:
Закон Миллера (объем рабочей памяти): Человек может одновременно удерживать 7±2 объекта. Сложная BPMN-диаграмма с десятком пересекающихся потоков легко превышает этот лимит. ДРАКОН, через силуэты и ветки, дробит информацию на «когнитивно усваиваемые» порции.
Закон Хика (время принятия решения): Время выбора растет с увеличением числа вариантов. Хаотичная схема предлагает мозгу десятки «вариантов» для отслеживания. Упорядоченная структура ДРАКОНа с главным маршрутом и правилом «чем правее - тем хуже» радикально сокращает это время.
Гештальт-принципы (прегнантность): Мозг бессознательно ищет простые, упорядоченные, замкнутые формы. Хаос пересекающихся линий в BPMN нарушает эти принципы. Силуэты ДРАКОНа - это и есть «хорошая форма», которую мозг схватывает мгновенно.
Требовать от ДРАКОНа новых масштабных исследований - все равно что требовать от создателей самолета заново доказывать закон Бернулли. Принципы, на которых он построен, доказаны, проверены и являются краеугольным камнем современной психофизики и эргономики.
Более того, «лабораторией» ДРАКОНа стали проекты, где цена ошибки была жизнью или национальной безопасностью - «Буран», «Морской старт». Масштабное «исследование» уже было проведено - успешным функционированием этих систем. В таких условиях не опираются на «маркетинговый буллшит», а используют только то, что гарантированно снижает когнитивную нагрузку и минимизирует риск ошибки.
Таким образом, научность ДРАКОНа - не в обещании волшебства, а в строгом следовании известным законам работы мозга, которые были проигнорированы при создании многих других, более «гибких» нотаций.
Запрет пересечений - это не ограничение, это принуждение к ясности через эргономическую дисциплину
Вы утверждаете, что запрет пересечений лишает возможности наглядно показывать взаимосвязи. Это ключевое заблуждение, проистекающее из привычки работать в хаотичной среде. ДРАКОН меняет саму парадигму: он жертвует ложной, поверхностной «наглядностью» паутины связей в пользу глубокой, архитектурной ясности.
Представьте два подхода к описанию одного сложного процесса, например, обработки заказа, где несколько подсистем обращаются к единой базе данных:
Подход BPMN («паутина»): Вы рисуете несколько потоков, которые пересекаются, чтобы соединиться с одним объектом «База данных». Да, связь «наглядна». Но что вы видите? Вы видите проблему, а не ее решение. Эта паутина не отвечает на критически важные вопросы: в какой последовательности происходит доступ? Где точки конфликта? Каков протокол взаимодействия? Схема превращается в лабиринт, где мозг вынужден вручную, в сукцессивном режиме, отслеживать каждую линию, чтобы понять общую картину. Это и есть та самая «когнитивная перегрузка», против которой борется Паронджанов.
Подход ДРАКОНа («архитектурный чертеж»): Запрет пересечений принуждает вас к декомпозиции и созданию интерфейсов.
Вы не можете просто провести линию. Вы должны создать четко обозначенную икону-вставку (например, «Выполнить запрос к БД»).
Эту икону вы не «привязываете» куда попало, а включаете в логически завершенный маршрут.
Если обращений много и схема усложняется, ДРАКОН-методология заставляет вас вынести работу с базой данных в отдельный силуэт - самостоятельный, законченный алгоритм с четкими входами и выходами.
Что вы получаете в итоге?
Вы получаете не красивую, но бесполезную картинку связей, а архитектурный проект системы. Вы видите не «что связано», а «как организовано взаимодействие». Вместо хаотичной паутины — набор модулей с прозрачными интерфейсами. Это уже не просто схема, это модель решения, а не модель проблемы.
Этот запрет - краеугольный камень философии ДРАКОНа: «Любая сложность, которую нельзя изобразить без хаоса, должна быть перепроектирована». Это не ограничение творчества. Это высочайшая требование к инженерной дисциплине, которое превращает визуальный хаос в структурированное знание, пригодное для безошибочного понимания и реализации.