系统产品是一个广泛而复杂的概念，特别是在企业内部，尤其是集团层面，各种系统共同协作的情况屡见不鲜。今天，我想结合自己的经验，从整体上谈谈如何看待系统产品的共性。

我先为系统产品下一个简单的定义：“系统产品是功能的集合。” 基于功能，它向前延展为用户的使用体验，向后则延展为系统数据。因此，本文将从功能-用户体验-数据这三个维度，展开简单的探讨。

一、功能

系统产品是功能的集合，所以每个单个系统都包含了大大小小的各种功能，系统间的功能可以重复，但核心功能的使用不建议重叠。没有一个集团的系统体系是一次性搭建完成的，基本都是渐进式的，这也是为什么现在敏捷开发管理成为主流的原因之一。在理想的状态下各个系统各司其职互相协作，但现实只能是将核心功能适度的分配到所有现存的系统产品中，以确保当前的业务需求得到满足。所以随着企业系统产品体系的完善也需要为老产品做一些功能上的减负，让擅长的系统去做擅长的功能。

那随之而来的就是第二个问题，每个系统应该有哪些功能，哪些功能应该是这个系统的核心功能。在传统的产品视角往往先给系统定性，这是一个什么类型的系统，所以需要什么功能。但其实可以再延伸一步。功能是为了满足一系列特定的需求。所以功能迭代最根本的目的还是追随需求的迭代。那么问题就变成了每个系统应该满足哪些业务需求，哪些业务需求是业务场景的核心需求。不同系统之间的定位差异其实也是来自对应的业务场景的差异。

那么需求又是从哪里来的，当然需求可以是外部环境的变化产生也可以是刻意创造的结果。这里就不展开聊具体的需求了，因为不同的业务场景差异很大而且需求也是永远在变化的。但这里可以再延伸一下，需求来自于系统用户。系统用户可以简单分为两个大类，会产生购买的客户和企业内部员工。想一下这些用户来到这个系统是想要得到什么就有需求了。有了需求就可以设计对应的功能，将这些功能集成到一起也就有了系统。

二、用户使用体验

这里先默认一个系统已经具备了应该有的功能，但仅仅拥有这些功能就是一个优秀的系统了吗。这么多年我一直寻觅一个词来形容用起来怪怪的系统，有天终于被一个同事提到了——“反人性”。我们抱怨一个系统不好用，大多的时候并不是因为这个系统不能满足我们的需求，而是这个功能并没有按照期望的方式来满足需求。另外一种经常发生的情况是操作太繁琐或使用门槛过高。这里作为产品只要自己实际用一下系统就行了，产品设计应该是整套系统的第一个使用者，也应该是最熟练的使用者，对系统相应的业务场景也要非常的熟悉，了解使用系统的人每天的工作内容。系统归根结底是为使用而生的。

另外以D2C使用者为客户的系统为例，其前端优化目标是通过高质量的用户体验引导客户完成购买，或通过提升用户粘性间接促成购买。尽管优化方法论多种多样，但我的方法是将系统视作“黑盒”，通过假设和目的明确的测试，逐步总结规律，形成独特的经验。当然，再完美的前端优化，有时也比不上简单直接的一张五折券。

三、系统数据

从数字化转型的视角来看，系统产品是一个产生、加工数据的地方。所以系统的本质是搭建在一条条数据之上的，系统之间的交互其实就是数据的传递。这里按照记录数据-分析数据分别聊一下。

1. 记录数据

一个系统记录自己产生的数据大家都比较好理解，但是在系统开发初期很少会去注意数据质量的问题，往往等到要用数据的时候才发现这样那样的问题。于是，企业不得不投入大量资源进行“数据治理”，用“修路填坑”的方式弥补漏洞。

在系统搭建初期这套系统会以什么样的方式产生什么样的数据，应该是被规划设计的，一些高价值的业务数据还要充分考虑后续使用的便利性。在开发的过程中也要持续去关注数据有没有按照设计的既定方式去产生。

单系统的数据还是比较容易去做设计规划的，但到了集团层面就需要一套高前瞻性的数据标准。在集团层面的数字化转型中，将不同个性的系统数据整合到一起也是一个不小的挑战。当然这里也是一种马后炮，在第一栋房子建造时，很少有人能想象得到整座城市的模样。

2. 分析数据

记录数据之后就是要将这些数据发挥价值。数据如果没有用起来就是成本，数据如果使用起来了就是资产。

数据分析是最低门槛的数据应用方式。每一条数据，都是过去某一时刻的切片，代表了一个状态。因此，数据分析的第一步是帮助我们了解过去。

随着数据的积累，从点连成线，我们可以分析变化趋势，洞察现象背后的原因，提出假设并进行验证。最终，将这些洞察整理为行动建议，再观察这些行动是否带来了预期变化，从而进入新的分析循环。当然，这一切的前提是高质量的数据，否则错误数据可能带来不可测的风险。

以上，是我基于参与多个系统项目及集团数字化转型项目的一些粗浅思考。系统产品是功能的集合，是用户体验的载体，也是数据的起点。欢迎大家分享看法，共同探讨与学习。