Создание ИИ агента можно оставить своей ИТ-команде, если она умеет работать с моделью, подключать нужные программы и сопровождать получившееся решение. Когда этих возможностей хватает лишь на часть задачи, разумно заказать недостающую часть. Мы рекомендуем выбирать исполнителя отдельно для обработки запроса, каждого подключения и дальнейшей поддержки. Так директор сможет использовать знания своих инженеров, не поручая им работу, к которой они пока не готовы.
Нейропрем внедряет ИИ и автоматизирует бизнес-процессы и производство. Мы предлагаем интеграцию с действующими учетными системами, ЭДО и камерами на тех участках, которые предприятие решило поручить внешнему исполнителю. Наличие своей ИТ-команды помогает предметно определить эту работу: какой обмен она берет на себя, а какой предстоит создать отдельно.
Может ли наша ИТ-команда сделать все сама?
Мы рекомендуем самостоятельную разработку, когда команда готова отвечать за весь выбранный процесс: от разбора входящего материала до результата в рабочей программе. Умение обслуживать учетную систему закрывает только часть этой готовности. Отдельно стоит проверить работу с моделью и возможность поддерживать решение наряду с текущими задачами.
Для разговора с руководителем ИТ полезно разделить компетенции. Знание своей программы означает, что инженер понимает ее справочники, доработки и способы обмена. Работа с моделью требует проверки ее поведения: что происходит при неполном сообщении, противоречащих вложениях или запросе, который выходит за выбранную задачу. Сопровождение предполагает человека, который сможет увидеть остановку и проверить исправление. Мы предлагаем оценивать эти возможности по конкретной операции.
Например, в возможном сценарии мастер отправляет заявку на запасную деталь. Будущее решение должно разобрать описание, запросить сведения в учете и подготовить материал для снабженца. Внутренний инженер может знать, где хранится остаток, но еще не уметь проверять, какую позицию модель выбрала по свободному описанию. В таком случае работу с моделью стоит выделить отдельно, сохранив знакомое подключение внутри компании.
Самостоятельное создание также не означает обучение собственной языковой модели. Оцените способность команды собрать решение вокруг подходящего готового компонента: связать его с процессом и проверить результат. Разработку всего технологического основания с нуля в такое поручение включать не нужно.
Если команда подтверждает готовность по всем этим частям, заказывать разработку только ради внешнего исполнителя незачем. Мы советуем уточнить, какую текущую работу придется отложить ради нового решения. Обещание инженера заняться агентом между обращениями сотрудников еще не означает, что предприятие выделило ресурс на создание и поддержку.
Когда стоит заказать разработку, а когда делать вместе?
Мы предлагаем выбирать между самостоятельной, заказной и совместной работой по пробелам в компетенциях и доступах. Внешняя разработка уместна там, где компания может передать конкретную инженерную задачу и организовать ее проверку. Совместная работа имеет смысл, если части действительно удобно разделить между людьми, которые знают их лучше.
| Вариант | Когда рекомендуем рассматривать | Что остается внутри предприятия |
|---|---|---|
| Сделать самим | Команда умеет создавать агентную часть, подключать программы и выделяет людей на поддержку | Разработка, проверка и сопровождение выбранного решения |
| Заказать разработку | Внутреннюю команду решили не занимать созданием решения, но она может обеспечить согласованный доступ и приемку | Знание процесса, выбор допустимых материалов, участие в проверке и координация поддержки |
| Создать совместно | Свои инженеры уверенно берут отдельные подключения или агентную часть, остальные работы можно выделить | Собственная часть разработки и согласованная граница обмена с внешней частью |
Заказная разработка не дает основания исключать ИТ-команду из обсуждения. Мы рекомендуем поручить ей подтвердить, какие обращения к действующим программам допустимы и кто ведет их доработки. Человек со стороны может получить описание полей, но значение поля для работы предприятия должен подтвердить тот, кто им пользуется.
В совместной схеме возможны разные распределения. Ваша команда создает обработку запроса, внешний разработчик занимается незнакомым подключением. Или свои инженеры обеспечивают обмен с учетом, а специалист со стороны разрабатывает работу с моделью. Выбирайте такое разделение по навыкам, без предположения, что агентная часть обязательно должна быть внешней.
У совместного создания есть встречное требование: согласовать данные на границе частей. Если внутреннее подключение возвращает общий остаток, а агенту нужен доступный для новой заявки, спор возникнет даже при исправном обмене. До разделения работы определите, что означает ответ каждой программы и кто подтверждает этот смысл.
Как разделить подключения между своими и внешними инженерами?
Мы рекомендуем делить работу по конкретным действиям программы: получить сведения, найти документ, вернуть статус, подготовить запись. Формулировка «подключить учет» слишком широка для распределения. Рядом с каждым действием полезно указать создателя подключения и будущего сопровождающего.
Продолжим объясняющий сценарий с запасной деталью. Мастер называет узел и прикладывает описание потребности. Агентная часть разбирает сообщение; подключение к учету получает подходящие позиции и доступные остатки; снабженец рассматривает подготовленный материал. На такой схеме видно, что знание справочника и работа со свободным текстом относятся к разным частям.
Мы предлагаем оставить внутренней команде получение сведений из учета, если она знает используемую конфигурацию, проверила допустимый способ обмена и готова его поддерживать. Для агентной части в этом варианте нужно согласовать, какие поля она получит и что делать, если подходящей позиции нет. Обратное распределение тоже допустимо, если свои инженеры лучше подготовлены к работе с моделью, чем к нужному обмену.
Для подключения к ЭДО отдельно опишите получение документа и получение сведений о его состоянии. Разработчик, который умеет забрать файл, еще не подтвердил готовность остальных действий выбранного процесса. Определите, какие сведения нужны сотруднику, откуда они приходят и кто проверит их соответствие исходному документу. Здесь мы обсуждаем распределение технической работы, без передачи агенту права подписывать документы.
Для камер мы предлагаем разделять доступ к изображению и его обработку. Ваша ИТ-команда может взять сеть и получение видеопотока, оставив специалисту задачу распознавания нужного события. Критерий события задает предприятие: что именно требуется увидеть на участке и как сотрудник подтвердит результат. Если выбранная операция не использует изображение, камеры в схему включать незачем.
Внешнюю часть интеграции мы предлагаем обсуждать на уровне нужного действия и установленной программы. Возможность обмена потребуется проверить по ее конфигурации и доработкам. Обещание подключить любую систему без такой проверки мы не даем.
Что придется делать нашим сотрудникам при заказной разработке?
Мы рекомендуем оставить внутри компании объяснение рабочего смысла, приемку результата и выбор порядка действий сотрудников. Разработка со стороны может реализовать согласованное правило, но само правило должно исходить от предприятия. ИТ-команда и специалист процесса здесь выполняют разные роли.
В сценарии с запасной деталью инженер знает поля учета, снабженец понимает допустимую замену, мастер подтверждает потребность участка. Если в справочнике есть похожие позиции, только доступа к базе недостаточно для выбора. Мы советуем привлекать к проверке человека, который может объяснить, почему конкретная позиция подходит или требует уточнения.
Предметному специалисту полезно показать исполнителю обычную заявку и возможное исключение вместе с ожидаемым результатом. Сохраните пояснения рядом с такими материалами: где нужна точная позиция, когда допустима замена и кому передавать неопределенность. Это рабочая информация для разработки, без требования заранее написать регламент на весь отдел.
При распределении работы также стоит определить, кто объяснит сотрудникам новое действие в их программе. Мы предлагаем проверить это на практической ситуации: снабженец получил подготовленный материал, увидел неподтвержденную позицию и смог передать уточнение ответственному. Если нужного действия в рабочем окне нет, вопрос относится к составу интерфейса и интеграции. Одной инструкции пользователю его не закрыть.
От своей команды не требуется воспроизводить все знания внешнего разработчика. Заранее выберите нужный уровень владения: самостоятельно менять выделенную часть или понимать ее вход, выход и порядок обращения за исправлением. Эти варианты дают разный объем передачи, и его лучше связать с будущей ролью инженеров.
Можно ли работать с внешним разработчиком без передачи рабочей базы?
Мы рекомендуем отдельно согласовать доступ решения к программам и доступ людей, которые его создают. Внешний исполнитель не должен автоматически получать рабочую базу лишь потому, что будущему агенту нужны сведения из нее. При выборе способа разработки нужно определить допустимые материалы и место их обработки.
Возможный сценарий: компания разрешает передать описание полей и подготовленные тестовые заявки. Внешний разработчик создает свою часть на этих материалах, внутренняя команда устанавливает ее в разрешенной среде и проверяет на рабочих данных. Для исправлений наружу передают только согласованные сведения об ошибке. Мы предлагаем рассматривать такой вариант, если ограничения доступа позволяют разработать и проверить выбранную часть.
Тестовый материал потребует отдельной проверки. Название «обезличенная заявка» само по себе ничего не говорит о сохранившихся в ней обозначениях, вложениях и комментариях. Включите в согласование также сообщения об ошибках и журналы: сведения могут попасть в них при проверке обмена.
Своя разработка тоже требует понимания пути данных. Если штатные инженеры используют внешнюю модель, принадлежность команды не удерживает отправленные ей материалы внутри предприятия. Для каждого рассматриваемого варианта выясните, где работает модель, какие сведения она получает и где сохраняются записи обращений.
Мы можем предложить размещение решения на инфраструктуре заказчика, чтобы данные оставались у него. Допустимый доступ разработчиков при этом нужно согласовать отдельно. Если пригодные тестовые материалы или нужный доступ предоставить нельзя, мы рекомендуем оставить соответствующую часть внутренней команде либо изменить границу внешней работы.
Кто исправит обмен после обновления программы или ухода инженера?
Мы рекомендуем назначать сопровождение каждой части до выбора ее создателя. Подключение может написать внешний разработчик, а поддерживать внутренняя команда, если предусмотрена передача. Либо сопровождение остается внешним и его состав согласуют отдельно. Сам факт сдачи разработки не определяет дальнейшую поддержку.
Для передачи своей команде мы предлагаем согласовать доступный код или настройки, описание обмена и способ проверки. Инженеру должно быть понятно, какие сведения передаются, где искать результат и как отличить ошибку подключения от ошибки обработки запроса. Получение архива файлов без возможности разобраться в них не подтверждает готовность принять поддержку.
Рассмотрим возможную остановку в том же сценарии. Потребность разобрана, запрос остатков отправлен, но учетная программа отказала в доступе. В другом варианте сведения получены, однако агентная часть выбрала неподходящую позицию. Мы рекомендуем сохранять различимые результаты этих обращений, чтобы сопровождающий понимал, какой участок проверять. Передачу содержимого журналов внешнему исполнителю нужно согласовать по правилам предприятия.
В совместной разработке назначьте технического координатора всей связи. Ему не обязательно исправлять каждую часть лично; нужно определить место остановки и передать задачу ее сопровождающему. Тогда директору не придется выяснять, почему каждый исполнитель считает свою часть исправной.
Готовность внутренней поддержки полезно проверить с инженером, который не создавал подключение. Дайте ему согласованное описание и тестовую ситуацию: сможет ли он найти результат и определить следующий шаг при отказе? Такая проверка покажет, достаточно ли передачи для выбранной роли команды, без обещания полной независимости от внешних специалистов.
Что поручить руководителю ИТ до выбора исполнителя?
Поручите отметить в схеме выбранного процесса подключения, которые команда готова создавать и сопровождать самостоятельно. Мы рекомендуем получить короткую рабочую запись с конкретными действиями программ и ответственными. Она даст основания выбрать внутренний, внешний или совместный объем разработки.
- Подпишите обращения к программам понятными действиями: получить остаток, найти документ, вернуть состояние обмена.
- Для каждого подключения отдельно отметьте, кто готов его создать и кто будет сопровождать.
- Рядом с неподтвержденной готовностью запишите причину: способ обмена не проверен, нет доступа, не выделен человек или нужна передача знаний.
- Отдельно обозначьте готовность команды создавать агентную часть и проверять ее поведение на материалах процесса.
- Для возможной внешней работы укажите допустимые материалы, среду проверки и участие своих инженеров.
Для директора полезный итог выглядит как решение по отдельным частям, с объяснением оставшихся пробелов. Отсутствие навыка работы с моделью не требует отдавать наружу привычный обмен с учетом. Нехватка времени на поддержку тоже не доказывает, что создание нужно заказывать целиком. Мы рекомендуем сохранить эти причины раздельно при определении внешнего объема.
Например, ваша команда готова создать обработку заявок, а подключение к учету хочет заказать и затем сопровождать сама. В таком варианте мы советуем сначала определить, что ей потребуется получить вместе с подключением и какой способ обмена она сможет поддерживать. От этого зависит состав заказываемой инженерной работы, даже если действие на схеме уже выбрано.
Предложение нашей компании Нейропрем - интеграция с действующими программами. При заказе подключения с передачей своим инженерам стоит сразу определить, какие изменения они будут выполнять сами, а для каких потребуется внешняя поддержка. Это зависит от способа обмена и навыков команды, которые общая схема процесса не раскрывает. Начать разговор с нами можно с описания того, что ваши инженеры уже меняют в учетной программе. Обсудим, какой объем сопровождения разумно оставить им и какие настройки, описания и способы проверки включить в передачу; неподтвержденные возможности выделим для проверки руководителем ИТ. Оставьте имя и телефон в форме ниже. Мы перезвоним в течение двух-трех часов.