将系统连接为一体

建立一个统一的连接点，让ERP、CRM、行业系统和电子表格通过它自动交换数据，每项数据交换都有说明，运行状态一目了然。

与我们探讨您的项目查看范围

范围

客户找到我们时的情况

同一个客户录入了三次
销售人员在CRM中创建客户。财务部门在ERP中再创建一次，因为系统之间没有连接。运营部门第三次把客户录入行业系统。三条记录久而久之就会对不上：地址不同、税号不同、联系人不同。发票寄到了旧地址，投诉则由一个不知道变更的人处理。
合作伙伴要求按其格式和时间提供数据
银行、运营商、零售连锁或大型供应商要求按约定格式、在约定时间提供订单、确认和结算数据。公司靠人工满足这一要求：有人导出文件，在电子表格里调整列，再用电子邮件发出。这个人不在，数据交换就停了。合作伙伴一改格式，整套工作就得重新安排。
每个连接都是单独建的
系统之间有部分连接，但每个连接由不同服务商在不同时期建成。没有人有一份清单，说明哪个系统与哪个系统通信、传递哪些数据。更换CRM供应商或升级ERP版本时，只能逐一检查所有连接，因为不知道哪些会失效。

范围

我们的工作

API是应用程序编程接口：一个系统在无人参与的情况下向另一个系统提供数据的约定方式。API层是公司各系统之间相互通信的统一节点。每个系统只连接一次，连接到API层，由API层掌握从哪里获取客户数据、把订单发往哪里，以及某个系统无响应时如何处理。
我们连接的是已经在运行的系统。ERP、CRM、行业系统、网店、仓储软件：每个系统都有某种数据交换途径，可能是厂商提供的现成接口、文件导出或数据库访问。我们检查系统提供哪种途径、条件如何，再把这一途径接入API层。我们不更换系统，除非分析表明正是它拖慢了流程。电子表格我们也当作系统对待：如果部门在电子表格中工作，API层就向它提供数据并接收结果，直到公司决定替换它为止。
在一些行业，数据交换方式是预先规定好的。在电信行业，这就是TM Forum，一项运营商之间协作的行业标准。如果您所在行业有这样的标准，API层就使用这一标准的语言，而您的内部系统无需了解它。
最终形成三样东西。接口：为每个系统约定的输入和输出，并用贵公司的数据验证过。文档：对每项数据交换的说明，包括什么数据、从哪里来、到哪里去、频率如何、由谁负责，形式上确保下一个服务商也能读懂。数据交换监控：一个视图，显示哪些交换已经完成，哪些中断了以及原因，并向指定人员发送通知。

范围

您将获得什么

- 数据流图：各个系统、系统之间传递的数据、每项交换的方向和频率，以及公司这边每项数据的负责人。
- 部署在欧盟境内的云上或您的基础设施中的API层，附每个接口的文档。
- 与现有系统的连接，上线前用您的数据验证，并说明出错时如何处理。
- 带通知和日志的数据交换监控，日志中可以看到每一次交换及其结果。
- 接入新系统的操作说明，以备更换CRM供应商或新增网店时使用。

范围

工作如何进行

1. 梳理数据流。我们与目前手工转录数据的人员交谈，并深入查看各系统。成果：数据流图和待建的数据交换清单，按每项交换所替代的人工工作量排序。
2. 设计API层。我们确定每项数据以哪个系统为源头、每个接口的形式，以及系统无响应时如何处理。成果：API层设计和接口文档，在开发前供您确认。
3. 逐个接入系统。每个连接单独上线，先在数据副本上运行，再进入一个部门的日常工作。成果：数据交换依次自动运行，手工转录逐个部门停用。
4. 移交监管。我们启用监控，培训指定人员读懂交换日志，并移交接入新系统的操作说明。成果：数据交换按合同约定由贵公司团队或我们负责维护。

范围

团队经验

团队成员曾在电信行业开发符合TM Forum标准的运营商间平台，并为一家批发市场运营商（批发市场即运营商之间买卖服务的市场）开发产品目录管理系统。在金融行业，团队成员开发了带文档识别和债务催收自动化功能的ERP和CRM。在一家银行业客户的集团各公司中，他们主导了工单和任务管理工具JIRA的实施和标准化。

范围

管理层应向集成承包商提出的问题

1. 项目结束后接口文档由谁持有？文档是否写得让其他服务商也能读懂？
2. 如果其中一个系统一小时无法访问，数据会怎样：等待、丢失，还是重复传送？
3. 谁会通过什么方式得知某项数据交换已经中断？
4. 接入一个新系统或更换现有某个系统的供应商，需要多少工作量？
5. 哪些个人数据会经过API层？存储在哪里？谁能访问？
6. 接入我们的ERP或CRM是否需要厂商同意或许可？由谁去取得？
7. 连接在上线前用什么数据验证？我们这边由谁确认结果？
答案取决于涉及哪些系统和哪些数据，因此我们从流程和系统分析开始，最后给出附带范围的建议。