开发指南 / 业务系统与流程集成
咨询、报价、订单散在不同工具中，应先改善哪一步？
从一条咨询跟到报价和开单，看看资料在哪里漏掉、谁还未接手。先改善这段工作，比一次更换所有工具更容易知道是否有帮助。
工作量增加，为什么表格开始跟不上？
客户从网站或邮件发来咨询，员工复制到表格，报价确认后再交给另一个人创建订单。信息变更、负责人不在或同一消息收到两次时，就可能无法判断哪份记录是最新的。
拿一笔实际工作，列出它经过哪些人和工具，就能开始找问题。改善未必需要立即买新软件；一致的编号、清楚的状态和共用待办清单，有时已能解决眼前的混乱。
改善设置、连接工具，还是建立新系统？
现有 CRM、表格或订单系统，也许改设置便能改善。如果只是重复搬资料，可把两个工具连起来；如果报价规则、权限或跨部门审批难以放进现有工具，才考虑定制开发。
同一客户或订单靠什么字段辨认、资料以哪个系统为准、失败后谁处理，都要订好。否则连接得再快，也可能只是更快地增加重复或错误记录。
先改善现有设置
问题主要来自字段、状态及负责人不清楚，可先改好同一工具内的做法。先建立一致记录方式，再评估是否要连接其他系统。
连接两个合用工具
两端功能合适，只是要重复输入资料，才集中评估连接。确认工具允许的读写方式、资料对应及失败后补处理。
定制开发业务系统
多层报价规则、角色权限或跨部门审批难以合理放进现有工具，可先建立一段主要流程，再决定是否扩充。
跟一条咨询走到正式开单
以下为说明方法的假设例子，并非客户案例或已交付成效。
假设网站咨询要转成报价及订单：先建立咨询编号，检查必要资料并指派负责人；确认报价后才建立订单。重复收到同一通知时更新原有记录；缺资料则列入待补清单，不把它误当完成。
需要处理异常情况，而不只是建立连接
收到两次通知，不应开两张单
连接暂时失败后，原通知可能再次送达。先定义如何辨认同一次工作，并保留已处理记录；同一个客户再次购买，则应能建立新的订单。验收必须分清“重复通知”与“新的业务要求”，不能只用客户名称作判断。
两个系统都有价格，以哪个作准？
明确每个重要字段以哪个系统为准。报价确认前可以修改，客户接受后应保留对应版本。若另一个系统也能改价格，就要约定同步方向和冲突处理，避免后续更新覆盖已确认的内容。
失败项目，需要有人看得见
列明哪些错误可自动重试，哪些要由人补资料，以及多久后需要提醒。负责人应能从待办找到原因、来源与下一步。错误只留在技术记录里，同事未必会看到；要有可跟进的清单，才不会继续漏处理。
正常情况以外，也要验收失败与重试
- 准备正常、缺资料、重复、取消及更新的样本，逐笔核对两端资料与处理结果。
- 模拟连接暂时失败，确认可找到失败记录、收到提醒，并能安全重试而不重复开单。
- 用同一类工作比较改善前后的人工步骤、漏处理记录及例外处理时间，再决定是否扩充。
估算成本，要把资料与维护算进去
集成费用会受工具的连接能力、资料质量、审批规则及例外数量影响。如果历史资料本身有大量重复或缺漏，应把清理工作分开列明。第三方平台订阅、用量及后续监控亦要一起计算。
先选数量足以看出问题、但出错时能人工补救的一段流程试行。正式切换前，要确认旧流程何时停止、失败记录由谁检查，以及需要回退时怎样避免两边同时开单。
分阶段切换，才看得出改善是否有效
选一类订单或一个可控制的流程试行，先记录目前处理时间、重复输入次数及漏处理情况。新流程运行后，用同类工作比较，并把例外补救时间一并计入。自动传送成功的次数，只是其中一个技术信号。
切换当日要有明确界线：哪些新记录走新流程、未完成旧单如何处理，以及暂停时由谁接手。如果需要同时观察新旧系统，可让新流程仅作核对，避免两边都直接建立正式订单。确认无重复与漏单后，再扩大适用范围。
开始前，准备这几份样本
整理目前工具、匿名表格样本、资料字段、审批规则、一天的实际工作量及常见例外。报价时一并确认历史数据迁移、平台权限、用量费、监控与日后修改由谁负责。
开始前，还有这些常见问题
有自动化工具，还需要开发吗？
先看现有工具能否可靠处理规则及例外。简单字段对应可能通过设置完成；复杂权限、资料冲突或不能安全重试的流程，才需要进一步设计及开发。
是否要先搬走所有旧资料？
不一定。可先界定试行需要哪些资料、未完成工作怎样延续，以及旧数据保留在哪里。完整搬移应有独立范围与核对方式，不应当作无需处理的小步骤。
