Scenario Experience


Feishu
Choose your preferred way to join


企业最想问的数据,往往不在一个干净的数据表里。
订单在 ERP。
客户在 CRM。
库存、合同、回款、售后、会员、渠道数据分散在不同系统。
所以很多企业会问:ERP、CRM 里的数据能不能直接 AI 问数?
答案是:可以接入,但不能把“接上系统”理解成“马上就能可靠回答业务问题”。
ERP 和 CRM 不是一张表。
里面有客户、订单、合同、商品、库存、回款、发票、组织、人员等多个业务对象。
AI 问数前,必须先知道每类对象对应哪些表,表之间如何关联。
否则用户问“这个客户今年贡献多少收入”,系统可能不知道该查合同、订单、回款还是开票。
企业业务系统常见问题是编码不统一。
同一个客户在 CRM 和 ERP 里可能有不同名称。
同一个商品可能有历史编码、渠道编码和财务编码。
如果主数据没有梳理,AI 生成的答案会出现重复、漏算或错配。
业务系统保存的是事实数据。
但业务用户问的是指标。
销售额是否含税?
退货是否扣除?
回款按到账还是按开票?
客户活跃按下单、访问还是沟通记录?
这些口径必须在语义层中固定下来。
Snowflake Semantic Views 的方向,就是把业务实体、关系和指标定义放进可被应用复用的语义对象中。
ERP、CRM 本身有权限。
AI 问数接入后,也必须继续遵守组织边界。
销售只能看自己的客户,区域经理只能看所辖区域,财务字段不应该对所有人开放。
如果 AI 问数绕开原有权限,业务价值再高也很难上线。
有些问题需要实时查。
有些问题按小时或按天同步就够。
企业接入 ERP、CRM 前,要区分经营复盘、业务预警、临时报表和战略分析对时效的不同要求。
不是所有数据都需要实时,也不是所有数据都适合直接查生产库。
业务系统里会有测试单、作废单、历史迁移数据、人工备注和缺失字段。
这些异常如果不处理,AI 很容易把错误数据解释得很像真的。
因此,AI 问数上线前要建立数据质量检查和异常过滤规则。
AskTable 更关注业务系统接入后的可问性。
BuildTable 可以帮助企业把 ERP、CRM、数据库、文件和公开数据整理成更适合 AI 使用的数据基础。
AskTable 在此基础上配置表字段说明、业务口径、常见问题、权限范围和分析偏好。
用户不需要知道系统里有哪些表,只需要用业务语言提问。
ERP、CRM 数据当然可以成为 AI 问数的数据来源。
但企业不能只做连接器。
真正重要的是把业务对象、主数据、指标口径、权限、同步方式和异常处理梳理清楚。
只有这样,AI 才能从“查到数据”走向“答对业务问题”。
From building awareness to hands-on implementation, we provide complete enterprise AI services
Executive awareness workshops, AI Readiness assessment, industry case studies, risk & compliance training
Scenario selection & assessment, technical architecture design, process reengineering, continuous iteration & performance tracking
Whether you're just starting to evaluate AI or ready to implement, we can provide the right support