头头脑脑

本BLOG将暂停更新，未来新文章见ttnn 邮件列表：http://groups.google.com/group/ttnn

继续昨天关于主数据的话题，又想到一个概念，“system of record”，这个词语我也一直不明白是什么意思，从字面上理解，曾经将它理解为记录原子数据的表，将它用中文表述成为“记录系统”。见《度量数据仓库系统的指标》。

但恐怕它并非此意，而跟主数据有着很类似的含义。由此，又开始犯糊涂，它们俩到底有什么区别呢？

System of record是一个比较古老的概念，应该是在主数据之前。它是记录某种信息的地方，是唯一的，是标准的。

数据一般会分布、复制。在作版本控制的时候，总得确定一个最新版本，这个版本可以被取出，但如果你要修改，就要锁定这个最新版本，告诉别人，这个最新版本在你这里，修改完了在解除锁定，否则，造成版本混乱。因此，可以将最新版本看作是一种system of record。

譬如对于目前移动正在建设的数据集市，同样的数据会出现在省公司数据仓库、地市公司集市，例如客户的姓名、地址资料，帐单、详单等。总得要以某个为标准，这个标准就是system of record，按理来说，这个标准是在省公司的。但很多实际工作中，并没有这样的标准。例如客户资料，在营业系统中录入的客户资料很多都是不准确的，大客户部门提取大客户资料进行一对一关怀，在沟通过程中完善了客户资料，可这些资料有时就保留在大客户部门自己手中。如此，也就没有了标准。

在统计工作中，通常发生统计口径不一致的现象，同一个指标数，从市场部得到，和从生产部门得到的，有差别。可能是指标定义不同，也可能获取的途径不同。这也是缺乏标准的结果。

我想system of record无非就是强调标准化。作数据管理也要想作版本管理一样，要有个作为标准的地方，可以将数据复制发布下去。如果副本修改，需要更新标准。

因此，说到system of record与主数据的区别，我想他们应当是不同领域中，在不同语境中用到的两个词，前者是在信息架构中用到，是一种数据管理的基本思想。而主数据，大多在数据仓库领域，谈论数据质量的时候谈到，可以认为它用到了前者的思想。

本文主要谈谈此类专题作需求分析时候的模式，撇开细节的挖掘模型不谈，那是设计层面的东西，可以将它看作一个黑盒，输入一堆基础数据，输出目标客户名单。这一段如此表述，其通用性是很高的，对于不同城市，可能最终模型上有差异，但都是如此的输入输出。在名单输出之后，根据名单作营销，这是变化非常大的，有的城市可能使用自动的名单分配，有的可能是手动，有的利用现有的某个支撑系统，有的可能需要重新开发一个外挂系统。可以将这两者称为"分析模型"和"营销流程"两部分。

再简要重复一下，"分析模型"输出名单给"营销流程"，"营销流程"输出执行活动反馈信息给"分析模型"。

那么在作需求分析时，通常要在哪些方面是重点把住的呢？可以说这是一种"分析模式"吧。

"目标、角色、策略、评估"

首先是目标，这个专题最终要解决什么问题，通常，目标需要用一个或几个指标值达到某个特定值来表示。例如"至某年某月，离网率小于3％"。这也是衡量系统成败的标准，或许的营销活动都是针对这个目标的。如果是没有量化的衡量方法，可以说，这个专题已经存在很大隐患了。例如这样一个目标"让客户价值提高一个档次"。

当然，影响此类目标不光是技术原因，还有营销活动甚至是大局面的原因，技术原因要在"分析模型"中搜寻，而营销原因，恐怕要在"营销流程"中搜寻，所以面对总体的目标，必须得有评估模型和营销活动的方法。

第二个，角色，一般是指与系统边界之外与系统交互的人、物、系统。这里即是指参与专题所支持整个过程中，包括建模、营销过程的部门、人员，以及外部系统。从一般意义上，大致可以将分成数据源系统、营销支撑系统、建模人员、营销设计人员、营销执行人员几类。但对于不同客户，其对应到组织结构中是不大相同的，例如营销设计可能是市场部的职责，有的可能变成信息部的职责。究竟属于那个部门，也是需求分析阶段需要确定下来的。

对于具体的执行层面的角色，还得计算其数量，并且评估其可以承受的营销活动量，这会决定目标客户名单的数量。

第三个策略，其实在整个专题中，营销策略的制定工作量比重很大，只是他并非由系统设计者主导，多半由客户市场人员主导（除非是专门的咨询项目）。

在策略制定之前，需要对目标客户进行分群，哪些是高价值的，哪些通话行为有明显特征的。这种分群可以通过业务经验，当然也可以通过聚类的挖掘方法了。其目的还是为了支持后续的营销流程。

这个策略的本身设计就可以单独拿出来说的，从目标客户的分群，针对不同类型的客户将用用什么样的营销方案对待，谁来执行，执行的具体步骤等，都要在策略设计中实现。可以用策略图来表示，类似决策树的模样。针对每种类型的客户，考虑其属性，例如是否消费超过200等条件判断，最终落实到推荐的具体营销方案。例如对于低价值客户，可以用短信的方式群发促销信息，对于高价值客户，可以由客户经理一对一营销，甚至上门服务。

通过策略的制定，客户的类型、参与策略判断的属性，都需要体现在目标客户名单中，也就是说策略制定决定了客户名单的内容。

第四个评估，是要有方法衡量模型、营销活动的完成目标的效果。因此必须在执行营销活动之后将执行情况返回给模型。通常，评估也是通过一系列指标体现的，例如对于活动来说，如果是电话营销，可以有响应率、应答率来评估基本的通话情况，用成功率来衡量目标客户接受营销方案的比例等。

要得到这类评估信息，显然必须要将营销活动执行结果反馈至模型，对多少客户进行营销，多少失败了，多少成功了，多少根本就联系不上。

当然执行反馈信息可以从两个角度来看，一是从评估者的角度，评估者希望得到评估指标，希望能够有多多的反馈信息得到。也可以从执行者的角度，会有哪些反馈信息，执行人员能够承受填写反馈的工作量来精简反馈的内容。这似乎是对立的两个角度，一个希望反馈多，一个希望少填反馈，需要平衡。

此四点，窃以为是定向营销型专题的分析模式。当然，所谓"模式"，是仁者见仁智者见智。

关于产品和项目的需求分析差异问题，和西宁私下沟通了过，明晰了一些。其实，我的回答并没有多少集中在差异上，而是对需求应该包含什么提出看法。

主要观点是，需求应该包括对系统边界的描述，不论这个系统是产品还是项目。所谓边界，也就是将这个系统看成一个黑盒子，和外界的交互。"这，是一个黑色的立方体，长45厘米，宽23厘米，高3厘米，盒子的每个角都不尖锐，上方平坦，并有柔软质感；下方在四角之处都有凹进去的螺丝口，可以接杆子，以作凳子用。"

这就是仅仅对其功用的描述，其目标是作凳子用。这可以看作是功能性需求，当然如果还有一些约束，例如"此立方体可以承受300斤胖人之重"，这就可以看作是非功能性需求。但同样还是在描述边界。而对于其内部构造如何，在需求中不要描述，例如盒子是空心的还是实心的，材质用钢板还是木头，这都不是需求，而是已经在设计了。

因此，在描述需求的时候，重要的就是界定系统的内外。看过很多的需求，自己也写过很多的需求，界定内外不是容易的事情。有几个原因，一是没有内外的概念，不知道需求描述的是什么；二是知道内外，然而对于边界的定义，没有足够的词语描述清楚，只能用对系统内部设计来代替。这样的结果是，一份需求书，你搞不清楚它是需求还是设计。

譬如有的需求书，它描述了系统内部模块划分，三层结构，数据存储、中间逻辑等等。比如专题分析的需求中，包含了对挖掘变量的描述，嗬，将上百个变量列在文档中确实能够让页数增加。然而这恐怕不是阅读对象关心的，也不符合分离变化与不变的原则。需求书的阅读对象关心的是系统是什么，而非如何实现。系统是什么是相对不变的，而实现方式却是相对变化的。例如上面盒子的例子，用它作凳子是不变的，而至于用木头或是钢材，是后面考虑，可能会反复变化的。对于专题分析也是如此，这个分析针对的业务问题，诸如哪些客户最有可能离网，这个目标是相对固定的。而你是考虑使用呼转次数或是话费突降的角度来考虑，这是变化的。因此，在需求中，绝对不要将设计的东西加入进去（除非你是想便于说明问题），因为那种东西不能够作为一种"规格"，用于验收、测试的标准。

当然，有时候根据客户在作要求的时候，并非完全从系统边界上考虑，而真的会从系统内部提要求。譬如说，这个凳子，你就得用钢板，不能用木板，至于为什么，可能这仅仅是他的喜好。软件系统也是如此，有时候他会提出要求，你就得用某种产品，你就得用分类模型或者是神经元算法来实现。面对这样的要求，我也不知道该如何在需求书中表述，难道写上一堆系统约束——必须用叉叉产品，不得在系统中出现任何英文字母…？

需求所描述的系统边界，用UML中的用例图来表示是比较简洁的，用例图中的"角色"既是外部与系统交互的人或物或其他系统，"用例"则是系统表现出来的功能，而上面还提到了一些"约束"，不知道在用例图中是否有对应，研究不够。

用例图是起到示意作用，在需求规格说明书中，需要对这些角色、用例、约束进行阐述。例如在描述事务型系统的时候，会涉及到业务流程中参与的各个角色，有必要对每种角色进行定义。而对于一个分析系统，总感觉其流程不似事务型系统般流程清晰，因此，在早期的经营分析系统需求书中，大量篇幅在定义分析主题的维度、度量构成，却忽视，这个分析主题真正的业务目标和流程（谁来用这个多维分析？产生什么输出？）