技术研发中心的组织结构

技术研发中心的组织结构随着国际及国内技术竞争的加剧，企业或组织的兴亡成败越来越多地与技术的强弱有了紧密联系。在很多行业，无论是技工贸一体化的企业，还是纯技术型企业，都不可避免地涉及一个问题：以什么样的结构来组织技术研发中心，能够取得最好的效果。在技工贸一体化的企业中，营销中心及生产运营中心的组织结构，往往已经有了主流的公认答案。随便找一个职场人士，问他（她）生产运营中心的常见组织结构，多半会给出正确的回答：生产部、采购部、品质部、储运部（物流部）。但是，对于技术中心的组织结构，能够答得上来的职场人士却很少。在本文中，笔者试图对此作一些探讨。但是由于技术领域的广泛性，以及行业的广泛性，本文不可避免地具有局限性。希望能够起到抛砖引玉的作用。根据笔者的调查，目前可能的技术中心组织结构主要有四种：按照项目来分工；按照子系统来分工；按照技术领域来分工；按照职能来分工。1. 按照项目来分工，往往有三种情况：1.1.单一技术领域，例如软件行业（尽管还可以细分子领域）。在一些规模不是很大的软件公司里，由软件高工担任项目经理，往往能够取得不错的效果。当然，软件高工有两种，一种是架构师，另一种是高级算法师；架构师有全局观，担任项目经理比较容易管好；而高级算法师更适合作为公司的核心资源在各个项目之间调剂；除非是某些以算法为主的项目，由高级算法师主持更合适。单一技术领域的行业还有很多，采用按项目划分的方式往往能取得不错的效果。1.2.一个技术领域要求较高，其它还有一至数个辅助技术领域。例如，开发电源电子产品，在电子方面的技术较深，而产品结构框架及外壳比较简单，内部的单片机嵌入软件规模较小。这种情况下，由电子高工担任项目经理，领导机械结构工程师及嵌入软件工程师，是个可行的安排，项目成功率较高。1.3.两个或两个以上的技术领域要求较高。这时候往往会遇到一个问题，项目经理可能在一个领域水平较高，但是在别的领域较弱。例如，在某通讯公司，某软件高工担任项目经理，主持开发嵌入复杂软件的复杂芯片。他把软件架构做得很好，但是由于他在微电子方面比较弱，所以微电子架构存在很多问题，后来问题不断冒出来，进度屡屡延误。在此期间，他也曾向担任其他项目经理的几位微电子高工求助，但是由于项目经理之间是竞争关系，所以得到的答复总是“对不起，没有时间”。2. 按照子系统来分工中国人民解放军武器装备研制设计师系统及行政指挥系统工作条例规定：大型武器系统的研制由一位总设计师和一位总指挥联席主持工作。总设计师下设多位子系统主任设计师，每位主任设计师下设多位模块主管设计师，主管设计师下设多位设计员。同时，总指挥下设各级指挥员。这种组织结构主要有两个特点：一是对专业官与行政官的角色进行了清晰的区分；二是按照自顶向下的系统分层结构来部署组织结构。在系统高度复杂的情况下，这种安排很可能是唯一的选择。但是，这种安排有一个缺点，就是组织结构与产品结构严格挂钩。当需要进行架构创新时，可能取消某个子系统，扩大某个子系统，精简某个子系统。这就必然会导致组织结构之间此消彼长，但是哪个负责人愿意看到自己的地盘减小甚至消失？因此政治阻力在所难免，技术问题与政治问题就会相互纠缠。好在军方项目把子系统及模块分配给各个承接单位，这种此消彼长只是跨单位之间的利益关系，相对容易协调。但是，如果一个企业内部的技术研发中心拟采用这种组织结构，就要慎重了！3. 按照技术领域来分工优点在于：A. 各部门之间的利益界面比较简单，容易协调。虽然一定程度上也有踢皮球或抢地盘的问题，例如某些控制功能，既可以用机械方法来实现，也可以用电路来实现，还可以用软件算法来实现；但是，这都不会导致哪个技术领域被全部取消，只要技术总监出面协调，就能够得到较好的解决。B. 各领域技术人员的技术水平，决定了其自身的升、降、辞，从而激发了技术人员精益求精，不断钻研的动力，有利于打造企业的核心竞争力。C. 各个不同项目在同一个技术领域的任务会由同一个部门完成，容易积累经验及教训。既可以避免在不同的项目上犯相同的错误，又可以把一个项目上取得的创新移植到其它项目上。D. 便于实施专业审核与逐级杀头制。在前述按照项目分工的的情况下，项目经理可能是一个领域的高工，但下属中有其它领域的工程师；也可能会由纯管理人员（例如没有技术背景的MBA）担任项目经理。在这两种情况下，项目经理很可能在审核工程师编制的技术文件时，闭着眼睛签字；事后出了问题，就推托说，自己不是这个专业的，主要问题是公司给自己配备的工程师太差，而把好的工程师都配给其他项目经理了。在按照技术领域分工的情况下，机械高工（机械经理）如果没有审出机械工程师的模具图有问题，而导致模具报废损失惨重的话，理所当然要卷铺盖走人。缺点在于：A. 各个技术部门及各领域技术人员对项目的成败不够重视，只要老板对自己的水平满意就可以了。我们有的老兄甚至以各个项目合用人力资源为借口，推脱工作量，人为制造项目之间的矛盾冲突。B. 在这种组织结构下，增加一个项目不需要增加一个项目团队，不会导致直接可见的人力资源成本，所以有些好大喜功的老板往往会在无意中不断立项，项目越来越多。同时老板又不太愿意给各个部门增员，从而导致资源冲突，每个项目都进展缓慢。上述两个缺点听起来很像微观经济学的信息不对称博弈。4. 按照职能来分工这听起来似乎有点像生产运营中心了，那是最典型的按照职能来分工的。其实，技术研发中心的职能，也是可以好好地分工一下的：4.1.研发质量部产品的研发过程，是产品质量的源头。虽然在生产运营中心也有质量部，但是要让运营质量部兼顾研发质量，往往比较困难。原因在于：A. 传统的运营质量部熟悉的是ISO9000或类似的质量体系，这类质量体系在研发质量管理方面非常薄弱。B. 传统的运营质量部擅长统计分析，这类方法在研发质量管理方面用武之地较少。C. 传统的运营质量部擅长按照已经编好的标准来检验产品，却不善于编制标准。也就是说，擅长执法而不擅长立法。当然，从另一个角度来看，要求执法者去立法，也不是很合理。D. 有些大公司，研发中心与运营中心隔得比较远，甚至可能不在同一个国家。 设立专业的研发质量部，有下述优点：E. 传统上，标准的编制，根据其重要性，往往由各个层级的技术人员来完成。这往往会导致自己设计自己立法的情况，缺乏公信力。而由专业的研发质量部来立法，比较合理。F. 配置版本管理，对于技术研发工作具有较高的重要性。但是其工作量又不是很大，难度也不是很高。在规模不大的研发中心，没有必要成立专门的配置管理部。由于配置管理是研发质量管理的重要支柱，由研发质量部经理来统筹这项工作，下面设立一个配置主管的岗位，是较好的安排。G. 有利于更好地推行专业的研发质量管理体系，例如CMMI等。H. 研发质量部向技术总监或研发总监汇报，运营质量部向运营总监汇报，可以很好地避免多头领导的尴尬。4.2.项目管理部前面已经提到了，按照技术领域来分工的两个缺点都是由于信息不对称引起的。而专职的计划调度团队，可以使得工作量透明化，并协调各个项目之间的资源冲突，根据优先度排序。另外，项目在进展过程中，需要与公司内部及外部的很多相关方进行沟通，这种沟通的工作量较大，但是难度往往不大，资深的技术人员往往不屑于做这种沟通。而专职的项目管理部可以作为一个统一的对外窗口，例如受理营销中心发来的立项建议书并启动立项程序，组织项目例会并作会议记录等。项目管理专家也不必为技术决策操心并承担责任，可以专注于计划调度、沟通协调、成本控制等；根据重要度的不同，技术决策由各个不同层级的技术人员作出并白纸黑字留下记录。在按照项目分工的情况下，如果每个项目安排一个没有技术背景的纯管理人员担任项目经理，以便加快进度的话，一方面HR成本会太高；另一方面工程师会抱怨外行领导内行，影响工作积极性，高级工程师会拒绝参加项目，仅给多个项目充当顾问。而设立专业的项目管理部来加快进度，就解决了这一矛盾。同时，由于只需要一位资深的项目管理专家领导这个部门，其他的都是一些资历较浅的项目主管、项目协调员，所以项目管理的HR成本不会太高。4.3.知识产权部知识产权的重要性及设立知识产权部的必要性，近年来有很多媒体作了充分的宣传，本文不再重复论述。4.4.前沿研究与工程开发的分离有些高科技企业，其技术纵深度较大，既有开发工程师在从事工程产品的开发，同时又有研究科学家在从事前沿技术的研究。将科学家与工程师分开，或者说将研究部与开发部分开，将有下列好处：A. 在前沿技术研究成熟之后再启动产品开发，可以消除技术不确定性导致的项目投资风险及对进度计划的冲击。B. 可以让科学家们有一个更加安静的环境来思考，避免每天参加各种项目例会。C. 可以避免或至少延缓核心技术的扩散。等到研究部的相关科学家将核心技术移交给开发部时，专利申请文件早已提交了。D. 其它部门内部的类似于金字塔的组织结构，往往令科学家们反感。常规执行部门的经理领导主管、主管领导办事员，设计部门的主任设计师领导主管设计师、主管设计师领导设计员，已经是天经地义的了。而大科学家却不一定愿意去领导小科学家、小科学家也不一定愿意被大科学家领导。所以，研究部与开发部分离以后，便于安排非金字塔的组织