Карнавал автоматизации
На Новый год я протестировала генератор желаний и рассказала, чего хочу.
А хочу я на карнавал в Венецию.
Я помню маски и костюмы, семьи в образах, незнакомых людей с глинтвейном и печеньем. Триумф креатива, артистизма, тщеславия и позёрства среди отражений дворцов в воде и тишины города без автомобилей.
Но промпт подошёл к делу основательно.
Мы обсудили, зачем мне это нужно, и свели желание к потребности.
Карнавал в Венеции превратился в поиск свободы. Правда, мы так и не определились — внутренней или внешней.
Формулировка стала глубже. Только это уже не было моим желанием.
Исчезла картинка: я иду по Венеции в полноценном костюме. Мне хотелось найти собственный образ, полгода придумывать его, изучать материалы, развивать насмотренность. Под видом позёрства снять привычную социальную маску.
А затем исчезли вода, февральский воздух и сама Венеция.
Примерно так иногда автоматизируют бизнес-процессы.
На схеме всё прекрасно: специалист получает данные, применяет формулы и формирует результат.
Но основную часть его работы могут занимать не вычисления.
Он сопоставляет источники, замечает противоречия, возвращается к проверенным сведениям, сравнивает новый объект со знакомыми случаями. И решает не столько, какую формулу применить, сколько как интерпретировать данные без потери смысла.
Сам расчёт автоматизировать легко.
Но решение о том, что именно считать и можно ли доверять исходным данным, осталось за пределами модели процесса.
Обычно всё это сворачивается в одну операцию: «Специалист анализирует информацию».
Но для надёжной автоматизации недостаточно передать ИИ глагол «анализирует».
Нужно определить источники, границы контекста, основания для сомнения, критерии достаточности и условия остановки.
В профессиональном решении есть неочевидные действия, которые сам специалист не воспринимает как работу. Для него это просто способ думать.
Я люблю хрестоматийную историю создания домашней хлебопечки Matsushita.
Инженеры долго не могли получить правильное тесто. Тогда разработчица Икуко Танака пошла учиться к пекарю Osaka International Hotel.
Повторяя его движения, она обнаружила: пекарь не просто растягивает тесто, а одновременно скручивает его. Сам мастер мог не считать это отдельной операцией.
Для него это и означало «замесить правильно».
Это движение пришлось воспроизвести в конструкции хлебопечки.
Если бы процесс описали как «заложить ингредиенты — замесить — выдержать — выпечь», схема была бы правильной.
Только хлеб — неправильным.
В своей работе я встречала другой подход.
Команду собирали и спрашивали: — Что ещё можно автоматизировать?
Специалисты предлагали отдельные функции. Затем предложения обобщались и превращались в перечень улучшений.
Живой опыт становился списком операций.
Из него исчезал контекст, затем исключения, а вместе с ними — логика профессионального выбора.
Специалист, который мог бы показать «скручивающее движение», становился кандидатом на сокращение. А организация получала типовой процесс, лишённый всего, что помогало ему работать в реальности.
Отличить профессиональное условие от лишнего действия или привычки можно только после исследования опыта, а не после увольнения его носителя.
Раньше система могла считать, а человек — проверять данные, интерпретировать результат и разбираться с исключениями.
Теперь ИИ хотят передать и само профессиональное решение.
И оказалось, что готового описания нет. Контекст свернули до слов «проверяет» и «анализирует», за которыми скрывалась основная часть работы.
Поэтому до вопроса «что здесь можно автоматизировать?» я бы спросила:
Что обеспечивает качество результата?
Как специалист понимает, что данным можно доверять?
Какие очевидные для него действия не попали в описание?
И что исчезнет вместе с человеком, если сначала автоматизировать операции, а разбираться с опытом уже после сокращения?
Иначе можно получить безупречно автоматизированную свободу.
Только вы, возможно, как и я, хотели в Венецию.
#ИИ #автоматизация #бизнеспроцессы #цифроваятрансформация #управлениезнаниями
· 1 ч
Самые дорогие ошибки в автоматизации появляются на этапе описания процесса. Команда обычно хорошо фиксирует входы, действия и выходы, но упускает то, как специалист распознаёт сомнительные данные, какие источники считает приоритетными и в какой момент перестаёт доверять привычной схеме.
В таких проектах полезно не ограничиваться интервью "как вы это делаете". Лучше разбирать реальные кейсы вместе с исполнителем: обычный случай, ошибочный, пограничный, срочный. Просить показать, где он изменил бы решение, что проверил дополнительно и почему. Именно там находятся правила, которые нельзя восстановить по регламенту или списку функций.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён