垂直整合 SAP甲骨文IBM火拼

垂直分工是过去一百多年来工厂进行量产化革命必然的结果。由于需要不断追求成本的降低,最好的方法就是让生产线上的每个作业员,只专注在一件事情上面,当他每天重复做这件事情,无论速度与精准度都会达到最高,因此整体的成本也就能够压到最低。

久而久之,企业的经营者误以为一个公司的所有任务都应该这样被的分工,所以业务部门、行销部门、客服部门、RD、MIS,一个个的被独立出来。但这样的效果似乎比工厂的垂直分工效果差很多,部门间需要经常的开会,但很多时候还是不知道对方在做什么,最后甚至出现部门间角力的情况。理论上,行销部门应该负责去了解客户想要什么,再交由 RD 部门去研发这个产品,最后由业务部门去贩售,再由客服部门提供售后服务。

但实务上,RD 部门往往是公司里最了不起的,因为他们掌握了关键技术与创新。RD 常常擅自作主研发出了产品,然后行销才要被迫要去想出如何推广这个东西,往往是在老板的压力之下 — 没办法,老板也是 RD 出身的。行销想出种种的说帖,好不容易说服了业务,但等到他们去跟客户推销,才发现那根本不是客户要的 — 没办法,行销窝在家裡,接触客户的时间很少,往往也不知道客户在想什么。业务回头钉 RD,最后这两个部门成为每个公司裡死敌,因为业务往往拿客户压 RD,而 RD 则用技术压业务。两个人都不知道对方的领域,只能造成无止境的恶性循环。

这不是垂直分工的用意。这个系统的设计,生产线上的第一个作业员,并不需要知道第叁个作业员在做什么,两个人只要分别专心的把自己的事情做好,这条生产线就会有最大的产出。但一个常常进行新产品开发的公司,业务、行销、RD 与客服部门没办法用生产线的方式分工,他们不能不知道对方在做什么,更不能闷着头只做自己的事情。

所以垂直分工是量产型组织的好结构,但不是知识型组织的好结构。常常做新产品开发的组织,更适合的结构是垂直整合、动态分工。依据每一个任务的需要,去动态的组织任务小组,小组内集合行销、设计、开发、业务等等人才,整合在一起,共同把任务完成。

这不是一个新的系统,也不是只能小规模的运作,事实上,Google 从 2000 左右,就开始实验这样的组织,时至今日,他们已经有接近 2 万名员工,还是在用这样垂直整合的组织型态。同样硅谷出身的科技巨人 Facebook,目前有近 4,000 名人员,也是师承 Google 这样新型态的组织结构。

其实,这些就是一个个内部创业的团队,他们运作的方式与外面的创业团队非常类似,因为事实证明,在开发有商业价值的新产品这件事情上面,垂直整合的创业团队比起垂直分工的工厂组织,来得有效率多了。