POC是什么

[转]POC是什么
最近公司要求做一个POC，不太明白具体含义，网上查了下与大家共享。

刘庆20060511
昨天，在公司等着报销呢，两位不大认得的同事过来，想了解一下客户需求的问题，因为他们奉旨开发"原型"，我对他们说的原型不是非常明白，到底是个什么玩意儿。

从他们的迷惑中看，似乎也不怎么了了。

之前，曾听起过这么一回事，要针对几套方案开发一些东西，其目的呢，我猜想一是用于售前演示，二是作为产品化的前奏。

从二人游离的目光中，我以为他们并非真的想从我这里得到什么信息，恐怕只是领导的要求吧，跟我意思意思而已。

因此，也没有多少热情跟他们说，说一些不用负责任的言论当然简单，信口开河而已。

现在都想不起来当时说了些啥。

晚上在旅途中，闲来无聊，不禁寻思这个事。

他们的困惑之源还是在于，不知道这个"原型"其目的究竟为何，无从下手。

可以试着将它展开一下。

说起"原型"，是软件工程里面常见的词，可以是prototype，可以是demo，也可以是POC。

现在在集成商、厂商那里，称呼为POC是比较流行的。

它的全称是Proof Of Conception——概念证明。

可以认为它将主要精力放在与用户交互的环节上，譬如说"仪表盘"，第一次听到这个词，会奇怪，你给他解释，"就像汽车里面的仪表盘，能够指示出一些性能指标的进度，并起到告警作用"。

即便如此，还是抽象的，因此就做一个实实在在的界面给用户看。

哦，有些指标可以用红绿灯来表示优劣程度，有些真的可以用跟汽车仪表盘差不多的东东展示，而且用鼠标点进去，还可以查看到明细。

原来这就是"仪表盘"。

可以看到，POC的目的是偏向局部的，面向功能的。

客户问，"啥是即席查询？啥是专题？啥是星型模式？"这些都可以一一用直观的界面表示出来，然而他们是割裂的，是系统内部的事。

POC给客户以直观的认识，它对客户说，"我做给你看"。

但转念想想，这种POC 是解决了客户对概念模糊的疑惑，也就是说已经知道了问题所在，知道了这些概念是为解决它而提出。

但在BI应用，还有很多问题有待抽象，因此还没有到概念这一步，首先要给客户证明的，是一套解决方案。

集成商就是干这个的，应标的时候，会给出方案建议书。

可惜看看建议书的内容，大多不会将客户遇到的问题介绍清楚，多数是给出一些产品的组合，这未免流于形式了。

其实，这种解决方案是要将企业的组织结构都协调起来，并非仅仅是产品组合和功能。

例如，一个经营分析系统，在建议书里面给出若干中应用，报表、OLAP，那么这些应用都是哪些部门、
哪些人员、在什么时间点用到呢？能否提供一个"场景"直观表达方案的应用呢？这样的方案书太少。

可是这种方案不像POC那样有形，POC可以是机器上的一个程序，运行起来可以交互，而解决方案原型，可能有软件界面，还可能有预定的流程、模拟的角色、操作场景。

因此，它告诉客户说，"这事得这么干"。

如果说POC和解决方案原型都是向客户表达最终完成的系统是什么的话，所谓"原型"，还有一层意思，那就是面向项目实施的，可以称之为"试验田"。

在BI项目实施中，类似的项目、类似的业务，却因为项目组的分散，缺乏集中控制，因此诸侯割据，大家作项目的方法，甚至结构都相差甚远，实施成本非常高。

因此，形成实施方法论，作标准化，甚至产品化也是很多人关注的话题。

早先，曾设想过一种方式，让BI实施人员作模型、作ETL、作报表，都像是在士兵装卸枪支。

这需要建立一个演练环境，尽量跟实际环境相似，模拟数据源接口、数据仓库模型、ETL，以及前端展现等，其中最难模拟的是数据量和需求变化，除此之外，剩下的工作就是从复杂到简单的抽象过程（当然，这也非易事）。

在这件事上，自己曾经开了个头，之后却因为不在其位，也就不谋其事了。

但想想，有这样一个环境确实是好处多多，可以让客户看到实实在在的效果演示，可以让项目组成员快速掌握实施方法，可以对分布的项目组进行统一的指导。