现场！只有现场才会让我有无限的力量，最近几天埋头项目上线前的准备工作，效率不高，好多次有一种“卡壳”的感觉。赶紧恢复早先的习惯--在车间里面转圈。今天傍晚转了两个小时，居然又有新的发现。这就是“无流程”的流程的实践思维活动。

    对于快速流转的一种产品（从客户下单到送达客户的时间不超过20小时），如何在各个作业工序与管理工序上进行“快速通关”？和同事初步交流，还是有操作空间的，那些表面上很严谨的程序其实可以省略掉，比如检验记录，入库记录，等等。基于各种环节的衔接意义重大，事件或者说业务过程如果是可以连贯的，可以通过工序间的自律来实现交接，自然的信任也将发生重大作用。管理者可以把更多的精力用在对异常的处理之上。

     ......

     或许我们这样就可以进一步地接近业务的内在逻辑，我们的时间消耗也会越来越少。

    这个管理单元是纯粹的以现场管理为主体的管理单元。一般来说它同一于能力单元，也就是通常情况下，一个能力单元就是一个管理单元。由于规模经济的原因，加上很多企业在推行单元化生产，会形成几个有关联的能力单元的聚合，虽然在输入与输出上，还是可以用能力单元来区分，但是管理的精度与力度已经发生了变化。
    这样的情形就需要组织一个管理单元，既保障了“能力单元组”的有效输出，同时也保障了单一能力单元的输出追溯与输出管理。精细化才有可能。

    管理单元的中心任务是一个作业班次内的过程驱动与记录。通过IT手段进行现场管理的，通常是一个管理单元内的能力单元共享一个管理界面。
   
    事实上，放大到SCM来考虑，一个管理单元，就是一个有经济意义的组织，可以接受与输出“订单”而不是工作任务的组织。这对于我们在更大范围内整合资源，有相当大的帮助。
    当然，一个企业可能是一个管理单元（温州的中小企业非常多，相当大的一部分是这样的情形），也有多个管理单元所组成。这个角度看，“企业”还是一个虚的，是一种特定关系的结合，管理单元是一个具体的，是价值实现的管家，能力单元自然在基层来实现其价值。一个企业能够做的事情，决定于对能力单元的组织方式，这其实就是管理单元要做的事情。所以企业的基层组织，必须从业务逻辑和业务载体（能力单元）来考虑如何设计，而不是其他。

（野生项目笔记28）

    管理报表是什么呢？

    而前一个“路”则不管是战壕，还是河面、丘陵，都没有关系，这样就为客户（轮子）提供了一种贴合型的依赖性质的服务，具体表现上则为客户在复杂环境中提供了一个专设的成本最低的需求满足通道。

    只有基于这样的一个确定性关系才会有精细交付的可能。具体在一个企业里面，我们的精细交付是建立在客户需求与内部供给能力的充分耦合基础上的。这个耦合必须以前面我们说的“构造”为媒介，也就是将需求进行产品化的过程。

    就一个我们通常能理解的业务控制域来说，它包含这些方面：工艺活动/能力单元/工序组合/产品类别/客户需求/时间计划/执行反馈/订单成本/运输任务/结算分析。企业的内部能力与外部能力构成满足客户需求的角色体系，这些角色被分配到具体岗位之上，进行业务管理与作业活动。这样接近客户的那一端就形成了前台，接近供方的那一端就成为后台，它们围绕订单展开必要的活动。

    大乱必然大治。这些暗含的关系在平常情况下不容易被发现，一旦遇到大面积的交付问题的时候，就容易被发现了。然而我们通常会用经验的方式进行处置，而不善于在规律面上去明确处置的规则。

    企业一旦遇到严重的交付问题，事实上就有了感知“履带式”服务的机会了。精细交付自然不再是一个神话。

    核算与结算在财务软件中是一个标准化程度比较高的功能模块，已经得到普遍的应用。然而在以时间为管理重点的通过平台软件开发的信息系统，应该如何处理呢？这点是值得思考的，虽然在最后的结果中似乎是等效的。

    在这样的软件设计思想里面，有一个特点，就是业务必须是能够闭环的，财务是附生于业务的。所以财务所需要的动作，需要在业务的基础属性里面体现，事实上就是对资源、活动价值量的货币化测量。包括向供应商支付的，向员工（具化来说，在网络经济逻辑下，员工也是一种类型的供应商）支付的，以及从客户那里收取的。向社会与股东支付的属于财富再分配环节，这里不讨论。

    所以成本核算与供需两边结算的重点就集中在业务基本属性中货币化测量的精度了，具体的计算方法则是一个口径诉求，在另外一个面里面给予关注，就是关系面，后面（野生项目笔记的其他篇章）将对这个关系面进行分析，其实也就是核算与结算的层级问题，涉及到核算组织的确定与数据输出的方式等等。在业务面上，具体的操作方式主要关注一下几个点：

   （1）内部定价

    包括对资源、活动的定价，一般通过能力单元与工艺活动两个维度来锁定。包括但是不限于这几个情况---通过一个能力单元完成的闭环动作价值，也就是工艺活动的工价，这个闭环动作将输入物按照特定的工艺要求转化为合格的输出物，它可以分为多种类型，每种类型又根据不同的负荷水平进行区分，这样就能够很好地对该能力单元所承载的工艺活动进行结构化，比如一台印刷机，可以做5种类型的印刷活动（双色套印/叠印，单色一次，单色二次，单色三次），每种活动又可以按照输出物的规格进行劳动负荷分档。这样结构化下来的结果就是相对客观的，能够反应真实成本的（甚至会优于作业成本法的计算方法）；资源包括设备占用费用和材料（输入物）两种，设备占用费用，在财务上通过折旧来体现，在具体业务中其实类似于租赁费，与时间以及活动的价值量有关；材料则是一个可以通过统一的计算方法进行测量与定价的，通常以内部计划价来表达（在基于时间链的信息系统中，最终是完全可以按照实际的购买价格来进行成本核算，而不需要通过加权平均的方式计算出周期性的计划价）；管理费用分摊其实也是一种资源占用，问题是未来的能力单元将会干预到管理费用到底需要多少，它是应当评估外在的服务对本能力单元的贡献到底多大，比如计划人员、生产管理人员以及高层管理的工资，办公费用等等，是否值得付出那个分摊的额度？另外一个方面就客户而言，是否愿意在这个方面买单？这些在时间链里面都是非常重要的价值挖掘点，也是降本的所在，在后面我们将会分析到。

    以上是内部定价，内部定价在业务基础里面将作为一个属性提出。活动与资源是构成产品的要件，这些属性的集中为产品对外报价提供了基础。内部定价是一个不定期的调整过程，最终将完全通过市场所形成的商务价格“导入”到属性中解决问题。在相当长的时间里面，将通过专门人员的维护来解决，这个维护工作需要与时俱进，也有许多问题值得考虑。

   （2）对外报价

    报价不可能直接采用内部定价的那个结构化的资源与活动价格体系进行，它会采用相对粗的工序分档价格加上材料价格产生一个报价基础。报价是对凝聚了活动与资源的产品进行的，对外报价的目的是在商务价格和实际成本之间有个盘算，这实际成本自然包括机会成本。

    所以在产品管理中，报价所采集的价格数据是一个结构化但是有一定“概括性”的。一般的操作过程是在系统中将客户的需求进行产品化的配制，然后加上商务因素提供给客户。以缩短询盘和还盘的时间，快速达成交易基础。

   （3）结算过程

    结算本质上是一个付款方式的规则约束。

    ......（待续）

    他们的具体做法是：在基层（县级管理机构）选拔精通业务有计算机基础的人员到市里面统一进行“地图作业”，业务也是分好多块的，有财务开票，有加油作业，有物资管理等等。地图作业由软件实施公司的顾问主持，教授学员操作新的系统功能，非常细致，基本上是一个PPT，对应一套习题，然后在演示系统中进行练习。布置的作业有两种，一是同样的业务，目前处理与新系统处理的方法有什么不同？如何改进？有没有更好的方法？二是该业务所需要的基础数据收集，比如产品型号，职工资料等等。老师批改作业，同时启动下一轮的课堂教学。安排得非常紧凑。基本上几轮下来，具体业务模块的基础数据准备工作已经顺利完成，新的系统环境也熟悉到位，具体应用中可能遇到什么样的问题也比较清楚。最根本的是基于新业务立即的业务种子已经形成，他们由学员成为师资，可以为县属机构的同类业务的岗位人员展开培训了。

    据说，后面的实施工作比较顺利，因为由熟悉两边情况的人员主导。

    平台软件与商业软件不一样的是，应用功能设计中存在的问题经过评估和批准后，可以迅速得到修改。虽然一个单体企业从实施工作量上似乎不需要这个过程，但是从实施质量来看，还是非常值得引入这个过程的。其核心是“内部人”具有不一样的实施准备价值，实施方与应用方有了很好的合作管道，可以进行“就事论事”般的沟通，可以跳出一般的利益圈子，潜在的问题容易透明。当然，这个前提是业务功能已经根据需求做出来了，至少超过原型的精细程度。事实上等于有了一个共同雕琢的对象。

    当然我们清楚，这个过程中还有许多东西需要明确的，比如，需求必须进行结构性的变更，应该如何处理？

一年快结束了，要说这年的最大感受，那就是在年末的时候，确定了信息化战略合作伙伴，你说怎么表达这么罗嗦，不就是一个软件供应商吗？我说那还远远不能表达这个意思，寻战略合作伙伴就象找终生伴侣，不是简单的讨老婆。为这事情花了半年时间，我觉得很值得。最大的价值在于拥有共同的价值观。我们所希望的伙伴有这样的几个条件：

（1）有强劲的平台技术基础，支持我们做自主开发；（2）贴合公司战略，辅导我们进行信息化规划与项目实施；（3）持续的知识与管理支持。

这是完全基于“管理支持产业”理念提出的需求，不单单从具体的业务管理信息化角度提出的，看中的恰是长期支持公司战略的特殊能力。事实上满足一定技术条件的软件公司有许多，但能从内心深处认为管理支持才是其核心与价值的并不多，或者说是没有。目前确定的这个战略合作伙伴在资源方面符合我们的要求，在战略成长性上也基本合拍，合作空间应该是越来越大。当然我也很清楚，它是否能全面执行“支持”这样的活动，还是有折扣打的。我们要软件公司提供，不是产品，不是方案，不是服务，是支持，是支持下的产品、方案、服务。

每个企业在发展过程中都有许多非常有创造性的做法，这些东西在传统世界中有许多实际的“链接”，很可能成为企业运营体系的一部分。它是随时随地可以产生的，是群众智慧在商业活动里面的“涌现”；同时企业运营中经常产生一些由上而下的变革，这些变革有时候非常脆弱，很多人质疑是“执行率”的问题，事实上是执行环境与执行工具、执行习惯协同的问题，在技术层面它迫切需要一种机制来进行固化；我们也会经常请一些“外脑”帮助进行改善甚至是变革的事情，除了文化方面的差异之外，还有上面的同样的问题，优秀的基因怎么进入系统值得好好考虑，不至于产生排异，“赔了夫人又折兵”。

我们也很清楚，信息化在建设企业运营体系方面的巨大作用，也实际看到了很多富有示范意义的案例。目前主流的商业软件在很多方面起到了优化流程、固化成果、提高效率的作用，但是同时我们也看到“软件不软”才是这些软件的真切写照。很多软件宣称已经在系统中内置了许多专家的商业智慧和企业的实战经验，可以解决企业的很多问题，确实在软件项目实施的初期也有不俗的表现，随着项目的推进和新需求的源源不断产生，一种现象也就自然而然的产生了-----维护的工作量与日俱增，系统经常会捉襟见肘，信息系统与实际运营的系统之间的缝隙越来越大，对信息化的目标也不停的进行修正----随后发现，系统能解决的大部分是固定程式的业务，从这个角度看，信息化和电算化几乎是一个意思。系统一方面有非常大的成长压力，另外一个方面也表现出很实际的蜕化现象。这样的尴尬情况还将长期存在。本质上这是商业软件的设计与开发方式决定的。

我们到底需要怎么样的信息化路径呢？北京思维加速公司的《从用到控--Jusutep信息化蓝皮书》里面有许多文字值得我们一读：

正如所有的科学一样，无法有效预见、控制的事物一定会在某个时候给我们“惊奇的打击”！无法控制的信息化是危险的信息化。无法控制的软件，哪怕再好，对于用户只是“垃圾”，甚至是灾难。然而失控的信息化俯仰皆是，在很多用户看来搞信息化就是与狼共舞，很多时候信息化的确是“洪水猛兽”。

有效控制信息化是企业信息化的核心和关键目标，而不是信息化的摊子要搞多大、蓝图要画多好！

我们一直在深思：到底什么是信息化？如何安全、可靠地走到信息化的彼岸？到底是什么从根本上限制了信息化发展？

我们先看看流行着的两种极端的信息化解决方案，然后逐渐去解开这些疑团。

 All in One这种方案指的是把软件交给一个厂商来完成。乍看起来，这种方法好像可以解决成本、合作和集成等等一大堆问题。但是这种想法十分天真。放眼全球，也没有一家软件厂商真的能干这件事情。

  Best of All这种方案指的是把所有最好的软件都买来，像搭积木一样来制造信息化。这种想法同样很天真，就好像把天下最美的面部器官拼成一张脸，绝对不是最美的，而且可能非常难看。生产管理软件不是搭积木、完成拼图，可以这样比喻，但千万不要这样做。

其实，不论是All in One还是Best of All，这种思想的核心都是“一种对厂商的彻底依赖”，而缺乏自己独立的勇气。然而，我们的厂商能够经受这种期待和依赖吗？

事实上我们需要一种软件，其实是一种平台，能实在的让企业把握自己的信息化主动权，同时又不作茧自缚。这个软件要在以下四个方面要有非常充分的体现：

（1）用户主导

利用业务架构平台，用户将成为信息化的主导。用户将轻松逾越技术的关卡，充分发挥自己熟悉业务、对内容易沟通和了解需求等长处。架构平台提供的“以业务为导向”的能力，使得用户可以很轻松地利用模型工具描述需求、设计模式；然后再利用架构平台提供的业务引擎，自动生成需求的目标软件。这样用户可以彻底改变以前信息化过程中的被动地位，从而有效保证软件和需求二者之间的平衡。

 （2）快速开发

需求和设计之间的反复迭代不可避免。但是如果需求和设计二者的重合过程过于漫长，那么必将导致信息化的失败。然而这种问题屡见不鲜，用户部门提出一个小小的需求，IT部门就需要1个月才能提供，如此缓慢的相应速度，导致了严重的“交货延迟”。业务架构平台使得我们拥有了以“敏捷开发+快速迭代”为特点的快速开发能力，从而让那些看似不可能的项目变得游刃有余，让需求和设计之间保持高度的一致性。

 （3）全面集成

现在的业务需求都是复合型的业务需求。OA和MIS，OA和WF（工作流），WF和MIS等已经难以清晰地进行界定，这些传统意义上的“系统”都被统一在了现在的复杂管理系统之中。业务架构平台为应用提供了全面的集成应用环境，将OA及其群件系统、WorkFlow、MIS（ERP、CRM、SCM等都属于我们定义的MIS范畴）和BI等都有机地集成在一起，无论你要建立什么样的管理系统，这些功能都将轻松整合在一起。同时前期的软件也可以用“描红”的方式迅速融入。

  （4）持续完善

业务架构平台要提供了一个完整的软件生命周期模型，通过快速开发的方式来实现模型的生命周期模型。该模型不仅是一个设计期模型，也是一个完整的运行期模型。EMA的模式有效地驱动了管理软件的持续完善，从根本上保证了管理软件和企业发展的动态平衡关系。

我们清楚：信息化将不再是一个形象工程、面子工程，信息化将发挥真正的效力，将会把效益作为第一评估目标。

信息化将不再将项目验收作为评判标准，而将以“是否成功”作为标准。我们要将信息化项目做成成功的项目，而不象以前只是求个交差即可。

信息化将不再是基于某些事务需求和战术需求而采取的应对措施。信息化将理所当然成为企业的生命战略，使信息系统真正成为企事业的发展战略、改革战略和业务模式的重要支撑基础。信息化战略将成为一个整体化的战略。

这个题目到最后就是我们为什么需要平台软件？为什么需要业务基础架构平台？因为没有其他选择。

    最近论坛活跃人士阿朱在支点论坛上发了许多有争议的话题，其实也是对自主权的担忧，大家不妨去看看。