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