Добрый день, Оксана 👋🏻 Да, я тоже кекнул с поста на английском про BPMN 2.0 😌 Да мне все равно, кто фактически это запостил. Хоть Аматэрасу собственной божественной волей 😌

Я так понимаю, ты японизировался.

Добрый день, Иван! Да, я понимаю, что личность пишущего не так важна, просто при таком профиле (опять же, моё личное суждение, ограниченное только моими глазами и выводами), я бы не ожидала чего-то действительно серьёзного)

Нет, с чего ты взял? 🙄

С недавних пор живёшь по времени Токио и упоминаешь Аматэрасу, о которой среднестатистический россиянин, не интересующийся Японией, не знает. Отсюда предположение о ментальном сдвиге, который я и назвал "японизацией".

Что, если я тебе скажу, что я там жил и работал продолжительное время и часть моих проектов, не связанных с той профессиональной деятельностью, которую мы тут периодически увлекательно обсуждаем, нацелены исключительно на японскую аудиторию? 😌 У меня даже целый пост есть про опыт японской "корпоративной ответственности", которому я был свидетелем и непосредственным участником 😌

Ну как скажешь, тогда и обсудим.

Есть слово wapanese. Или weeaboo %))

Да там обычный нейрослоп.

Я пойду дальше - не имеющий отношения к реальному миру вообще 😌

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

На мой взгляд критерий есть, и он не в технологии.

Внедрение: ИИ поставили в процесс, спроектированный под человека. Контроль прежний, человек читает каждый ответ.

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

Трансформация: уровень индустрии, а не компании. Конвейер стал ею, когда под него переписали стандарты, а не когда его запустил один завод. Роботов не перестали проверять, проверку перенесли с детали на процесс. С ИИ будет так же, и стандарта для этого пока нет.

Поэтому всё, что сейчас называют ИИ-трансформацией, по определению внедрение.

Термин не ложный, он преждевременный.

Добрый день, Станислав 👋🏻 Давайте я немного деконструирую ваши три категории, потому что там два зеленых и одно соленое. Внедрение и проектирование описывают способы организации деятельности с применением технологии. Ваша категория "трансформация" описывает масштаб распространения изменений. Теперь главный вопрос: почему трансформация должна происходить именно на уровне индустрии? Если предприятие радикально изменило способы создания ценности, организационную структуру, процессы и механизмы управления, почему мы не можем говорить о его трансформации до тех пор, пока аналогичные изменения не произошли у конкурентов? Ваш пример с конвейером меня немного ввел в замешательство. Возможно, вы его раскроете немного по-другому. Конвейер представляет собой способ организации производства, а трансформация обозначает изменение состояния некоторой системы. Во-вторых, почему изменение стандартов должно быть критерием трансформации? Стандартизация может быть следствием распространения новой практики, а не условием, при котором изменения впервые становятся трансформационными. Пока, на мой взгляд, получается, что вы самостоятельно определили трансформацию как исключительно отраслевое явление, а затем на основании этого определения объявили все изменения на уровне компаний обычным внедрением?

Станислав, ты описал не субстантивные характеристики, а акцидентальные.

Признаю, способ и масштаб это разные вещи. Но вывод у меня другой.

Трансформация это изменение состояния. Вопрос, какой системы. Компания, перестроившая процессы под ИИ, изменила своё состояние, это её трансформация, спорить не буду. Но термин «ИИ-трансформация», как мне кажется, заявляет большее - смену подхода. А подход это не то, что одна компания делает внутри, а то, с чем взаимодействует остальной мир: партнёры, клиенты, регуляторы, рынок труда. USB и Lightning существовали параллельно годами, и это ещё не была трансформация. Она произошла, когда победила одна система и всё остальное стало строиться под неё. Пока с ИИ каждая компания делает свой разъём, а мир вокруг не обязан с ним взаимодействовать, подход не сменился.

Стандарты не условие, а свидетельство: они фиксируют, что подход сменился. Сегодня таких свидетельств нет, значит, полной трансформации нет. Есть внедрения и отдельные перепроектирования.

Критерий, который вы просили, при этом остаётся: изменились ли допущения об исполнителе и контроль. Если человек читает каждый ответ - не изменились.

Доброе утро, Станислав 👋🏻 Вы снова предлагаете критерий, который не отвечает на мой исходный вопрос 😌 Смотрите, изменение допущений об исполнителе и контрольных процедур характеризует особенности проектного решения, но никак не разграничивает внедрение и трансформацию. Давайте представим себе, что компания внедрила ИИ для обработки документов, полностью передав ему выполнение операций и оставив человеку только контроль исключений. Ваш критерий выполнен. Но почему это трансформация (по вашему критерию), а не обычное внедрение системы автоматизации? И наоборот, организация может радикально изменить бизнес-модель, структуру и процессы с применением ИИ, сохранив обязательную проверку результатов человеком. Разве это отменяет факт организационной трансформации? У меня сложилось впечатление, что вы пытаетесь определить характер изменений организации через особенности реализации конкретного технологического решения. Но внедрение и трансформация вообще не являются взаимоисключающими категориями: первое обозначает введение решения в эксплуатацию, второе характеризует изменение состояния системы. Но мне искренне и неиронично нравится, что вы это со мной обсуждаете 👍🏻

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

Первый пример: ИИ обрабатывает документы, человек разбирает исключения. Это внедрение, согласен. Но «контроль исключений» предполагает, что мы знаем, что такое исключение. У вероятностного исполнителя ошибка не выглядит исключением, она выглядит нормальным результатом. Поэтому система должна знать частоту ошибок своего исполнителя, измерять её выборкой, ловить дрейф и возвращать найденное в его знания. Станку, скрипту и регламенту такой контур не требовался: они делали ровно то, что сказано. Это изменение состояния системы, а не особенность решения.

Второй пример: Компания перестроила бизнес-модель и структуру с помощью ИИ, но каждый его результат проверяет человек. Это оргтрансформация, но не ИИ-трансформация: замените ИИ на людей, и система останется той же. Кто исполняет, здесь не важно, значит, состояние системы изменил не ИИ.

Так что внедрение и трансформация друг друга не исключают, тут согласен. Внедрение это акт. ИИ-трансформация это состояние, в котором ошибка исполнителя заложена в систему как управляемая величина, а не вынесена человеку на исключения.

Обсуждать тоже интересно, взаимно. Ну и помогает самому лучше это всё понять для себя.

Я поймал себя на мысли, что мы немного разошлись в предмете обсуждения. Обратите внимание: во всей нашей дискуссии я говорю о трансформации как категории изменений, а не пытаюсь сформулировать специальное определение "ИИ-трансформации". Вы же сначала согласились, что трансформация представляет собой изменение состояния системы, а теперь определяете ее через наличие определенного механизма контроля ошибок. Но это характеристика архитектуры решения, а не критерий трансформации. Мы можем внедрить ИИ-систему со статистическим контролем ошибок, мониторингом дрейфа и механизмами корректировки, вообще не изменив существенно деятельность организации. Почему это должно считаться трансформацией? Кроме того, ваше утверждение, что станкам и традиционной автоматизации подобные механизмы не требовались, просто исторически неверно. Статистическое управление процессами, выборочный контроль качества и управление отклонениями существуют уже десятилетиями. Вероятностные модели имеют некоторую свою специфику, но сам принцип управления ошибками исполнителя далеко не нов. В итоге, как мне видится, вы пытаетесь описать особенности проектирования ИИ-систем, но по-прежнему не объясняете, где проходит граница между внедрением технологического решения и трансформацией системы, в которой оно применяется.

По станкам поправлю себя: У станка отклонение это особая причина, её находят и устраняют. У ИИ ошибка это общая причина, свойство исполнителя: ею управляют как долей. Контур тот же, предмет контроля другой.

А критерий предлагаю такой: Замените ИИ на людей. Если схема работы осталась прежней, состояние изменил не ИИ, это внедрение инструмента, даже если вокруг него перестроили структуру. Если схему придётся перестраивать, значит, работа была построена на свойствах этого исполнителя, и это ИИ-трансформация.

Одна проверка, без степени контроля и без определения трансформации вообще.

Вы так и будете как маленькие гадать на кофейной гуще, будучи не в состоянии разобраться в предмете спора?

В споре рождается истина ☝️ Плюс я себе это фиксирую на будущее. Я в этом вижу для себя пользу

Ох, вы снова предложили критерий, который определяет совершенно другое явление. Необходимость перепроектировать процесс при замене ИИ человеком свидетельствует о зависимости процесса от характеристик исполнителя, но не о трансформации. Смотрите. Замените промышленного робота человеком или автоматизированную систему обработки заказов сотней операторов. Во многих случаях процесс также придется перепроектировать. По вашей логике, любое подобное внедрение становится отдельным видом трансформации. Кроме того, общие и особые причины вариации существуют как в традиционных производственных процессах, так и в ИИ-системах. Это не различие между станком и вероятностной моделью 😌 И, наконец, вы за нашу дискуссию уже предложили несколько разных критериев, каждый из которых определяет что-то свое. Хочу намекнуть совсем явно: прежде чем искать признаки ИИ-трансформации, все-таки необходимо определить, что мы понимаем под трансформацией вообще 🙄

Так, тебя на hh забанили что ли? 🙄 Не мешай Станиславу размышлять 👆🏻

Согласен, мы видимо понимаем этот термин по разному.

Не соглашусь, что предлагаю разные критерии, для меня это одно и то же. Я пытаюсь разными словами донести свою мысль.

Возможно, стоит взять паузу

Да-да, я понимаю 👍🏻 Моя задача не переубедить вас или выставить каким-то неправым, давайте я просто покажу, почему они разные. От самого первого (про целую отрасль/индустрию) вы отказались, поэтому, по сути, остались два основных. Сначала вы определили ИИ-трансформацию как состояние, в котором ошибка вероятностного исполнителя заложена в систему как управляемая величина. Затем предложили другой критерий: необходимость перепроектирования процесса при замене ИИ человеком. Но это два разных признака, которые могут существовать независимо друг от друга 😌 Например, мы внедрили ИИ для обработки документов, предусмотрели статистический контроль ошибок, мониторинг дрейфа и механизмы корректировки. При этом сохранили возможность выполнять те же операции силами сотрудников без изменения схемы процесса. Первый критерий выполнен, второй нет. Обратная ситуация: мы построили процесс, экономически жизнеспособный исключительно благодаря производительности ИИ. Замена его людьми потребует полного перепроектирования. Однако специальных механизмов статистического контроля ошибок мы не предусмотрели. Второй критерий выполнен, первый нет. Таким образом, управление ошибками вероятностного исполнителя и зависимость организации процесса от характеристик ИИ не являются одним и тем же признаком. Это не разные формулировки одной мысли, а логически независимые характеристики системы. Именно на это противоречие я и хочу обратить ваше внимание 😌 Давайте возьмем паузу, если нужно 👍🏻

А можно я немного ворвусь? Меня просто терминология чуток резанула, не могу сдержаться и не поправить.

Изменение состояния — это переключение.

А трансфрмация — изменение самой структуры, то есть набора состояний и условий их переключения.

Знаете, тот факт, что мы не можем определиться с терминологией и по разному понимаем одни и те же слова и есть отсутствие стандарта.

Добрый день, Станислав 👋🏻 По этому комментарию у меня сложилось впечатление, что вы не совсем понимаете, что тут происходит 😌 У меня изначально есть ответ на свой вопрос, а также вполне определенное понимание терминов. Мне просто интересно провести вас по вашей же цепочке рассуждений, при этом не навязывая каких-то своих ответов. Дело ведь не в том, что мы по-разному понимаем термины. Я просто последовательно проверяю предложенные вами критерии на логическую согласованность. Для этого нам совершенно необязательно даже иметь единый стандарт терминологии, достаточно, чтобы критерии не противоречили друг другу и позволяли однозначно классифицировать рассматриваемые случаи 😌

Добрый день, Никита 👋🏻 А где вы увидели кейс? Для разбора какого "кейса" вы предлагаете свою проверку?

Все фломастеры на вкус одинаковые 😆 Добрый день, Роман, простите, не удержался 😅