李宏舟

一、美日歐企業發包高端業務的動機分析
傳統觀點認為,隨著軟件開發的模塊化發展,一個項目或產品可以被分為若干個能夠獨立運行的模塊,這些模塊對知識的需求程度和需求種類是不同的,考慮到溝通成本的問題,發包方傾向于將需要與最終用戶方頻繁溝通的模塊、需要大量隱性知識轉移的模塊留在企業內部或是發包給本地區的企業。在這種情況下,印度等發展中國家的接包企業所能接觸到的模塊的知識含量較低,通過這些業務模塊掌握行業知識、系統集成經驗和開拓市場的機會有限,而這些知識和經驗對于企業構建自己的軟件開發能力又至關重要,所以通常被控制在發包方企業內部,使其核心競爭力所在。因此說,傳統的軟件服務外包業務對于接包方企業而言,學習效果是有限的(DCosta 2004),因為發包方企業將發包業務限制在了軟件開發中的生產環節,追求的是低成本。可是如上文所述,在實踐中,美日歐的企業已經把軟件開發的高端業務外包給了印度的企業,這是為什么呢?從發包方的角度,Rasmus Lema在綜合其他人的研究成果和自己調研的基礎上,給出了兩個原因:(1)發包方企業核心競爭力的前移;(2)軟件創新活動與生產活動之間的聯系經濟性(linkage economy)。
隨著大型企業內部各業務部門分工的細化和對信息技術依賴程度的增加,這些業務部門越來越希望信息部門能夠根據其掌握的行業知識和對行業發展的預測,開發出實用的軟件產品,以提高部門的運行效率,但是由于人員和預算限制,即使企業內部的信息部門對所有的業務部門的行業知識了如指掌(現實中做到這一點已經很困難),他們也沒有能力開發出所有的軟件產品,因此在這種情況下,大型企業的信息部門對外部技術力量的依賴已經不可避免,從競爭戰略的觀點來看,這些信息部門往往把自己的優勢定義為對行業知識的掌握和對客戶需求的熟知,因為信息部門的這種優勢是外部企業無法復制的,因此在軟件開發的整個價值鏈中占有重要的作用,被分配的價值比例也相應較高。
也就是說,隨著價值分配的重點從軟件的框架設計活動轉向與最終用戶的關系維護(通過掌握客戶的操作流程和行業知識,企劃有針對性的新產品)、市場開拓以及新的商業模式的開發與管理等方面的活動,軟件開發中框架設計的重要性和價值分配比例有所降低,并開始被外包給印度的軟件企業。
對于美日歐一些新興的軟件開發企業而言,他們對客戶需求有著很好的理解,但是如何通過軟件開發的功能設計滿足這些需求則不是強項。為了將顧客需求轉化為軟件產品,發包方企業和接包方企業往往組成聯合項目組,共同實施軟件的抽象設計,之后將軟件的詳細設計和編碼等業務發包給相同的印度公司,因為參與了前期的需求分析和抽象設計,所以接包方企業對軟件的功能等有著較好的理解,這便于他們以較高的效率完成后續開發工作,為發包方企業節省成本,實現所謂的聯系經濟性(linkage economy)。
當發包方企業為電子產品或通訊設備的制造商時,情況則有所不同,他們發包嵌入式軟件業務的主要目的是借助印度企業的技術力量縮短產品上市時間和節約成本。隨著電子產品和通訊設備的日益復雜,單個企業的技術能力已經不可能完成新產品的開發,在這種情況下,擁有各自優勢的企業通過契約關系聯合在一起共同開發新產品已經成為必然,大的龍頭企業負責管理整個價值鏈并進行系統集成。印度的企業可能負責子系統、甚至是孫系統的嵌入式軟件的開發過程,但是這些硬件的生產、整個系統的設計和集成則由龍頭企業或其他企業負責。由于電子產品的系統集成和各個模塊的開發可以在組織上實行分離,所以往往是只發包與軟件相關的業務(嵌入式軟件),而硬件的設計則留在企業內部或發包給專業的硬件設計企業,模塊與硬件之間的接口設計已經在整個產品的設計時予以規定。體現在勞動分工上,美日歐的發包方負責監督整個產品的設計,規定各個子模塊需要具備的功能以及最后的系統集成;而接包方只負責完成子模塊甚至是孫模塊的具體設計及其編碼等業務,其向上延伸業務范圍的空間有限。換言之,對于嵌入式軟件接包方企業而言,它們很難進入整個產品的設計及其系統集成等綜合業務的領域。
通過以上的分析可知,美日歐的發包方企業為了將自己的力量放到更能創造價值的高端項目和市場開拓、顧客關系維護以及跟蹤預測行業發展等非軟件開發技術方面,所以逐步將包括抽象設計(甚至是需求分析)在內的業務發包給班加羅爾的企業。當然,隨著美日歐發包方企業核心競爭力的前移,價值分配的重點也相應地起了變化。但是相對于編碼、測試等軟件生產業務而言,抽象設計等高端業務被分配的價值要高,如果班加羅爾的軟件服務外包企業確實構建了自己的軟件創新能力,那么這意味著在世界范圍內的軟件服務外包中,作為接包方,印度的優勢已經不只是成本,還包括創新能力,它們將獲得更多、更為高端的外包業務。
那么,作為接包方的印度企業是如何利用好這些機會,成功延伸自己的業務范圍,構建軟件開發的創新能力的呢?
二、創新事件與SECI模型
Rasmus Lema(2010)認為,印度的軟件服務外包企業對創新事件(innovation event)的管理能力和能力杠桿(competence leveraging ability)的發揮程度決定了他們能否抓住因美日歐發包企業核心競爭力前移而空出的創新空間,從而實現業務范圍的延伸。
所謂的創新事件是指使印度的接包公司獲得了以前不具備的能力的一些重要事件、這些能力的具備可以使公司開發新的產品(服務)或改善了現有的產品(服務)。那么為什么創新事件能夠使公司獲得新的能力呢?其背后的理論基礎是什么呢?
實踐表明,創新事件主要是通過項目組的方式實施的,Hobday(2000)指出,“公司的知識、能力和資源主要是通過關鍵項目的實施得到的;項目組式的組織方式(project-based organization)是創造、應對和實施新的商業機會的常規機制?!蹦敲错椖拷M式的組織方式究竟是如何實現上述功能的呢?
2.1 野中郁次郎的SECI模型
野中郁次郎在1995年的《論知識創造的能動過程》中首次提出了知識創造的SECI模型,同時強調了知識創造的知識場——“巴(ba)”的重要性。野中郁次郎認為,組織知識主要是通過隱性知識和顯性知識的相互轉換而被創造和實現組織內部普及的,這種相互轉換可以分為四種模式(如圖1所示),即潛移默化、外部明示、匯總組合和內部升華。
潛移默化是組織內部個體之間隱性知識的分享過程,傳播者借助的主要工具是做,接受者則主要通過觀察和揣摩實現對隱性知識的領悟和掌握。外部明示要求隱性知識持有者能夠以一種被他人所理解的方式將隱性知識表達出來,借助的主要工具是說或寫,這要求隱性知識要具有一定的清晰度,接受者主要通過聽和看(文字化的材料)理解所要學習的知識。匯總組合是指已有的顯性知識和新獲得的顯性知識的組合,這是知識創造的關鍵過程,需要的是創造性的思考,這種匯總組合的實施主體可能是組織內部的個體,也可能是組織內部的某個小集團(比如項目組)。內部升華是指新的顯性知識轉換為個體隱性知識的過程,主要通過實踐、訓練和練習來實現新知識的內在化。
上述四個不同的知識轉化模式是一個有機整體,是知識創造、共享和使用過程中不可或缺的組成部分,整個過程也是高度個人化的隱性知識通過共享化、概念化和系統化實現了個人之間、個人與組織之間知識的傳遞、創造和使用,并最終又產生了新的隱性知識。在這個過程中,知識的轉化、共享和創造是一個動態的、遞進的過程,當個人的隱性知識完成一次知識螺旋運動、轉化為新的隱性知識后,新的知識螺旋運動又開始了。在這個過程中,外部明示至關重要,否則這些共享知識是很難成為整個組織內部的共識,在空間共享上將受到限制。當然僅有隱性知識的共享和積累,或光有顯性知識的組合和吸收,都只是整個組織知識創造過程中的一個孤立部分。
野中郁次郎還很針對知識創造、轉化和共享的場所,在SECI模型中引入了“巴”的概念,“巴”主要指物理的場所,如工作現場、公司的會議室乃至同事之間聚會的酒吧等,也包括虛擬的場所,比如組織內部的網絡討論空間。野中郁次郎根據知識轉化的四種模式,將“巴”分為原始的巴(隱性知識的共享)、對話的巴(隱性知識的明示化)、系統的巴(顯性知識的結合)和練習的巴(顯性知識的個人化)四個部分(耿新等,2004)。
2.2 SECI模型在創新事件中的應用
如前文所述,在對創新事件的研究中,Rasmus Lema發現發包方和軟件的最終用戶往往是最重要的知識提供者。因為需要印度企業的軟件技術力量或行業知識(domain knowledge,這種情況很少),作為發包方的美日歐企業和作為接包方的印度企業會共同組建開發團隊,這使印度企業有機會從需求分析階段開始介入軟件開發。在這個過程中,通過相互交流,印度企業獲得了新的知識。
印度企業獲得新知識的過程可以通過SECI模型來解釋。實際上,雙方共同組建的項目組實際上就是SECI模型的中“巴”,因為在開展業務的先后順序上,軟件服務外包企業通常是先實施編碼、測試等勞動密集型低端業務,然后在試圖向設計、需求分析等高端業務延伸(Peter Maskell etc.,2008),低端業務的實施使印度企業與美日歐的發包方企業有了一定程度的共同語言,當然這種共同語言主要是軟件開發技術上的專業用語(涉及到某個具體行業的專業知識則比較少),擁有共同語言是項目組成員良好溝通的基礎,是SECI模型的先提條件。在開展創新事件時,擁有抽象設計能力的個體(可能由發包方企業派出,也可能是接包方企業自己培養或歸國的留學生等)通過潛移默化、外部明示、匯總合成和內部升華實現了項目組成員之間的知識共享和創造,在完成創新事件的同時,培養了高端人才、并且積累了在某一行業(比如金融行業)的某一領域(比如人力資源管理)的專業知識和軟件抽象設計能力。
可以說,創新事件、高端人才和知識創造的SECI模型是印度接包企業獲得軟件創新能力的必備條件。這其中,創新項目是載體,高端人才是關鍵、SECI模型是保證。
當然,單個的創新事件很難使印度的接包方企業獲得全面的能力提升,為了在多行業的多領域獲得軟件開發的創新能力,接包方企業還需要更多的項目和更為復雜的知識管理能力。