【IT168 专稿】笔者从事技术工作11年了，也曾经是一名持技术至上观点的、很单纯与封闭的技术人员，经历了近10年对BI项目的理解和学习。笔者要凭自己的良心指出，技术至上的观点，不但会成为商业智能发展的桎梏，甚至会成为扼杀商业智能应用推广的无形黑手。
那些技术至上的数据模型规范，不考虑实际用户业务模型的特点，迟早会受到谴责的，只是时间没有到而已。商业智能，就让它回归“商业”的本质，减少“智能”式的技术色彩吧。从“商业”的本质看待“商业智能”，至少这样的天空是真实的。
抛弃狭隘的技术思维，摆正虚心的态度，多考虑客户实际的需求，多考虑一下客户的GMROI（投资回报率），是BI应用的正道。BI技术的运用方法不是BI成功的关键方法，笔者将从非技术层面寻找BI成功的关键方法。
“抛砖引玉”度BI成功
笔者用“抛砖引玉”来定义BI的实施方式，并不是要求实施商、用户的IT部门、咨询专家们，先把BI应用做得不好，然后通过经验的积累和努力，把它继续改进和修正。如果是这样，在企业以GMROI为衡量的方式，你抛了砖，没人会让你产生玉了，BI应用也就无法持续成功了。
“抛砖引玉”的典故里有2个主体，所以，参考BI应用的实施和使用，也一定是2个主体（实施者和使用者），我们把BI厂商、集成商、开发商、用户的IT部门、咨询专家统统归纳为BI应用的“实施商”，把用户的中层干部、业务部门人员、市场/分析部门的人员、公司高层等定义为BI应用的“使用者”。
根据“持续改善”的企业管理理论，BI应用的成功之处，就是以中层为主体的BI应用使用者，通过BI应用利用不同的分析方式（用户的中层干部、业务部门人员通过演绎法，市场/分析部门的人员通过归纳法），找到带来成本降低和经营改善的模型。
那么这种找到模型所带来的成果如何利用？这就是中层出给高层的题目。如果高层不能迅速并有效利用这些成果（如何利用，通过BI应用中的KPI/BSC技术），员工积极性便会丧失，这样BI应用也失去了价值，谈不上成功。
“持续改善”的企业不应满足于对改善成果的发布，而应做改善成果被使用的发布。否则，任何BI应用都无法持续。BI实施商抛出“砖”，引出BI应用使用者的“玉”，让项目互动起来，变BI项目应用由“高层驱动”为“中层驱动”，由“压迫执行”为“活性化分析”，由“被动式统计”为“主动式分析”。
为什么要引玉
“抛砖引玉”的本质是调动员工的上进心及积极性。传统BI的实施方式为：IT部门在总结业务部门的需求和行业咨询顾问的业务模型后，开发出应用，以统计好的报表和控制范围内的纬度变化出给统计和分析标准，工人们按标准做做统计即可。而“抛砖引玉”式的BI实施方式，是充分相信业务人员的智慧，提倡“精细分析”。
其实在企业中，没有消极的员工。只要方法正确，员工都能焕发活力。因为，人都希望有归属感，个别人的落后也会在集体向上的带动下，发生变化。只不过，时间不同而已。
业务人员自主分析的活力是一点点被激发的。让员工做分析，只要有50%的可能，就开始去行动，在行动中进行交流，持续改善到100%。不要给员工过高的压力和期望，最好只要让他伸伸手就能够进行分析。然后，员工产生一种成就感，充实感，大脑才能不断思考，进取向上。
当然，发挥一线业务人员的智慧进行分析，并不表示分析目标是自下而上，而是每年公司都有分析方针，从质量、成本、安全等多个角度制定分析目标，把目标层层分解到每个组。而发挥一线业务人员的智慧进行分析，正是对这些目的的改善和修正，不希望他们在没有思考的状态中无条件操作。
在每一个企业，没有一个业务人员喜欢自己只是螺丝钉，工作一成不变，只是听命行事，不知道为何而忙。“抛砖引玉”做的事很简单，就是真正给员工思考的空间，引导出他们的智慧。员工奉献宝贵的时间给公司，如果不妥善运用他们的智慧，才是浪费。
“抛砖引玉”BI实施2要点
“抛砖引玉”BI实施的本质是以中层驱动为基础，调动企业业务人员的上进心及积极性。进入实施阶段，一定要抓住2个实施要点，才能让“抛砖引玉”BI方式互动起来：
①IT部门（包括SI公司）侧重于以“数据模型”为基础，快时去解决由于业务模型变化而产生的“数据质量”和“数据完整性”问题。
②业务人员侧重于“业务模型”为基础，实时创造“分析角度”（观看数据的概括方式和角度）。
只有让这2点互动起来，“抛砖引玉”BI方式才能实现。而传统的BI项目，我们是牺牲IT部门为代价的，太关注数据模型了，而业务模型来自于咨询和传统的需求调研，这样的方式限制了企业的创新能力。因为这样出现的业务模型不是实时的，是历史的，无法对企业快速的业务变化做归纳和创新，无法发挥使用者的思考能力。
为什么传统的需求调研加项目开发不适合BI实施方式，就是因为BI的本质是分析，通过分析提供决策，分析不是相对固化流程化的东西，往往是灵感的体现，而传统的需求调研加项目开发的BI实施方式就是固化流程的开发方式，违背了分析的本源。
因此，在“抛砖引玉”BI方式中，业务人员对“分析角度”进行归纳和定义来形成新的业务模型，是BI项目成功的关键。
管理视点方法——业务人员自己定义“业务模型”的基础
分析角度是指观看数据的概括方式和角度。例如，它对应于交叉统计表（中国式传统分析报表）中的表头或者表侧，也是定义业务模型的基础。传统的业务模型来自由数据模型进行定义完毕，在数据模型控制的范围内进行定义，这违反了“业务驱动BI”的原则。
业务模型是太阳，数据模型应该围着业务模型在转，不然，会出现业务模型受制于数据模型变化的情况，使BI项目变成传统的统计项目，无法适应快速变化的现象。而充分相信业务人员的智慧，提倡“精细分析”的“持续改善”的企业，让业务人员自己定义分析所需要的业务模型最为关键。
业务人员自己来定义“业务模型”来验证自己的分析（征实或者证伪），重要的是快速设置想指定的管理项目（分析角度）。实现这一目标就是所谓的“管理视点”。
通过引入管理视点这一概念，就是不过分借助IT部门的力量，对于不懂SQL语句无法进行或者更加复杂的统计/加工处理，就可以简单操作。这是业务部门结合自身的分析方法和业务要求来快速归纳的业务模型。在日常业务中使用的所有分析角度均可成为管理视点。
管理视点是对数据模型进行管理和定义分析角度，并快速将数据模型转化成业务模型，通过简单操作，就可以实现对使用管理视点的数据分类以及对象数据的插入。将管理视点配置到分析报表的表侧和表头，可以自如地分析自己证实与证伪的过程。不了解数据模型使用方法的最终用户，也可以得到自己分析和自我改善的机会，从而实现企业的“持续改善”。
管理视点可以在不改变数据模型的前提下，实现定义/修改。由此，终端用户就可以自行对困难的分类方法和排列顺序进行及时地定义/更改，从而形成新的分析角度和业务模型。
用户能够利用管理视点来快速归纳分析角度，创建业务模型，同时通过最常见的桌面报表工具来分析数据，这样，我们的“持续改善”的实践就有了基础，但还需要业务部门结合业务分析的方法论来支撑这些分析。
业务分析方法——业务人员必须掌握的方法
目前，BI在应用企业中有点声名狼藉，很多人都对BI有这样的看法：浪费大量资源，提供的报表又几乎没人去读。而事实上，BI的投资回报之所以不确定，其问题并不是出在技术本身，而是由于技术与业务的脱节。
BI常常遭遇这样的尴尬：公司主管们需要更多的报表来获取宝贵信息，从而有效管理公司。但是很多公司，它们在各业务部门部署了一大堆BI解决方案，并把BI系统附加到包括ERP、财务、CRM在内的各种系统上，然而并没有获得应有的价值。
多年来，BI让人觉得不仅是高成本，而且部署环境复杂。许多企业的对策是采用仪表盘，这种简化的图形显示工具绕开了功能全面的BI系统，以近乎实时的方式为公司领导提供业务度量。但实际上，仪表盘解决方案会导致更大的花费，因为任何有意义的仪表盘都需要部署报表分析和数据集成工具，这两者是必要的基础，它们占了80%的成本”
IDC的分析师认为，BI的投资回报之所以不确定，其问题不是出在技术本身，而是由于根本的脱节现象。他说：“对IT人员而言，BI意味着报表制作、查询工具、多维分析、OLAP工具以及数据挖掘等；而对业务人员而言，却意味着分析，利用分析来进行决策支持。”
大多数企业把BI当成了一套技术，结果就偏离了轨道；构建的系统越来越复杂，却满足不了用户的需求，这就需要IT人员更深入地了解底层数据和业务需求。
“从解决业务问题着手”就是业务人员掌握业务分析的方法，根据这些方法，去定义业务模型，把这些业务模型和IT部门提供的数据模型做匹配，如果数据模型无法匹配业务模型，就让IT部门去修改数据模型和采集新的数据，修正数据质量和数据完整性问题。
现在BI项目实施中最大的问题，就是IT部门期望建一个完善的可适应业务模型变化的数据模型，一劳永逸解决企业业务模型的变化，如果您公司的BI项目经理是这种“技术至上”型的话，建议赶快换掉他，不然这个BI项目注定是失败的。
这就是IT部门抛“数据模型”这个砖去引业务人员“业务模型”这个玉，“抛砖”是手段，“引玉”是目标，“如何抛砖”需要方法，“如何引玉”也需要方法。当我们用“持续改善”的标准来要求企业人员的时候，这都不是问题了。
在“引玉”之前，首先让业务人员学会如何做他自己想证实或者证伪分析所需要的业务模型，当他可以采用“管理视点”的技术来做业务模型的时候，就需要用业务分析方法来解决自己为什么需要做业务模型，笔者总结的有以下几种，企业可以按照自身的特点自己总结。
①综合性分析：依据某一期间，在选定的范围内，分析关键指标(KPI)，比较效率。
②结构性分析：找出重点事项，加强管理，可细分为：ABC分析、价格段分析、产品群分析、客户群分析、厂商依赖度分析。
③趋势性分析：找出发展的走势，预判未来，事前采取必要的决策。
④成长性分析：分析时间、季节、促销因素影响销售业绩的状况。
⑤流转性分析：依据不同时间段产品进/售/存/调/退/耗损的变动，改善物流流转。
⑥相关性分析：依据客户和产品销售行为进行关联分析，进而实行交叉销售。
数据模型——看起来很美
数据模型是表示信息或信息集合的方法。在一般情况下，将数据保存在关系型数据库中，旨在减少数据冗余和遵守“关系”的原则。它将数据分别保存在多个表中。分开保存在多个表中的数据，在访问数据库时，利用SQL命令等指定表的处理方法(组合法等)加以使用。分割的表之间存在概念上的组合关系。
通常，企业处理的数据遍布整个表，有复杂的组合关系。但是，如果仅考虑处理(报表制作等)的表，那么组合关系以及数据的处理方法有一定的模式。这被称作数据模型。
做这些数据模型的原则：尽量建星型，雪花是可以选择的，坚决杜绝循环模型。
要先弄清楚实施BI的理由（这就是你的业务需要），然后再构建及完善数据模型，并确保来自多个系统的数据具有一致性。
BI厂商试图利用主数据管理（MDM）解决方案来解决数据质量和集成问题，但数据治理、清理及调和等方面的工作不单单是BI的范畴，还会影响企业的每个角落。公司必须全面完成数据工作，这是一个长期项目，最好的策略是减少数据源，只留下可满足明确的业务目标的数据源。
这样可以消除相互冲突的数据源，从而易于管理数据清理和集成。力求数据尽量准确，让数据更贴近上下文和元数据。减少数据源仅仅是第一步，它的作用是避免繁琐的工作，最关键的还是数据质量要达到标准。
有些数据总是很“脏”，可能因为它来自外部，或者因为它是很难抽取的数据。一个常见的例子就是顾客的出生日期，因为顾客觉得没有必要向别人透露年龄，就随手输入11/11/11，或者干脆什么信息都不输入，于是产生了错误数据。
IT部门在部署BI时面临的主要难题是数据质量，其次是集成来自操作型系统的数据，以及将BI软件与现有的IT基础设施进行集成。
所以，“数据模型”这个看起来很美的名字，正在或者已经迷惑着我们BI用户的眼睛，企业的领导如果真的花巨资整一个完全适合业务模型改变的“数据模型”，除非这个企业将是行业领导性企业，他整出来的“数据模型”可以进行全行业销售才行。可惜，中国还没有这样的企业，这样做要么被欺骗，要么就是别有用心。
总结：在每一个企业，没有一个业务人员喜欢自己只是螺丝钉，工作一成不变，只是听命行事，不知道为何而忙。“抛砖引玉”做的事很简单，就是真正给员工思考的空间，引导出他们的智慧。员工奉献宝贵的时间给公司，如果不妥善运用他们的智慧，才是浪费。当企业业务人员知道自己可以定义业务模型，来思考和分析，这是多么大的智慧空间！
