产品开发的职能组织
虽然在产品开发中， 跨部门的项目组织取得了成功， 但很多公司依然根据职能来组织产品开发。 使用这种方法， 每个职能部门依次对产品开发起作用，与接力赛跑差不多。 开发周期是从市场部提出产品要求开始的。 然后， 这些要求转给工程部， 制作出产品规格， 并开始产品设计。 生产部就根据设计制造出样品和测试产品； 销售部把生产出来的产品派发到各个分销渠道。 最后， 客户服务部开始发挥作用， 支持初期销售工作并处理客户投诉。
如果一个项目的先后工作顺序明确、 重复很少， 那么使用职能部门的方法可能很好， 但一般来说， 这种方法并不是十分适用于产品开发。 我们发现， 使用职能部门的方法容易造成“各人自扫门前雪” 的态度， 也就是说， 每个部门完成他们那一摊子任务后， 项目的其它事就撒手不管了。 很多时候， 这个问题并未能被人揭示出来， 因为项目组织忙得根本就没时间回头将整个项目的实际表现与最初的目标进行比较。
使用职能产品开发的方法还有一个弊端， 那就是这种方法使得签字审批手续繁杂， 没完没了地转来转去， 造成机构臃肿不堪。 在过去出现的问题当中，这种耗时的体制尤其多见。 一旦问题得以解决， 就有人做出决定， 以后如果要避免类似问题， 应采用正式签字的方式， 各个职能部门对产品进行审视、 批准后方可进入下一步工作。 这样通过保留审查纪录， 出现问题时就可查到责任人是谁。 虽然过一阵后， 问题不再出现了， 但是关卡却越设越多， 开发时间也变得更长了。
例如， 有一家生产电子设备的公司在样品材料上比预算多花了 860 美元。 管理层于是制定了一个工作程序， 规定生产一种新产品要购买样品材料时， 需要四名副总裁签了批准。 结果大量的时间花在找人签字上， 这样大大增加了产品开发成本， 也无谓地延长了把产品推向市场的时间。
职能部门的体系纵向层次繁多， 往往缺乏必要的横向网络， 不利于进行有效的沟通、 协调和作出迅速的决策， 而在产品开发上要有所作为， 必须要有有效的沟通、 协调和迅速的决策。 复杂的结构层次可能会导致部门沟通渠道不畅，从而拖延制定新产品的决策。 例如， 如果生产部门非得等到产品设计正式得到批准之后才去订购样品材料， 那么在连续的各个步骤间拖延就蔓延开了。 一些最初有控制点的体系往往演变成官僚本义的迷宫， 人们在里面打转转， 而不是花时间将其改正过来。 对于一些产品开发周期长的公司， 这些是典型的症状。
在职能组织体系中，要开发新产品， 信息在组织中必须横向流向多个职能部门， 还要纵向穿过多个组织阶层。 沟通渠道迅速增加， 每个渠道都会延长整个开发周期的时间。当职能组织法运作好时， 进度却很慢； 但如果运作得不好， 很少有产品能及时推出而且具有竞争力。 当产生矛盾时， 皮球就踢到下一级， 让他们去解决。最终， 有关产品的决策是由嗓门最大或权利最大的人来作出， 而不是由最了解设计和顾客的人员来制定。
职能组织法最主要的缺陷在于其结构本身。 在任何一个职能部门中， 工作人员的工作表现和奖惩完全是按该部门的工作目标评定的。 因此， 参与产品开发的人员一般会努力争取在该职能部门中表现出色。 很多情况下， 那些在具体职能部门中表现最好的人员， 对产品或对公司整体而言却并非很好。 职能部门的工作目标与公司的工作目标不能总是保持一致， 而且也经常跟其它职能部门的工作目标不一致。
有一家微电脑公司的项目小组是按照职能组建的， 设有市场推广和销售部、研究开发部、 技术工程部、 前期生产部、 生产部和客户服务部。 每个部门都负责新产品开发过程中不同阶段的工作。 开发工作通常从市场推广部开始， 由市场推广部提出 它 认为新产品应该有的一系列需求。 市场推广部将市场需求文件（MRD） 交给技术工程部。 技术工程部随后根据市场需求文件决定该做什么、不该做什么。 产品功能规格（PFS） 技术工程部提出设计要求。 不幸的是， 市场需求文件（MRD） 和产品功能规格（PFS） 往往不一致。
只有到制造试制品时， 生产部门才会加入到项目中来。 由于工程师负责订购所有部件并制造他们自己的样品， 所以生产部的工作必须从零开始。 他们要花很多时间去搞清设计要求、 找出标准和合适的部件。 最后， 在第一批货即将发运给客户时， 客户服务部才猛然发现原来有这么一个项目。 当然， 从战略的角度来说， 所有零部件都应合理散布在全国各地。 这使得生产部更加手忙脚乱，而工程部就要把各种技术工程上的许多要更改的地方尽快地定下来。由于采用了职能组织法， 该公司开发一个新产品， 要比它的竞争对手花多一倍的时间。 后来， 该公司被卖给一家外国公司。 这家外国公司想做一些改进，却被其根深蒂固的“职能观念” 弄得一筹莫展。
不同职能部门里的个人通常熟知自己本行当的事， 但未必知道对于其它职能部门而言什么是重要的。（而产品开发是系统性的工作， 对于某职能部门来说是最优的， 对于产品和公司来说未必是最优的。 所以各环节的人都应该有系统性的观点） 图 4-3 说明了一个职能部门的专家认为有用且有趣的事情， 另一个职能部门的专家却常常并不以为然。 个人所做的每一个工作步骤， 都深深打上了个人专业兴趣的烙印。 这种观念偏差所形成的产品， 经常与成功背道而驰。
在一家电脑制造公司里， 市场部指出一种新电脑应该满足从工业到军事的各领域广泛的需求。 工程技术部在规格里又附加注明这种电脑应拥有最先进的处理器技术， 而这种技术在一年后才面世。 尽管这些过分的要求并不是非要不可的， 但根据设计意见， 产品还是包括了这些要求。 一年后， 该公司意识到开发这样的产品既费时又费钱。 于是重新进行产品定位， 着眼于现实的需要。产品开发采取职能组织结构的做法， 往往在产品种类不多又关系密切的小公司内运作良好。 在这些公司， 每个人都互相认识， 而且一般情况下他们在一起工作都很有经验。 初建的公司往往使用这种方法， 并已成为这种方法运作的典范。
然而， 当一个小公司只开发一个新产品时， 整个公司就是一个产品开发小组。有些大公司为了有效地沟通、 协调和决策就试图效仿小公司的组织结构。 他们成立了规模较小的自治事业部， 自负盈亏而且在财务上有自主权。 这种组织结构在该事业部内部的优势确实有所体现， 但对外交流就越发显得困难了。 结果，公司白白失去了对公共资源及其它规模经济资源的利用， 而利用这些资源正是大公司的优势所在。 核心小组的方法是力求达到一种更好的平衡。
联系我们
Contact us
战略解码