正确的做事逻辑，为什么走不通？

在大数据、智能制造、工业互联网相关的会议上，经常听到有人讲一些正确的逻辑。但我知道他们的做法走不通。

我们先来看一个正确的逻辑。

几十年前，IBM公司就在其大型计算机上提供了一种叫做GOSSD的功能框架：

G（Gather）采集数据和信息

O（Organize）组织集中存储数据和信息

S（Select）选取所需的数据和信息

S（Synthesis）合成所需的知识

D（Distribute）向特定的人发布知识和信息

相信很多人会觉得这个逻辑眼熟。它和今天人们经常提到的智能化、大数据项目的逻辑颇为相似。宝钢当年的信息系统就是这么建立起来的。根据这样的逻辑，有人提出搞大数据的步骤：先收集数据、再组织数据.....大体就是GOSSD的逻辑。

但是，在大多数情况下，如果真的按照这个逻辑套路走起来，恐怕就不会那么舒畅了：结果很可能是收集了一大推无用的数据，开发了一大堆可有可无的功能，最后不了了之，也创造不了什么价值。

这个逻辑怎么看怎么对，问题出在什么地方呢？

其实，问题的根源，是人们混淆了技术的实施逻辑和技术的策划逻辑。技术策划要用工程化的思想来推进，要以终为始、要把上面的逻辑反过来用。换句话说，在策划技术的时候，首先要想明白什么人需要什么知识和信息（D）；然后去思考如何去合成这些知识（S）；进而如何选取数据（S）。最后考虑如何进行哪些数据的采集和存储（OG）。按照这个逻辑想清楚了，再按照GOSSD的逻辑去实施。简单地说，就是“反着想、正着做”。IBM提供的这套工具，是实施时用的工具，而不是策划项目时的工具。

“以终为始”能够落实业务驱动和价值驱动：因为信息和知识发送（D）是根据业务需求来的。有了业务需求再去实施IT项目，才能有的放矢、才能做到“雪中送炭”而不是“锦上添花”。这样做下来，自然不会问：这套系统有什么价值啊？

这种思维方式，不仅IT领域的研发需要，所有的技术创新工作都需要——除非问题本身是非常清晰的、是纯粹技术问题。我大概20年前搞数学模型时发现了创新逻辑的反向性。最近给这套思维方式取了一个名字，叫做“工程创新方法”。