产品开发的职能组织

admin

    职能组织法最主要的缺陷在于其结构本身。在任何一个职能部门中，工作人员的工作表现和奖惩完全是按该部门的工作目标评定的。因此，参与产品开发的人员一般会努力争取在该职能部门中表现出色。很多情况下，那些在具体职能部门中表现最好的人员，对产品或对公司整体而言却并非很好。职能部门的工作目标与公司的工作目标不能总是保持一致，而且也经常跟其它职能部门的工作目标不一致。

    有一家微电脑公司的项目小组是按照职能组建的，设有市场推广和销售部、研究开发部、技术工程部、前期生产部、生产部和客户服务部。每个部门都负责新产品开发过程中不同阶段的工作。开发工作通常从市场推广部开始，由市场推广部提出它认为新产品应该有的一系列需求。市场推广部将市场需求文件  （MRD）交给技术工程部。技术工程部随后根据市场需求文件决定该做什么、不该做什么。产品功能规格（PFS）技术工程部提出设计要求。不幸的是，市场需求文件（MRD）和产品功能规格（PFS）往往不一致。

    只有到制造试制品时，生产部门才会加入到项目中来。由于工程师负责订购所有部件并制造他们自己的样品，所以生产部的工作必须从零开始。他们要花很多时间去搞清设计要求、找出标准和合适的部件。最后，在第一批货即将发运给客户时，客户服务部才猛然发现原来有这么一个项目。当然，从战略的角度来说，所有零部件都应合理散布在全国各地。这使得生产部更加手忙脚乱，而工程部就要把各种技术工程上的许多要更改的地方尽快地定下来。

    由于采用了职能组织法，该公司开发一个新产品，要比它的竞争对手花多一倍的时间。后来，该公司被卖给一家外国公司。这家外国公司想做一些改进，却被其根深蒂固的“职能观念”弄得一筹莫展。

    不同职能部门里的个人通常熟知自己本行当的事，但未必知道对于其它职

能部门而言什么是重要的。（而产品开发是系统性的工作，对于某职能部门来说是最优的，对于产品和公司来说未必是最优的。所以各环节的人都应该有系统性的观点）图4-3说明了一个职能部门的专家认为有用且有趣的事情，另一个职能部门的专家却常常并不以为然。个人所做的每一个工作步骤，都深深打上了个人专业兴趣的烙印。这种观念偏差所形成的产品，经常与成功背道而驰。

    在一家电脑制造公司里，市场部指出一种新电脑应该满足从工业到军事的各领域广泛的需求。工程技术部在规格里又附加注明这种电脑应拥有最先进的处理器技术，而这种技术在一年后才面世。尽管这些过分的要求并不是非要不可的，但根据设计意见，产品还是包括了这些要求。一年后，该公司意识到开发这样的产品既费时又费钱。于是重新进行产品定位，着眼于现实的需要。

    产品开发采取职能组织结构的做法，往往在产品种类不多又关系密切的小公司内运作良好。在这些公司，每个人都互相认识，而且一般情况下他们在一起工作都很有经验。初建的公司往往使用这种方法，并已成为这种方法运作的典范。然而，当一个小公司只开发一个新产品时，整个公司就是一个产品开发小组。

有些大公司为了有效地沟通、协调和决策就试图效仿小公司的组织结构。他们成立了规模较小的自治事业部，自负盈亏而且在财务上有自主权。这种组织结构在该事业部内部的优势确实有所体现，但对外交流就越发显得困难了。结果，公司白白失去了对公共资源及其它规模经济资源的利用，而利用这些资源正是大公司的优势所在。核心小组的方法是力求达到一种更好的平衡。