Чем занимается инженер, работающий непосредственно в процессе, и когда вам он нужен

Инженер, работающий непосредственно у клиента, — это программист, который занимается реализацией решений внутри процессов клиента, а не в отдельном отделе разработки. Он работает вместе с теми, кто будет использовать инструмент, изучает способы выполнения работы на практике, создает первую версию на основе реальных данных и остается до тех пор, пока инструмент не начнет использоваться в повседневной деятельности. Такой подход характерен для компаний, которые продают сложное программное обеспечение крупным организациям, где продукт может функционировать только после того, как его интегрируют в системы и процессы клиента.

Тот же подход подходит и для малых и средних компаний, возможно, даже лучше. У малого бизнеса редко бывает внутренняя IT-команда, способная преобразовать расплывчатую идею («Может ли ИИ читать наши сертификаты поставщиков?») в техническое описание. Ему нужен человек, который сможет провести анализ, написать код и взять на себя ответственность за результат.

Чем на самом деле занимается этая должность

Большая часть работы выполняется до и после написания кода. Типичный проект проходит через четыре этапа:

• Исследование. Интервью с теми, кто выполняет работу, просмотр реальных документов, таблиц и систем, а также письменное описание текущего процесса вместе с его исключениями. Именно исключения имеют наибольшее значение, поскольку именно здесь возникают сбои при автоматизации.
• Прототип. Рабочий инструмент на примере реальных данных, созданный в течение нескольких дней, а не просто презентация. Он грубый, но люди могут им пользоваться и указывать на ошибки.
• Промышленное внедрение. Контроль доступа, обработка ошибок, ведение журналов, мониторинг, резервное копирование, этап проверки, на котором человек утверждает сомнительные результаты, и набор тестов, показывающий, продолжает ли инструмент работать после каждой изменения.

Передача и поддержка. Документация, краткое обучение команды, а также установленный способ сообщения о проблемах и запроса изменений.

В чем это отличается от классического проекта

В проекте с фиксированным объемом работ клиент формулирует требования, поставщик их реализует, и обе стороны спорят о том, что именно подразумеваются этими требованиями. Этот подход работает, когда проблема хорошо понятна, например, при создании нового веб-сайта или реализации известной интеграции.

Принципы автоматизации с использованием ИИ редко ясны с самого начала. Никто не знает, сколько счетов имеют нестандартную структуру, как часто поставщик присылает скан вместо PDF или какое правило бухгалтер применяет, не записав его. Инженер, работающий непосредственно над проектом, выясняет это, работая с материалами, поэтому объем работ определяется фактами, а не догадками.

Это также отличается от найма дополнительного персонала. Разработчик, работающий в рамках такой модели, получает задачи от руководителя команды. От инженера, работающего непосредственно на проекте, ожидается, что он будет принимать решения о том, что следует создать, отклонять идеи, которые не приносят результата, и оценивать эффективность полученного результата.

Когда малому бизнесу он нужен

Такая модель имеет смысл, когда верны несколько из следующих условий:

• повторяющийся процесс занимает по несколько часов каждую неделю: чтение документов, копирование данных между системами, проверка сроков, ответы на одни и те же вопросы;
• данные хранятся во многих местах: в системах ERP или 1C, в файлах Excel, в вложениях писем, в общих папках, на отсканированных документах;
• кто-то уже пробовал чат-бота или прототип ChatGPT, и он работает в демо-версии, но не в реальных условиях;
• у компании нет внутреннего разработчика, который хорошо разбирается как в бизнесе, так и в технологиях.

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

Чего ожидать в первые две недели

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

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

Вопросы, которые следует задать перед наймом

• Будет ли инженер работать с нашими реальными данными с первой недели, и как контролируется доступ к ним?
• Как мы узнаем, что инструмент работает правильно? Попросите пример набора данных для тестирования и показатели эффективности, а не просто обещания. В наших записях о методах оценки и человеческом аудите описано, как это выглядит на практике.
• Где выполняются модели, и покидают ли наши данные нашу инфраструктуру? Информацию о работе с конфиденциальными файлами смотрите в статье о локальных ИИ-решениях для конфиденциальных документов.
• Что происходит после передачи: кто будет исправлять проблемы, если поставщик изменит формат счета?

Если ответы будут нечеткими, проект тоже будет нечетким. Если вы хотите обсудить конкретный процесс, наша страница forward-deployed engineering описывает, как мы выполняем такие задачи, и вы можете ответить нам через форму обратной связи.