前置部署工程师的职责以及何时需要聘请他们

前置部署工程师是一种软件工程师，他们直接在客户的业务流程中工作，而非仅仅处理待办任务。他们会与工具的使用者一起，了解实际的工作流程，根据真实数据构建第一个版本，并持续跟进直至该工具能够融入日常运营。这一称谓源于那些向大型企业销售复杂软件的公司——只有当产品被整合到客户的系统与工作习惯中后才能真正发挥作用。

这种工作方式同样适用于中小型企业，甚至可能更为合适。小型企业很少拥有能够将模糊的想法（“人工智能能读取我们的供应商证书吗？”）转化为具体需求的内部IT团队，因此需要一名既能进行需求分析、编写代码又能对最终结果负责的人。

该职位的实际职责

大部分工作都在编写代码之前和之后进行。一个典型的项目会经历四个阶段：

• 需求分析。与实际执行任务的人员进行访谈，查看真实的文档、电子表格和系统，同时以书面形式描述当前流程及其异常情况。异常情况最为重要，因为自动化往往会在这些地方出问题。
• 原型开发。在几天内基于真实数据样本制作出可使用的工具，而非仅提供演示文稿。虽然这个原型较为粗糙，但人们可以点击它并指出存在的问题。
• 正式部署。包括访问控制、错误处理、日志记录、监控、备份功能，以及由专人审核不确定结果的环节；此外还有测试集，用于确认每次修改后工具是否依然正常运行。

交接与支持。包括相关文档、针对团队的简短培训，以及约定好的问题报告和变更申请方式。

其与传统项目的区别

在固定范围的项目中，客户制定需求，供应商按照需求进行开发，双方可能会就需求的含义产生分歧。当问题较为明确时，比如新建网站或已知的系统集成，这种方式可行。

而人工智能自动化在初期往往并不清晰。没人知道有多少发票的格式异常，供应商多久会发送扫描件而非PDF文件，或是会计在未书面记录的情况下遵循了哪条规则。通过实际操作，驻场工程师能够弄清这些问题，因此项目范围是由实际证据而非猜测来确定的。

它也与临时人员补充有所不同。临时开发者是从团队负责人那里接收任务。而前置部署的工程师则需要自行决定该开发什么内容，当某个想法不可行时提出反对意见，并评估最终成果是否有效。

小型企业何时需要这类人才

在以下情况同时存在时，这种模式才具有意义：

• 某些重复性工作每周要耗费大量时间：阅读文档、在系统间复制数据、检查截止日期、回答重复的问题；
• 数据分散在多个地方：ERP或1C系统、Excel文件、邮件附件、共享文件夹、扫描后的纸质文档；
• 已有团队尝试过聊天机器人或ChatGPT原型，其在演示环境中可行，但在实际应用中却不行；
• 企业内部没有既懂业务又懂技术的开发人员。

如果流程每月都在变化，没有专人每周花几小时解答问题，或者已有现成工具能完成工作，那么这样做就没什么意义了。这种情况下直接购买该工具吧。

前两周会有哪些进展

我们的服务以两周的固定价格周期开始。服务结束时，您将获得三样东西：一份包含实际数据中发现的异常情况的流程书面图谱、一个基于您部分文档或记录运行的原型，以及关于实际生产所需时间的真实估算，包括哪些部分根本不应自动化。

之后由您决定是否继续合作。完整的服务周期通常为两到六周，具体时长取决于涉及的系统数量以及结果需要多少审核工作。

雇佣之前应询问的问题

• 工程师会从第一周就开始使用我们的真实数据吗？数据访问是如何控制的？
• 我们如何确认该工具是正确的？应要求提供测试集和评估指标，而非口头承诺。我们在评估与人工审核方面的说明介绍了具体标准。
• 模型在何处运行？我们的数据会有任何流出我们基础设施的情况吗？有关机密文件的处理方式，请参阅用于机密文件的本地AI方案。
• 交接之后会发生什么？如果供应商更改发票格式，谁来负责解决？

如果答案含糊不清，项目也会如此。如果您希望详细了解具体流程，我们的前置部署工程服务页面会介绍我们开展此类工作的方式，您也可以通过联系表单与我们取得联系。