数据库管理员提供了六张表以满足我们的项目需求。

• Restaurant 表——客户主数据表。
• Item 主数据表——涵盖产品线，用于交叉销售。
• 事务性数据——包括安装项目 Project、服务合同 Contract、订单头信息 Order Header 和订单明细 Order Lines。

我们将数据读入内存。

1import pandas as pd
2
3restaurants = pd.read_csv('solvers_kitchen/restaurants.csv')
4projects = pd.read_csv('solvers_kitchen/projects.csv')
5contracts = pd.read_csv('solvers_kitchen/contracts.csv')
6items = pd.read_csv('solvers_kitchen/items.csv')
7order_headers = pd.read_csv('solvers_kitchen/order_headers.csv')
8order_lines = pd.read_csv('solvers_kitchen/order_lines.csv')
9
10print('客户记录数量：', restaurants.shape[0])
11print('安装项目数量：', projects.shape[0])
12print('服务合同数量：', contracts.shape[0])
13
14print(restaurants.sample(2, random_state=1).T)

我们发现项目数量与合同数量之间存在显著差距。这52个未转化为服务合同的项目正是企业希望进行升级销售的目标。让我们深入分析数据，看看是否能获得更多信息。

输入混乱的数据，输出混乱的洞察

管理层声称，SK仅在完成同一客户的安装项目后才会销售服务合同。我们用数据来验证这一说法。

1# 若符合业务预期，应输出 1.0
2print(contracts.customer_id.isin(projects.customer_id).mean())

超过21%的服务合同记录违反了管理层的预期。到底是谁错了？是管理层，还是数据？

快速检查部分示例记录证实了我们的怀疑：客户数据中存在重复记录——这是我们必须在继续开展向上销售和交叉销售分析之前解决的问题。否则，我们将向错误的客户发送不恰当的推荐，影响营销效果。

修复流程，而不仅仅是数据

公司的核心业务是销售、安装和服务。这类重复数据对日常运营影响不大，因此一线团队没有动力保持数据整洁。相反，创建新记录往往比在数据库中查找已有记录更省事。

通过实体识别来处理数据属于被动应对，如同设备故障后才响应紧急呼叫。餐厅可能不得不暂停运营，导致收入损失和客户不满。这也是SK推出预防性维护合同的原因。

同样，实体识别项目的另一个重要成果是识别出未解决数据的根本原因。研究表明，预防重复带来的价值远超事后修复。以下是SK可以改进的流程：

• 在所有团队创建新订单记录的界面中加入自动补全功能。该功能将根据用户输入实时从现有客户数据库中提供匹配建议。
• 每当新增一个安装项目记录时，系统自动生成一个临时服务合同记录。用户只能更新这些合同记录，确保所有服务合同都与安装项目相关联。

尽管今天修复流程无法帮助我们解决历史数据质量问题，但这是未来避免问题的关键。

核心要点

实体识别有助于改善历史数据质量。我们可以通过对比使用与未使用实体识别处理后的分析洞察来证明其价值。但不应止步于此。此类项目的理想结果是识别并解决根本原因，例如通过优化业务流程实现。