【IT168 信息化】
BI系统的核心功能是什么？数据分析。但是企业的数据纷繁复杂，格式也不同一。在这种情况下，如何缩短BI系统部署的时间、降低部署的成本呢？对此笔者建议可以采用主题包的形式。如下图所示，这就是某款BI系统的主题包。基本上包括了企业数据分析的大部分范围。在这篇文章中，笔者就对主题包的设计、开发与实施做一个说明，以供大家参考。
一、根据固定格式来设计主题分析包。
什么是主题分析包呢？简单的说，就是预先设计好的分析工具。只要用户提供基础数据，直接运行这个工具包就可以获得想要的结果。而不需要重新设计分析模型等等。这就可以简化在BI系统部署过程中的不必要的工作量。不过在设计主题分析包时，对用户的数据有一个统一的要求，即需要有固定的格式。具体根据数据来源的不同，可能会有不同的要求。
一是对于数据的来源会有要求。
如企业的数据可能是存储在数据库中（如通过ERP等系统），有的数据则是存储在Excel或者文本文件中。在设计主题分析包的时候，不可能适合所有的数据来源。为此要求用户在提供数据的时候，能够有一个整理的动作。如将文本文档的数据整理到Excel文件中等等。
二是对于数据存储的格式也有要求。
如对于采购分析这个主题包，需要有哪些数据，一般都有严格的要求。如需要价格、供应商、付款条件、承诺到料日期、实际到料日期等等。通常情况下，所提供的数据越全，那么在数据分析中得到的结果也就越详细。在这一点，对于主题包的设计也有一定的要求。如在主题包设计时，可以将字段分为两类，一类是必须要有的字段，如供应商、产品等等。另外一类则是可选的。如对于供应商到料及时率分析来说，预计交货日期与实际到料日期是必需的。而价格等内容则可有可无。但是对于任何一个分析，供应商、产品等信息则都是必需的内容。在数据导入的过程中，就需要对此有一个判断。而不能够在数据分析的过程中，才发现某个数据没有，系统才报错。
二、提供标准格式让客户存储数据
通过主题包目的就是为了减少系统的开发量。如果用户提供的数据格式不统一，然后还需要根据用户现有的格式去调整主题包，那么开发的工作量并没有降低多少。为此在BI系统实施的过程中，可能需要提供标准的格式让客户来存储数据。此时又包括两种具体的情况。
一是客户现在采用的数据存储格式确实不合理。
有个数据库使用经验的人或许知道，为了简化数据的管理，对于数据的设计、记录与记录之间的关联往往有一些合理的建议。虽然不同的存储设计，记录都是在的。但是可能会因为不合理的设计，而缺乏数据之间的钩稽关系。如一家企业利用Excle表格来管理自己的数据。此时销售部门有销售部门自己的表格，采购部门有采购自己的表格。但是无法通过两张表格发现业务部门与采购部门之间的关联。也就是说，在采购部门的表格中无法知道我这些采购订单对应的是哪些销售订单。在销售订单的表格中，也无法发现哪些销售订单已经有了采购计划或者采购订单。记录之间如果缺乏逻辑的关系，那么即使最好的BI系统也无用武之地。
为此在BI系统的实施过程中，实施顾问可能要与用户有一个沟通的过程。如果发现用户提供的表格存在比较严重的缺陷，就需要跟用户进行协调有些缺陷实施顾问是比较难以发现的，如数据的准确性。但是有些缺陷是比较容易识别的，如记录之间的逻辑关系等等。当记录之间无法串联起来时，这些数据对于BI系统的用处并不是很大。或者说，只适用于部门内部之间的分析。如只能够分析销售额的变化情况。而不适用于垮部分之间的分析。如销售订单插单对采购计划于生产计划的影响分析等等。为此对于缺乏钩稽关系的记录，顾问应该与用户进行说明。在必要的时候，对用户进行培训。然后提供标准的格式，让用户来整理数据。
二是如果用户的数据存储设计是合理的，但是现有的主题分析包与其格式不一致，那又该如何处理呢？
如现在用户使用的是一个ERP系统。此时数据都是存储在数据库中的。在这种情况下，一般认为其数据的设计是比较合理的。因为这经过数据库管理员的合理设计。通常情况下，笔者如果遇到这种事情时，往往会在数据库系统与主体包分析之间建立一个中间的媒体。举一个简单的例子。如现在有一个采购分析主体包，需要为用户分析到料的情况。在这个主体包中，需要用到供应商、采购员、产品、预计到料日期、实际到料日期、对应的销售订单等信息。但是在数据库的表格设计中，这些信息分别存储在不同的地方。如在采购订单中，保存的是采购员的ID。而用户实际需要看到的是采购员的名字。ID对他们来说没有实际的意义。此时实施顾问不需要调整主体分析包，也不需要调整原有的数据存储格式。一个比较简单的方法就是在数据库中设计一个视图，将这些数据都存放在一个视图中。当然这个视图的格式是根据BI系统主体分析包的要求而设计的。
三是直接通过BI系统中的SQL语句从数据库中获取数据。
有些ERP系统对于数据库的保护比较严格。如出于系统安全的考虑，不允许用户更改数据库的对象，包括创建视图。在这种情况下，实施顾问只具有从数据库中查询数据的权限。如果遇到这种情形时，用户也不用担心。不用将数据导出来，然后再按固定的格式进行整理。在BI主体分析包中，可以直接通过SQL语句从数据库中查询数据。不过笔者需要提醒的是，这是一个不得已而为之的选择。这是什么意思呢？如果用户能够在数据库中创建对象，那么最好直接在数据库中设计视图为好。这主要是因为，在数据库中设计视图，速度比较快、准确率也比较高。而且还可以边设计边开发。在BI系统中的话，设计起来就没这么方便。而且出错的几率也会高许多。为此在数据库权限允许的情况下，优先考虑在数据库中直接设计视图来调整格式。主要千万不能够直接更改数据库表的格式。否则的话，会引起前端ERP或者进销存系统的出错。只有在不具备数据库对象创建权限的时候，才BI系统中通过SQL语句来查询。
三、 主体分析包要兼顾灵活性。
不同的企业，对于同一个分析目标，其也会有不同的要求。如对于采购到料及时率这个分析目标，不同的企业，对于此会与不同的需求。
如可能对于时间的要求不同。如对于到料时间，有一个前后的宽限期。如规定供应商到料的日期为10月20日。不过可以允许供应商有两天的宽限期，即只要22日前到都不算延迟交货等等。另外，有可能对不同类型的采购订单也有不同的要求。如对于安全库存的订单，可能料是备在供应商那边，为此就不需要统计到这个指标中。
对于用户不同的需求，该如何处理呢？在这里笔者提两个建议。一是在通过SQL语句从数据源中提取数据的时候，可以进行过滤。如过滤掉库存订单的数据等等。二是在主体包中，可以设计一些开关，如是否允许前后的宽限期等等。这么设计的话，可以满足不同企业的不同需求。在项目实施的过程中，尽量减少二次开发的数量，以缩短实施的周期、提高项目的成功率。
