Comments 19
мысль классная, но поленились написать более развернуто и четче.... Ну и Дракон и Фильтр - что это такое и с чем его едят?
Посмотрел я статьи, восторженные отзывы о Драконе, но где сама основа.... посмотрел сайт Дракона, прикольно, но какое практическое применение? Формализация процессов в бизнесе? Так это простая и логичная мысль. Зачем столько воды вокруг нее? Вот Вам кейс - компания, около 40-50 человек, все друг друга знают, куча регламентов и инструкций, которые пересматриваются раз где-то в полгода. Но, возникают ситуации, когда сотрудник, даже имея инструкцию, все равно делает не так, тупит, все наперекосяк... Как тут Дракон поможет, те же бизнесс-процессы пусть будут описаны на Драконе... И? Что от этого изменится? Ок, возьмем второй пример - компания побольше, около 100 сотрудников, все бизнес процессы в Битрикс24, так же регламенты, описания процессов, инструкции - а ситуация еще хуже, сотрудники даже имея 80% стандартизированных списков действий в различных ситуациях, начинают переводить стрелки друг на друга, так как в процессах обычно не один человек. И эта игра бесконечна, это реальные кейсы. Где тут Дракон даст выигрыш? Вот что интересно. А статей - о, было так, сделали так и все вуаля круто, их море... нет связи между было и почему так стало. Смысла нет. Я не отрицаю, в Вашей голове и Вашей вселенной он видимо есть, но он недоступен для Ваших читателей. Мы то Ваши мысли, даже с Драконом, читать не можем....
Согласен, вопрос сложный. Дело не в Драконе, а в подходе. Проблема ваших кейсов: процессы есть, но они не работают в реальности.
Дракон помогает потому, что: Вместо текстовых инструкций - визуальная схема, где видно ВСЕ условия и решения. Все участники процесса смотрят на одну схему, а не интерпретируют каждый по-своему. На схеме сразу видно, где зоны ответственности и точки передачи
В вашем случае с 50 сотрудниками: когда человек "тупит" с инструкцией, в Драконе он видит не текст, а наглядный маршрут со всеми "если/то". Он просто не сможет затупить :)
В случае с 100 сотрудниками в Битрикс: схема прекращает споры "кто виноват", потому что все видят единую логику процесса.
Предложение: возьмите один проблемный процесс и опишите его в Драконе вместе с сотрудниками. Уже на этом этапе станет ясно, где именно система ломается. Это не про еще больше документов, а про то, чтобы наконец сделать процессы понятными.
Вот так уже лучше, Дракон = инструмент визуализации -> результат = понятный процесс. Но, опять же, поработаю критиком, даже когда одна и та же картинка, найдется товарищ, который поймет даже картинку не так, как все остальные, особенно если надо напрягать мозг, интерпретируя УГО из схемы. А затупить могут на пустом месте, особенно молодняк современный, да и старая школа тоже уже когнитивные способности начинает терять из-за возраста. Такое ощущение, что золотая середина просто пропала...
Но, основная проблема любой формализации процессов в бизнесе - "процессы есть, но они не работают в реальности". Это реальная БОЛЬ! И не важно, как они описаны или визуализированы. КАК ЗАСТАВИТЬ ПРОЦЕССЫ РАБОТАТЬ?
Рекомендации из 2 ключевых шага, чтобы процессы начали работать:
Рисуем реальность, а не идеал
Не "как должно быть", а "как есть - со всеми костылями и обходными путями". Когда в одной из компаний описали реальный процесс приёма клиента, выяснилось: 40% заказов ждали кладовщика больше 15 минут, а менеджеры часто "думали за других". Схема стала объективным зеркалом - с картинкой нельзя спорить.
(ну и как вы наверное уже догадались, возникнет вопрос так дальше жить нельзя, быстрее всего немного позднее возникнет новая схема "как будет" )Чёткие точки передачи ответственности
В схеме указываем не просто "передать", а "Иван должен подтвердить выполнение в течение 1 часа". Это убирает "я думал, ты сделал" - теперь есть чёткий критерий: "не получил подтверждение → процесс прерван".
Этих двух шагов достаточно, чтобы процессы перестали быть фикцией. Вы создаёте прозрачность, где работать по схеме становится проще, чем в хаосе.
Категорически обострю обсуждение (так же интересней) радикальной точкой зрения:
"Что русскому - хорошо, то немцу - смерть!", а по теме процессов в организации это звучит как-то так "что хорошо продавцам, то плохо производству" (названия структурных подразделений можно менять как угодно "что хорошо конструктору, то плохо технологу" и т.д). К чему я веду: какой бы язык визуализации (от хорошего, до расчудесного) не использовался, пока не решена проблема гармонизации целей и задач процессов организации, любое описание системы управления, созданное на базе интервью представителей отдельных структурных подразделений (а дисбаланс интересов существует не только между подразделениями, но и внутри подразделений, об этом я пока молчу) - это автоматизация ХАОСА. Поэтому декларации про то что НАДО описывать, и описанные процессы для организации лучше - это манипуляция, потому что описывать ХАОС, чтобы потом "управлять" ХАОСОМ - так себе результат (выкинутые напрасно время и немалые деньги) ((( Содержание статьи очищенное от манипуляций выглядит как-то так "наш язык визуализации опишет ваш ХАОС царящий в организации быстрее, чем другие языки". Без компетенции гармонизации процессов любой язык визуализации - обезьяна с гранатой! А ответа на этот вопрос и такую постановку задачи, что-то я здесь (в этой публикации в частности, и на ХАБР вообще) не наблюдаю((( У кого есть ответ? Где он описан? Где эту проблематику "автоматизации ХАОСа" обсуждают? Ну очень интересно было бы посмотреть!!!
Отличное обострение. Вы затронули серьёзный философский вопрос.
Но чтобы объяснить мою позицию - давайте сначала договоримся об определениях.
Что такое ХАОС?
Наиболее рабочим определением можно считать то, что следует из работ Генриха Миллера:
«Хаос - это не отсутствие порядка. Это порядок, который человек не может удержать в сознании».
(Напомним: кратковременная память вмещает 7±2 элемента. Превысите - и мозг перестаёт видеть систему, включая импровизацию и «обходные пути».)
Из вашего комментария следует:
«Описывать ХАОС, чтобы потом “управлять” ХАОСОМ - так себе результат»,
«Это манипуляция».
Вы справедливо замечаете:
«Без компетенции гармонизации процессов любой язык визуализации - обезьяна с гранатой!»
Я с вами полностью согласен.
Но позвольте задать встречный вопрос:
→ Как приобрести эту компетенцию - не описав хаос сначала?
Нельзя гармонизировать то, что существует лишь в виде
тумана взаимных претензий,
скрытых устных договорённостей,
«исторически сложившихся» костылей,
и вечного диалога: «Я думал, ты сделал».
Что происходит при описании в ДРАКОНе?
Мы не превращаем хаос в космос автоматически.
Но описание становится зоной модернизации:
→ Мы кристаллизуем хаос в набор конкретных, видимых проблем.
→ Осознав процесс, мы уже не можем считать его хаосом- это карта.
Пусть мутная. Пусть неполная. Но - карта.
А с картой можно:
увидеть, где слабые зоны,
понять, где точки приложения силы,
договориться - не в пустоте, а над одной схемой.
Понятый хаос перестаёт быть хаосом.
Почему ДРАКОН, а не BPMN?
Не потому, что BPMN «плох». А потому, что он часто фиксирует сложность- и остаётся в зоне ответственности аналитика.
ДРАКОН же - построен на законах когнитивной эргономики (Миллер, Хик, гештальт) - принудительно вскрывает нестыковки и делает их очевидными для всех:
для менеджера,
для кладовщика,
для программиста,
для руководителя.
Это - не документация. Это фасилитация диалога.
Итог
Ваша критика абсолютно верна - если считать описание конечной точкой.
Но в моём подходе - она отправная.
→ Сначала - диагноз (карта «как есть»),
→ Потом - лечение (гармонизация «как будет»).
Без первого - второе действительно превращается в шаманство.
Во-первых, Спасибо, что не сердитесь за перевод беседы с обсуждения вашего оригинального языка на надязыковую тему👍
Я знаком (да все знакомы) с логикой (зачем и почему) сначала AS-IS и только потом TO BE! Но можно, я продолжу "дёргать за ус" эту "общепринятую" надязыковую логику, и от этого лежачего на поверхности стандартного (причём для любого языка, это не ноу-хау Дракона) концепта, предложу нырнуть в глубину? Безусловно, есть огромная область эффективного применения логики AS-IS TO-BE, но она, увы, годится не для всех случаев жизни! Можете предположить ситуации
(и это не какие то вырожденные события, о которых не стоит и говорить), когда составлять модель AS-IS методом интервью - напрасная трата сил и времени (вопреки Вашему утверждению)? Извините за то, что я не даю ответ, а задаю вопрос - мне очень интересны Ваши гипотезы, ход мысли на этот счет! Просто я вижу в Вашем ответе такую же манипуляцию умалчивания как в (1) начинать описывать не важно что, потому что это в любом случае полезно (в моем контрпримере хаос - сомнительная среда для описания) и (2) обязательно описывать ситуацию AS-IS, потому что без этого нельзя (существует ли по-вашему контрпример?).
--
Спасибо за вопрос. Он настолько важен, что сердиться на него - бессмысленно. Вы абсолютно правы в главном: слепое следование догме «сначала опиши AS-IS» - это прямой путь к автоматизации хаоса.
Я использую ДРАКОН не как религию, а как инструмент. Это язык, рожденный в Институте Пилюгина для космической программы «Буран», где цена ошибки - катастрофа. Его сила - в принудительной ясности. Но никакой язык не отменяет необходимости думать.
Вы спрашиваете, где описание «как есть» - вредная трата времени. Вот три реальных кейса из моей практики:
Когда описывать нечего. Компания после ухода ключевых сотрудников. Процессы живут в головах двух стажеров. Любое интервью фиксирует «карту пустоты». Вместо этого мы сразу строили TO-BE - простой и рабочий MVP, который и стал новой реальностью.
Когда описание - самообман. Процесс давно стал ритуалом. На интервью вам рисуют красивую формальную схему, а реальная работа идет по негласным договоренностям. Описание такого AS-IS - это легитимация вранья. Мы шли другим путем - «теневым аудитом», наблюдая и фиксируя реальность, а не слова.
Когда нужен скачок, а не шаг. Компания кардинально меняет бизнес-модель. Изучение того, как они копали ямы лопатами, бесполезно для проектирования экскаватора. Здесь нужен чистый лист, а не ремонт старого фундамента.
Так зачем тогда вообще нужно описание?
Не для того, чтобы слепо верить интервью и фиксировать хаос. А для того, чтобы создать общую зону модернизации.
Когда начальник отдела видит свой процесс, выложенный на лаконичной схеме ДРАКОНа, происходит "чудо": он САМ начинает видеть свои же косяки. Проблема, которая была смутным ощущением в его голове, становится осязаемой и неустранимой. Это запускает правильный импульс - не «давайте задокументируем этот бардак», а «так, сейчас же все переделаем!».
Вывод прост. Не язык определяет метод, а задача определяет инструмент.
В 95% случаев бизнес - это «туман», где описание AS-IS - единственный способ этот туман развеять и начать диалог.
В 5% случаев - это «пожар» или «революция», где нужно не описывать, а тушить и строить.
Ваша критика бьет точно в цель: догматики, продающие описание как панацею, действительно опасны. Но отказ от диагностики под предлогом «здесь хаос» - это капитуляция. Истина, как всегда, в компетенции различать, где ты находишься - в тумане или в горящем здании.
Аплодирую стоя Вашим примерам 1,2,3 когда описание AS-IS не нужно!
А вот то, что написано после, почему то противоречит Вашим же 1,2,3!?
Посмотрите какая получается конструкция Вашего комментария: Если ситуация 1,2,3, то описывать AS-IS не надо, а после Вы пишите текст, что описывать надо все равно в любом случае!? При этом делаете манипуляцию, ставя знак равенства между диагностикой и описанием AS IS методом интервьюирования((( Диагностику же можно делать множеством других способов!?))) Про отказ от диагностики, как этапа никто же не говорил?
Корректней было бы после 1,2.3 написать, что для этих случаев моделирование AS-IS и TO-BE методами интервьюирования - это плохая область применения этой методологии (не зависимо от выбора языка). В этих случаях нужны другие подходы.
Т.е. ИМХО, должна декларироваться следующая логика:
Проводим диагностику предприятия на предмет наличия ситуаций 1,2.3
Если 1,2,3 - то работаем по методологии "???", иначе метод интервьюирования и только Дракон для эффективного прохождения маршрута AS-IS TO-BE)))
Вы правы: диагностика должна быть первой. И если она показывает, что вы в ситуации пожара, токсичной среды или тотального хаоса - метод интервьюирования и ДРАКОН становятся не просто бесполезными, а опасными. Такие условия требуют совершенно иного подхода.
Но в подавляющем большинстве случаев - в тех 95% бизнеса, где система не понятна, а подразделения воюют из-за недопонимания - отказ от AS-IS равносилен работе с закрытыми глазами. Это самый быстрый путь от хаоса к порядку.
Моя логика теперь выглядит так:
Диагностика: что у нас? Пожар, туман или токсин?
Выбор метода: если туман → ДРАКОН, если пожар → диктатура, если токсин → внешний аудит.
Действие:
Для тумана: кристаллизация знания через визуализацию
Для пожара: тушение кризиса немедленными решениями
Для токсина: очищение культуры от источника давления
Спасибо за принципиальную критику...
У нас с Вами оценки "с точностью до наоборот"))) Моя практика (35+ лет) прикладного консалтинга промышленных предприятий/холдингов/цепей поставок, говорит о том, что территория 1,2.3 - это 95%, а Ваша оценка как эксперта из IT отрасли этой области - 5%! Мы (я - эксперт "Прикладного мира", Вы - эксперт IT мира, который должен удовлетворять потребности Прикладного мира) на одного и того же "слона" (состояние промпредприятий и что им для улучшения нужно делать) смотрим с радикально разных точек зрения!!!! А должно быть расхождение в долях процентов (в идеале - совпадать)! Вот это ТОЧНО БОЛЬШАЯ И НЕ ТОЛЬКО ФИЛОСОВСКАЯ ПРОБЛЕМА!!!!
Кстати, для диагностики состояния и определение областей для улучшения в Прикладном мире есть свои "языки" (международные стандарты ISO серии 9000 и ISO/TS2 (16949), концепция "Бережливое производство"). Почему IT отрасль на их основе не создает (де факто ИГНОРИТ!!! то, чем реально работает Прикладной мир) языки для диагностики и описания AS-IS TO-BE, а выдумывает "велосипеды" в виде нотаций BPMN, IDEFх, Дракон ..?!
Спасибо за честную и профессиональную полемику. Действительно, наше расхождение - не в «процентах», а в самих типах проблем, с которыми приходится сталкиваться в разных отраслях и культурах управления.
Ваш опыт с производственными «пожарами» - крайне показателен для промышленности, где кризисы часто возникают из-за объективных внешних факторов: санкций, сбоев поставок, износа оборудования. В таких условиях ключевым инструментом нередко становится экстренное управление, быстрое принятие решений, иногда - «ручное» вмешательство без длительной формализации. Методологии вроде Lean, ISO 9000, IATF 16949 и технологические карты здесь доказали свою эффективность и поддерживаются всей структурой предприятия.
В моём опыте, связанного преимущественно с IT и корпоративным управлением, действительно преобладают «туманные» ситуации: размытые зоны ответственности, недооформленные процессы, расслоение на неформальные договорённости и устные сценарии. Инструменты визуализации типа ДРАКОН или BPMN хорошо работают именно там, где процессы не описаны - для согласования действий, выявления пробелов, фасилитации диалога между отделами.
Но важно признать - именно контекст определяет инструмент:
Если речь идёт о классическом внешнем кризисе - перебои, санкции, ломка производственной цепи - формальные схемы и визуализация вторичны, приоритет за экстренными мерами, директивным управлением и поддержкой нормативных стандартов.
Если речь о внутреннем недопонимании, затяжных конфликтах между отделами либо корпоративной «невидимости» процессов, то визуализация или совместная разработка схем часто помогает прояснить зоны ответственности и снизить накал противоречий.
В производстве многоуровневые стандартные методы работают, потому что годы практики отшлифовали их под реальные боли отрасли. В IT или в гибких B2B-структурах порой не хватает даже элементарной согласованности, а потому схемы вроде ДРАКОН становятся временным «протезом», но не заменой для настоящей системы управления качеством и операциями.
Поэтому на практике мой совет прост: сначала честная диагностика - какая у нас ситуация? Фундаментальные внешние ограничения? Хронический конфликт целей? Или же туманная неясность? И только после этого - выбор подхода: стандарты ISO/Lean для систем с устоявшейся структурой, визуализация и фасилитация - для гибридных и рассогласованных систем.
Спасибо за остроумную и профессиональную дискуссию - такие споры не дают расслабиться и расширяют взгляд на реальную природу организационных болей.
Добавлю к предыдущему посту:
И на вопрос из названия Вашей публикации "Чем болен средний бизнес? Статья 6. Как описание может остановить хаос многомиллионных потерь", мой ответ для 95% производственных компаний звучал бы так: тем, что применяемые ими подходы к организации производства ("лекарство" - "Бережливое производство"), к системе управления предприятием ("лекарство" - "ISO серии 9000"), к управлению несоответствиями ("лекарство" - "ISO 16949") требуют радикального переосмысления/перестройки. Описывать эти проблемы и решение проблем, нужно на языке перечисленных "лекарств" (Дракон спроектировать прикладные решения методом интервью, лежащие в основе перечисленных "лекарств", не способен от слова "совсем" (это все равно, что предположить, что методом интервьюирования физиков можно было разработать решение в виде "Теории относительности"), т.е. не поможет/бесполезен). Для 5% производственных компаний, кто это "лечение" успешно прошел, по определению "хаоса многомиллионных потерь" у них уже нет. Но тогда и описание на языке Дракона принесет таким предприятиям пользу, но уже не в виде "многомиллионных эффектов". Именно поэтому я и включился в дискуссию к Вашей публикации.
Спасибо за это уточнение. Вы подняли дискуссию на принципиально новый уровень, и я с вами полностью согласен в основной premise.
Вы абсолютно правы: если фундамент - система управления - треснул или изначально был построен на устаревших принципах, то никакое «описание» этого кривого фундамента не выровняет здание. Максимум - позволит аккуратнее спотыкаться на ровном месте.
Вы ставите вопрос о разных уровнях проблем и решений:
Стратегический / Парадигмальный уровень (разработка «Теории относительности» для бизнеса). Это уровень создания и радикального переосмысления таких систем, как Lean, TOC, Agile. Здесь работают гении, исследователи и архитекторы бизнес-процессов. Инструмент здесь - глубокий анализ, научный метод, прорывные идеи. Ни ДРАКОН, ни BPMN на этом уровне не работают - они для этого и не создавались.
Тактический / Операционный уровень (применение законов физики для расчета моста). Это уровень внедрения, адаптации и ежедневного исполнения этих парадигм. Вот здесь языки визуализации и находят свою нишу.
Моя статья и мой инструмент — про второй уровень. Про то, как донести гениальную, но сложную «Теорию относительности», до рядового инженера, технолога и кладовщика так, чтобы они ее не только поняли, но и смогли применить без искажений.
Таким образом, вы правы в главном: ДРАКОН - не замена Lean или ISO. Это - «переводчик» и «усилитель» их принципов на операционном уровне.
И ваша оценка в 95/5% вероятно, точна для промышленности. Я благодарен вам за эту корректировку. Она заставляет задуматься: возможно, IT-консультант, предлагающий «описание», должен начинать с вашего вопроса: «А ваша система управления в принципе адекватна текущим вызовам? Или нам нужно начинать не с описания, а с проектирования нового фундамента?».
Спасибо, что своим комментарием вы превратили узкотехническую дискуссию в стратегическую. Это бесценно.
Спасибо Вам, Сергей! Если бы не Ваша добрая и профессиональная позиция, быстрая реакция и точное восприятие обсуждаемых посылов, мы бы так далеко не зашли!
А по поводу выхода на стратегический уровень - вот еще одна стратегическая эскалация в моем видении (на стратегию поведения IT отрасли в целом), если это интересно!
Тезисно:
(1) Бизнес-сообщество сейчас переходит через "точку бифуркации" (разворот на 180 градусов с условий бизнес-среды "спрос больше предложения" (этот период длился около 300 лет), на "спрос меньше предложения" (начался с 80х годов прошлого века)). Это означает, что старые решения для промпредприятий под среду "спрос больше предложения", нужно "выкинуть на свалку истории" и срочно переходить на альтернативные радикально иные решения (по организации производства, системе управления) под условия "предложения больше спроса". Предприятия, которые вовремя этого не сделают - окажутся в большой беде. Но такая постановка задачи в сообществе не обсуждается (почему - ниже), и это проблема_1.
(2) Промышленность (руководство и сотрудники предприятий, выросшие и сделавшие карьеру на старых решениях) очень сильно тормозит с этой вынужденной революцией, которую они должны совершить для выживания в новых условиях (тормозит в объеме 95%). По разным причинам эти ленивцы руководствуются безосновательной верой, что можно эту революцию осуществить через безболезненные малые улучшения (как эволюцию, а не революцию). Подробнее можно про это прочитать в моей статье https://centr-prioritet.ru/index.php?option=com_content&view=article&id=4449 И это проблема_2! В мире вообще (и в промышленности в частности) почему то царит идея, что все должно быть просто, если предлагается сложная для реализации конструкция - это автоматически маркируется как "неправильная идея".
(3) IT отрасль, вместо того, чтобы возглавить/помочь этому переходу, саботирует эту ситуацию и эту потребность. Все разработанные на сегодня IT продукты (средства описания/моделирования деятельности организации в виде нотаций BPMN и IDEFx, продукты по управлению(ERP, MES) Предприятиями и Холдингами (не важно от каких вендоров SAP или 1С) - это все разработки под среду "спрос больше предложения" (бесполезные вплоть до вредные в новых условиях), т.е. в терминах индейцев Дакота - это все "Дохлая лошадь", которая в современной бизнес-среде "скакать с нужной скоростью" не сможет от слова совсем . И вместо того, чтобы переделать эти продукты под новые условия, отрасль лишь рационально (покупают и эксплуатируют же старые решения) и цинично (в явном виде отказываются от переработки существующих решений, зачем сейчас тратить деньги на разработку, сейчас нужно собрать все сливки с продажи старых разработок) наживается на промышленности, продавая им ненужный и вредный в новых условиях товар. И это проблема_3.
(4) Такая позиция IT отрасли по отношению к проблематике промпредприятий уже привела к ситуации "автоматизации хаоса" - внедрения ERP&MES решений под среду "спрос больше предложения" никак не способствуют нужному для выживания росту конкурентоспособности, потому что они автоматизируют "Дохлую лошадь". Этот безумный "не приходя в сознание" (не понимая смыслов) маркетинг "Всем автоматизироваться", а сейчас "Всем цифровизироваться", приводит к тому, что цифровые двойники, интернет вещей , ИИ и прочая навешиваются на неправильные/устаревшие решения (на "Дохлую лошадь"). Т.е. вслед за результатом "автоматизация хаоса" мы стремительно летим к "цифровизации хаоса" и IT отрасль это движение осознанно или нет, но возглавляет((( И это проблема_4
Извините, конечно, что мы на такие "верха" забрались, начав обсуждение с узкотехнического вопроса борьбы с рассогласованием в организациях - у меня "накипело", и видимо из-за этой профдеформации я везде вижу "следы" опасного проявления описанных мною проблем (1,2,3,4), и поэтому любое обсуждение в моем исполнении - это "сваливание" на мои "болячки"(((
Благодарю Вас за столь глубокий и стратегический взгляд! Ваш комментарий - это не просто "накипь", а точнейший диагноз системного кризиса, который я наблюдал в каждой компании, с которой работал. И он поразительным образом описывает мою собственную эволюцию.
Вы абсолютно правы во всех четырех тезисах, и мои статьи - это тактическое подтверждение вашей стратегической концепции:
Про "точку бифуркации" и "дохлых лошадей" - я видел это в каждой компании:
"BPMN чудовищно перегружен. Стандарт предлагает нам выучить более сотни разных значков... А BPMN предлагает нам интеллектуальное жонглирование десятками. Мозг от такого просто отключается" [1]
"ERP-система - это как хирургический скальпель. В руках опытного хирурга... но сам по себе скальпель никого не лечит. Если ваши бизнес-процессы - это клубок неформальных договоренностей, то новая система этот клубок не распутает. Она его усилит и забетонирует" [2]
Про сопротивление революции - я прошел это на собственной шкуре:
"Стратегический уровень так и не был принят высшим руководством... Мне удавалось добиваться ROI 137% на отдельных процессах, но когда я пытался говорить о смене парадигмы управления в масштабах всей компании, я упирался в стену непонимания" [1]
"В СТО Фильтр директор, очарованный 'прогрессивной' IT-командой, выбрал путь 'зоопарка'. Прошло пять лет - воз и ныне там" [3]
Про саботаж IT-отрасли - это моя ежедневная боль:
"Бизнес-модель франчайзинга '1С'... Чувствуете, где заложен конфликт интересов? '1С' продает 'коробки', а не успех" [2]
"Встроенный BPM в '1С' - это не фундамент для построения адаптивной, процессно-ориентированной компании. Это удобный 'таск-менеджер' для автоматизации примитивных административных маршрутов" [2]
Про "автоматизацию хаоса" - это было моим кошмаром:
"Попытка автоматизировать то, что и так работает криво, закрепляя в коде лишние согласования и дублирующие друг друга действия" [2]
"Мы уже поняли простую истину: покупка нового софта не решит проблемы, если сами бизнес-процессы не организованы. Автоматизация хаоса - это просто оцифровка беспорядка" [2]
Мой тактический ответ через ДРАКОН стал "шлюзом" в вашу стратегию, но я понял, что этого недостаточно. Именно поэтому я являюсь соратником Олега Захарчука и платформы АСис, находясь в прямой связи с разработчиком.
Платформа АСис - это тот самый стратегический ответ на все четыре проблемы, которые вы обозначили:
В своих статьях я прихожу к тому же выводу, что и вы:
"Платформа АСис, в отличие от SAP/ERP, построена не на 'колодцах', а на единой метамодели. Она не автоматизирует хаос, а заменяет его целостным цифровым двойником вашей компании" [3]
"Эта связка - ДРАКОН + АСис + ИИ - это инженерный фундамент для построения настоящей, работающей холакратии" [3]
Таким образом, ваша стратегическая концепция и моя тактическая практика сошлись в одной точке:
Вы дали диагноз и стратегический императив. Я предлагаю тактический инструмент (ДРАКОН) для "первой помощи" бизнесу. А платформа АСис предлагает готовую технологическую основу для полномасштабного перехода на новую парадигму.
Я понимаю, что мои отдельные победы с ДРАКОНом были лишь симптоматическим лечением. Настоящее исцеление бизнеса требует именно того системного подхода, который предлагает АСис и который вы так точно описали.
Именно поэтому я не просто сторонний наблюдатель, а соратник этой платформы. Потому что только такие целостные решения способны сломить сопротивление системы и дать бизнесу шанс на выживание в новых условиях.
Источники:
[1] "От Intel 086 до нейросетей: исповедь охотника за бизнес-процессами"
[2] "Миллионы на ветер: как не купить IT-систему, которая вас разорит"
[3] "Почему ваш бизнес хромает: история одного IT-ортопеда"
Спасибо за позитивную рецензию на мою т.з! Рад в Вашем лице найти единомышленника! Где я могу познакомиться с Асис (поделитесь хорошими ссылками)?
Про саботаж от IT: мои многолетние попытки зайти в головную компанию 1С для совместной корректной постановки задачи и разработки нужной в настоящей бизнес-среде платформы - все закончились снобистским отказом (ни разу даже на мои обращения не ответили)(((( А франчайзи 1С - не хотят тратить свои силы и время, когда и так все продается (у каждого уже есть какая-то своя рабочая бизнес-ниша).
В такой диспозиции, где:
IT отрасль цинично не хочет меняться и в текущей ситуации импортозамещения купается в золотом дожде от Предприятий и грантов от Государства, которые покупают/финансируют все что им не предложи
Предприятия не имея компетенций оценить качество навязываемого (других нет) IT продукта тратятся на "Дохлую лошадь", идя на поводу у IT отрасли (Предприятия не занимают позицию компетентного и требовательного Потребителя, берут что есть/дают, а не то что надо)
Государство - ровно в такой же позиции как и Предприятия, только еще и финансирует этот "банкет" для IT отрасли
я вижу только следующую стратегию выхода из системного кризиса: донести до Государства и Предприятий, что им за дорого продают "Дохлую лошадь", с тем, чтобы они перестали покупать у IT "то что есть" и финансировать цифровизацию этой "Дохлой лошади". Может быть тогда IT отрасль развернется к проблеме "лицом"?
IT отрасли нужно учиться, учиться и еще раз учиться, ибо страшно далеки они от потребностей рынка, и слишком долго они "почивали на лаврах" своих допотопных решений!
Чем болен средний бизнес? Статья 6. Как описание может остановить хаос многомиллионных потерь