尊龙凯时 - 人生就是搏!

張冰：如何搭建研發管理體系？——研發的責、權、利管理

　　前言

　　本文主要是針對那些准備建設研發組織的領導、或者新研發組織裏的各層管理者、或者沒有真正在競爭性的成熟研發組織裏曆練過但又很需要相關知識的人員。

　　對于競爭性行業裏穩定運行的研發組織的管理者，本文的內容可能屬于非常基本的常識，基本到甚至感覺不到這些邏輯的存在，但又每天工作在其中。

　　國內市場上，體制內的研發組織，很多運行起來問題多多，很大一部分原因是這些最基本的管理邏輯的缺失，處在其中的人要麽是認識不到，要麽是周圍有太多不明白的人而無力回天。

　　摘要

　　1. 研发组织是企业的组成部分，必须以企业的效益提升为目的。

　　2. 研发活动是手段，不是目的。所有的研发活动必须以解决企业的技术需求为目的。

　　3. 企业的中短期技术需求必须由产业部门负责制定，长期发展需求由总部战略责任部门制定，别的部门或研发组织可以辅助或提议，但产业部门不能免责。

　　4. 责权利统一，谁的需求谁负责出资开展研发活动，出资必须是全口径覆盖。直接经费和间接经费的分口管理模式�：�巨大。

　　5. 企业必须有成体系的科研成果管理机制，最大化整体利益。

　　以上各條，企業的技術主管領導必須有深刻的認識並負責親自落實。

　　1. 研发组织必须建立与产业部门的需求对接机制（定时、定点、定人、定交付物）。

　　2. 项目的确定必须根据不同类型的需求落实投资回报率评估。

　　3. 研发组织内部需要有完善的项目评估和立项机制。

　　4. 项目在执行过程，目的是为产业提供投资决策，需要时时评估继续执行的必要性，以最优的路径、最少的支出获得可靠的结论。

　　5. 管项目与管组织是两个截然不同的逻辑，要杜绝以管组织的方式管项目，甚至于用管组织来代替管项目，造成因人设事的恶果。

　　以上各條，研發組織負責人必須有深刻的認識並負責落實。

　　圖片

　　企業是要盈利的，企業裏所有的部門都是圍繞這個最終目的在運作。圍繞這個目的的責、權、利是企業裏所有管理的核心。所謂管理體系，就是圍繞責、權、利的制度設計和運行管理。權責不清或權責不一致，是各種管理問題的病根兒，研發組織也不例外。

　　行事前，列梗概；

　　責權利，是利害；

　　有責無權是陷害，

　　有責無利受傷害；

　　有利無責是溺愛，

　　有權無責生腐敗。

　　責權不清把事害，

　　心焦力疲互相怪；

　　領責行權利放開，

　　功成利現皆開懷。

　　所謂研發管理體系，就是圍繞研發組織這個主體，在兩個層面的責權利體系設計。

　　一是確定研發組織作爲整體，與企業的其他部分之間的責權利的體系設計，我們稱之爲大研發體系；

　　二是在研發組織內部的責權利管理體系設計，我們稱之爲小研發體系。

　　我們就以研發部門的視角，依托外責、權、利和內責、權、利這六個方面來介紹大研發體系和小研發體系應該如何搭建。

　　第一部分：大研發體系

　　研發組織作爲企業內部的一部分，其運作和功能也必須與整個企業的運行融合貫通。研發組織在企業中的職責就是爲企業運行和發展中的問題提供技術解決方案，並幫助企業盈利。

　　因此，企業賦予研發組織的“責”就是企業發展中碰到的“技術問題（problem)”，也就是我們常說的“需求”。

　　研發組織要解決接到的研發任務，就需要調動資源（人、錢、物），按照研發的規律決定研發計劃，努力完成任務。對于人、錢、物調動的權力，就是行使職責所需要的權力，但是研發組織並不能直接産生盈利，而是需要從企業獲得資源，因此，企業配備給研發組織相應的資源和對資源的支配權就是一次賦權過程。

　　研發組織經過內部的一系列研發活動，産生的技術成果，就是“利”。

　　所以在大研發體系中的賦責就是提出需求，賦權就是配備研發資源，分利就是對技術成果的管理。

　　所以從研發組織與企業其他部分的相互關系角度，就可以把大研發體系中的管理問題歸納成三個方面：1.責怎麽領（需求怎麽來）；2.權怎麽賦（資源怎麽給）；3.利怎麽分（成果怎麽歸屬）。

　　一.（一）責怎麽領

　　大研發體系的責（技術需求）是整個研發體系的立足點，對這個的理解不透或不到位，會導致各種各樣的衍生問題。

　　既然是領責，就必然涉及從“誰”那裏領的問題。

　　首先，研發組織是負責解決需求的，需求本身必須來自于企業的運營單位。從企業的運營角度，能通過技術的開發解決的問題無非這麽幾類：

　　1.現有産品或技術的性能提升，提高競爭能力。要麽賣更高的價格獲取更多的利潤，要麽降低了成本，獲取了更多的利潤。

　　2.設置技術障礙，增加競爭對手的成本，從而讓自己公司的産品獲取競爭優勢，擡升售價，獲取更多利潤。

　　3.針對將要采購的産品或技術，研發備胎，作爲競爭手段，獲得談判中的籌碼，壓低價格。

　　4.打通新業務模式的關鍵環節技術，拓展原有産品的應用方式和應用領域。

　　5.探索新的技術，潛在可以發展爲新行業或新産業的技術，爲企業的長遠發展占據有利市場地位（藍海戰術，本質是把競爭對手消滅在萌芽中）。

　　可以通過技術解決的問題或需求很多，性質跟以上5種大同小異。我們就以這幾類問題爲例，不再一一列舉了。

　　需求1，得利的是企業內部的具體産業部門。而且效益是顯性的，其中提升價格顯性指數強，降低成本的顯性指數較弱（換句話說，容易被産業部門賴賬）。

　　需求2，得利的是企業內部的具體産業部門。而且效益是隱性的，這屬于高階玩法，對于産業部門的決策能力要求很高，如果研發組織主動做好事的結果一定是被産業部門“賴賬”，因爲他們看不懂。

　　需求3，得利的是企業內部的具體産業部門。雖然效益名義上是顯性的，但是往往只在博弈的時候有用，碰上“渣男”（缺德的産業部門領導），跟所有的備胎命運一樣，用完就扔。博弈著急的時候，恨不得你馬上就把成果做出來，要啥給啥說啥都行，博弈有眉目了，馬上玩失蹤。

　　需求4，要在企業的戰略層面，發現市場運行的短板，通過開發新技術成立新的産業，與原有的産業或産品形成1+1大于2的業務發展效果。得利體現在公司整體業務的拓展，這種效益在公司層面是顯性的，但對于原有的産品或産業部門是隱性的。

　　需求5，得利的必然是公司的業務拓展，獲得更大的發展機會，效益長期看是顯性的，短期看是隱性的（創造了可能性）。但對于原有的産業部門，反而是“有害”的，因爲需要從已有的産業部門“榨取”利潤，用來轉移支付新産業的開展。

　　俗話說，誰的孩子誰抱走，誰的需求誰領走。技術開發成功後得利的那一方，就是該需求的主責方。

　　從上面的分析，大家應該可以感受到，所謂的大研發體系管理的核心就是通過制度設計和文化認知建設，讓企業內部的主責部門承擔起自己該有的責任，定義出正確合理的技術開發需求，同時遏止産業部門領導做“渣男”的沖動。

　　對于一個希望通過技術創新建立競爭優勢的企業來說，那些無能力或不願意主動制定合理的、用于支撐自己産業發展的技術需求路線圖的産業部門領導，該怎麽處置，不用我明說了吧。

　　對于需求1，不需要太複雜的管理能力，只要願意，産業部門肯定能定義出來，不做純粹屬于懶惰。

　　對于需求2，需要産業部門有外向型思維，能時刻關注競爭對手的動態，制定相應的策略。

　　對于需求3，需求、思路、做法、判斷標准，都是禿頭上的虱子，唯獨考驗的是産業部門領導的人品。

　　需求4和需求5，主責部門都是在企業層面，往往需要企業的一把手或董事會做出相應的決策和判斷，而不是下面的現有産業部門。這部分需求在日常工作中由哪個組織來負責收集和整理，各個企業有各種不同的做法，但是無非是叫做戰略部、戰略委員會等等，大都劃到戰略一類。但是不管叫什麽，或賦予什麽部門，清晰明確的需求4和需求5的定義，是戰略部門或組織的核心交付物。

　　如果負責戰略的組織或部門，天天分析各種國際局勢，時時高唱各種新業態新模式，就是不把自己的分析結合企業實際，落實到具體的需求4或需求5清單上，這種戰略部門是個什麽貨色，也不用我明說了吧。

　　至此，我們分析了整個研發體系的基石（需求）的核心作用，以及對各種不同的需求進行定義的主要責任方。我們這裏強調主要責任方意味著，這些主責方是牽頭的，而不是讓他們獨立完成（拍腦殼，閉門造車）。決策過程中可以包括各方的意見（尤其是研發組織和市場部的意見），做各種調研分析和討論，但最終拍板負責的必須是這些主責部門。

　　注：研發單位的技術自由探索功能主責部門是誰呢？這個問題可以換個問法，研發單位是爲誰做的自由探索？如果自由探索的領域是尋找新的業務領域，其天然服務對象是企業總部，因此必須是由總部出資並授權的研發活動。如果自由探索的領域是已有産業部門的業務範圍，對于一個穩定運行的産業或産品線，有那麽多自由的探索空間嗎？業務邏輯已經清晰明了的情況下，什麽該做什麽不該做還不清楚嗎？如果有，一定是決策鏈條上某個環節的失職，而不是需要研發單位越殂代疱充大頭。

　　基于上述討論，我們可以得出結論，大研發體系建設的首要任務：明確短中期技術需求制定的責任方爲産業部門，明確中長期前沿技術需求制定的責任方爲企業總部層面的戰略組織或部門，明確這兩類部門制定相應技術需求規劃的標准和流程（紀錄在案的年度時間節點、任務和交付物）。

　　一.（二）權怎麽賦

　　前面提到，“權”就是對各種研發資源的使用權。這裏需要強調資源是指廣義的“資源”，即一切可以通過資金換取的資源，包括設備、設施、場地、人才、已有成果、圖紙等等，也包括其他的資質類的資源。

　　有了“責”，跟責對應的就是“權”，責是權之魂，權爲責所用。主責部門確立了需求清單之後，自然而然就需要爲自己的需求買單，做好相應的預算。准備好讓渡相應的資源使用權給承擔相應的研發任務的組織或部門。

　　主責部門基于明確的需求清單，與通過篩選之後確定的相應研發單位之間要有明確的“責、權”交接，在賦予研發單位解決技術需求責任的同時，給與相應的資源使用權（即研發資金），做到權責統一。

　　對于需求類別1、2、3，出資單位就應該是相應的産業部門。各個産業部門每年在完成相應的需求清單制定過程中，應該有制度化的安排，同步完成相應的資金預算研判並做列支，無合理預算列支的需求是假需求。基于合理的投資回報率核算，預算的額度應該與該需求對應的業務價值匹配，核算時需要同步計入項目的成功幾率或試錯成本。

　　同理，對于企業層面的戰略性技術布局需求（需求類別4、5），應該由企業的總部預算覆蓋。希望開展此類業務的企業，也必然需要在總部層面有配套的需求研判機制和資源調撥機制（實操層面有具體的年度時間節點、地點、任務、責任人、交付物等等細節）。

　　在實操層面，各個企業往往沒有一個專門負責技術相關戰略的部門，同時技術與産業互動的長期趨勢和布局又具有高度的專業性，需要對技術在行業的發展趨勢有長期的觀察和深入的思考才能給出有價值的判斷。因此企業裏的中央研究院（或前沿技術研究院等類似組織）往往被企業賦予了相應的職責，在這種情況下，這些中央研究院也必須建立起相應的信息收集、篩選、整合和決策的機制，以幫助企業能更有效地承擔技術戰略布局的責任。相應地，爲整個公司的發展探索技術長期戰略的“權”也應該被賦予中央研究院，在實操層面往往表現爲預撥的由研究院自主支配的固定研發經費（全口徑，包含人工費用）。例如，GE公司的中央研究院經費構成中，60%是來自于子分公司的橫向經費，研發任務完全由子分公司定義，研究院的技術業務總監負責管理；30%經費屬于前沿技術開發，資金由GE總部承擔，但是研發任務需要跟有相關性的子分公司共同商定，研究院有決定性的話語權；10%的經費屬于戰略性尖端技術探索，完全由研究院確定（有一個戰略科學家群體和工作的機制流程），資金也自然而然由總部承擔。在GE的案例中，中央研究院的戰略科學家群體和領導層承擔了GE集團公司層面的技術戰略部門的角色（權、責）。（注：GE公司的資金是全口徑核算，以上的比例嚴格代表了包括人力資源的整體研發資源分配比例）。

　　關于顯性效益與隱性效益。無論顯性效益還是隱性效益，最終都是企業的真金白銀。但是其中圍繞顯性效益類別的決策，邏輯鏈條浮在水面之上，只要認清上面所述的業務責任和決策邏輯，並不需要太多的“智商”就能明白應該怎麽操作。而隱性效益類的需求，往往對企業相關人員的智商和專業認知有一定的要求。因此，企業與企業之間的競爭，最大的差異也往往體現在隱性效益類的需求和研發決策上。對于“低智商”類企業，往往死都不知道自己是怎麽死的，屬于傳說中的被降維打擊。至于總想“當渣男”的企業或産業部門，除非家裏有礦，否則遲早被社會淘汰。

　　注意：在原有的计划经济时代遗留下来的直接经费和间接经费（人员费等）的分类，造成了很多认识上的混乱，也给很多研发组织的管理造成了很大的困扰。企业是一个经济体，所有的支出大体分为两类，固定资产支出和费用支出（本人非财会人员，不接受财务专业的抬杠），其中固定资产支出适用一次支出，但按照折旧计提的方式入账，费用则边用、边消耗、边全额入账。从这个维度，所有的人员费用和材料消耗没有本质的不同，从企业与研发单位之间管理的角度，不应该区分。另一方面，作为研发过程， 真正宝贵的是研发人员的时间消耗（本质是脑力消耗），而不是买实验材料那仨瓜俩枣儿，在这个问题上，有太多的愚蠢至极而且毫无意义的纠缠不清（有人无意，有人故意），白白消耗了大量的公司层面和研发组织内部宝贵的管理资源。

　　這一點是目前科研大環境的短板之一。所有人都有“解決豬的問題，但是讓狗買單”的思想傾向。問題的根源與過去幾十年直接經費和人員費分兩條線管理有一定關系。

　　在計劃經濟年代，人員費往往由國家或總部作爲固定花費支出，沒有計入研發成本。在實際操作中，産業單位也往往只需要考慮研發項目的直接經費的支出。即使是提供技術解決方案的第三方，在中國往往是各個大學或國家擁有的科研院所，他們的人工費也往往由財政直接覆蓋。導致企業跟大學談研發任務的時候，也是幾十年如一日的只考慮直接經費，對于研發中最重要的也是最大頭兒的資源消耗（人力）卻不管不顧。這直接導致了兩個惡果：

　　1.市場上的所有人對研發中真正核心的人才價值缺乏下意識的尊重（嘴上漂亮話大家都會說），很多人的思維邏輯架構都已經潛意識裏把人的價值忽略了，需要提醒才會“哦，對對對”。對你個頭啊。

　　2.在研發項目的管理過程中，人力資源的量化管理長期處以畸形狀態，各種扭曲的奇葩操作被衍生出來。

　　所有的研發單位領導，永遠在爲人員費奔波；要麽研發項目做一個虧一個，無論成果多麽的漂亮；要麽在財務報表上做手腳，想方設法把人力成本塞進去；市場上還流傳者各種各樣的應對財務審計的心得、甚至于經驗分享（比如如何把一個專家的費用拆解到幾個普通員工的名額上），殊不知這些財務審計的底層邏輯本身就是個大笑話，是整個體系扭曲的結果。而到了項目層面，有影響力的項目經理永遠在尋找各種各樣的借口要求更多的人員配置，哪怕是要來了人給自己端茶倒水也是好的，反正不花項目的錢；甚至于科研人員本人，也願意到人浮于事的項目上去，反正同樣有工資領，人浮于事的項目反而活兒少，責任輕。

　　放眼全球，有獨立核算的經濟主體，包括跨國公司，大型的民營企業，基本都能做到：誰的事兒誰出錢，全口徑核算（包括量化計量的人員費消耗）。

　　有人狡辯說人員費不好計量，難以做到准確，這些的都是非常幼稚的認知，或者腦子進水了。能不能算的准是技術問題，算與不算是性質問題，豈可同日而語。無論多麽不准的計量都比假裝看不見要強。

　　一.（三）“利怎麽分”，即成果的管理

　　任何研發項目必然自帶探索性質，因此，研發過程中，必然會得到一系列的信息和基于信息形成的判斷和結論。這些一系列的結論鏈接起來，最終可能形成一個可操作落地的技術方案，也可能在某一個環節形成此路不通的結論，這些都是研發的成果。

　　在項目的執行過程中，必然會借用到一些原來就存在的知識資産，這些資産有可能是研發單位之前自己擁有的知識資産，也可能是不相關的第三方的知識資産。

　　同時，通過項目的執行，也可能形成了一些新的知識資産。

　　對于一個“客戶”（産業部門或企業總部）根據自身的技術需求，定制化開發的研發項目，項目中形成的技術方案或者是項目失敗形成的結論，其使用權天然歸出資的“客戶”，因爲客戶可以通過使用這些結論，做出自己業務上的合理決策，這些不管是成功還是失敗的結論，相當于是一個咨詢答案，而業務部門對于自身的技術需求下一步要采取的措施，需要這些“咨詢”答案做決策。

　　研發過程中借用到的已有知識資産，如果在最終的技術方案中，也會用到這些知識資産，那麽，企業在以後的成果落地過程中，必須考慮購買這些知識資産的使用權（注意，不是産權）。

　　研發過程中形成的知識資産，其産權和使用權的歸屬，取決于形成過程中哪部分的貢獻大，如果研發單位自身過去的知識和經驗積累貢獻大，産權歸研發單位；如果客戶出資所對應的研發活動貢獻大，則産權歸出資方；如果無法清晰界定的一般可作爲共有産權，或遵從雙方的約定。（注：在一些歐美國家法律體系中，知識資産的産權自動歸發明人個人，需要一系列的法律權利讓渡安排才能歸屬企業）。但是無論何種安排，出資人一般自動獲得使用權，除非另有特殊約定。

　　爲了後面關于成果管理的討論方便，我們假設所有的項目執行中産生的新知識資産，産權歸屬于出資人。

　　至此，出資方（即技術需求主責方），通過對研發和技術的投資，獲得了一個可以落地實施的解決方案，研發組織完成了研發環節上的所有任務，並交接完畢，完成了整個過程的邏輯閉環。在此之後的業務活動純粹屬于投資和生産範疇。

　　從技術需求主責方的角度，爲了成功進入生産運營環節，在技術開發環節的總投入包含，1.整個研發項目的過程中支出，2.落地成果所必要的已有知識資産使用權的購買。因此，在前端，需要做出相應的准備。（知識資産的産權的購買屬于投資性質，無關成果落地，這裏不做討論）。

　　而對于一個企業來說，經過一段時間的研發投入，必然會形成衆多的知識資産，如何通過統籌安排，優化這些知識資産的所有權和使用權，最大化它們的價值，並減少管理成本和風險，是一門學問。很多企業，尤其是有衆多法人實體，且跨國運營的企業，往往在經曆了慘痛的教訓，交了不菲的學費之後才認識到統籌管理知識産權的重要性。

　　系統化、專業化的知識産權管理體系和理念的形成，標志著大研發體系建設完成邏輯閉環。

　　某跨國公司在業務擴張和全球化的過程中，一開始並沒有刻意設計知識産權的管理體系，任由各個子分公司和法人實體，在項目執行的過程中自行決策和談判他們投資的研發項目形成的知識資産的歸屬權和使用權。當公司的業務橫跨很多個國家與地區，擁有成百上千個法人實體之後，知識産權的使用逐漸演變成了一場噩夢。

　　首先，知識資産的定性和歸屬是個法律概念，不同國家和地區的管理理念和模式不全一樣。

　　其次，各個子分公司和法人實體對知識産權的管理能力和經驗參差不齊，形成了很多短板和漏洞。

　　第三，作爲一個集團公司，存在的價值就是資源共享，最大化共同的收益，因此各個子分公司擁有的知識産權在全集團的共享是個必然趨勢，但是勢必造成各種來回的交叉授權。

　　第四，每一次的知識産權授權行爲，都會牽扯到授權雙發的稅務管理問題。上千家法人實體，幾萬個專利，所産生的這種交叉授權關系和潛在的稅務合規風險迅速膨脹到一個天文數字。

　　經過評估，公司重新設計了知識産權管理結構，拿出一大筆資金，在全球把所有子分公司所擁有的知識産權歸屬統統收購到總公司名下，再由總公司統一授權給需要使用的子分公司或法人實體（如下圖）。之後，在整個集團公司內部，所有新申請的知識産權都唯一歸屬到總公司名下，除非極其特殊情況下經總公司評估和批准，否則不允許有任何例外。但是各個子分公司跟自己業務相關的知識産權，仍然在集團公司內部的管理系統中做出相應的管理權限標記，在各種評估和管理操作上，賦予被標記的子分公司決定權（對外授權、轉讓、放棄或打官司等等），但是法律層面的操作，全部由總公司完成，子分公司法人不體現在對外的任何文件上。

　　在這種管理結構之下，産權簡潔明晰，法律關系邊界清晰，風險完全在掌控之下，而且節省了大量的交叉授權帶來的稅務成本。

　　第二部分：小研發體系

　　不同于大研發體系，小研發體系是由一個專職的研發組織來承載，因此，小研發體系的設計必須同步考慮組織結構設計，體系與組織互相成就，互相影響。研發組織具有所有常見組織的基本內核，基本分爲三大類：核心業務，隊伍，運營輔助。

　　小研發體系的責權利體系建設主要體現在它的核心業務（即研發活動）中，這部分是整個研發組織區別于任何其他組織的關鍵所在，也是研發組織之所以存在的基礎。因此，所謂研發體系的搭建就是研發業務管理體系的搭建，研發體系的管理就是指研發業務的管理，和圍繞研發業務特點對其他的輔助職能提出的配合要求。我們下面重點介紹研發業務活動的責權利設計邏輯和管理邏輯。

　　研發活動相對于生産活動，更加依賴人的品質和能動性。在生産部門中，生産主要依賴于生産資料，人通過管理和操作生産資料完成生産活動。而在研發單位，科研人員本身就是生産資料，其管理受科研活動特質的深度影響。因此，我們後面順帶介紹一下研發單位的科研人員管理。

　　运营辅助功能，如IT, 财务，法律，后勤保障等等，虽然需要考虑服务于研发单位的业务特殊性，但就这些职能本身，并不会因为服务于研发单位而改变它们的工作内在逻辑。因此，我们讨论研发体系建设的时候，并不必过多涉及这部分内容。

　　二．（一）管業務：研發活動的權、責管理

　　小研發體系是研發組織內的責、權、利管理。因此，管業務就是圍繞研發活動的責權利展開。

　　1）權責的交接和分解

　　小研發體系的第一個環節，是與大研發體系的責任（需求）交接機制。即産業部門的技術需求如何通過一系列的溝通和篩選決策機制，成爲研發組織內部承接的一個個有清晰和明確定義的研發任務。

　　對接與溝通一定是通過人與人之間的互動完成，因此，大研發體系與小研發體系的責任交接機制就是要：1.明確産業部門和研發組織對接的具體負責人（兩邊都要)；2.明確對接的過程、內容、交付物和年度時間節點；3.這些交付物的表現形式就是逐個精確定義的可承接問題（problem，責）清單，以及每個問題對應的研發經費（權）安排。

　　研發組織內部這個與産業部門對接需求的負責人，我們暫且稱爲技術業務總監。從研發組織承接到一個研發任務（從這裏開始，我們可以稱之爲項目）開始，就啓動了研發組織內部的責任“切分和分包”機制。

　　爲了准確理解研發活動的責權利，我們首先得對企業的研發活動的本質做一個准確的理解。

　　當一個産業部門有一個技術需求的時候，這個需求的表現形式是有一個技術問題（攔路虎，problem）沒有解決方案，導致無法做進一步的業務決策。這個問題可以是一個很大的複雜問題，比如航空母艦怎麽設計；也可以是一個很小的具體問題點，比如瓷磚的表面平整度怎麽提高。當這個問題交給研發單位的時候（當然連同研發經費一起），希望研發單位通過內部的研發活動給出一個方案。考慮研發結果的先天不確定性，通過研發之後，給出的結論可能是：1.這個問題按照技術指標要求解決不了；2.這個問題有能滿足指標要求的解決方案，並給出方案。

　　研发组织需要为自己的“结论”负责，无论结论是1 还是 2。如果结论是 1，而且结论可靠，那么产业部门就可以依据这个否定的结论，否决围绕这个技术需求的投资计划，获得了宝贵的确定性，把业务重点转向别的方向。如果结论是2，有解决方案，而且结论可靠，意味着这个方案确实能满足初始定义的技术需求，那么生产部门就可以以这个技术方案为基础，做出进一步的产业投资，形成“产品”并产生预期的经济效益。

　　技術業務總監需要把一個個定義清楚的“問題”通過篩選機制，交接給研發組織內部具有解決問題能力的研發專家，篩選出的合格研發專家如果也同意承接該任務（“問題”，責）和對應的研發資源（權：廣義的資金調配權力）並按流程完成錄入管理系統，則一個研發項目就完成了定義和立項，該研發專家正式成爲“項目負責人”。如果承接的是一個複雜的大問題，這個項目負責人還可以把這個大問題合理地拆解成一系列的小問題，再把這些小問題分配給他認爲具備相應解決能力的小研發專家（項目課題負責人）。

　　拆分出來的並列的小問題之間，往往由不同的責任人分別承擔。沿著時間縱軸，大問題還可以拆分成一系列前後互相依賴的小問題，往往需要按照前後邏輯一一順次解決。這個問題拆分的過程，就是一個拆責分責的過程，換句話說，每一個項目負責人或課題負責人，都是真正意義上的“負責”人。反過來在執行過程中，每個“負責人”通過得出自已研發任務的結論，累積成整個項目的結論，回饋給“交辦”的客戶，完成整個研發任務的邏輯閉環。

　　2）利的定義和管理

　　由以上討論我們可以看出，整個研發活動的“利”就是研發的結論，能被客戶拿去做決策和使用的“結論”。而絕不是什麽狗屁的專利、文章、示範項目等等，那些都是錦上添花的額外收獲，或者是研發的資源。在這一點上，只有那些真正在市場上拼刺刀的産業部門才有深刻的認識。

　　對于那些以炫耀爲目的的研發投入，領導們最喜歡看到的可能就是投入XX個億，規模XX萬噸的示範裝置。針對這類項目，當被問到，這麽大的投入，能說明什麽問題？得出什麽結論？往往幹的人一臉懵圈兒，整個決策簡直弱智透頂。我們並不反對建設大裝置，也不反對投大的示範，關鍵是針對所要回答的問題，這個投入是否必要？是否唯一的選項？這種花架子類的投入，多發生在兩類企業裏，一類是“反正不是花自家錢”的企業，大家都懂的；另一類是對研發的探索本質缺乏了解，把“幹活兒”當成了研發的企業，以爲活兒幹的越大越多越牛X。

　　3）責權利的互動

　　在这个拆分问题、“分责”的过程中，必然伴随者“分权”的过程，即为了解决问题，相应的项目负责人或课题负责人，拥有支配所给与的研发资源、选择最佳验证方式和验证资源的权力。因此，我们一再强调，项目中的每一个工程师，都是一个权责主体，需要发挥自己的聪明才智和主观能动性，针对所负责的“问题”（责）用最快最有效的方式（权）得到可靠的“结论”（利）。 大家研发能力的高低就体现在，1.是否能对自己负责的问题得到可靠的结论；2.在得到可靠结论的前提下，能以更高效的资源消耗得到结论。用通俗的话讲，如果结论是该问题解决不了，那能否用最小的代价发现真相？如果问题最终能解决，能否用最节省的路径尽量少的研发资源找到解决方案？作为技术业务总监，这两条就是挑选项目负责人的标准（在这个大原则下可以细化成很多特征），而作为项目负责人，这两条也是他们挑选项目组成员的标准。

　　注意：這裏項目負責人經常犯的錯誤是把分責過程弄成了分活兒過程。我們一再強調，科研活動（例如：做實驗，查資料）的目的是科研結論（說明了什麽問題），因此每一個工程師在項目中的角色是認領需要解決的“問題”，而不是認領一堆的活兒（比如做實驗）。實驗是手段，結論才是目的，而一旦手段與目的顛倒（或者不知道目的是什麽），“幹活兒”本身變成了衡量標准，無論對項目還是對個人，都會産生極大的資源浪費，甚至導致項目完全失�。ㄙY源總是有限的）。在日�？蒲泄芾碇�，本人非常痛心疾首的就是碰到“工作極其努力，夜以繼日以做實驗爲目的”的工程師，對組織對個人的發展危害極大。

　　基于權責對等的原則，項目負責人必須有權根據項目的問題需要，挑選合適的工程師，同時給與所選合適工程師他認爲合適的細分“權責”。從這裏可以看出，研發組織裏的工程師們本質上是一個一個的“資源”。這些資源要想發揮最大化的作用，就必須按照項目的需求來匹配，即項目需求決定人員組成。

　　4）研發業務（軟件）與研發組織（硬件）的互動關系

　　研發工程師作爲一種研發的資源，需要保持高度的流動性，流動性越高的資源，其發揮作用的效率就越高。但是，任何的研發組織，其中的研發工程師都是劃分成一個一個更小的組織單元，實現人員的管理，是一個天然的穩定結構。組織的穩定性與研發活動對資源流動性的要求天然矛盾。

　　這就需要對組織裏工程師作爲人的屬性和作爲資源的屬性做分離處理。工程師只有花在研發任務上的時間和精力才是研發的資源，自然屬性的“人”本身並不是研發的資源。這種劃分類似于資産的歸屬權和使用權，歸屬權是一個整體，是死的，而使用權是可以分割調配的，是活的。下表是對研發中的三種核心要素的比較。

　　項目需求

　　人的資源屬性

　　人的資産屬性

　　研發任務

　　研發時間

　　組織身份

　　解決不確定性

　　高流動性，可調配

　　穩定，不易變動

　　表1 三种核心研发要素比较

　　項目內部的管理核心就是對這三種研發要素的合理匹配。這裏需要明確一點，研發組織的核心責任是解決技術需求，因此，資源的調配必須以項目需求爲核心來完成。而研發組織的內部管理機制的設計，就是要反映研發項目需求的核心地位和圍繞項目需求的研發資源調配機制，從而實現項目責權的統一。

　　對于這三種研發要素之間關系的深刻認知是設計研發組織內部項目管理機制的基石。研發項目管理是個分責的過程；人員的組織關系屬于“資産産權”的性質；項目負責人對研發人員的調配，類似于資産使用權的購買。

　　由于研發活動高度依賴科研人員的主觀能動性，很多吃瓜群衆往往難以正確理解科研單位裏面的管組織與管業務的區別，更有甚者，直接把管業務和管組織完全混爲一談。

　　有很多研發組織的管理者，也對這三者要素之間的地位和約束關系理解不到位，把管項目與管組織混淆起來，極端情況下，甚至出現以管組織代替管項目的最糟糕情形。

　　以管組織代替管項目這種現象在我國的體制內單位中最爲常見，而且也深深影響了整個社會的管理習慣。組織死的，項目是活的，是兩種截然不同的管理原則。這種現象的出現也有整個社會“官本位”文化的推波助瀾，誰都願意到外面炫耀自己管多少多少人，而不是管理一個多麽重要多麽複雜的項目（主要是社會上的吃瓜群衆們也聽不懂）。

　　5）項目的跟蹤評估機制

　　項目組畢竟是由人組成，一旦設立，就會産生一直向前的執行慣性，甚至脫離它作爲“獲取結論的手段”的定位，向組織化方向演進。因此，研發組織必須有專人負責的、剛性的定期項目評估機制，對項目繼續的必要性和內容的合理性隨時做出必要的判斷和終止決策，以制衡項目組天然的組織化傾向，進而導致本末倒置，讓研發資源失去流動性。

　　關于項目的日常管理，絕不應該忽視項目的探索本質，技術業務總監對項目的目標結論的有效性應時時關注。我們大部分人的認知是定期看看項目的進度，看看任務完成的怎麽樣了。大部分的日常項目評審內容也確實是根據項目計劃評估項目團隊的執行情況，並根據項目碰到的問題從研發組織層面協調資源予以支持。但一個永遠隱含的項目管理和評估目的是及時決策：一旦有支撐信息出現證明預期的結論爲否，項目應該隨時被終止以節省研發資源。

　　目前國內市場上的項目管理一個很大的誤區是假設項目肯定能成功，與研發項目的探索本質南轅北轍。項目管理普遍是以檢查“幹活兒”爲導向，而不是以檢查“結論”爲導向，即：項目一旦立項，就必須按計劃完成所有的規定動作和任務。如果是結論已知的工程類項目，這種做法無可厚非，因爲執行力就是省錢，只要執行好就一定能成功。但是對于探索性質的研發項目，這種做法就�：�巨大。我們不可能在要求項目組必須完成所有規定動作的管理方式下，同時要求項目組尋找最優的驗證路徑用以時時判斷項目成功的可能性，以遵循研發的探索本質。

　　二．（二）管組織：就是管理人的職業需求

　　從業務本質上說，研發組織裏的工程師，作爲一個整體，都是爲項目服務的資源池。如果類比生産單位的話，研發的工程師們就相當于是工廠裏的生産線，而研發的成果就相當于生産線上下來的産品。從這個角度，生産線都是爲産品服務的。

　　但是，這些産線又是有主觀能動性、自我管理的“産線”，因此，工程師群體在完成研發任務、爲企業創造價值的過程中，同時也是他們建立自己的職業生涯、實現自我價值的過程。另一方面，他們又是能學習的“産線”，隨著一個個研發任務的執行和反饋，有不斷地自我總結、自我學習和自我提升的需求。

　　從企業的視角看，服務于項目需要、最大化人員的利用價值是主要目的，工程師們獲得經驗、反饋、能力、成長，變得更有價值，從資源增值和儲備的角度，是手段。

　　從工程師的個人視角看，通過項目的執行，獲得經驗、知識、能力、認可和回報才是目的，把項目做好爲企業創造價值是實現自我價值的手段。

　　兩個視角從過程上看是一致的，但是在作選擇時是不一致的。因此，對于研發組織裏面工程師的管理，就是要平衡好企業目的與個人目的之間的關系。

　　研發組織內部部門的設立，往往是基于人員的管理和成長需要。需要擔負起每個工程師的招聘、培訓、輔導、考核、個性化的發展和晉升等等，同時研發組織還需要爲自身的發展培養人才梯隊以搭建管理體系，這些都需要組織內部的“部門”來完成。

　　從項目的角度，希望組織越扁平越好，這樣有利于資源的流動和調配。

　　從人員和組織發展的角度，希望組織結構化，這樣才能形成一個有機的整體，保持組織發展的穩定性和長期性，同時爲戰略性決策奠定組織基礎。

　　最終，研發組織作爲一個組織，也是有“生命”、有生存意識的。如果所有的決定和流程都只是有利于項目，有利于企業，而研發組織自身的利益和長遠發展卻得不到保證，那麽這個研發組織也不可能發展的好，反過來又會損害企業的研發能力和創新能力。整個研發組織的“生存意識”也是由內部個各個部門的生存意識疊加組成，所以在各個部門層面，這個矛盾同樣適用。

　　如何能平衡好個人、部門、組織的長期發展訴求與項目的階段性、具體的、靈活性的訴求，有許多不同的做法和管理技巧，比如矩陣式管理、內部創業制、自由組隊揭榜挂帥、賽馬制、重點攻關等等，都是在項目需要和人員管理之間尋找平衡。沒有一個方式是包打天下的完美方式，作爲研發組織的管理者和研發體系的設計者，需要對項目管理和人員管理之間的差異和關系有深刻的理解，才能做到因地制宜，靈活舉措。如果混淆了管項目與管組織，甚至于以管組織的方式管項目，最終一定異化成“因人設事”，組織和部門變成綁架研發決策的家天下（因爲有這些人、因爲這些人是XXX專家、因爲這些人又有了話語權，所以就要設立XXX項目）。最終的結果是整個研發體系效率的大幅度下降。

　　歸納第二部分的討論，小研發體系的搭建由這幾方面構成：1.技術需求的責權利的承接分包機制；2.研發資源（人員）的歸屬和調用機制；3.研發項目的全生命周期評估管理機制。4.如何把項目的“利”與組織和個人的“利”合理地結合起來以高效地調動人的積極性，就是考核機制。組織和個人的考核論題內涵複雜豐富，我們另文專門論述。

　　第三部分：總結

　　整個研發體系的建設歸根結底是對研發決策和研發執行過程中責權利的深刻理解，並基于責權利協調一致的原則，設計這個組織的所有相關管理機制和流程，包括企業層面研發組織與其他業務部門之間的權責利協調機制和研發組織內部圍繞研發活動本身的權責利劃分與協調。

　　三．（一）

　　負責搭建大研發體系的是企業科技創新的主管領導（也即之前文章提到的發起籌建研發組織的1號種子）：科技創新的主管領導是把科技體系與整個企業的運營融爲一體的人。如果一個企業不大，業務相對單一，那麽企業的總經理就是科技創新的主管領導，如果企業業務構成複雜且體量龐大，那麽就有可能有一個專職的主管領導。

　　主管領導必須能深刻理解科技創新是企業的一個功能，不是一個獨立存在的業務。科研部門負責探索，厘清風險，提供方案和選項，然後由業務部門依據科研隊伍的結果，結合業務上的非技術因素一起，制定投資和業務計劃，從而實現企業效益的提升。在這裏必須強調，科技創新是爲産業服務的，是替産業部門解決當前問題或探索未來道路的，但“路”要産業部門自己去走，企業的效益也必須由産業活動來實現。

　　産業部門作爲這個鏈條上的甲方，必須負責爲乙方（研發部門）提供産業發展方向的指示，如果産業部門在這方面沒有合格的知識儲備和戰略思考，就必然會出現亂指方向，或不作爲要求研發部門自己定方向的現象。造成的後果就是研發部門出了一堆成果産業部門沒法落地。所以，如何把業務部門打造成研發創新鏈條上合格的甲方是主管領導的重要職責。如果一個科技創新的主管領導認爲自己就是要把科研隊伍管好，那就是把自己降格爲研發組織的負責人了。所以當一個企業的領導追問研發部門的直接經濟效益的時候，那麽整個公司的創新體系，尤其是産業部門的創新職能一定出現了問題！

　　因此，作爲整個企業創新體系的負責人，如何提高企業（注意，不是研發部門）的創新效率，創造更多的經濟價值是核心責任。需要在工作中緊緊抓住産業部門這個創新鏈條的龍頭。如果産業部門在創新戰略的實施上有任何閃失，造成的後果都是不可彌補的。

　　那麽，作爲創新體系的負責人，在主抓産業部門創新職能時需要注意什麽？

　　1.深刻理解产业部门在创新体系中的头尾作用。产业部门才是创新需求的提出者，任何没有产业部门认可的创新活动都是无源之水，无本之木。所有的创新成果要由产业部门（全套商业功能）来实施，如果一个成果没有一个对应的产业部门，必然无法对本企业创造价值 （技术转让/许可也是通过广义上的“产业部门”—即技术受让方—产生效益）。

　　2.對産業部門實施正確的考核和激勵手段，促使他們發揮創新龍頭和龍尾的作用。作爲龍頭，要考核他們是否有高效的需求收集和篩選機制，提出的研發目標是否契合業務發展戰略，是否了解市場和競爭對手的前瞻布局，是否有效利用企業內外的創新力量。作爲龍尾，要考核産業部門是否有成熟穩定的研發成果評估和接收機制，是否了解新技術新産品的生産推廣規律，相應的隊伍是否完善。

　　創新體系建設常見的誤區：

　　1.認爲創新是研發部門的事兒，導致産業部門在創新鏈條上缺位，整個體系無法發揮作用，體系運作難以持續。

　　2.考核指標錯位。比如把産業部門當成創新活動的主體，用考核研發部門的指標考核産業部門。比如考核産業部門的知識産權數量（專利數），導致産業部門與研發隊伍在本是一家人的情況下爭搶知識産權的冠名或名義歸屬（實際都應該是歸屬整個企業）。或者走另一個極端，用直接的經濟指標考核研發部門，導致研發部門熱衷于自立門戶，進入生産銷售，對服務本企業的産業部門不積極不熱心，甚至把産業部門當成競爭對手。

　　3.做不到結合本企業所在的行業特點，盲目地與別的行業的企業攀比對標。一個企業所在行業的發展曲線一般符合下圖所示的S曲線，在不同的發展階段，技術演進的特點和作用不同，企業需要采取不同的風險和投資評估機制，技術發展的曲線會略早于行業曲線。在早期，技術/行業前景高度不確定，需要多點布局，小心試探，積極求證，避免冒進。中期，行業/技術爆發，行動慢是最大的風險。後期，技術/行業走向成熟，需求和回報相對明確，是企業運行的基礎，但難以形成高回報的投資機會，決策避免掉入舒適區陷阱，固步自封，忽視新技術/業務模式的産生。

　　三．（二）

　　負責搭建小研發體系的是研發組織的負責人（也即之前文章提到的發起籌建研發組織的2號種子）：我們一再說，研發組織的負責人，必須對研發的內在邏輯有深刻的洞見（不能只是有很多經驗而已）。既要基于研發活動的特質搭建合理的小研發體系：搭建合理的組織架構（分責）、設計合理的管理流程（分權）以及高效的獎懲機制（分利）；還要完成與大研發體系對接，與企業的其它部門形成融爲一體的合作機制。最後，研發組織的負責人還必須是“人精兒”！這個社會畢竟是“人”的社會，如何管理好一個由人構成的組織，對人的認識必須深刻精准。

　　首先，負責人必須對人性有深刻的理解，工作安排如果符合人性，就很容易開展，如果違背人性就會寸步難行。當一個組織的職責和流程設定、或者工作安排出現問題的時候，組織負責人要能迅速地識別出是否由人性的因素造成，如果有，則必須首先解決和改變。

　　其次，負責人必須對自己組織裏每個角色的能力模型有准確的認知，這樣在安排人員時才能判斷一個人是否具備勝任這個角色的能力、潛在的弱項是什麽。對組織的弱點能有准確的判斷和預估，在發展組織時，知道從哪些角度出發能做到事半功倍。