關于豐田的精益開發,華為也在内部學習和發起過,而且正在大規模推廣的時候,“豐田”出了“刹車門”事件, 豐田汽車公司因為“刹車門”事件,宣布在全世界回收910餘萬輛汽車。910萬輛汽車對于豐田公司來說,意味着什麼?意味着這一家公司一年生産的汽車全部重新回爐還不夠。且不說,這麼多汽車的回收與修理需要支出多少龐大的費用?其實最糟糕的,無疑是“世界最高品質”的豐田車在全世界的威信掃地。于是,後來“精益開發”在華為并沒有大規模的推廣和學習。如同,溫州動車撞車之後,華為的高鐵的安全計算機項目也就慢慢地消失了。
關于精益開發還有個故事:Hua為 某大領導,跟硬件部說,你們怎麼進度這麼慢?畫個PCB怎麼還要30天?你們不是搞精益開發了麼?不是搞硬件敏捷麼?不是可以快速交付了麼?你們可以安排30個互連工程師(PCB Layout工程師),一天不就搞定了?不管什麼管理方法,我們都需要充分理解,并且要與實際的客觀規律相結合,否則就要鬧笑話了。
這是錯誤理解精益開發,把精益生産與精益開發,混同的笑話。
豐田是一家非常偉大的公司,精益開發也是非常偉大的管理方法。值得我們去學習。
正文:
英雄所見略同(IPD與精益)——這是我讀完豐田精益産品開發體系十三個原則後想到的第一句話。不能說每一條原則都是和華為IPD管理體系一緻,但是可以說,大部分的思想都是一緻的。成功總有相似之處啊。
對于精益産品開發體系也剛在學習之中,所以下面的解讀僅僅是個人粗淺看法,歡迎大家一起探讨,更歡迎了解精益産品開發的高手來指點江山。
上圖為精益産品開發體系統模式,13個原則就是圍繞“流程”“高技能員工”“工具與技術”三個子模塊提出的。
今天我來給大家把精益開發的“流程子模塊”與“IPD”流程做一個對比。
精益開發的“流程”子模塊,原則1到原則4。
原則1:确立由消費者定義的價值,把增值活動與浪費區别開來
IPD流程體系中非常重要的一個組成部分就是需求管理流程。它定義了整個需求管理的過程,包括了需求的收集、分析、分發、實現、驗證,哪一條需求是怎麼來的,怎麼實現,驗證的結果是什麼,都有清晰,可追溯的痕迹。
工程師容易犯的錯誤是什麼?老子技術天下第一,但是你的技術再牛叉,你開發出來的東西不是客戶需要的東西,有什麼意義呢?所以一些産品開發的源動力,都應該來源于客戶需求。
要真正做到“以客戶為中心”也不容易。很多企業都喊着這個口号,但是實際做到的又有幾家?大家可以盤點一下自己公司的産品,是不是所有産品的開發都是以客戶需求驅動的?對于客戶的需求,是簡單地拿來就用,還是經過理解和澄清?有沒有主動幫助客戶挖掘深層次的需求?公司内部的所有部門,都是圍繞“實現客戶需求”在轉嗎?整個開發的過程中,有沒有需求跟蹤?
何為浪費?所有跟客戶需求無關的是浪費,過度設計也是浪費。HW有個例子,某個地方發生大地震,别人家的基站都倒了,華為的基站沒倒,本來工程師們還在得瑟,結果老闆發火了,該倒的時候不倒,這也是浪費,這是質量成本的浪費!
不過請你們不要教條,客戶層面看不見的基礎功能的實現,那不叫浪費。修房子不打地基,能修好嗎?但是修30層高的房子,打100層的地基,就是浪費。
在華為的大隊培訓時(入職培訓),一位培訓老師講了一個産品設計的例子:“如果一個客戶吃牛肉總是卡牙,市面上剔牙的牙簽都不好用,提出需要一種質量上乘,高端的牙簽,應該如何設計一款好的産品俘獲客戶的心?”,所有在設計牙簽的同學都答錯了。
真正的答案是:研發一款不卡牙的牛肉。 這就是挖掘客戶的潛在需求,挖掘需求背後的真實需求。
研發的人,都有一些技術情節。都想做出自己内心認為完美的産品,但往往在研發産品的過程中,忽略客戶真正的需求。所以對于每位研發人員來說,樹立一個正确的産品觀尤為重要。特别是,之前華為做運營商業務和企業業務,設計者往往不是使用者,體會不到使用者的訴求和内心的痛苦。并且商務策略和客戶關系比客戶體驗可能在某種程度上比客戶體驗更重要。
銷售人員緊盯客戶需求,然後賦予一線銷售人員推動研發的權利和渠道。打通客戶推動研發實現需求的通道。
原則2:在産品開發流程初期徹底分析各種可選方案,因為此時設計改變的空間最大
以硬件為例,華為的開發流程一般是這幾個階段:需求分析,概要設計,詳細設計,原理圖設計,PCB設計,調測與測試。整個開發的過程,前期的分析占了一半以上的時間,就是為了在開發前期進行充分的分析,避免前期的工作不充分,導緻後期的返工重來。
總有人喜歡拿産品開發周期太短,當作不好好做設計方案、不寫過程文檔的借口。真的是這樣嗎?難道畫原理圖就真的隻是在“畫”原理圖,不需要思考嗎?芯片與芯片之間的管腳應該怎樣連接,芯片的外圍電路應該怎樣設計,需要調整阻值、容值的地方該怎樣調整,這些難道不需要好好分析之後才能出結果嗎?分析的過程是什麼?就是寫技術方案的過程。别覺得寫文檔是負擔,這是在幫你思考!
再說回進度和成本的問題。首先是進度,我認為産品真正能夠穩定量産的時候,才算開發周期結束,而且在整個開發周期内,質量問題是處于收斂狀态的。千萬别說産品都已經量産都已經發貨給客戶了,還不斷爆問題,還需要修改設計。如果你的産品是這個情況,我隻能說産品的開發質量不及格。在這樣的狀态下,光追求快又有什麼用?再從成本的角度看,到底是開發初期進行充分的分析讨論,把問題提早暴露出來耗費的成本少還是等到調試的時候發現一堆問題來改闆成本少?
有句話叫“出來混總是要還的”。需求階段不分析清楚需求,方案設計階段不好好做各種分析,到了調試的階段,通通要還回來,而且是加倍的還。
原則3:建立均衡的産品開發流程
“盡管在某個項目中可能存在特殊或特有的設計問題,但是對于不同的項目來說,應該采取的步驟以及順序基本上是相似的”這是原話。
從HW的角度來看,雖然後面分成了3大BG,開發流程也各有區别,但實際上除了終端産品确實比較特殊,有自己的一套開發流程外,其他兩個BG的N個産品線,基本上還是遵循的同一套開發流程。有了共同語言,才有對話的基礎,才能保證基本一緻的輸出,才能保證産品的成功。産品的成功不依賴于某個人,不因為人員的流程而産生巨大的波動,這就是流程的價值。
那麼怎樣對待開發過程中的缺點呢?這涉及到兩個層次的問題,一個是流程的适配,一個是開發項目的質量策劃活動。
流程的适配:當公司級流程發布以後,産品線會根據産品線的具體情況對于新發布的公司級流程做适配,看看這個版本變更的内容在産品線怎麼落地,是全部推行,還是适配推行,還是不推行,這屬于流程适配。同樣,要對流程文檔模闆進行适配。
項目的質量策劃:在項目初期進行,識别人與組織要求的差距,識别組織與流程匹配的差距,制定知識管理計劃,進行團隊陣型設計。其中,識别組織與流程匹配的差距,就包括項目開發過程的流程适配,在這個項目開發的過程中,要執行哪些流程活動,不執行哪裡流程活動,理由是什麼,都要在質量策劃活動中明确,在開發的過程中尊重執行。
聽過很多企業或者個人講流程無用論,根本不是流程無用,而且沒有把流程用起來!難道你認為畫在紙上的流程圖,寫在文檔裡的流程說明文件,就算是流程圖了嗎?如果沒有理解,沒有執行,那算什麼流程,那就是一紙空文。不但要制定流程,還要适配流程,要推行流程,要優化流程,這樣的流程才是能指導業務的流程。
産品硬件項目的開發,首先是要明确硬件總體需求情況,如CPU處理能力、存儲容量及速度,I/O端口的分配、接口要求、電平要求、特殊電路(厚膜等)要求等等。其次,根據需求分析制定硬件總體方案,尋求關鍵器件及其技術資料、技術途徑、技術支持,要比較充分地考慮技術可能性、可靠性以及成本控制,并對開發調試工具提出明确的要求,關鍵器件索取樣品。第三,總體方案确定且評審通過後,撰寫硬件和單闆軟件的詳細設計,包括繪制硬件原理圖、單闆軟件功能框圖及編碼、PCB布線,同時完成開發物料清單、新器件編碼申請、物料申領等工作。第四,PCB裸闆回闆及物料采購到貨後由焊工焊好1~2塊單闆,作單闆調試,對原理設計中的各功能進行調測,必要時修改原理圖并作記錄。第五,軟硬件系統聯調,一般的單闆需硬件人員、單闆軟件人員的配合,特殊的單闆(如主機闆)需比較大型軟件的開發,參與聯調的軟件人員更多。一般地,經過單闆調試後在原理及PCB布線方面有些調整,需經過多次投闆疊代測試。第六,内部驗收及轉中試,硬件項目完成開發過程。
硬件開發的規範化上節硬件開發的基本過程應遵循硬件開發流程規範文件執行,不僅如此,硬件開發涉及到技術的應用、器件的選擇等,必須遵照相應的規範化措施才能達到質量保障的要求。這主要表現在,技術的采用要經過項目組的評審,器件和廠家的選擇要參照物料認證的相關要求和規範,開發過程完成相應的規定文檔,另外,常用的硬件電路要采用通用的标準設計。
原則4:利用嚴格的标準化降低變異,并建立高度柔性和可預測的産出。
豐田的三類标準化:1.設計标準化;2.流程标準化;3.工程技能集标準化(指跨工程團隊和技術團隊的技能與能力的标準化,換句話說,就是按照一套固定的标準培養人員的能力)
我認為設計标準化包括兩方面的含義,一個是共用模塊(CBB),一個是設計準則。使用CBB的好處是什麼呢?我認為通俗點說就是前人栽樹後人乘涼。前面的工程師把方案設計好了,原理圖畫好了,器件封裝建好了,電路也調試過了,再共享出來,後面需要用到的工程師直接調用,何樂而不為?既降低設計風險和成本,也有利于器件的歸一化。
設計準則,在華為是一系列的指導書和checklist,讓工程師在設計産品的過程中,有一條線在牽引,是設計出來的産品能夠達成目标,不會出現太大的偏差。規範、指導書、checklist可以規避很多已知風險,是基于前人的經驗總結和歸納的粗大标準化成果。
《硬十,無源器件》的VIP套裝贈送資料包含大量規範和checklist。VIP用戶可以在線預覽和下載以下内容。
原則5:創建自始至終領導整個項目開發的總工程師制度
大部分的公司都有多個負責産品開發中不同模塊的小組,但是沒有一個部門或人能告知産品開發的進展精确狀況。豐田的總工程師就是這樣一個人,他能告訴你項目的精确狀态。更重要的是他是一位領導者和技術集成者,對産品項目有關的重大問題有最終決策權,他既能代表客戶的心聲,也對産品的成敗負最終責任,不同于一般公司的項目經理,後者僅僅是控制項目的人事和工期而已。
原則6:建立适當的組織結構,找出功能部門内技術專長與跨功能整合之間的平衡。
豐田在根本上來說是以功能來組織運作的,也強調各部門的專業技能,并以此為基礎進行等級劃分,但它将傳統的部門間的“壁壘”通過總工程師、模塊開發以及“作戰室研讨”等方式來加以打破,并能以此将目光聚焦于産品開發項目。
原則7:為所有工程師構建“尖塔”型的知識結構。
很多公司都喜歡技術明星,但并不喜歡自己培養,它們希望工程師能拓展知識面,而不是更深入地鑽研;它們比較喜歡培養MBA,而不是更多的專業技術人才。
豐田采取嚴格的标準招聘人員,然後為其設計一條職業發展道路,專注于某個領域而獲得極高的技術水平,專注于學習關鍵技能以支持技術卓越。
華為的硬件類技術任職資格标準
級别名稱:硬件類一級工程師
要點:有一定的子模塊(包括:單元電路、邏輯、單闆底層軟件、單闆硬件等)開發/測試設計實踐經驗,能夠獨立編碼、測試或設計電路等。承擔華為某一産品領域或特定産品技術領域中一般子模塊的詳細設計、實現、驗證、及文檔編寫、改進和維護等工作,是子模塊功能的直接實現者、操作者或測試驗證者;或者從事網上問題處理/分析/定位、網上設備巡檢、開局支持、入網測試、網上疑難問題攻關等維護工作。在二級及以上工程師的指導下按計劃要求完成任務并保證其質量。
級别名稱:硬件類二級工程師
要點:有較多的子模塊(包括:單闆上複雜的模塊單元、邏輯單元、單闆底層軟件、單闆和産品功能模塊等)開發/測試設計實踐經驗,進行子模塊集成/測試,獨立編程、測試或設計電路等。承擔華為某一産品領域或特定産品技術領域中的模塊的詳細設計、實現、驗證、BOM及文檔編寫、改進和維護等工作。在三級及以上工程師的指導下解決模塊開發/測試一般難題或網上問題。按時完成指标、計劃并保證質量。具有培養、輔導新員工,擔任新員工思想導師的能力。
級别名稱:硬件類三級工程師
要點:有較多模塊開發/測試實踐經驗,進行模塊集成/測試及較複雜模塊的設計、實施或測試。可獨立主持小型項目的設計、實施或測試等任務;是設計或測試某一環節的技術主力,可獨擋一面。承擔華為某一産品或特定産品技術領域複雜模塊的設計/測試、改進和維護,對産品質量、成本、進度和客戶滿意度及産品的可測性、可生産性、可維護性或關鍵技術解決有一定影響;或者有豐富的網上疑難問題定位/解決實踐經驗,可獨立主持網上設備巡檢、開局支持、入網測試、網上疑難問題攻關等任務,是網上設備維護的技術主力,并承擔華為某一産品領域或特定産品領域中的網上設備維護、網上運行數據統計分析、維護資料開發、産品系統優化等工作,對網上設備運行穩定性和客戶滿意度以及産品的可靠性、可維護性或産品的關鍵改進點有一定影響。可以指導和培養低級别工程師,可擔負小型項目領導職責或作為中型項目的骨幹力量或維護小組領導職責。
級别名稱:硬件類四級工程師
要點:有較深入的産品設計/測試、改進和維護經驗,或核心技術的開發/測試實踐經驗,并注意總結、推廣和重複應用,可完成子系統設計、集成或測試。具有組織産品級疑難問題的定位解決,提出産品優化意見及需求的能力。能夠在系統上較深入地把握某一産品的核心技術和相關工程技術知識,引進或掌握本領域的關鍵套片(器件)、新标準(專利、規範)、新平台、新工具、新方法,在末産品上能夠成功運用。負責設計2個以上硬件系統方案(包括單闆、ASIC、FPGA、單闆軟件),在産品運用上不出現失誤,參與設計的産品經實踐證明是成熟穩定的。對産品的質量、成本、計劃、進度和客戶滿意度以及産品的可靠性、可測試性、可生産性、可維護性或關鍵技術解決有重要影響。可以知道和培養三級以内工程師,領導中型項目或作為大型項目的骨幹力量。
級别名稱:硬件類五級工程師
要點:具有深入的産品設計/測試、改進和維護經驗,或核心技術的開發/測試實踐經驗,可主持系統分析、設計、集成或測試工作,負責設計的産品系列硬件系統方案經實踐證明是成熟穩定的,産品在市場上運行穩定,改設計提升了本産品目标市場競争力,或在産品成功中起主要作用。公司内本領域帶頭人,對該領域的知識和經驗十分豐富完備,及時了解市場、關鍵競争對手、商業/技術環境的情況,按照華為産品規劃和戰略,參與制定某領域的路标規劃,确保本領域技術發展方向的正确性和可持續性,保障項目技術上最合理,并從技術角度确保項目按時保質完成。引進或掌握本領域的關鍵套片(器件)、新标準(專利、規範)、新平台、新工具、新方法,在多個産品上能成功應用或提升産品核心競争力。參與公司流程規範的建設和産品/技術/流程的優化改進。對四級及以下技術人員進行指導和培養。對産品質量、成本、計劃、進度和客戶滿意度以及可靠性、可生産性、可維護性有決定性的影響。
級别名稱:ASIC類六級工程師
要點:根據公司總體發展戰略,制定本領域技術發展戰略,引領本領域的技術方向,确保技術方向的正确性和可持續發展性;能夠主持設計本産品領域戰略産品的硬件系統方案,提出本領域的關鍵套片(器件)、新标準(專利、規範)、新平台、新工具、新方法,并在多個産品上能夠成功應用或提升某産品的核心競争力,形成行業技術優勢,在目标市場具有綜合市場競争力。通過對本領域大型/複雜項目的框架定義、需求規格定義、系統設計、評審、批準等活動,從技術上支撐本領域發展戰略的制定與實施,承擔主要技術責任,保障項目技術上的合理性。具備專業領域内豐富的産品技術創新、優化的經曆,在公司本領域内被認為是權威。參與公司流程規範的建設和産品/技術/流程的優化改進。具有強烈的客戶意識、質量意識、成本意識和商品觀念,對管理者和同事提供指導和方向的指引,能做出對産品的成本、計劃、進度和客戶滿意度有重大影響的決策并為實踐證明。
資格标準
硬件類技術任職資格标準由工作經驗、必備知識、技能标準、工作績效、行為标準等五個部分組成。
一 工作經驗
資格等級 |
工作經驗 |
一級 |
1年以上硬件類工作經驗;熟悉硬件類基礎知識,具備獨立處理一般硬件類技術問題的經驗。具備獨立完成單闆硬件詳細設計、原理圖設計的經驗。或者具備基本的網上設備維護經驗。 |
二級 |
獲得硬件或相關技術以及任職資格後,繼續從事硬件類工作1年以上。具備獨立進行硬件類開發的經驗,具備獨立完成單闆總體設計到單元測試的經驗,具備産品工程領域的基本知識。或者具備3個月以上網上設備維護經驗以及獨立解決網上一般問題的能力。 |
三級 |
獲得硬件或相關技術二級資格後,繼續從事硬件類工作2年以上。巨額被分析單闆需求并完成單闆全過程開發的經驗,具備産品工程領域較全面的知識,具備複雜單闆或簡單産品硬件開發設計的經驗,具備解決研發、生産現場硬件技術問題的經驗,具備知道相關設計人員進行硬件開發的經驗;具備提出流程優化建議的能力和經驗。或者具備網上疑難問題定位處理、組織網上問題攻關、網上設備巡檢/開局支持/入網測試,以及指導相關維護人員處理網上問題的經驗。 |
四級 |
獲得硬件或相關技術三級任職資格後,繼續從硬件類工作2年以上。具備産品硬件技術領域全面的知識,具備組織産品硬件開發設計或中等難度技術研究項目的經驗,具備解決産品開發過程中的重大技術問題的經驗,曾參與硬件類技術發展決策活動;具備1年以上的網上設備維護經驗;具備參與開發流程建設和優化的經驗。 |
五級 |
獲得硬件或相關技術四級任職則個後,繼續從事硬件類工作2年以上。具備産品硬件技術領域及系統領域全面的知識,具備解決産品開發過程中的重大技術難題的經驗,遇見企業未來産品某領域的硬件技術走向,具備組織跨産品的中等複雜項目開發經驗,具備開發公司内領先技術的經驗,享有技術專利;具備相關流程及技術規範标準的建設和優化經驗,是公司領域的技術帶頭人。 |
六級 |
獲得硬件或相關技術五級資格後,繼續從事硬件類工作2年以上。具備産品硬件技術領域、系統領域廣博精深的知識,具備解決産品開發過程的重大系統類、硬件技術難題的經驗,具備組織跨産品線的大型項目開發的經驗或者具備開發業界先進技術的經驗;在外部期刊雜志上發表論文;參與決策企業未來産品的技術走向,是公司硬件類技術的權威。 |
二 必備知識
(根據必備知識要求,确定上崗考試課程)
1、單闆硬件
必備知識 |
1級 |
2級 |
3級 |
4級 |
5級 |
6級 | |
流程規範方法論 |
硬件MINI培訓 |
√ | |||||
NPD基本知識 |
√ | ||||||
BOM知識 |
√ | ||||||
硬件測試與驗證 |
√ | ||||||
研發成本管理知識 |
√ | ||||||
系統工程導論 |
√ | ||||||
系統分析與設計方法 |
√ | ||||||
标準體系知識 |
√ | ||||||
集成和系統測試方法 |
√ | ||||||
基本技術知識 |
單元測試技術 |
√ | |||||
元器件基礎 |
√ | ||||||
CAD設計接口知識 |
√ | ||||||
邏輯可編程器件應用 |
√ | ||||||
工程設計基礎 |
√ | ||||||
器件應用與可靠性 |
√ | ||||||
信号完整性分析 |
√ | ||||||
單闆電源設計 |
√ | ||||||
通用處理器基礎 |
√ | ||||||
時鐘技術基礎 |
√ | ||||||
專項技術知識 |
EMC設計 |
√ | |||||
安規設計 |
√ | ||||||
熱設計 |
√ | ||||||
可測試性設計 |
√ | ||||||
可生産性設計 |
√ | ||||||
可靠性工程設計 |
√ | ||||||
可安裝性設計 |
√ | ||||||
可維護性設計 |
√ |
原則8:将供應商完全整合到産品開發體系中。
供應商在制造業中的地位越來越重要,比如汽車廠商的零件是有超過50%是供應商提供的。因此,如何管理、支持内部的産品制造工程,就應該以同樣的方法管理、支持供應商。豐田除了評估供應商的零件供應能力外,還評估其技術能力。在産品的前期,采購就會讓供應商參與進來,共同解決在開發中的問題。
華為采購組織結構——基于物料族的組織結構
華為采購部建立了物料專家團(Commodity Expert Groups,簡稱CEG),各CEG負責采購某一類/一族的物料滿足業務部門、地區市場的需要。每個CEG都是一個跨部門的團隊,通過統一的物料族策略、集中控制的供應商管理和合同管理提高采購效率。
按物料族進行采購運作的目的是在全球範圍内利用華為的采購杠杆。
主動的組織—— 早期介入産品開發和市場投标
CEG和技術和認證中心(Technology & Qualification Center,簡稱T&QC)在華為研發和供應商之間架起了溝通的橋梁,推動供應商早期參與産品設計來取得雙方的技術融合以及在成本、産品供應能力和功能方面的競争優勢。
工程采購部(Customer Solution Procurement,簡稱CSP)将和華為銷售和行銷一起積極地參與客戶标書的制作。參與市場投标将使采購部了解到客戶配套産品的需求,在訂單履行過程的早期充分了解華為向客戶做出的承諾以确保解決方案滿足客戶需求并能夠及時交付。
采購需求履行
生産采購和行政采購負責日常采購運作以及與供應商和内部客戶的溝通、及時處理采購請求和解決雙方的問題從而提高供應商的表現和内部客戶滿意度。同時華為也關注于不斷提高采購履行流程的自動化程度,讓采購執行人員有更多的機會積極地參與物料族采購策略的制定。
所以這個組織結構不是簡單的“采購”,而是供應商管理、物料管理!
采購能做的事情是有限的,執行采購動作和價格談判;
但是供應商管理的行為在項目早期就開始,則更多的主動權和談判砝碼。否則都是白談。
讓采購執行人員有更多的機會積極地參與到項目早期的物料族采購策略的制定。
下面是華為采購組織結構簡圖:
供應商選擇原則——
選擇最好的供應商
評定公平價值
供應商選擇流程
華為制定了完善的供應商選擇/公平價值判斷流程以确保華為選擇最符合華為利益的供應商,采購獲得最公平的價值,同時保證華為向所有供應商給予平等赢得華為生意的機會。該流程的基本原則是公平,公開和誠信,并由以下機制保證:
采購集中控制―― 采購是公司内部唯一授權向供應商作出資金承諾,獲得物品和/或服務的組織。除此以外的任何承諾都視為繞過行為,視為對公司政策的違背。
供應商選擇團隊―― 供應商選擇将由相關專家團主任組建團隊來進行,成員包括采購和内部客戶的代表。小組的使命是制定RFQ/RFP,确定能夠按照華為要求提供所需産品或服務的現有合格供應商名單。這個團隊管理供應商選擇流程,參與評估供應商的回複以及選擇供應商。
供應商反饋辦公室―― 如果供應商在與華為的交往中有任何不滿意的地方,有專門的幫助中心負責收集供應商的反饋和投訴。詳情請參見供應商反饋辦公室一節。
供應商績效評估
華為采購部制定了供應商評估流程,定期向供應商提供反饋。該流程包括相關專家團正式的績效評估。供應商的績效将從技術、質量、響應、交貨、成本和合同條款履行這幾個關鍵方面進行評估。評估流程的目的在于給雙方提供開放溝通的渠道,以提升彼此的關系。同時,華為鼓勵供應商反饋,站在客戶的角度他們如何評價華為。這些評估信息将用于改善彼此的業務關系,和改善華為内部的業務運作。
供應商認證
華為緻力于向所有潛在供應商提供合理、平等的機會,讓大家都能夠展示自己的能力。潛在供應商各種方式的垂詢都将轉給采購部門進行回複。
如果華為和供應商都有意開拓業務關系,華為采購部會要求潛在供應商完成調查問卷。在接到調查問卷并進行評估後,華為将知會供應商評估結果。如果華為有興趣和供應商進行合作,華為将啟動後續的認證步驟。後續認證可能需要和供應商面談,讨論供應商對調查問卷的回複。根據面談的結果,決定是否需要現場考察。然後可能需要進行樣品測試和小批量測試,确保供應商的産品滿足規格要求,産能滿足需求。認證的結果将知會供應商。在發生采購需求時,通過認證的供應商将作為侯選供應商進入供應商選擇流程。
華為的供應商認證流程
華為緻力于向所有潛在供應商提供合理、平等的機會,讓大家都能夠展示自己的能力。雖然執行的時候會有偏差,但是公司流程和績效評定會促使執行者讓相關的已經認證的合格供方參與。
潛在供應商各種方式的垂詢都将轉給采購部門進行回複。
如果華為和供應商都有意開拓業務關系,華為采購部會要求潛在供應商完成調查問卷。在接到調查問卷并進行評估後,華為将知會供應商評估結果。如果華為有興趣和供應商進行合作我們将啟動後續的認證步驟。
後續認證可能需要和供應商面談,讨論供應商對調查問卷的回複。根據面談的結果,決定是否需要現場考察。然後可能需要進行樣品測試和小批量測試,确保供應商的産品滿足規格要求,産能滿足需求。認證的結果将知會供應商。在發生采購需求時,通過認證的供應商将作為侯選供應商進入供應商選擇流程。
華為與供應商之間的溝通
華為相信,隻有良好的溝通才能培育出良好的業務關系。我們提供多樣化的溝通渠道,以便華為和供應商進行開放的對話和讨論。
單一接口
每個物料專家團内部都有供應商接口人,負責與供應商的接口和溝通,處理供應商與華為來往過程中可能碰到的任何問題和疑問。相應地,也要求供應商通過這一單一的接口與華為接觸。通過這一渠道,專家團會将所有可能影響到供應商業務的采購策略和計劃,傳達給供應商。
供應商反饋受理
華為設立供應商反饋渠道是為了受理所有與采購相關的問題,包括供應商針對華為員工或某部門的不公平行為和不道德行為的投訴等。
解讀《華為是怎樣對待供應商的》
原則9:公司内部的學習和持續改進。
學習和持續改進是精益産品開發體系中最強大的工具,也是豐田日常管理中的基礎工作。
原則10:形成追求卓越、銳意進取的企業文化。
企業文化是員工的工作方式,以及員工對工作和産品的看法。精益産品開發體系的核心是“現場現物”、多方案的思考方式、反思以及從客戶的角度來決定價值。
這些文化基因是推動精益産品開發體系的基礎,當然也是挑戰所在。
華為的相對考評
先解釋一下PBC是啥——個人績效承諾;Personal Business Commitment。本意是個人業務承諾,為了便于理解,華為稱之為個人績效承諾。
也就是在幹活前,員工你寫自己的半年或者一年要達成的目标:達标水平做成什麼樣,超水平發揮做成什麼樣。但是這些都是跟你自己的能力比,或者說會跟你往年的情況相比。
基本的目标是由主管分解下來的,然後出了基本目标之外,還需要寫一些自己想到的,要達成的目标。(這就是傑克韋爾奇說的,付出超越職責的努力)
但是矛盾點在哪呢?這個目标達成,不代表你自己的考評結果就好。
因為績效考評結果,不是跟你個人的承諾相比,是跟同事相比。
PBC是提醒你要做好自己,但是做好自己,不代表你能跑赢同事;
也就是說,你跑得再快,提高再多,如果仍然跑不過老虎的話,一樣會被吃掉。
那麼這種你追我趕的白色恐怖,帶動了整個團隊激發出更多的個人潛能。
那麼,問題來了:PBC還有什麼用?個人意見:對管理者有用,但是員工很快發現遊戲規則之後,就都不重視了。
有用點在于:第一目标一緻,就算你考評後仍然排名靠後,但是也要跟團隊目标保持一緻,貢獻應有的力量。第二自己制定目标的時候,就可以全團隊拉通進行對比。
大家不重視的點在于:隻是個副本任務,不是遊戲的主線任務了,那麼主線任務就是相對考評。(PBC裡面的技能提升更是小副本,發展到後來:都寫錯了,都沒人知道。。。)
相對考評帶來的問題:
問題一、相同等級的團隊之間、員工之間的矛盾會相對緊張。人人大比武,各個争上遊,一些品質不是那麼高尚的人,在領導面前要打壓同事。
問題二、以領導為中心;因為做績效排名的是誰,誰就是我的boss,誰就決定我的加薪、獎金、配股、任職資格、升級等等等等。
任正非曾經說過:“當你面對領導的時候,你屁股就對着客戶;當你面對客戶的時候,屁股就對着領導”。那麼華為不是“以客戶為中心”變成了“以領導為中心”了麼?
我曾經在一次主管的培訓過程中,問了華為杭研所的前所長這個問題,他說:“你考慮一個問題,領導在某種程度上,是不是客戶?”
高,實在是高——矛盾被調和了。正能量的看待這個問題:領導更懂客戶,聽領導的沒錯;研發的工作是被分解了,領導看到的問題更具全局觀,以領導為中心,團隊更具執行力。
原則11:讓技術去适應人員和流程。
很多公司希望借用技術的殺手锏來提升産品開發的效能,而忽略了技術可能給人員或流程的影響。豐田認為技術很容易被人複制,而應該讓技術去适合已經優化的流程,以及具有高超技能的人員。
原則12:運用簡單、可視化的溝通來理順你的組織。
很多問題之所以沒有被解決,是因為我們根本就不知道它的存在。豐田利用“方針管理”來設定工作的目标,将公司的策略目标層層展開,跟進落實。這種方法同樣也用在産品開發上面,它将整車的設計目标細化為性能、重量、成本、安全等特定目标的設定。這種目标導向的設計管理,容易讓設計團隊看到問題。
在此過程中,豐田用一種簡單的目視化工具來進行溝通,即産品開發中的問題報告限制在一張A3紙以内,也就是所謂的A3報告。而非有的公司報告都是厚厚的一疊,這樣的報告很難有人會去仔細閱讀。
字不如表、表不如圖,是華為寫PPT給領導彙報很流行的一句話。
原則13:運用強大的工具進行标準化和學習。
标準化是一切改善的基本,設計也不例外。根據這個原則,學習是一個項目接一個項目進行的,豐田有強大的工具來支持學習過程的标準化,比如設計審查檢查表就是一個這樣的工具,豐田要求每個工程師必須就自己的工作準備詳細的設計審查檢查表,并不斷的更新,就其中的問題展開研讨,這樣一來,設計的經驗和技術能代代傳承下去,設計過程有血有肉,而非隻是一張張冰冷的圖紙。
更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!