|返回首页|0755-26070628

1.研发变革管理所遵循的方法论


1.1    什么样的公司需要实施研发管理变革
        如果公司领导对公司发展前景颇有信心,但是研发效能低下,不能满足公司发展的要求,公司存在以下三种状态,那么突破困局,实施研发变革是适宜的:
    1)    没有完整和明确的产品开发结构;
    2)    有完整和明确的产品开发结构,但其过程并没有得到遵守;
    3)    有结构化的过程并得到了遵循,但并不能改进或加快开发进度。
          【案例】A公司是一个典型的例子。经过多年突飞猛进的发展之后,该公司遇到了重重困难。发展速度放慢,部分原因是由于产品开发周期的拖延,但它的竞争对手却能够如期推出了产品,抢占了很大一部分市场。该公司迫于市场压力,将仍未经过严格的设计确认的新产品勉强推向市场,由于试用期内客户反馈回来的技术问题很多,设计更改很多且售后服务成本奇高。这种状况使企业不得不推迟正式批量生产的时间,导致了客户的抱怨甚至流失。销售人员建议客户不要对新产品下订单,而是去购买老一代的折价产品。企业内部士气低落。项目工程师为了解决项目问题搬到公司来住,他们每星期工作八十个小时或者更多的时间。两个很有威信的工程师,最近都离开了这家公司,加入到另一个较小的竞争对手的阵营。此外,还有别的技术人员也四处散发简历准备跳槽。一个疲惫不堪的项目经理说:“有一点是肯定的,我们再也不能按照这种方式开发产品了”。

        最后决定需要开发一套新的开发流程。这任务交给了一个小组来完成。这个小组经过几个月辛勤的工作后,小组拟订了一份描述新流程的文件。该文件被发放至企业的各个部门。小组的宣传攻势很猛,到处分发过塑卡片,卡片上写着新流程的概要。几个项目小组也都试图采用这一流程,但都由于这样或那样的原因没能坚持。有些项目经理声称已进入开发中期或末期而不能使用新的流程;有些项目经理在执行新流程过程中遇到了具体的困难而得不到明确的指导而灰心;其中一个项目经理拒绝执行的理由简单地归结为新流程太长太细,执行周期太长。总之,所有的项目小组都可以找到自己项目放弃对新流程执行的理由。开始时新流程设计小组还与多个项目经理开会,鼓励他们使用新的研发流程体系,但在这些会议中并没有解决各个项目经理的抱怨。最后,新流程的设计者也失去信心,纷纷逃离这个职责而承担别的职责以免受到更多的责备。这份文件出台六个月之后还是没有一个项目小组是按此新流程行事的,但那份厚厚的流程文件已被束之高阁,一切似乎又回到了从前。
        通过研发管理水平的提升使研发能力得到了提升,这不是件容易的事,宛如诗经的著名诗篇“蒹葭苍苍,白露为霜。所谓伊人,在水一方。溯洄从之,道阻且长。溯游从之,宛在水中央......”,这的确是一段艰巨的航程。
        将先进流程与系统综合起来的效果是非常明显的,可以将更好的产品更快地推上市,同时以更少的投资做更多的事。某IVD体外诊断设备的公司,其管理水平大体属于阶段1(职能管理阶段),国内最为领先的同类IVD体外诊断设备公司,研发管理水平大体处于阶段3(集成项目管理阶段)。前者通过参观,进行总体对比分析,发现后者的研发生产率大约是前者的5倍。这是他们感到十分震惊。事实上研发管理每跨上一个台阶,其研发生产率大体上可以提升一倍左右。

1.2.    谨防研发管理变革失败的陷阱
        为什么那么多公司做出了真诚的努力却又见效甚微呢?经验告诉我们,阻碍企业获得成功的原因很多,可以归纳如下:
1)    高层管理者的支持和变革的思想准备不足
        产品开发横向跨越了各个部门,纵向跨越了各个管理层级。而各部门所遇到的困难和承担的责任都不同,所以对企业存在问题的认识也会不一致。如果产品开发进展缓慢,从某种意义上说是每个人的问题,但是也许有些人还觉得自己的工作还做得不错,或者没有意识到如果不实施变革,整个企业的生存和发展都会受到威胁。在大多数的企业里,产品开发管理改进常常专门由某个部门负责,一旦出现问题,人们都期待那个部门去解决问题。而事实上,有效的改进措施基本上都超出了一个部门的范围,除了公司最高管理层之外,很难有其他人员或部门能够承担起这样的责任来。

        变革的先决条件是企业必须拥有足够的内在动力,并且对变革的必要性及变革的方向达成了共识。非若此,就不能实现广泛的动员与参与,变革就成为了少数人员的事情,这就难以规划实施系统性地改进措施,就会遭遇到或明或暗的强大阻力而姗姗难行,最终归于失败。
2)    部门视角的局限导致缺乏系统性的改进
        但是许多公司往往将注意力集中于职能部门内部的具体改进而不是开发链的全过程的改进。市场、开发、工艺、质量、供应商管理、采购、生产、销售、售后服务各个部门都存在着这样或那样的问题,有的公司只是简单地要求各个部门抓住一两个点各自进行改善。这些局部的努力可能会有些短暂的效果,但却不能给整个公司以较大改观。
A公司对研发管理的质量效率都不满意,为此引入了可靠性设计方面的培训,这对专业设计人员技能的提升是由很大帮助的,但是尽管专业设计人员掌握了可靠性设计的技能,A公司的质量、效率仍然未得到显著的提升,这是因为跨部门沟通、协调、决策迟缓的短板所致,具体技能的提升无法弥补研发管理体系不足的缺陷。
因为忽略了对各个部门活动接口的改善,当产品开发陷入困境时,相关部门往往会采取相互指责或推卸责任的姿态,而不是去做些建设性的跨部门沟通协调工作,而各个部门在进行研发流程体系变革时却都试图尽量避免与其他部门进行协同所带来的“麻烦”,总是倾向于简单地调整组织结构来改善跨部门接口,忽略了通过研发流程体系解决产品研发中跨部门的沟通、协调、决策的问题才是更加具有本质性的,而这正是研发流程体系再造成功的关键。
        D公司发展的早期曾经有一次不成功的变革。总裁在听取了现有职能管理组织结构不足的分析和要改进的建议后,便决定建立矩阵式管理的组织,采用项目核心小组法进行产品开发。有几个副总裁提醒他需要拟订一个计划,仔细推敲研发流程体系所涉及的因素,而他却不以为然,产品开发过程中一些组织结构之外更重要的流程问题被忽略了。不久,项目核心小组的工作遇到了多方面的困难,研发效率并未得到提高,反而有下降的趋势。两年后公司又变回到职能式管理的组织结构。
3)    未解决与质量体系的融合
        由于贯彻ISO质量管理体系标准呢的主责部门一般是质量部,而负责产品开发的主责部门一般是研发部,由此产生了一个常见的误区是质量管理体系文件要求与产品开发活动相互脱节,产生了相互矛盾、重叠、二义性等多重困扰。甚至为了规避矛盾,简单地将新研发流程体系与质量管理体系对立起来。
        研发管理人员大多从技术岗位走向研发管理,急学先用,特别关注研发管理业界的具体实践,而较少注意将整个新研发流程体系的建立和优化置于整个质量管理体系中来考虑,并且大多对ISO9001族标准不不熟悉。而质量管理人员大都长于生产质量管理,缺乏对产品开发过程管理特殊性的认识,常常站在生产管理的视角将生产质量管理的思维类推到研发,通一孔,晓一理,而不知权衡,事实上就很难得到研发人员的认同。很多情况下,这种看似并不十分要紧的认识上的鸿沟却可能产生难以逾越的沟通障碍。
        【案例】G公司以研发中心为主,重组了研发流程体系,但是新的新研发流程体系文件却迟迟不纳入到质量管理体系中,原因是质量体系管理人员担心质量体系审核通不过。在新研发流程体系推动执行过程中遇到大量需要研发部门与质量部门联合解决的问题。研发部门只关注研发中心内部新研发流程体系文件的执行,而忽略了质量管理体系应发挥的支撑作用。例如纠正和预防措施是质量管理体系的基本要求,研发部门不是与质量管理部门充分沟通协作通过质量管理体框架来实施纠正和预防措施,反而以与质量管理部门沟通困难为名,另起炉灶,不断增加研发部门的人力资源,自建一套问题管理系统,研发部门人数越来越多,效率下降,作为质量管理体系不可缺少的纠正预防措施流程却变成了研发中心不理不睬的僵尸流程,其作用仅仅用于体系审核发现的问题,这样不仅增加了公司流程的复杂性,而且对公司的跨部门问题的分析解决都是很不利的。
某些公司不将新研发流程体系纳入质量管理体系的另一个常见的误区是新研发流程体系文件执行起来太灵活,担心质量体系审核通不过。的确,新研发流程体系常常不能直接执行,经常需要针对具体项目的特征对新研发流程体系规定的过程进行调整并形成项目计划,真正能够直接严格执行的是项目计划,而不是新研发流程体系,这正是产品开发的特殊性表现。这个困惑只需要将新研发流程体系文件解释为指南就会迎刃而解。
4)    忽略了隐性问题的解决
        冰山理论可以形象地说明研发管理变革所面临的挑战:组织结构、流程、信息化系统等方面存在的显性问题,好比露在水面以上的小部分冰体;由权

力关系、文化、运行机制、人才、愿景结合在一起的组织行为倾向等隐性问题,好比隐藏在水面以下的大部分冰体。
        显性的问题固然重要,但是隐性的问题也不能忽略。只有理解隐性的问题,并且与显性的问题联系起来考虑,采用协调一致的解决方案,才有可能达到良好的效果。
        研发流程体系的改进肯定会对已有的权力关系产生冲击,有些人为保护自己的权力而使行为成为了变革的阻力;过去只注意完成产品实体,现在要求写文档,并且对文档还要进行咬文嚼字的严格评审,这会让许多人感到不习惯。过去基于事件触发反应式的研发活动要转变到以研发流程体系为基础的研发项目计划指导下的研发活动,也会使许多人怀疑这样做

是否会降低工作效率;新的研发流程体系实施的效果在3个月之后就可以看到明显效果,但完全彻底地被吸收则大约需要2年或更多的时间,吸收的程度依赖于面向新研发流程体系的管理人才队伍,这支队伍的培养也是一个挑战。

5)    管理重心过早的转移。缺乏对过程持续改进的管理。
        成功地实施新的研发流程体系,需要有管理层稳定的支持和传递持之以恒的压力。如果还没有达到新的稳态之前管理层过分频繁地变换,或者领导层的工作重心转移而中断了持续一贯的改进努力,就会慢慢耗尽企业内变革的热情,使变革无疾而终,半途而废。
研发流程体系的改进需要公司在使用该流程的过程中要不断学习,吸取经验教训以便进一步改善。这一切都不可能自发地产生,因此公司应指定产品开发过程管理的责任人,由他来负责维持和改进开发流程。
        在当代技术条件下,过程的持续改进必须与信息化结合起来。许多公司的信息化建设缺乏系统规划,而是着眼于点状需求反应式的驱动,到了一定阶段信息化设施的破碎就不能支持流程体系协调发展。
        虽然上面这些障碍都是风险,是成功的研发管理变革不能不仔细考虑应对的。

1.3.    契合企业生态的多样性
        《晏子春秋?杂下之十》:“橘生淮南为橘,生于淮北为枳”,同样的物种产生不同的结果,这就是变异。物种的生存和成长必须与生态环境相适应,生态环境条件即物种形成的地理、气候、水质、土壤。万物都是环境的产物,生态环境不同,物种为了生存和成长而发生变异是自然的也是必需的。在生物进化的长河中,变异推进造就了物种的多样性,其中生态环境给予物种的影响是决定性的。在自然界生存最久的并不是最强壮的生物,而是最能与其他生物共生并能与环境协同进化的生物。
        企业生态和自然生态也相似。C公司是中国近二十年最为成功的企业之一,当然也包含了C研发的巨大成功。从企业生态环境看,也是具体企业生态环境下一种微观的成功实践,C研发的成功是C研发与其特定企业环境生态协同共生的结果。但是如果认为搞IPD就是模仿C模式,这是个很大的误区。IPD是集成产品开发的简称,其具体表现形式是多种多样的,但其基本思想在麦克格拉斯的PACE中得到了阐述。值得提醒的是PACE作为产品开发的指南也是有不足的,欠缺了至关重要的质量管理、物料控制方面的要求,这些要求在本书中的ePACE模型中给予了补充。
思而不学则殆学而不思则罔。我们应该学习行业标杆的最佳实践,但我们同时需要铭记先古哲学家赫拉克利的至理名言:"人不能两次踏进同一条河流"。将某业界标杆企业微观的成功实践无条件地推理和扩大至宏观规律,忽视对自身的特点和企业生态的分析研究,丧失了自我,违背了一切从实际出发的基本原则,这是许多企业模仿业界标杆不成功的重要思想根源。移植也许也是可行的,照搬教条则万万不可。在这里对于共性与个性关系的把握、变革尺度和管理灰度的把握就体现了管理的水平。
        许多公司之间的产品开发过程中有许多相似之处,但也有一些明显的区别,ePACE可根据不同行业、各公司在价值链的位置以及公司的要求进行大幅度的调整以适应具体情况。以下的例子说明在实施ePACE过程中如何顾及不同行业的特点。
1)    航天航空军工
        这些行业中政府或主要客户对产品开发的影响重大,遵守与政府或顾客所签订的合同,保证按期交付是最主要的。那么如何认识这些要求并有效地执行就构成了最大的挑战。有时最符合政府或顾客意图的做法与实际开发过程的最佳做法存在不一致,必须采用政府或顾客可以接受的方式进行产品开发,大多数情况下属于ODM开发方式。
航天产品的特点是所处的环境恶劣多变、产品高度复杂、单件生产、投入巨大、开发周期长、行政监管严格,并且要求一次性成功。
因此航天产品对六性(环境适应性、可靠性、维修性、保障性、安全性、测试性)要求很高。对于发现的产品缺陷必须贯彻双五归零(技术五归零、管理五归零),这是对ISO9001纠正预防措施的强化。技术五归零要求针对发生的问题,从按"定位准确、机理清楚、问题复现、措施有效、举一反三"的五条要求逐项落实,并形成技术归零报告或技术文件。管理五归零要求针对发生的质量问题,从管理上按"过程清楚、责任明确、措施落实、严肃处理、完善规章"的五条要求逐项落实,并形成管理归零报告或相关文件。
航天产品研制的组织一般是总体所+专业厂所,需要跨所协同。总体所提出需求和系统设计方案,专业厂所完成专业设计和产品制造。复杂的产品会被分解为系统、分系统、子系统与组件,分别进行开发,然后进行系统集成。
        航空产品与航天产品有许多方面相似,但也有显著区别。航空产品一般可重复使用,并且具有一定的批量。作为重复使用的运载工具,航空行业有其独特的质量管理体系要求,这个质量管理体系要求与汽车行业的质量管理要求有某些类似性。
军工产品具有小批量多品种的特点。在研发流程体系上需要考虑满足四证要求(国军标质量管理体系证、武器装备科研生产单位保密资质证、装备承制单位资格证、武器装备科研许可证)。
航天航空军工产品虽然理论上最强调全生命周期成本管理(LCC),但在实践中LCC并没有得到足够的重视,也许这与这些行业的开放度较低、竞争性不够强有关。航天、军工产品由于批量小,往往对可制造性考虑不够,在军民融合过程中,可制造性、成本往往会成为瓶颈。
2)    汽车
        汽车行业具有高安全性、可靠性、低成本、大批量的特点,属于强制认证的产品。汽车产品已经高度模块化,整车和零部件厂的开发管理各具特色,需要满足TS16949质量管理体系要求。APQP、PPAP、SPC、MSA、FMEA这五大质量工具符合汽车行业的特点和要求,因此得到了广泛的应用。汽车行业对供应商的质量管理要求可圈可点,对其他行业有很大的借鉴意义。
3)    轨道交通
        轨道交通与汽车有很高的相似性,都是安全性、可靠性要求高的产品。轨道交通产品与汽车产品的开发最大的不同也许是在于监管体制和行业开放程度的差异上。轨道交通在国际上属于行业监管(例如IRIS认证),在国内属于行政许可(如CRCC),虽然在逐步开放,但开放程度仍然不高,竞争不充分,传统上并不特别关注成本;而汽车产品属于行业监管、行业认证许可,已经达到充分竞争,对成本极为关注。随着轨道交通行业的逐步放开,竞争加剧,成本因素将逐渐突出。轨道交通企业许多技术和产品也是可以移植到公路交通方面的,但是轨道交通业产品成本偏高,极有可能导致在充分竞争的公路交通领域败北。只能在轨道上使用,一脱离轨道就在竞争中失败,这也许是许多轨道交通企业的心中之痛。
4)    医疗器械
        医疗器械的特点是要求产品的安全性、有效性,小批量多品种也是一个特点。医疗器械上市前,医疗器械产品开发周期通常很长,因为它们一般都需要经过漫长的开发周期,必须满足一系列的通用技术标准(例如电子医疗器械电气安全标准IEC 60601-1)、分类专业技术标准、风险管理标准(例如ISO14971)、医疗器械质量管理体系要求(例如ISO13485、QSR、GMP),需要进行临床评估,最后还要提交监管当局或政府审批(认证或注册)。使用精心策划的研发流程体系和有效的设计控制过程可以大大提高合规性,缩短医疗器械产品开发周期。
5)    药品
        新药从最初的实验室研究到最终摆放到药柜销售平均需要花费12年的时间。进行临床前试验的5000种化合物中平均只有5种能进入到后续的临床试验,而仅其中的1种化合物可以得到政府监管当局的上市批准。
        总的来说新药的研发分为两个阶段:研究和开发。这两个阶段是相继发生有互相联系的。区分两个阶段的标志是候选药物的确定,即在确定候选药物之前为研究阶段,确定之后的工作为开发阶段。
        药品研发受到政府监管。临床前研究需要向政府监管当局提出研发新药申请。在研究阶段要进行实验室试验、动物试验、例病患者试验。研究结束后进行产品开发。
新药的研发也要进行风险管理,符合政府监管当局发布的GMP的要求。
6)    机械设备
        机械设备大多数都属于小批量多品种、客户定制类产品。许多机械设备企业动辄达到几十万种物料,这是标准化不足导致的。另外机械设备企业经常有许多的供应商,采购量不大,如何管控好供应商和外协加工物料也是一个艰巨的挑战。
7)    集成电路
        由于制造加工集成电路设备要求高,费用极其昂贵,并且产量巨大,所以集成电路的设计对一次设计成功投产的期望很高,关注设计可靠性、工艺可靠性。
8)    通信
        这一行业的特点是技术变革日新月异,大批量生产,并且市场开放程度较高、竞争异常激烈。加上复杂的设计以及可靠性设计、人机工程、国际化设计、跨国开发使通信设备公司成为最适合彻底实施ePACE方案的行业之一。该行业普遍遵循行业质量体系标准TL9000,具有较完整的系统化指标要求。
9)    家电
        家电走进千家万户,大批量和小批量多品种兼有、可靠性、成本控制的要求都很高,产品技术相对成熟。许多家电的季节性强,产品生命周期较短,这将对研发流程体系以及阶段性审核产生影响。季节性产品的开发进度表应早期进行安排,才能在下一季节到来之前完成新产品上市。这就要求将产品战略和开发流程要密切结合,才可能迅速地用消费者的消费倾向来引导影响下一季产品的设计。家电行业核心技术突破(例如高性能高可靠性的变频器、压缩机等)也是一个难题也是一个新的利润增长点。
10)    材料及元器件
        新材料对客户的价值非常重要。材料及元器件的新产品开发一般需要有大量的基础研究,必须将预先研究流程和研发流程体系很好地结合起来。
11)    化工行业
        化工行业中不仅仅要考虑产品的配方,而且产品的开发与工艺的开发往往是同时进行的。产品的开发需要考虑关键的设备、生产场地的部署、环境的保护等。需要满足HSE(健康、安全和环境)管理体系要求。
12)    软件
        软件产品开发的效果在很大程度上有赖于对客户需求的理解,即需求分析的彻底性。另外在已定义的研发流程体系基础上,灵活地应增量开发、螺旋模型,在产品开发中进行持续集成,项目核心小组的高效运作,自动化开发工具、自动化测试工具的应用都会给软件产品开发效能带来很大的好处。
公司在价值链中的位置不同,决定了企业不同的外部环境。
1)    OEM方式的企业
        在OEM情况下,由上游企业给出了设计图纸和相关技术资料,OEM的企业完成工艺设计和验证,为上游企业实现按订单生产。
        OEM方式的企业规模一般比较大,一般和若干上游企业形成了稳定的战略合作关系。OEM方式的企业与上游企业应按照“与供方互利的原则”从战略角度处理好与上游企业之间的关系,着眼于长期合作能力的提升,包括与上游企业的需求和交付接口的管理、协同可制造性设计、建立协同纠正预防措施体系、建立协同更改控制机制、发货控制机制。
2)    ODM方式的企业
        采用ODM方式的企业,必须具有较强的设计开发能力,常常也同时是自研产品的企业。自研产品的需求分析和产品验证与确认是以自己为主,ODM方式与自研产品最大的不同首先在于需求的来源与验收上,其次还在于客户方对制造商的监管要求,因此实施ODM的企业对于技术状态管理就比较重视。如何与上游企业达成对需求的一致性的理解,这可能需要克服一些标准、法规、文化上的差异。一旦需求和验收要求确定下来,设计开发的过程与自产自销方式的企业是很相似的,但是需要满足客户的监管要求。我国铁路行业、航天航空军工行业由上级下达的研制任务,往往带有强烈的ODM方式特征。
3)    采用自研新产品方式的企业
        自研新产品中有一类是新颖程度较高的全新产品开发,另有一类是新颖程度不高的衍生产品开发。这些企业大部分具有从收集客户需求、进行产品开发、产品发布、产品销售完整的价值链,最适合全要素采用ePACE建立高效的研发流程体系。


1.4.    由低级阶段向高级阶段的渐次发展
        制造业发展极不平衡,各个公司在人力资源、文化、技术和市场发展上都有着巨大的差异,是呈现梯度发展状态的。中国大部分企业基础管理还非常薄弱,作坊式生产的企业还非常多。在现代化的工业园里、在现代化的厂房里还有很多大作坊式管理在进行着。在公司研发项目管理发展的过程中,只有某些管理要素按照一定的方式组合在一起才能有效地发生作用,于是就呈现了阶段性。
        无论是哪一个公司,产品开发过程的演变都必须经过几个阶段。理解这一演化过程有助于企业对自己所处的地位和产品开发过程改进的目标有一个客观的认识。
阶段模型是一种辅助理解的工具,同时也为实施研发流程体系变革提供了指引。每一阶段都有特定的目标、范围、一套改进措施以及收益。按照阶段递进的方式实施变革,可以降低风险,快速获得阶段性的收益。而每一个阶段的成功实施也为发展到下一个阶段奠定了基础。
        企业一个阶段一个阶段渐次完成演化过程是普遍规律。在某一特定的阶段转化期内。企业要在产品开发过程中导入相关阶段的主要要素,要使它成为企业正常运作的一部分,而将其他管理要素推迟导入,这是因为将下个阶段的某一管理要素过早地引入到上一阶段常常是没有意义的,甚至可能还增加了不必要的工作,起到了相反的作用。
强大的旧的传统观念使得从一个阶段到另一个阶段的转变非常困难,但是如果公司一旦先于竞争对手上升到了一个新的阶段往往就会取得长久的竞争优势,会给企业带来巨大的好处,但也不能忽略所面临的风险。在每次阶段转化之后,需要相当长的一段调整期(大约2年),使新的做法逐渐被接受成为例行的做法并成为企业文化的有机组成部分。
我们发现企业在从上一个阶段向下一个阶段转变过程中,常常是跃进式地优化了产品开发周期,使开发出来的产品质量更好、成本更低、周期更短。每个阶段中的做法一旦融合成为企业正常运作的一部分,就为发展到下一个阶段建立了基础。
         下面的阶段模型可以帮助公司认识和了解各个发展阶段的管理要素。我们将对每一阶段的典型要素和业绩标准进行论述,使企业可以评估自己的研发管理水平,以便对下一步应进行哪方面的改善有比较正确的估计,帮助企业理清研发管理改进的目标和顺序。
        产品开发过程的演变可分为五个阶段:经验管理、职能管理、项目管理、集成项目管理、开发链集成管理。随着过程的演进,研发管理能力、研发生产率同步得到了提升。这五个阶段应渐次提升,跨阶段提升将是十分危险的(具有高风险)。
阶段0:经验管理。
        公司成立伊始,产品开发项目的成功是重中之重,项目经理具有高度集中的权力,不经意之间形成了以项目成功为目标的团队运作,这实际上是重项目小组。尽管在公司创业期,流程规范都不健全,但是由于项目目标单纯而聚焦,团队规模不大,研发负责人富有经验和能力,因此有可能实现快捷的沟通、协调、决策。随着产品的成功上市,企业获得利润,为了巩固和提高市场地位以应对竞争,老产品必须得到维护,新产品必须持续开发,公司的规模扩大了,这时发现研发管理变得复杂起来,经验管理就会顾此失彼,不能适应公司发展的要求了。通常会随着质量管理体系的建立,自然而然地发展到职能管理阶段。
阶段1:职能管理
        阶段1引入了类似于ISO9001这样的质量管理体系。基于质量管理体系要求建立了设计和开发控制程序。在这个阶段,产品开发的责任被分配到各个职能部门。产品开发虽然有了一定之规,但是开发链是被职能部门所切割的,九龙治水各管一摊导致开发链是零碎的、不完整的。项目经理主要关注于技术实现,还没有能够实现真正的项目管理。开发过程很不稳定,结果难以预料。
阶段2:项目管理
        引入了类似于ePACE的结构化研发流程体系、项目核心小组法、阶段评审。项目经理不仅关注技术实现,而且被赋予了面向顾客成功的责任,进行为项目服务的跨部门协调,真正实行了完整的项目管理。这一阶段所带来的利益十分显著,开发过程的稳定性大幅度提供,结果可预料性大幅度提高。
阶段3:集成项目管理
        在结构化流程基础上,通过使用类似PLM的信息化系统,实现了工程管理领域的集成项目管理。工程管理领域项目信息获得的及时性、准确性、完整性得到了大幅度提高。项目核心小组被网络化小组形式所取代,有效地克服了时间和空间的局限性。所提供的信息不仅可以对单个项目进行决策,而且可以对项目群做出综合决策,从而增强了阶段评审的效果。
阶段4:开发链集成管理
        阶段4在阶段3的基础上,通过使用DCM进一步将实现了项目管理与产品战略管理、资源管理的集成。
表13-1标识了研发管理体系发展的五个阶段与项目管理、资源管理、战略管理、信息化建设四大领域之间的关系。
其中项目管理领域包括:产品开发的结构、项目计划管理、项目小组、质量管理、成本管理、风险管理、物料管理七个过程。战略管理包括组合与管理到管理、技术管理两个过程。资源管理、信息化建设各一个过程。共计十一个过程。
        上述十一个过程都可以拥有各自的五个阶段。这五个阶段与研发管理体系的五个阶段有着大体对应关系。
在这是十一个过程中,产品开发的结构是最具有统领性,除了信息化建设之外的其余九个过程都是产品开发的结构在这是九个过程的展开和表现,这九个过程的内容都应该在产品开发的结构中得到体现。而信息化则与产品开发的结构相互匹配。
        这十一个过程也应该渐次提升,跨越性提升将带来高的风险。

总体  研发管理体系 阶段0经验管理  阶段1职能管理  阶段2项目管理 阶段3集成项目管理 阶段4开发链集成管理

 产品开发的结构 无流程 职能管理流程  项目管理流程 集成项目管理流程 开发链集成管理流程
项目计划管理 临时计划管理 职能计划管理  项目计划管理 量化项目计划管理 分布式项目计划管理
项目小组 经验项目小组 职能项目小组  项目核心小组 网络化小组 分布式网络化小组
质量管理 经验质量管理 职能质量管理 项目质量管理 量化质量管理   全面质量管理
成本管理 经验成本管理 职能成本管理  项目成本管理   量化项目成本管理 全面预算管理
风险管理 经验风险管理   职能风险管理   集成风险管理管理  增强的集成风险管理 全面风险管理
 物料管理 经验物料管理 职能物料管理 物料优选管理 增强的物料优选管理  全面物料优选管理
资源管理 资源管理 经验资源管理  短期资源利用管理  中期资源计划与资源交易管理   项目资源需求计划与管理管理  资源全面集成管理
战略管理 组合管理与管道管理 经验组合与管道管理 定期组合与管道管理  动态组合与管道管理  全面集成财务管理  集成产品战略
技术管理  技术管理 无管理 非正式的技术管理 正式的技术管理 货架技术管理 集成技术管理
信息化建设 信息化建设  无管理 CMS   PDM PLM DCM

1.5.    研发管理变革的战略管理

        为了成功地领导研发管理变革,需要采用一种系统和透明的方式进行管理。最高管理者可运用如下八大研发管理变革的战略管理原则,领导组织进行业绩改进:
1)以顾客为关注焦点
        理解顾客当前和未来的需求,满足顾客要求并争取超越顾客期望。研发管理体系必须满足顾客的需求才具有意义。这里顾客包括外部顾客和内部顾客,在整个研发管理体系建设或维护过程中,必须时刻铭记客户的需求,满足客户的需求,有时还需要平衡客户需求。应当理解顾客当前和未来的需求,满足顾客要求并争取超越顾客期望。
2)领导作用
        领导可以不懂研发管理,不作具体的指导,但是领导不可以不发挥领导作用。领导作用在整个研发管理体系建设中的作用是确定研发改进的方向,创造并保持使员工能充分参与实现目标的内部环境,形成积极健康的变革文化,这是极为重要的基础。
        公司的总经理及其他高层的管理人员对研发流程体系的改善负有不可推卸的责任。这是一个总经理对公司的长期成功所能做的最重要的贡献。他们负责启动变革,制定新的目标,并通过实施项目来完成变革,推动变革的进行,为这样的变革保驾护航。在新的研发流程体系逐步实施但仍未完全实施之际,它所带来的好处还不明显,而相关人员所受到的压力已相当大,部分人员对变革的意义产生了怀疑,在这种关键时候,总经理必须站出来对变革表示支持,表明他坚信公司是沿着正确的方向前进的。
        所有职能部门的经理,高级顾问、技术专家和技术经理等在变革的过程中扮演着十分重要的角色。他们最熟悉业务,对确定现状的薄弱环节,新研发流程体系的细节和推动执行都负有重大责任。因为研发流程体系的改变是跨部门性的,需要得到其他部门的合作,这就要求各职能部门的经理们为了整个公司的利益要进行协作,必要时做出妥协。
变革涉及广泛领域,应有一个变革管理委员会统筹公司变革规划,进行变革专题和变革项目架构规划,统筹变革管理项目和推行变革成果。大多数公司还不具有统筹公司变革规划的能力,因此需要与咨询顾问合作。
3)全员参与
        研发管理的变革只有走群众路线,积极动员、依靠所有相关人员才能实施成功的改进,绝不能由管理机构关起门来实施。领导作用和全员参与相结合,就能创造出了一个既有民主又有统一意志,心情舒畅,生动活泼的局面。各级人员都是组织之本,只有他们的充分参与,才能使他们的才干为组织带来收益。真理在少数人手中是初级阶段,最终要为广大群众掌握,并得到认可。
4)过程方法
        任何使用资源将输入化为输出的活动或一组活动可视为一个过程。过程方法包括如下内容:
        识别过程,并将输入转化为输出的活动结构化为三段式样,即输入、活动、输出;
        识别相互关联和相互作用的过程,包括串行、并行;
        将这些过程进行分解或组合,形成各类新研发流程体系;
        过程方法和以顾客为关注焦点相结合,将使新研发流程体系与价值链合一。价值链看不见摸不着,新研发流程体系就是价值链的形式化表现。如果新研发流程体系不能反映价值链,即与价值链有偏差,就需要改进。将活动和相关的资源作为过程进行管理,可以更高效地得到期望的结果。
5)管理的系统方法
        将新研发流程体系作为价值链系统来理解和管理。从结构上看,可以自顶向下划分流程层级,从管理模式上看,需要识别预先研究、新产品开发、特殊订单产品开发、工程更改等模式;从产品开发生命周期管理角度看,需要考虑快速原型、瀑布模型、螺旋模型、并行开发等各类生命周期的应用,以及对产品开发过程的调整方法。将相互关联的过程作为系统加以识别、理解和管理,有助于组织实现目标的有效性和效率。
战略管理的指导者当其处在一个发展阶段时,应该考虑到往后多个阶段,至少也应考虑到下一个阶段。尽管往后变化难测,愈远看愈渺茫,然而贯通下一个发展阶段乃至全部发展阶段的、大体上想通了的、一个长时期的方针,不仅可能,也是绝不可少的。不这样做,就会弄出迟疑坐困的错误,陷自己于被动地位。没有这种分析估算,束缚于眼前的利害,就是失败之道。但是不要试图为实现ePACE各个阶段而计划一个完整的、详细的路标。全面规划、分步实施是一个好的策略。每走一步都应该看那一步的具体变化,据此以修改或发展自己的计划,不这样做,就会弄出冒险直冲的错误。
        跨行业学习是必要的,但是我们不能什么都零碎地学、孤立地用,这样只能是学成了白痴。因为这个向左,那个向右,综合起来的效果就抵消为零。
没有外来的咨询顾问的帮助,少数天才的企业也许能够通过摸着石头过河,成功地实施管理变革,大多数企业都没有能力采用系统的方法进行改进。但是,如果有一个优秀的咨询顾问,成功的概率、深度、广度就都会增大,变革过程也会更顺利、更快速。拥有丰富经验的优秀的咨询顾问可以结合业界已经证明过适用的系统的方法移植过来,帮助企业避免重犯其他企业曾经犯过的错误,对于问题改进的主次,会做出更加科学地判断,从而以节省很多时间,少走很多弯路。此外,外来咨询顾问能相对客观地对待企业内部问题和组织问题。
为保证系统方法的贯彻,建议公司的高层管理者在三五年内只向一个顾问学习,只学一种系统的方法模型,老老实实按照顾问的要求做。不理解的允许思考,但不允许擅自做方案,出报告。也就是允许做一个善于思考和学习、完善细节的工匠,而不允许做一个改变系统方法的大师。在这里要反对经验主义、狭隘的民族主义、骄傲自满对系统方法的干扰,保证系统方法的贯彻,才能发挥系统方法的效用,最终才能发展成为难以战胜的公司。
6)持续改进
        持续改进总体业绩应当是一个永恒目标。研发流程体系是从低级到高级不断上升的。这种发展分为两种不同的模式:业务流程重组(BPR)与业务流程改进(BPI)。这两种模式正好吻合了发展与稳定及其相互关系的要求。一个公司通常都会经历过这两种模式。BPR的次数应该是很少的,而BPI则是伴随着企业生命周期持续进行的。BPI为BPR创造了条件,BPR是BPI的自然结果,没有BPR就没有破局,不能发展到新的阶段。BPI是BPR的前提,没有BPI的推进,BPR就缺乏思想动力和基础。
 “削足适履,先僵化,后优化,再固化”,一般说来是形而上学,但是C公司响亮地提出了这个一般貌似不正确的口号,并取得了成功。这个口号在特定环境中的正确性,是建立在C公司对本公司的现状与顾问公司提供的解决方案有充分信心的基础上的,表明了为了C高层管理者为实现管理变革排除变革阻力的决心。也体现了C公司高层管理者的远见与担当。这对参与BPR的相关方是巨大的支持,充分体现了领导作用。
        但是在BPR完成,新的管理框架建成之后,在通常情况下,如果经常变革内外秩序就很难得以安定地保障和延续,改动的成本可能会抵消改进的效益,这是十分现实的问题,切忌草率行动。一个有效的程序应长期稳定运行,不要用随意创新去破坏它,而是在使用中不断严肃认真地完善它,这种无生命的管理,只会随时间的推移越来越有水平。一代一代人死去,而无生命的管理在一代一代优化中越来越成熟。因此高层管理者要强调任何事情不要等到问题成堆,才去做英雄去“力挽巨澜”,而是要不断地疏导。要求干部即使被人误解为没有能力抓管理,也不能为了个人名声而去“大刀阔斧”的改革,宁可保守一些,也不可太激进。
        在持续改进中,既有规范性的坚守,又要有创新的精神。在德治多于法制的文化传统熏陶下的中国人不愿受到规范的约束,而倾向于盲目创新。中国人老是想这个会了,再换个花样搞搞,好奇心是中国人的不灭的灵魂。通常在推行规范化管理后,中国人的创新精神仍是压也压不住的火花,不过创新不像以前那么幼稚了,而是有序的、有价值的创新。在常态下,95%情况下都应该是保持稳定规范,不要盲目去创新。变革比重不超过5%,对这5%的不规范的部分,允许探索与变革,其目的就是要促进发展。
7)基于事实的决策方法
        有效的决策是建立在数据和信息分析的基础上。对于研发而言,这些数据可称之为产品数据,必须对产品数据实施管理。这些数据可以包括:图文档、零件、BOM、流程数据、项目管理数据等。没有良好的数据管理,就很难做出正确的决策。
基于事实的决策方法需要与过程方法、管理的系统方法相互结合,也就是业务流程必须与信息化建设明确结合。
8)与供方互利的关系
        企业与供方是相互依存的,互利的关系可以增强双方创造价值的能力。研发需要的大量零部件、软件可能都有依赖于供方。传统的企业与供方的关系是剥夺与被剥夺、压榨与反压榨之间对抗性的关系。与供方的互利关系不仅仅是公司管理伦理上的巨大进步,而且也符合企业追求长期利润最大化的客观规律。通过互利关系的建立,达成了克服危机、解决问题的共同愿景,实现了共享成果的机制,对企业和供方的发展都带来了新的机会和动力。
1.6.    研发管理变革的项目管理
        研发管理变革的实质就是要解决端到端业务集成的问题。具体就需要回答三个层次问题:价值链上端到端的流程集成;产品数据围绕产品生命周期在价值链上的集成问题;前面两个集成解决了项目管理问题,更进一步就是要解决项目管理与资源管理、战略管理集成的问题。
1)    研发管理变革的业务统筹
        研发管理变革要实现三个方面的统筹协调,这三个方面就是流程、组织、信息化。
流程建设
        流程必须体现公司的价值链,只有以顾客为关注焦点,对客户实现端到端拉通的跨部门的流程才是BPR、BPI的重点;
        业务流程架构应采用分层结构化的架构,逐级深入;
        流程必须是最简化的,应尽量减少重复和冗余;
        流程一定要采用过程的管理方法,清晰地描述输入、活动、输出,便于实现质量管理;
        所有质量管理要求、标准与法规要求、保密、信息安全、内控要求都应作为流程的要素整合到流程里面去,因此执行了流程也就执行了上述要求。
组织配套
        使得公司上下能够接受新的流程体系,就需要组织能够匹配流程,能够明确谁对流程的业务绩效负责,谁对流程的执行和监控负责,谁对流程的改进优化负责。为了贯彻相关责任,一般还需要成立一些跨部门的委员会。
        流程的执行者应定义为角色。角色是通过具体的人来扮演的。一般情况下一个人可以扮演一个或若干个角色,特殊情况下,例如当人员素质达不到时,也可能两个人共同扮演一个角色。
角色的定义除了来自流程中的活动内容之外,内控所要求的职责分离也是非常重要的问题。例如管钱、管账、批准应该不是同一个人,提出采购需求的人员、执行采购的人员以及选择合格供应商人员也应该考虑分离,被评审的工作产品的作者与评审管理者QA之间的职责也应该分离、设计者和设计确认者应该分离......。
        角色的定义解除了流程运行与部门的紧密耦合关系,使得部门的组建具有了更大的灵活性,而流程体系变得更加稳定,流程体系的优化关注于业务和不是部门设置。但是角色的引入,增加了对角色定位到人的转化环节。
        应根据角色、内控的要求,就可以分析每个岗位所在的技能难度、可替代性、工作强度、风险程度等因素,就可以比较各个岗位之间的价值大小、任职资格的要求,进一步确定薪酬结构。
        根据岗位的专业的内在联系设计组织机构(如部门等)。部门的组建的原则是部门内相关岗位紧耦合,部门之间相关岗位松耦合。例如D公司流程优化部不仅仅包含流程优化管理,还包含了信息化规划控制、应用开发实施、基础设施和网络安全、系统运维功能。
        以流程为导向打通部门山头。以对立统一的观点看待整体和局部,并为此建立起以公司价值链为导向的组织结构和绩效管理体系,就是以流程为导向进行组织结构配置。
        组织配套建设应明确如下事项:
        应建立公司变革委员会进行重大问题决策;
        应确定流程体系总责任人;
        各个部门都应该清楚本部门跟公司中的哪些流程、哪些角色有关系,从而落实职责;
        确定每个流程的责任人。流程的责任人原则上应由业务规模最大的那个部门的负责人担任。他的责任是承担用好、维护好相关流程的责任;
        正在变革的流程都有相应的研发管理变革和IT团队;
        有明确流程审核人员,审核这些流程执行情况,并对流程设计是否合理,是否需要优化提出建议。

2)    信息化配套建设
        信息化的投资是一种长期战略性的投资,信息化建设要有好的架构规划与管控,避免功能重复、无人管、推倒重来的问题。
        一方面信息化建设要与公司发展战略和研发管理变革紧密结合,另一方面流程管理的规范化、高效运作又越来越依靠信息系统来实现。流程再造与信息化的实施应该是紧密结合前后衔接的,不能单打独斗。通常采用信息化系统执行的流程与通过纸面方式执行的流程在细节上还会有所不同,有些事项用流程来管控是合理的,而有些事想则用IT来管控更加有效,如果IT直接管控了,流程就可以简化了;反之流程管控了,IT就可以简化了。这就必须进行细节的协调和调整,保证总体最优化。
        【案例】C公司的IT架构规划与管控
        C公司的IT架构除了几个大系统ERP、PLM有独立的平台外,其他的应用系统都在一个平台上,这个平台实质上就是DCM平台。在IT建设方面,强调可用性、可靠性、可维护性、安全性、标准化、配套化、有线无线融合、分布式的数据处理。使“用户更高效、终端更安全、运维更简单”
        C公司业务与IT紧密结合,到了一种言必谈IT的状态。C公司每年都进行未来3-5年在管理变革与信息化建设上的规划,然后确定明年的业务流程改进计划、IT建设计划、IT业务的服务计划。
        IT架构需求来源于法规和标准、公司新的业务模式、和变革机会点、业界最佳实践、技术发展趋势、问题点的需求。C公司制定了业务战略以后,基于业务战略应该具备哪些业务能力,在此基础上进行流程化,同步考虑IT系统支撑,分析IT系统是如何实现的、各个应用系统之间是什么样的关系。企业架构管控就是回答这些问题。
        针对业务部门碎片化的IT需求,C发明了版本火车的方式,一年开四趟列车,都有相应的版本。需求方提交的需求可能搭载当前一班列车,也可能搭载以后的某版列车。这样就将无序、碎片化的需求进行了整合有序的管理,同时响应速度也快。对于提出的需求,采用如下顺序考虑解决方案:
        首先,要考虑已经建好的系统产生业务价值的问题,尽可能系统功能复用。
        其次,对于IT需求,如果业界有相应的软件包,匹配度达到七八成,一般就可以直接上这个软件;
        如果需要二次开发应用软件,则要尽可能采用第三方的开源软件。对应用软件开发要实行项目管理,并做好应用软件的测试。要考虑二次开发面向未来的升版和兼容性。
        IT系统必须支撑业务运作才有价值。所以IT人员不能够只是维修,而是要做服务。服务水平、数据保障、灾难应对等重要事项都应有相应的组织和流程去支撑。
        为保护过去的像ERP、PLM等投资,又要提高IT用户的体验,C提出“前轻后重”改造传统应用的方法。前端:以人为中心,便捷、易用、协同、高效;后端:以流程和服务为中心,基于“五朵云”持续系统整合。“五朵云”是指售前云、供应链云、交付云、采购云、财务云。
3)    对研发管理变革的项目管理。
        研发管理变革关心的是要把重要的事情做好,所以对质量要求高,而进度相对不是那么重要。对于研发管理变革,也应实行项目管理,例如C对于业务流程变革项目按照概念、计划、开发、验证、推行、生命周期管理各个阶段进行项目管理。
        概念阶段:编制业务流程变革的策划书。提交变革管理委员会批准;这里需要注意的一个关键是循序渐进。任何企业在某一段时间里能承受和吸收的变化是有限的。改进新产品开发过程有效的方法就是充分认识到公司目前所处的位置或阶段,并针对要提高到下一阶段而必须改善的每一个因素狠下功夫。
        在此阶段,公司应进行一些培训活动,以提高各职能部门和各层领导对改进产品开发过程必要性的认识,并对改进的愿景、路线图、方法论达成一致的看法。
计划阶段:对变革进行详细计划。制定实施目标和步骤。
开发阶段:完成交付件的开发;在此阶段为了加速变化过程,传统的整个企业同时受训的大块培训方式(类似质量管理体系培训)并不完全适用。而小型的、及时的、针对性、多批次的细节培训才会更加有效。
        验证阶段:完成试点运行;
        推行阶段:完成全面推广运行;
        生命周期维护阶段:进行运行维护,巩固和提高变革获得的成果。
        而对IT项目则按照软件开发流程进行管理,例如遵从CMMI体系。
4) 贵在落实——新研发管理体系的导入
        我们帮助许多公司成功地实施了研发流程重组,并使这种变化植根于企业文化之中。同时,我们还发现许多希望对其研发流程进行根本性改进的公司,改进效果并不好或是不能持续保持。究其原因是改进成果从未真正内化为公司运作的一部分,并使这种变化植根于企业文化之中。
任何一个变革,不在于它的开工,不在于它的研讨与推行,而在于能否落地,能否真正起到切实的作用。许多公司以为只需要制定一个新的研发流程体系就完事了,事实上让人们去理解并在行动中实践这些流程可能比编写文件还要困难。
        常会听到这句话“我们公司,流程都有,就是得不到执行”。说这些话的人往往是写制度、管流程、发规范文件的职能部门。这话的潜台词是在说流程没有执行的原因那些不执行流程的人意识有问题、态度有问题,责任全在他们身上。
        我理解说这些话的职能部门开展工作的困惑,但不认为简单地把责任推在执行者身上能够解决问题。究竟原因何在,需要具体分析。可以从深层次到浅层次依次分析原因,当存在的问题弥漫到深层次和浅层次时,通常只有优先解决了深层次的问题才能为解决浅层次的问题创造条件。
        第一个层次是流程本身的问题。
        著名质量管理大师戴明说过“一个事情没有做好,85%是体系设计时就出了问题,15%是操作者个人的问题”。因此每当我听到“流程都有了,就是不执行”,总是怀疑是否回避了体系设计存在的问题(因为这是自身的问题了),而开始进行一种有心或者无心的扯皮。实际上,停止扯皮。
这个流程文件为什么得不到执行,是不是这研发流程体系的本身冗长烦琐甚至是破碎的,不能体现企业价值链?当执行者总是不遵守这个研发流程体系、走某种灰色通道的时候,实际上是一种对这个低效的研发流程体系的无声抵制,值得流程设计者的注意。如果这些灰色通道效率高、风险可接受,有时是可以将这个灰色通道变成正式通道的。但是由于这种自发的抵制所产生的行为不具备深思熟虑的系统性,简单地扶正将破坏研发流程体系总体的系统性和简洁性,反而使研发流程体系越来越累赘和繁琐。如果是这种情况,研发流程体系的优化乃至再造就是首要需要解决的问题。
        第二个层次是研发流程体系执行的组织保证问题。
        在第一个层次的问题已经解决的基础上,就面临着第二个层次的问题。
        过去习惯于九龙治水各管一摊,现在要求打穿部门墙,这就需要增加一些跨部门沟通的角色和组织,这些在传统的职能式管理中是没有的。这些角色和组织的建立对于价值链整合具有很大意义。例如设计转换、工程更改、物料认证等这些流程的有效运作,都涉及到了一些非传统职位和组织的匹配。因此扩展或改进现有组织结构,建立新的委员会、部门、职位以匹配研发流程体系执行的需要也是十分关键的。总的研发流程体系应明确责任人,每个具体流程也应该明确流程责任人。这些责任人担负起流程的解释、运行维护的责任。赋予日常过程管理者QA相应的职责尤为重要。
        第三个层次是人员意识与能力培养的问题。
        研发管理变革涉及非常广泛而深入,对研发管理变革持有不同的看法这是正常现象。我们应该了解存在着如下几种类型的人员:
        变革的极力反对者,不仅对变革持反对态度,而且付诸行动阻挠变革,以免变革伤害到个人利益(如对知识的独享和控制权)。这需要通过感知与信仰管理,进行利益关系的调整,尽可能地改变他们对待变革的态度。
        变革的暗藏反对者,尽管表面上看似支持变革,事实上他们是对变革基本上持反对态度的机会主义者。对待他们,除了感知与信仰管理之外,还需要通过示范作用改变他们的态度,坚定他们的信心。
        变革的积极促进者,不仅对变革持普遍的欢迎态度,而且从个人出发积极推动变革,以期通过变革在实现公司的价值的同时实现个人的价值,对这些人员的积极性要给予保护和鼓励。
对于新的研发流程体系建立与推行,意识与培训的需求是广泛的、大量的。对于中高层管理者、项目经理、质量管理人员、骨干员工意识与培训最好从建立研发流程体系开始,让相关干系人充分参与研发流程体系建设过程,这样的意识与培训的效果可以达到所需要的深度。对于更加广泛的普通员工,也必须进行适当的培训,使他们在执行层掌握执行新的研发流程体系所必需的知识。
 “攻城部队”的培养。
        “攻城部队”是积极推动研发流程体系执行的QA、高中层管理者、项目经理、部门经理、骨干员工。他们愿意变革,在业务链条的地位举足轻重。他们是建立、运行、维护新流程的骨干力量。QA作为过程的总负责,有责任通过引导、培训发现和壮大“攻城部队”,让他们承担首次使用新流程体系的任务。每当完成一个新任务(执行了新的流程、表单模板),就如同攻下了一个城池,就在公司内形成了一个本土的样例,于是可以复制、推广。
“守城部队”的培养。
         “守城部队”有些是新员工,有些是老员工,还有个别是处于观望彷徨状态的高中层管理者。他们对新的研发流程体系既不反对,也没有表现出积极的热情。这些人可加入“守城部队”。对于“守城部队”的职责要求就是巩固已经攻下城池的稳定。“守城部队”应包括内审员、项目管理人员、文控人员。他们的职责就是通过规范性审核、纠偏的方式保证新的流程持续执行下去,如有必要还需要优化。公司高层管理者要下定决心不准再次复辟(即退回到过去),他们是反复辟巩固已有变革成果的骨干力量,最后使新流程变成公司的新常态。
“攻守兼备部队”的培养。
        “攻守兼备部队”的特点是既能推动变革,又能维护稳定。他们就是研发QA。在前期他们会进行培训、引导推动变革,在后期,他们通过审核、纠偏、优化巩固已有的变革成果。
许多公司在研发管理变革时都苦于找不到能够带领破局的研发管理人员,研发管理打不开局面。这是由于以下原因造成的。
许多公司在研发管理变革时都苦于找不到能够带领破局的研发管理人员,研发管理打不开局面。这是由于以下原因造成的。
研发团队在创业初期人员规模不大,沟通管理比较容易,矛盾相对不突出,而是否熟练掌握了相关技术,成为快速推出新产品的主要因素。在初期创业环境中总是以技术为上,管理人员的提拔也以技术能力为主要依据,没有产生适合于管理人员成长的土壤。随着研发团队规模扩大,在线产品改进、新产品开发、预先研究项目数量的增加,管理问题就越来越突出,原有管理人员的素质就不能适应了。
        为弥补原有管理然人员素质不足的缺陷,一个办法就是空降专职的管理人员,但是这也是有风险的。
        【案例】:D公司空降MBA的结局
        D公司为解决管理人员素质不足的问题,引入了MBA和若干配合工作的专职研发管理人员,希望MBA能够带来新鲜的元素,带领专职研发管理人员提升研发管理的水平。但是MBA在半年内就提出了离职。办理离职手续时,人力资源专员与MBA进行了面谈:
        人力资源专员:“您离职的原因是什么?”,
        MBA:“觉得缺少职业发展前景”。
        人力资源专员:“相比与其他专职研发管理人员,您觉得作为MBA在工作效果上有什么不同?”,
        MBA:”“对项目管理的理解上可能全面些、深入些,理性些,但实际上所做的工作和效果也没有什么大的差别,这也是我想离职的原因之一”。
        这个案例是一个不成功的引入MBA的案例。这个案例给我们两点启示:
        公司对专职研发管理人员的发展通道还没有给予应有的重视和相应的设计,使专职研发管理人员有一种不被重视的感觉,对职业发展前景感到茫然;因此应及早筑巢引风,做好专职研发管理人员的发展通过设计。
        MBA的实际工作对研发改进的主动性、推动性不强(即攻城能力不强),使工作效果与一般专职研发管理人员没有什么差别,MBA感觉到了过高期待的压力,这也与这个MBA的个人能力不足有关,应该对其能发挥的作用给予合理的期待。
        另外一种方法是从现有人员中去选拔培。但这也不能保证都能成功。
        [案例]:提拔的研发QA经理想调换工作—一个职业转型失败的例子。
        D公司提拔了一个资深的工程师作为研发QA经理,干了不到3个月,就提出了调岗的要求,希望调换到做在线产品更改的岗位。公司领导与他进行了谈话。
       公司领导:“您为什么想调岗?”
       研发QA经理:“感到压力很大?”
       公司领导:“调换到在线产品更改的岗位压力就不大了吗?”
        研发QA经理:“压力也很大,不过事情很具体,我觉得心里不虚。现在的工作压力大,但怎样中做好工作心里没有底,觉得不能胜任,为了不影响公司的发展,所以我提出调换工作。”
研发管理是技术管理,是一种非传统性的岗位,学校里并没有这个专业,不像专业技术岗位,可以从学校对口招聘。这个岗位需要的是复合型人才,不仅懂得管理也要懂得技术,既具有相关的知识,还要具有将相关知识运用于实践的能力。这样的人才光靠学校培养是不够的,还需要在实践中锻炼成长。南车时代规定研发管理人员必须从有工作经验的人员中选拔,这是符合研发管理岗位的素质要求的特点的。
        【案例】一个QA的成长素描—从技术走向管理。
        D公司正处于高速发展期,每年研发系统都要完成几十项新产品开发任务,年年销售额增长50%左右,财务状况非常好,D公司领导已经开始布局公司上市。由于D公司的生产的医疗器械涉及到人身安全,一旦发生安全事故,将导致无可挽回的损失。虽然还没有出现导致人的死亡和伤亡的重大事故,但是面对规模的迅速扩大的风险,公司领导层对产品质量是非常不满意的。当时产品质量表现不良体现在顾客投诉多,故障率高,返工量大。
        公司为此设立一个研发QA专门职位来抓产品质量,先进行内部招聘,在当时重技术轻管理的大环境中没有人愿意干,然后就是组织动员和任命。
前面几任都是资深工程师,虽然也都努力,但是努力的着眼点总是倾向于依靠自身的技术能力来把住质量关,但是成效没有得到认可,时间不长就离任或离职了。
王武有十多年的产品开发经验,平时也喜欢阅读软件工程、ISO9001等管理方面的书籍,逐步认识到产品开发中的很多质量问题直接体现在技术上的失误,但是只从技术上解决是治标不治本,技术能够快速有效地解决具体问题,但不能降低整个质量问题出现的概率。也就是其现象表现为技术失误,但其原因却是管理的疏漏。
        王武接收任命后就收到各种各样的在线产品的质量投诉,他就面临着两种选择,第一种选择是类似前任的做法,努力以自身的技术特长通过技术审核来把质量关,把精力重点投入到解决具体的质量问题,短平快地解决具体问题;另一种是将具体质量问题的解决还是依靠原来规定的职责进行,而将精力转移到思考如何增强研发中心产品质量保证措施的研发管理变革上来,但这可能短期不见成效,也有可能在过程改进方面失败。王武经过冷静的思考,最终选择超越单纯的技术视角,而选择了后者。王武后来引导进行研发过程管理改进,取得了很大成功,在管理岗位占住了脚跟,完成了从技术走向管理的转变。公司领导也从过程改进的成功效果中建立了信心,给予王武大力支持,创造了一个良好的过程改进氛围和必要的资源支持,形成了良性互动的局面,D公司研发管理开始走上了自主改进为主的破局之道。
        对于一个优秀的QA,其特征是“博学而笃志,切问而近思,仁在其中矣”。
        第四个层次是执行与监控的问题。
        新研发流程文件总不可能十全十美。一种情况是要求过细,另一种情况是要求过粗。前者需要先满足基本要求,再满足提高的要求;后者则需要具体解释流程执行落地的问题。如果流程没能得到及时的优化调整和解释,就会影响执行的力度,甚至受到抵触。
         一旦新的研发流程体系要执行,马上面临许多在后来看来是“低级的”细节问题,需要得到及时的解释和合理的处置。例如:
         新增物料认证,就可能提出来工装夹具上非产品用的物料是否需要走物料认证流程?
         预先研究用的物料是否需要走新增物料认证流程认证?    
         定制件是否需要走新增物料认证流程?
         新产品开发流程执行到一半客户需求发生了变更怎么处理?
         评审之后文档迟迟不能整改完毕怎么办?
         工程更改需要分析填写的表格信息太多了能不能简化?
        工程更改需要跨部门联合评估,各个部门接口人是谁?
        项目已经完成了一半,中途是否需要导入到新的研发流程体系?如何导入?
        文控不严格,文件编码、格式混乱,甚至还有许多乱码、错别字,谁去审核?
        项目小组不按照研发流程体系要求执行,例如不进行正式评审,如之奈何?
        ......等等。
        这些问题对于推动执行者来说,面临着真正的考验,这些问题如果不能得到及时答复,给予切实具体的指导,并且在必要时落实到表单模板中,也将延缓新的研发流程体系执行的效果,甚至导致失败。
        要解决上述问题,QA必须发挥引导、解释、监督执行与监控的作用。同时应考虑将过程遵从度作为对项目经理的考核要求纳入考核体系中。
        【案例】A公司新研发流程体系导入的部分策略
新流程体系的导入
        不少项目已经进行了一半,如何导入到新的研发管理体系中。一般来说依靠开发计划来进行导入。这种半截子导入的情况与新启动项目的不同之处在于需要补课。
        例如由于过去要求比较低,需求规格书常常不符合要求,需要重新编写;样机评审按照新流程体系要求缺少许多要素,导致评审通不过,但是客户订单就要履行,此时需要做出风险决策。某些控制要素首次执行不能一次到位,那么就必须渐次逼近要求,二次执行基本达到要求也是可以接受的。
导入阶段经常会问到流程遵守和紧急的事项发生冲突时怎么办,应该对积极使用新流程的员工实行鼓励,打消他们的顾虑,促进旧的工作模式向新的工作模式的转变。
实施设计控制
        设计控制的核心是设计评审。能否有效地抓好设计评审,决定了新研发流程体系能否导入的关键。在这里抓大放小是一个误区,必须抓大而不放小,可能这就是研发管理的特点,要求有锱铢必较的精神。
项目经理绩效考评权
        项目小组是来源于各个部门的。项目经理有权对来自各个部门的核心代表进行绩效考评。例如对采购代表进行绩效考评。这样就增强了项目经理对跨部门人员的管理能力。