产品开发过程演变的阶段.docx

上传人:b****3 文档编号:10955584 上传时间:2023-05-28 格式:DOCX 页数:16 大小:118.23KB
下载 相关 举报
产品开发过程演变的阶段.docx_第1页
第1页 / 共16页
产品开发过程演变的阶段.docx_第2页
第2页 / 共16页
产品开发过程演变的阶段.docx_第3页
第3页 / 共16页
产品开发过程演变的阶段.docx_第4页
第4页 / 共16页
产品开发过程演变的阶段.docx_第5页
第5页 / 共16页
产品开发过程演变的阶段.docx_第6页
第6页 / 共16页
产品开发过程演变的阶段.docx_第7页
第7页 / 共16页
产品开发过程演变的阶段.docx_第8页
第8页 / 共16页
产品开发过程演变的阶段.docx_第9页
第9页 / 共16页
产品开发过程演变的阶段.docx_第10页
第10页 / 共16页
产品开发过程演变的阶段.docx_第11页
第11页 / 共16页
产品开发过程演变的阶段.docx_第12页
第12页 / 共16页
产品开发过程演变的阶段.docx_第13页
第13页 / 共16页
产品开发过程演变的阶段.docx_第14页
第14页 / 共16页
产品开发过程演变的阶段.docx_第15页
第15页 / 共16页
产品开发过程演变的阶段.docx_第16页
第16页 / 共16页
亲,该文档总共16页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

产品开发过程演变的阶段.docx

《产品开发过程演变的阶段.docx》由会员分享,可在线阅读,更多相关《产品开发过程演变的阶段.docx(16页珍藏版)》请在冰点文库上搜索。

产品开发过程演变的阶段.docx

产品开发过程演变的阶段

产品开发过程演变的阶段

                             阿姆拉穆·R·夏皮罗

凡是真正改进过产品研发过程的企业都必然要经历演变的各个阶段。

有些公司步子比其它公司快一些,走的弯路也少一些。

但无论如何,每个具有世界水平的公司必须要经过这些阶段,绝无捷径可走。

  像新产品开发这样复杂的系统或过程需要一个演化的过程。

一个系统中,只有某些要素按特定方式组合在一起才能持续发生作用。

将这些要素汇在一起就成了某个阶段中构成整个过程的代表性要素。

从某种意义上说,新产品的开发有时与其最薄弱的环节一样很不可靠。

将下个阶段的某一要素过早地引入到现阶段是毫无意义的,就如同给一辆自行车加上涡轮增压器一样。

无助于速度的提高,反而增加了重量。

  每一阶段都有不同的业绩标准。

这是我们对产品开发中采用的最佳手段和取得的最佳业绩作基准研究后得到的一个最重要的发现。

企业在阶段转变过程中,业绩明显提高,而且常常是以跃进式的方式进行。

开发周期对开发阶段很敏感。

无效开发或研究开发效率等也是如此。

结果的可预测性也随之加强。

每个阶段中的做法一旦形成规律,成为企业正常运作的一部分,则各阶段仍有不断改善、提高的可能。

  在这一章里,我们将对每一阶段进行论述,包括对各典型要素和业绩标准的论述。

了解每一阶段能使企业给自己定位,并决定下一步应进行那方面的改善。

它使企业都较早地认识到改善机会,并对下一步改善所需付出的努力有较现实的估测。

向“产品及周期优化法(PACE)”的演变

       新产品开发过程的演变可分为四个阶段(如图10-1所示)

  ●零阶段——产品开发过程所需的要素根本不存在或极其薄弱。

采用的方法是非正式的、随意的。

产品开发的失败对企业的生存构成威胁。

  ●第一阶段——这是一个典型的阶段。

项目管理的职责在这一阶段被分配到各个职能部门,协调工作艰难而费时。

  ●第二阶段——这一阶段的特点是项目管理在多层面上(从核心小组到产品审批委员会)进行跨部门的整合,其结果是缩短了周期,最大程度地减少了无效开发。

这一阶段面临的主要挑战是如何采用有效的跨部门项目管理结构和技巧。

  ●第三阶段——在第二阶段成功实施计划的基础上,在整个企业或跨项目的层面上进行整体计划。

产品战略和技术策划与项目管理联系起来。

对整个产品开发管道进行优化管理,取的战略上的收益。

该阶段所面临的最大挑战是实现跨项目管理。

  由于组织变化的速度有限,企业只有按部就班,一步步完成演化过程。

在某一特定时间内,企业只能承受的一定量的变化,一般来说,要少于进行改革或采取其它改善措施所付出的努力。

新产品开发过程演化牵涉到要适当落实各阶段的主要要素,这需要一定的时间。

要使它成为企业正常运作的一部分也同样需要时间。

(凭已往的经验,彻底完成一个阶段需要一至两年时间。

)因此,关键是要认识和了解对发展至关重要的下一批要素,只有这样,才能将工作重点放在这些要素上而将其有效的做法推迟一些。

  实际上,多数公司都是工作负荷过大。

试想一下,有多少公司在初期是超负荷运作的?

管理层推崇同时实施多个项目(MalcolmBaldrige、ISO-9000、JIT、质量周期、QFD、“顾客第一”、鼓励创新、雇员参与、目标管理、创造股东价值等等),而企业往往是无法全部承受。

雇员们学会了口头上服从,而在心里则静静地等待者“下个月的项目”。

在某一特定时间内,管理层只能实施为数不多的几个新项目。

  所有的公司都应认识到这一点:

它们只能在几方面有真正突出的表现。

有的公司职能部门表现出色,也有的是在关键的经营过程中表现不凡。

要取得佳绩并保持佳绩非得要坚持不懈和全力以赴不可。

一个公司在某些方面的优势植根于企业的文化、结构和运作中。

当初正基于这些优势公司才得以建立,因此这些优势也往往受到普遍的好评。

只有努力发挥几个关键的方面的优势,才有可能坚持不懈。

  在某一领域表现杰出的公司,往往担心它们能否保持这种优势。

举例来说,3M公司之所以名声在外,不光是因为其发明创新之多创下了记录,而且还因为其花费巨大精力和时间进行自我评定和对发明记录进行跟踪调查。

3M公司并未满足于商业报刊常把自己作为典型的创新例子加以引用,而是对自己的做法进行定期审核,看是否与报道的一致。

同时,公司建立一个存有各项目数据的大型资料库来帮助了解哪些要素能预测项目的成功。

像杜邦、摩托罗拉和IBM等公司都定期评定自己的发展阶段:

摩托罗拉每年都要进行质量审计;杜邦也应用类似的方法来进行所谓的“持续发展评定”。

  文化的惯性很大,这就意味者从一个阶段到另一阶段的转变是非常困难的。

但是,对一个公司的竞争对手来说,这也不是轻而易举的事。

公司一旦达到了一个新的阶段就会取得竞争优势。

已取得的成就往往可能保持很久,因为正如创造成就一样,改变成就也绝非易事。

  向PACE演化的各个阶段的主要特点已在表10-1中作了概要的说明,我们将在下面章节作更具体的阐述。

表10-1:

零阶段

每一阶段

第二阶段

第三阶段

产品开发过程

(结构及定义)

无。

对能否推出新产品的担忧多于对其它有关开发过程的考虑。

项目管理缺乏原则性。

各职能部门的职责明确。

难于协调。

对开发过程的依赖程度相差很大。

开发流程有一定的结构,并有清楚但简单的定义。

是综合各职能部门的简单整体调配过程。

适用于所有项目。

开发流程已植根于企业文化中。

产品开发流程与产品战略和技术过程有效地结合起来。

项目小组的组成

随意组合。

“消防队员”即应急的人员往往比项目经理更受尊重。

小组成员变化很大。

职能部门间的矛盾大。

领导权易手快或无法确定。

类似核心小组模式的小型、跨部门专业小组。

强有力的项目管理。

经验丰富的核心小组通常开发多代产品。

利用核心小组作为产品开发平台及进行技术开发。

管理决策过程

非正式且非常被动的。

管理层注意到什么项目,资源就流向什么项目。

通过年预算确定项目的优先等级。

建立了项目进展状况的汇报渠道,但往往很费时。

职能部门管理者确定项目的优先次序时,实际上往往是自相矛盾。

资源分配困难。

跨部门的领导小组(如PAC)依照有效的、以产品开发事件为依据的阶段性审核,确定项目的优先次序。

资源的分配与项目的优先次序保持一致。

决策基于已充分开发的产品和技术策略。

项目的优先次序依管道的状况和技能综合计划而定。

有关产品平台的决策越来越受重视。

持续改进

个人有长进,但难构成有组织的过程。

个别的部门掌握着开发过程的主要要素;关键技能只限于某些个人知道。

难于从失败的项目中汲取教训因为怕遭到责备

专职的开发流程总设计师到位。

定期进行程序评定和更新。

确定进入下一阶段的机会。

程序的所有使用者同时又是其参与者。

有过程改进及延伸的历史习惯。

确定不断完善的机会。

目标和衡量尺度的制订

没有明确程序目标。

注意力集中在怎样生存或扭转财务状况。

无总进度目标或总进度目标完全由管理层制定。

现有业绩难以评定。

定期设立程序目标,对照检查。

程序目标包括周期和质量指标。

通过大量分析世界一流公司的衡量尺度而设立自己的程序目标。

正常情况下,计划每年在各主要方面较前一年进步5—15%。

产品战略过程

无具体过程,依以往决策行事。

有策略不统一的倾向。

战略目标与产品战略不一致或脱节。

有操之过急或希望满足所有客户之所有要求的倾向。

重心在于个别的产品,而不在于产品平台。

产品战略如果做的话就每年策划一次。

阶段性审核中出现的产品战略问题倾向于采用非正式的方法处理。

重心放在现行的和新的产品平台。

产品战略的策划是个正式的过程。

它与技术策划紧密联系起来,通过有效的产品开发过程而实现。

技术管理过程

技术开发与产品开发无明显区别。

这是职能部门的责任。

市场部和技术部之间的相互指责是常见的事。

年度间资源分配的出入很大。

通常无正式的技术策划过程。

技术开发与产品开发的区别日益明显,却未得到很好的管理。

技术策划与产品战略有机结合起来。

更有意识地对技术开发进行管理。

明确界定了从技术到产品开发的转移。

管道管理

管道失控或失衡。

“应急行动”占用很大比例的开发资源。

同时展开的项目过多。

某些部门长期存在“瓶颈现象”。

学会分期分批地展开项目。

获得人员供给的项目更少了。

技能合理组合不当仍然是个常见问题。

学会管理分期分批展开的项目。

有了长期的技能合理组合。

上市时间的管理

无法测量的控制。

可能是无限期的。

无规律亦难于预测。

难以衡量。

倾向于在尚未充分调试的情况下将产品推向市场,生产上问题多,经常做重大设计修改。

是第一阶段上市周期的40%至60%。

主要开发质量好的产品,批量生产以达到一定的回报。

是同行业中的佼佼者且上市周期日益缩短。

上市周期与产品战略优势相结合,重点开发适销对路产品,取得造成优势,令竞争对手难于超越。

开发生产力

无法测控。

通常极低。

许多产品在后期被取消而根本无上市机会。

上市周期长,限制了生产力。

新产品创收远远落在同行业领先者的后面。

缩短上市周期,大提高了生产力。

阶段性审核要早期就可取消计划,避免后期取消产品开发计划而带来的研究和开发费用的浪费。

新产品的创收有所提高。

研究和开发部几乎没有浪费现象。

公司所有努力都集中于产品平台、技术和产品上。

企业销售额的相当大一部分来自于新产品或新产品平台的创收。

零阶段

  处于零阶段的企业既没有一个结构化开发过程,又没有成熟和过硬的职能部门或项目管理技术以克服无组织性。

这是个非正式或随意性的阶段,每个开发项目都被作为有史以来的第一个项目对待。

项目的组织、管理没有一贯的模式。

如果企业遇到外来压力,就会随意成立或改变不同的专门小组。

在这种被动的环境中,资源往往流向管理人员注意到的那些项目。

这些应急措施通常是针对某一问题或客户的投诉。

没有一个改进和衡量进展的过程,只有个人从中学到一些新东西,而公司的整体财务状况是衡量开发过程是否成功的唯一工具。

甚至连产品战略、技术管理、管道管理之类的高级过程都不被看作是过程。

  处于零阶段的公司,难以定期定量地将成功产品推向市场。

偶然的成功又因缺乏相应的产品促销手段而无法保持竞争优势。

单个项目开发周期的长短无法预料,但总体开发时间往往拖得非常长,因此,相当多的项目最终无法完成。

管道的测量没有记录。

如果没记录,就会显示很大比例的开发资源被用于非开发性活动,如技术服务和生产支援等。

  多数有生存和发展能力的公司都会进入第一阶段或通过第一阶段,但是有相当一部分的公司仍停留在零阶段或保留着零阶段公司的某些特点。

一些零阶段的公司都有某一强项(如工程方面)及几个弱项(如生产和市场部门)。

例如,一家由学院着名人士创立的生物技术公司或许要寻求一家有名气的药品公司将其某一新产品推向市场。

一些处于第一阶段的公司可能因为忽略了开发活动,原先已形成的结构发生裂变,结果倒退至零阶段。

  处于零阶段的企业所面临的主要挑战是如何正视并改进其职能部门的弱点,同时制定一些新产品开发活动所涉及的原则,如基本的项目管理技巧等。

如果零阶段公司能从职能上重视其产品开发及项目管理的薄弱环节,它就会进入第一阶段。

如果它能加大产品开发力度,跨部门改进产品开发的过程,则它有可能直接进入第二阶段,但所做的努力和所负的责任不应有一丝松懈。

第一阶段

  第一阶段的主题是职能部门的有效管理。

零阶段的问题在于特定职能部门的失误和失衡。

随着各部门找到其特长并逐步实行正规化运作,这些难题便迎刃而解。

与零阶段的非正式的、随意性的过程不同,在第一阶段中,各职能部门发展和应用了一系列已归档并可以重复的流程。

组织结构也是以职能部门为单位的。

由于更多地强调职能部门的优秀表现,所以,停留在第一阶段的公司往往将大量的精力用于各个部门间的沟通上。

  产品开发被视为职能部门的责任。

在一些公司里,某一职能部门如工程部或研究与开发部或市场部对产品开发负全责。

在另一些公司,产品开发的主要责任在不同时期落在不同的职能部门上。

从一个部门转移到另一部门的责任交接点上往往是矛盾重重和问题成堆,简直成了部门之间的“战场”,尤其是当一个部门将责任以“扔过墙去”是方式转到另一部门时,更是如此。

这样,某些在开发早期未得到妥善处理的问题也被一起“扔过墙去”。

“扔过墙去”的方法在第一阶段很普遍,因为毕竟开发过程中有许多堵这样的墙。

  企业以各种方式试图改善这种互相扯皮的现状。

有时,它们制定详细的流程文件以捕捉每项职能部门的责任及跨部门的依托关系,但往往由于过分复杂和缺乏弹性而渐渐不为所用。

更多的努似乎花在了详细说明各部门的共同职责上,而没有花在寻求简化部门间相互配合的方法上。

  有时,处于第一阶段的企业为了改善它们的系列化流程而积极地寻求推倒这些墙的方法。

例如,有的公司要求生产工程师承担部分开发工程师的职责,以保证项目启动前能完成各项任务。

有一家公司的文档编制组在不知不觉中承担了产品功能规格编写的任务,而这样的编写在开发过程中是很笼统的,所以也从来没有确定下来。

  在第一阶段,项目的组织结构较零阶段好些。

但各小组的组成缺乏专一性各连贯性,项目经理也没有恰当地发挥作用。

从一个项目到另一个项目,攻关小组的构成都不同,而且常常在进入职能部门的迷宫后还不断发生变化。

一旦他人的工作重心稍转移,项目管理者们便毫不犹豫地调整各小组的成员。

  处于第一阶段的公司倾向于使用负责相对较弱项目的经理。

他们的角色更像是行政管理人员、记录人员、协调人员,而不是领导者。

有时我们将这类管理者称为“我是克劳狄”式的项目经理,他们会如实记录罗马被焚烧的全过程,而不为大火所动,他们只会记录项目的历史,却不会有力地影响其进程。

  这一阶段中的计划几乎无一例外地缺乏精确性。

一旦有什么闪失,就一再隐瞒,只在万不得已时才告诉管理者。

由于项目的责任人常常变化,计划进度便常常只包括开发项目的一部分。

制定各职能部门进度表的人似乎与项目一开始时设制的总体进度表没有什么关系,其结果是总体进度计划缺乏完整性,也得不到及时的补充或修正。

实际计划进展没有及时地向管理层汇报,因为没有人对此负有全责。

当我们向处于第一阶段企业的开发人员询问其项目进展计划时,得到的回答通常是:

“你想看哪一份呢?

  由于职能部门所拥有的权利和责任往往比项目开发组多,责任的划分就变得很模糊。

当我们分析第一阶段项目开发受阻的企业时,发现一条规律,即责任随着项目的展开而不断转移。

一个职能部门做出的决定到了下一个部门便被否决了。

每次责任的移交成了重新界定项目的机会。

开发组成员对其所在职能部门的忠诚远远超过其公司或项目的忠心程度,这就导致他们决策的狭隘性。

一旦出了问题,部门之间就相互抱怨及推诿责任,备忘录中常常出现这样的字眼:

“市场部认为……或“工程部的看法是……”,或“生产部觉得……”。

  处于第一阶段的企业在决策过程采用逐个签字把关的程序。

这是一项费时且颇具政治倾向的活动。

一项已签字通过的决定在任何一个关键的部门可能会遇到私下抵触。

此外,整个程序没有任何时间压力。

一旦出问题,如对某一产品的看法不一致时,逐个签字把关就会使开发活动停下来。

在纪律性强的公司里,这种做法会延误时机。

在组织相对松散的公司里,最终解决此公开问题的时间会无限期地向后推。

开发人员不得在未得到某些签字的情况下继续工作,希望会有好的结果。

如果出现问题,那些未签字的人便会站出来否定这一项目。

  预算是用来分清优先次序的机制。

年度拨款划到各个职能部门,再由他们将资源下拨到各个开发项目。

这样一来,经常会发生优先次序冲突,妨碍整体资源调拨的优化,造成延误。

  由于没有关键的阶段性审核,管理层通常要求开发小组成员经常汇报开发进展情况,高层管理人员以这种方式来对项目进行监督既费时又往往效果不佳。

  第一阶段工作的不断完善是在各职能部门这一级单位完成的。

由于第一阶段的重点是优化职能部门,因此以某些职能步骤作详细的定义和归档并不少见,但对另一些同样重要的职能步骤却并没有定义和归档也是屡见不鲜。

例如,有一家测试公司,是世界一流的,但开发过程的效率却极低。

虽然它有高水平测试经验法则,但在现实环境里却是一贯地超预算运作。

没有人能改善部门间的联系。

因为各部门都小心翼翼地守护着自己的职能,没人会主动承担改进整个开发过程的责任,缺乏协同作战、共同开发的动力。

处于下游的职能部门如生产和服务部等往往到项目的后期才参与进来。

由于在开发项目后期的调整困难重重而且费用很高,因此缺乏协同作战就势必会造成超支和延误。

  处于第一阶段的公司或许在职能部门内部有较好的衡量尺度,但整个开发过程往往缺乏准确的衡量尺度。

没有像样的开发项目衡量尺度,比如上市时间或无效开发的衡量等,就很难为开发过程的完善制定合理的目标,也很难为具体的项目制定精确的目标,所以相对以后的两个阶段而言,其预测的准确性差,便是意料中的事。

在后面的两个阶段中,周期指导方针是设立具体目标的良好基础。

  由于没有客观的运作目标,高级管理层便常常随心所欲。

他们或是认定原进度计划太虚而要求速度放慢一倍,或是因窥视到市场的机会而将某一完成日期强加给开发人员。

开发人员往往会对这类强加给他们的目标置之不理,或者因此而士气大跌。

有的开发人员甚至备有两份进度表,一份是给管理层看的,另一份则是用于指导项目活动的实际进度表。

上述的一切致使原计划目标与实际运作脱节。

  在第一阶段,产品战略通常无原则性。

既使制定了长期产品规划,也是存放在市场部,可能与实际上马的项目没什么关系。

这一阶段的通病是想做的事情太多或是满足所有客户的所有要求。

由于开发周期比内部认同的要长,产品规划就不会长远。

注意力总是集中在下一个产品,而不是把产品看作产品系列的一部分,或是把产品系列看作产品平台的一部分。

这样,项目筛选过程就不免带有盲目性和随机性。

  基础技术开发也面临类似的问题。

职能部门各自为政导致管理层决定投资的项目不一定与企业或其战略目标有任何关联。

研发部的管理者不相信市场部的人会有长远的眼光,因而希望独立选择应该支持哪些项目。

其结果是,在努力取得较好的项目和资源平衡的同时展开的项目往往过多,对项目采取周期性的,删减(往往是无效的)也过于频繁。

  处于第一阶段的企业肯定有新产品上市,但其周期相当长,大约是处于第二阶段公司的两倍。

制定管理决策时效率不高,使得有些项目迟迟未能取消,无效开发比例却在上升,远远超过了第二阶段。

在条件不成熟的情况下,迫于时间压力,草率地将产品推向市场,往往会增加后期的成本,甚至当产品上市之后,公司仍要为此付出昂贵的代价。

  处于第一阶段水平的动作在某些行业中仍具有稍许的竞争力,原因是这些行业产品开发管理的展开较迟,但这种状况不会持续太久。

对时间极为紧迫行业如电子业来说,处于这一阶段的企业仍然很难生存。

  处于第一阶段的公司所面临的主要挑战是怎样在项目层次上综合各部门的力量进行产品开发,并获得这一步改进带来的所有好处。

第二阶段

  在第二阶段,企业取得巨大的进步。

通过协调实施产品开发项目的各职能部门的力量,这些公司奇迹般顾缩短了开发周期,提高了开发效率。

  一个简单的总体流程联合了所有的职能部门。

这一流程的界定清晰、结构简单。

它吸收了第一阶段中形成的职能部门运作的精华部分,精简并纳入各部门共有的最佳方面。

在较成熟的、处于第二阶段的公司里,这一流程几乎涉及所有的方方面面:

百分之百的合理项目都使用这一流程。

  第二阶段中,一个共同的做法就是成立小规模的、专一的跨部门小组,如核心小组。

成员组成有一定的标准,因项目的复杂程度和大小而容许有一定的差别。

在实施所有项目的相关事宜中,这些小组有效地履行了它们的功能或职责。

作为一个整体,它们对整个项目负责,从而减少了第一阶段中常见的部门间相互扯皮的现象。

它们由项目经理带领,有效地通过跨部门动作来达到项目的目标。

  第二阶段中,管理决策的制定过程上了正轨。

建立了有决策能力的跨部门管理机构,如产品审批委员会(PAC)。

在一些关键的决策点上,委员会通过有效的、针对研发事件的阶段性评审过程将各开发小组的表现清楚地展现在管理层的面前。

第一阶段中频繁的情况汇报因费时不得要领而不再使用。

每个阶段性审核后都要进行决策。

这样就排除了因决策拖延而造成的占总数百分之四十的无效开发。

  这些综合管理小组既有企业战略策划人员又有主要资源的管理人员,所以不大可能制定背道而驰的决策。

决定实施某个项目就要同时决定提供项目所需资源。

这种从高级管理层到核心小组层面的跨部门沟通使企业的决策始终保持一致。

  第一阶段中的项目进度计划伴有很大随意性,而第二阶段因为有了周期指导方针情况就截然不同了。

这些指导方针是针对开发过程的每个步骤而制定的,它们依项目的特点不同而有所不同,这些特点包括项目的复杂程度和对新技术的依赖程度。

随着过程的深入,周期指导方针会得到定期的修正。

所谓周期指导方针实际上就是时间的标准开支。

把注意力放在在开发活动的内容上,而不是在评价制表人的动机如何,就可改进计划进度表的制定。

计划进度表准确性的提高,有利于处于第二阶段的公司更合理地规划项目和分配资源,减少了项目经费不足的情况。

  处于第二阶段的企业采用了共同开发的方法。

因为各主要职能部门自始至终都是项目开发的一部分,所以从一开始各方面的人员都希望把事情办好。

生产部门在项目开发初期就加入,开发人员也不会在要加大项目开发力度时放弃该项目。

运用专门开发小组和进行行结构化开发就能在开发活动中取得高度的一致性和协调性。

  在第二阶段,职能部门依旧扮演着至关重要的角色,但它与开发单项产品时所负的责任还是有显着区别。

现在职能部门的主要任务是保持和提高技能水平,并为单个项目提供必要的资源(这在管道管理中开始使用综合技能,这一过程在第三阶段中将得到进一步的完善)。

  与以前的各阶段不同,第二阶段的企业可以树立有实际意义的新产品开发过程动作目标。

在第一阶段,因为对运作表现没有历史记录,所以预测将来的动作时相当不准确或过分地小心翼翼。

相反,在第二阶段,既有历史资料记录,流程中的责权也很分明。

专职的流程管理者,有时亦称作PACE工程师或PACE管理者,已到位,定期地更新流程并确立新的流程目标。

流程管理者最关键的职责之一就是要准确把握进入下一阶段的时机。

  从上市时间和产品质量角度来看,最好的百分之二十的公司都处在第二阶段。

第二阶段公司的上市时间通常只是第一阶段公司的40%--60%。

显然,从第一阶段到第二阶段的演变是企业跨出的一大步。

要保持竞争力,企业就必须走这一步。

达不到第二阶段动作标准的公司便只能由已达到这一阶段标准的公司任意摆布了。

  各阶段性审核自然会提出一些处在第二阶段的企业尚无成熟办法解决的问题。

这都是些跨项目间的问题:

如产品战略、技术管理和管道管理。

在某种程度上,第二阶段公司也处理了一些相关问题,但是它们缺乏特定的机制去系统的消化和解决这些问题。

针对每个问题按制定处理过程,就成了第三阶段所面临的主要挑战。

第三阶段

  一旦公司实现了以项目为单位的跨部门协调,那么它们就为了一次飞跃奠定了基础。

下一次的飞跃是指全公司范围内的跨部门协调节。

这便是第三阶段——整个企业范围内产品开发的协调。

在这一阶段,企业在PACE管理中加入跨部门的要素,这些要素使产品开发与其长远的战略目标保持一致,并优化了开发组合。

  在这一阶段中,引入了几个新的流程与第二阶段的流程有机地结合在一起。

显而易见,新的流程包括产品战略流程和技术策划流程。

而管道管理自第二阶段起便有了,现在需要细化。

最后,第二阶段建立的PACE项目管理要素,在第三阶段得以进一步改革进和理顺。

第二阶段的作法得到广泛理解和认同,不必进行像以往那样正规的说明和监督。

  在第三个阶段,企业对专一跨部门小组如核心小组的依赖关系已完全建立起来。

这些开发小组通常有很

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 工程科技 > 材料科学

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2