Перед автоматизацией полезно проверить, нужна ли операция и оправданы ли затраты ожидаемым эффектом. Но кто со стороны бизнеса способен провести такую проверку и довести гипотезу до прототипа?   Обычно роли разделены: бизнес формулирует потребность, ИТ разрабатывает решение, пользователь принимает результат.   Схема понятна, но важные детали могут теряться при передаче задачи.   Проблема проходит через несколько пересказов: пользователь описывает её руководителю, руководитель формулирует потребность, аналитик превращает её в требования, а разработчик - в решение. На каждом этапе исходный смысл немного меняется. В результате можно качественно реализовать и исправить не совсем то, что действительно мешало работе.   Работник-пользователь знает исключения, неформальные правила и причины задержек, но не всегда представляет технические возможности.   ИТ-специалист знает инструменты, но может не видеть, почему пользователь делает дополнительные шаги, которых нет в инструкции и постановке задачи.   Поэтому интересен человек на пересечении областей: он понимает процесс изнутри, оценивает смысл и эффект изменения и способен собрать прототип.   Это не FDE в классическом понимании, а бизнес-эксперт с FDE-подходом: он проверяет решение на реальном процессе.   Он не обязательно профессиональный разработчик. Важнее уметь разложить задачу на операции и до начала разработки ответить на два вопроса: нужна ли операция вообще и достаточно ли велик ожидаемый эффект? И только потом проверять гипотезу скриптом, low-code-инструментом или ИИ.   Когда пользователь видит прототип на реальной задаче, обнаруживаются исключения, ограничения и ошибочные предположения, скрытые в требованиях.   Хороший прототип отвечает не только на вопрос «Можно ли это сделать?». Он позволяет проверить, станет ли операция проще, сохранится ли полезный результат и не появится ли новая ручная работа на соседнем этапе. Иногда такая проверка подтверждает идею, иногда заставляет её изменить, а иногда показывает, что разработка вообще не нужна.   Современные инструменты снизили порог создания прототипов. Поэтому на первый план выходит способность правильно сформулировать проблему и проверить, действительно ли предложенное решение улучшает процесс.   Вероятно, бизнесу всё чаще будут нужны не только постановщики задач и пользователи готовых систем, но и внутренние создатели небольших прикладных решений.   В некотором смысле это офисные работники-энтузиасты, мотивированные снижать собственные трудозатраты. Именно они первыми замечают конкретную проблему, оценивают практическую возможность её решения и могут превратить наблюдение в проверяемую гипотезу.   Но рассчитывать только на личную инициативу недостаточно. Организации нужен понятный и безопасный маршрут: где показать прототип, кто поможет оценить эффект и риски, когда подключить ИТ и как превратить локальную находку в поддерживаемое решение. Иначе полезная идея останется «домашним» инструментом одного сотрудника или исчезнет вместе с его интересом.   Разработку, безопасность и поддержку нельзя перекладывать на энтузиаста из бизнеса. Его задача - проверить гипотезу и передать нужное решение в промышленную реализацию, а не заменить ИТ.   Должен ли современный бизнес-эксперт уметь самостоятельно проверять гипотезы и собирать прототипы? И где, на ваш взгляд, должна проходить граница между инициативой бизнеса и ответственностью ИТ?