研發流程(四)(轉)
依流程提供的資訊來區分
流程圖上除了各種代表作業的符號之外,還會有文字敘述提供實為詳細的資訊,由於討論不同的管理議題時,分析作業活動所需的資訊也不同,所以我們將流程圖依分析的角度區分為時間觀、單位觀、方位觀、人員觀、系統介面觀、控制觀等六種觀點:
1 時間觀
*提供工作執行的頻率、件數、所需時間等資訊。
*用途:分析工作所需的時間、規劃預計時程、執行進度控制,並檢驗是否能以工人調配的方式縮短流程的時程。
*管理議題:流程效率的改進,專案時程及進度控制。
2 單位觀
*顯示每個部門在流程中負責的工作事項以及彼此間往來互動的關係,與前面提過的跨功能作業互動圖相同。
*用途:確認各部門的職掌及工作範圍,劃分各部門的權利與義務,建立部門間工作協調的機制。
*管理議題:組織結構。
3 方位觀
*顯示工作單位,裝置的相對位置與地理關係,就是前面提過的平面分析圖。
*用途:工作的傳遞是否與辦公空間的配置相符,對辦公空間作最有效的運用。
管理議題:流程改進、成本管理。
4 人員觀
*顯示每個人員在流程中負責的工作事項以及彼此間往來互動的關係。
*用途:分析人員實際執行的工作,是否與其責任相符,同時評估人員處理工作的許可權是否適當並使用系統的介面。
*管理議題:人力資源管理、許可權控制、系統功能介面設計。
5 系統介面觀
*描述流程中各項工作須對系統輸入/輸出資料的專案。
*用途:分析系統資料輸入與輸出的位置是否適當。
*管理議題:資料輸入與輸出的正確性、系統功能介面設計。
6 控制觀
*描述流程控制點的位置以及控制措施的執行方式,與前面提過的控制點流程圖相同。
研發流程概況
研發流程的特性
在企業傳統作業流程八在迴圈的分類中,研發迴圈應該是最複雜,最難以管理的一個,臺灣製造業一向以生產的效率聞名,然而在產品開發方面的成績並不理想,如果從個別研發人員的產能來比較,可能比不上美國或日本,生產線由人員及機器裝置構成,而且材料及零件依生產步驟逐次傳遞,屬於“看得見的作業流程”,投入資源與產出成果的數量都很容易比較及衡量,基本上公司高層主管只要在產能滿載時到生產線逛一逛,就能發現那裡是作業的瓶頸,而且製造流程很容易藉由自動化改善效能。
研發作業是以人員為主體,所有的成果都是研發人員智慧的結晶,由於屬知識性、創造性的活動,比較難像其他作業一樣可以標準化,因而管理上的難度比較大,我們可以從以下幾個層面來分析研發流程的複雜性:
1 專案導向
研發作業活動,不論是產品設計代工,或是自行開發新產品,都是屬於專案導向的工作,必須針對每個專案重新確認目標、範圍、時程、展開工作計劃、分配資源、而且這些專案都是預估值,實際執行的結果通常與當初預期不一致,不像其他作業工作的週期比較固定,以財會為例,每個月底一定會有結帳作業,而且執行步驟及所需的時間也很固定,比較不會出現誤差,研發作業實際執行的情形不如預期而發生變動或調整,很容易對其他專案造成影響,而且這樣的效還會逐步擴散甚至互動影響。
2 跨部門支援作業及溝通協調
新開發的產品不但要滿足客戶對功能的需注,成本還要夠低,因而研發人員需要許多其他部門的協助,例如業管部門在專案開始之前必須提供客戶的需求資料,並在客戶需求變更時立即通知研發單位,倉儲部門必須提醒研發人員還有哪些多餘的零件庫存,高法先消耗掉,如果新產品必須用到新的零件,必須由資材部門協助完成新料件確認的工作,如此新料件才能在生產線正式使用,採購部門必須協助研發人員製作樣品並高定整個製造過程,程式部門必須協助研發人員開發輸出入介面等程式。
以上眾多的支援作業,會在整個研發流程中的不同時點,由各部門重複提供支援協助,然則由於支援作業的掌控通常不在研發部門手上,跨部門協調溝通比較費時,很容易因為支援作業未如期執行,而影研發作業完成的時間及質量。
3 權責難在明確
傳統上企業是將功能類似的職責,合併成一個部門,然後指派一名主管負責該部門業務的推動,大部分的人員也只有一個老闆,相比這下研發作業就複雜很多,通常研發部門也是會依各項專業技術劃分功能單位,以電子業為例,至少都有線路設計、機構設計、元件配置設計,輸出入軟體設計等單位,然而研發的工作為專案導向,各功能單位的人員都會分派到不同的專案上,由專案經理掌控工作狀況及進度,導致研發人員可能必須面對2個經上的老闆,變成矩陣式組織,此時很容易出現人員指揮與績效考核的衝突。
如果人員的績準備是單位主管負責考評,那麼專案經理就沒有權利要求人員達面專案目標,此外主管通常須負責人力資源的管理與排程,可以因親的專案出現,或是其他專案必須趕進度,要求抽調其他專案的人員,專案經理通常無法拒絕單位主管的要求,人員的調動不但進接影響到專案的進度,也容易因為權責無法明確而導致研發質量的降低,研發作業所面臨人力資源的排程及指揮的問題,是其他作業不會遇到的。
4 檔案資料滿天飛
研發作業的核心工作在於產生設計圖等檔案,一個產品的設計往往須由種專業技術人員共同完成,以電子業我例,其中包含硬體機構的設計,線路的設計,元件擺放位置的設計,這些設計專案不但有前後順序的關係,而且會互相影響,例如線路圖變更設計,就必須將變更的結果交給其他研發人員作機構與元件配置的修改,因而設計圖及規格資料(還有個別零件圖與規格資料)會在各專案成員之間不斷傳來傳去,甚至還必須送給客戶或供貨商等其他單位,在多個專案同步進行的情況下,檔案資料傳遞路徑變得十分複雜,造成管理上的問題。
5 迴圈性的測試與設計變更作業
為了確保新產品的質量,通常在開發過程中會製造樣本並進行測試,如果發現問題,就必須執行設計變更問題排除,並於修改樣本之後南重新執行測試工作,此項作業將不斷迴圈,一直到產品質量達到標準為止。
部分產業產品測試的專案繁多,以電子業為例,主機板的開發必須在一週的時間之內完成四千項測試工作,在多個專案同時進行的情況下,測試作業的排程本身就是個挑戰。其次由於測試及設計變更作業不斷重複,而且每次設計變更需要修改的部分以及負責修改的人員可能都不同,一旦重複次數太多,研發人員可能會搞不清楚到底是執行第幾次的設計變更,導致設計檔案版本的混亂,造成產品一再出現錯誤,而廷誤單交付的時程。
6 外部溝通
收於科技的快速發展,新的產品技術及元件不斷出現,消費者的需求也不斷變化,為了確保開發出來的產品能滿足客戶的需求,又能達到最佳質量及最低成本的目標,研發人員必須不斷與上游技術廠商聯絡,以掌握最新的產品技術及元件,同時必須與客戶保持聯絡,以便在客戶改變功能需求時,可以隨時調整,另一個方面也須與供貨商密切溝通,以確保新元件的來源沒有問題。這些溝通與聯絡的工作對研發作業而言不但是常態,也是流程上的不確定因素,而且其結果對於產品開發的進度有直接的影響。
7 知識性工作
另一個研發作業的特色,是其為知識性的工作,而非操作性的工作,其他部門的工作通常比較偏向操作層面,以財會流程為例,前端的輸入訂單、中間的過財動作以及後端的報表編制,主要是執行會計例行性的程式,不但沒有固定的步驟,而且作業時間比較容易估計,相比之下研發工作就屬於知識性、創造性的,以主機板為例,某一個元件原本為長方形,而新的元件為圓形,如何將新的元件加入並調整配置方式,而不影響原本主機板的大小,又可兼顧電源、散熱,電磁波等質量要求,就元件配置的設計而言可能是從未遇過的問題,此問題的解決步驟可能與之前不同,而所需的時間也比較難以掌握。
[@more@]
流程圖上除了各種代表作業的符號之外,還會有文字敘述提供實為詳細的資訊,由於討論不同的管理議題時,分析作業活動所需的資訊也不同,所以我們將流程圖依分析的角度區分為時間觀、單位觀、方位觀、人員觀、系統介面觀、控制觀等六種觀點:
1 時間觀
*提供工作執行的頻率、件數、所需時間等資訊。
*用途:分析工作所需的時間、規劃預計時程、執行進度控制,並檢驗是否能以工人調配的方式縮短流程的時程。
*管理議題:流程效率的改進,專案時程及進度控制。
2 單位觀
*顯示每個部門在流程中負責的工作事項以及彼此間往來互動的關係,與前面提過的跨功能作業互動圖相同。
*用途:確認各部門的職掌及工作範圍,劃分各部門的權利與義務,建立部門間工作協調的機制。
*管理議題:組織結構。
3 方位觀
*顯示工作單位,裝置的相對位置與地理關係,就是前面提過的平面分析圖。
*用途:工作的傳遞是否與辦公空間的配置相符,對辦公空間作最有效的運用。
管理議題:流程改進、成本管理。
4 人員觀
*顯示每個人員在流程中負責的工作事項以及彼此間往來互動的關係。
*用途:分析人員實際執行的工作,是否與其責任相符,同時評估人員處理工作的許可權是否適當並使用系統的介面。
*管理議題:人力資源管理、許可權控制、系統功能介面設計。
5 系統介面觀
*描述流程中各項工作須對系統輸入/輸出資料的專案。
*用途:分析系統資料輸入與輸出的位置是否適當。
*管理議題:資料輸入與輸出的正確性、系統功能介面設計。
6 控制觀
*描述流程控制點的位置以及控制措施的執行方式,與前面提過的控制點流程圖相同。
研發流程概況
研發流程的特性
在企業傳統作業流程八在迴圈的分類中,研發迴圈應該是最複雜,最難以管理的一個,臺灣製造業一向以生產的效率聞名,然而在產品開發方面的成績並不理想,如果從個別研發人員的產能來比較,可能比不上美國或日本,生產線由人員及機器裝置構成,而且材料及零件依生產步驟逐次傳遞,屬於“看得見的作業流程”,投入資源與產出成果的數量都很容易比較及衡量,基本上公司高層主管只要在產能滿載時到生產線逛一逛,就能發現那裡是作業的瓶頸,而且製造流程很容易藉由自動化改善效能。
研發作業是以人員為主體,所有的成果都是研發人員智慧的結晶,由於屬知識性、創造性的活動,比較難像其他作業一樣可以標準化,因而管理上的難度比較大,我們可以從以下幾個層面來分析研發流程的複雜性:
1 專案導向
研發作業活動,不論是產品設計代工,或是自行開發新產品,都是屬於專案導向的工作,必須針對每個專案重新確認目標、範圍、時程、展開工作計劃、分配資源、而且這些專案都是預估值,實際執行的結果通常與當初預期不一致,不像其他作業工作的週期比較固定,以財會為例,每個月底一定會有結帳作業,而且執行步驟及所需的時間也很固定,比較不會出現誤差,研發作業實際執行的情形不如預期而發生變動或調整,很容易對其他專案造成影響,而且這樣的效還會逐步擴散甚至互動影響。
2 跨部門支援作業及溝通協調
新開發的產品不但要滿足客戶對功能的需注,成本還要夠低,因而研發人員需要許多其他部門的協助,例如業管部門在專案開始之前必須提供客戶的需求資料,並在客戶需求變更時立即通知研發單位,倉儲部門必須提醒研發人員還有哪些多餘的零件庫存,高法先消耗掉,如果新產品必須用到新的零件,必須由資材部門協助完成新料件確認的工作,如此新料件才能在生產線正式使用,採購部門必須協助研發人員製作樣品並高定整個製造過程,程式部門必須協助研發人員開發輸出入介面等程式。
以上眾多的支援作業,會在整個研發流程中的不同時點,由各部門重複提供支援協助,然則由於支援作業的掌控通常不在研發部門手上,跨部門協調溝通比較費時,很容易因為支援作業未如期執行,而影研發作業完成的時間及質量。
3 權責難在明確
傳統上企業是將功能類似的職責,合併成一個部門,然後指派一名主管負責該部門業務的推動,大部分的人員也只有一個老闆,相比這下研發作業就複雜很多,通常研發部門也是會依各項專業技術劃分功能單位,以電子業為例,至少都有線路設計、機構設計、元件配置設計,輸出入軟體設計等單位,然而研發的工作為專案導向,各功能單位的人員都會分派到不同的專案上,由專案經理掌控工作狀況及進度,導致研發人員可能必須面對2個經上的老闆,變成矩陣式組織,此時很容易出現人員指揮與績效考核的衝突。
如果人員的績準備是單位主管負責考評,那麼專案經理就沒有權利要求人員達面專案目標,此外主管通常須負責人力資源的管理與排程,可以因親的專案出現,或是其他專案必須趕進度,要求抽調其他專案的人員,專案經理通常無法拒絕單位主管的要求,人員的調動不但進接影響到專案的進度,也容易因為權責無法明確而導致研發質量的降低,研發作業所面臨人力資源的排程及指揮的問題,是其他作業不會遇到的。
4 檔案資料滿天飛
研發作業的核心工作在於產生設計圖等檔案,一個產品的設計往往須由種專業技術人員共同完成,以電子業我例,其中包含硬體機構的設計,線路的設計,元件擺放位置的設計,這些設計專案不但有前後順序的關係,而且會互相影響,例如線路圖變更設計,就必須將變更的結果交給其他研發人員作機構與元件配置的修改,因而設計圖及規格資料(還有個別零件圖與規格資料)會在各專案成員之間不斷傳來傳去,甚至還必須送給客戶或供貨商等其他單位,在多個專案同步進行的情況下,檔案資料傳遞路徑變得十分複雜,造成管理上的問題。
5 迴圈性的測試與設計變更作業
為了確保新產品的質量,通常在開發過程中會製造樣本並進行測試,如果發現問題,就必須執行設計變更問題排除,並於修改樣本之後南重新執行測試工作,此項作業將不斷迴圈,一直到產品質量達到標準為止。
部分產業產品測試的專案繁多,以電子業為例,主機板的開發必須在一週的時間之內完成四千項測試工作,在多個專案同時進行的情況下,測試作業的排程本身就是個挑戰。其次由於測試及設計變更作業不斷重複,而且每次設計變更需要修改的部分以及負責修改的人員可能都不同,一旦重複次數太多,研發人員可能會搞不清楚到底是執行第幾次的設計變更,導致設計檔案版本的混亂,造成產品一再出現錯誤,而廷誤單交付的時程。
6 外部溝通
收於科技的快速發展,新的產品技術及元件不斷出現,消費者的需求也不斷變化,為了確保開發出來的產品能滿足客戶的需求,又能達到最佳質量及最低成本的目標,研發人員必須不斷與上游技術廠商聯絡,以掌握最新的產品技術及元件,同時必須與客戶保持聯絡,以便在客戶改變功能需求時,可以隨時調整,另一個方面也須與供貨商密切溝通,以確保新元件的來源沒有問題。這些溝通與聯絡的工作對研發作業而言不但是常態,也是流程上的不確定因素,而且其結果對於產品開發的進度有直接的影響。
7 知識性工作
另一個研發作業的特色,是其為知識性的工作,而非操作性的工作,其他部門的工作通常比較偏向操作層面,以財會流程為例,前端的輸入訂單、中間的過財動作以及後端的報表編制,主要是執行會計例行性的程式,不但沒有固定的步驟,而且作業時間比較容易估計,相比之下研發工作就屬於知識性、創造性的,以主機板為例,某一個元件原本為長方形,而新的元件為圓形,如何將新的元件加入並調整配置方式,而不影響原本主機板的大小,又可兼顧電源、散熱,電磁波等質量要求,就元件配置的設計而言可能是從未遇過的問題,此問題的解決步驟可能與之前不同,而所需的時間也比較難以掌握。
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-956358/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 研發管理流程 - 需求管理
- 研發模式和流程的再思考模式
- 企業研發流程演進之路
- 一個完整的軟體研發流程
- 研發流程在敏捷開發中的詳解敏捷
- 自主研發的流程引擎怎麼樣?好用嗎?
- 軟體專案研發流程該怎麼規範
- 雲擴研習社 | RPA流程開發最佳實踐(上)
- 雲擴研習社 | RPA流程開發最佳實踐(下)
- 雲擴RPA研習社 | 解析流程開發主要步驟
- 產品經理在研發流程中到底扮演什麼角色?
- 從創意CTR測試到立項研發製作 休閒遊戲研發全流程經驗分享遊戲
- Scala(四)之 流程控制
- 研發專案如何配置看板的任務流轉
- (2018-05-04.Python從Zero到One)四、(前端)前端頁面開發流程__1.4.0前端頁面開發流程...Python前端
- 企業流程數字化轉型研討會暨《流程最佳化風暴》新書釋出會 即將召開新書
- 從Android到React Native開發(四、打包流程解析和釋出AndroidReact Native
- Oracle vs PostgreSQL,研發注意事項(7)- 型別轉換OracleSQL型別
- camunda如何實現流程跳轉和流程退回
- 雲擴研習社 | 流程設計指南(下)
- 硬體開發筆記(四):硬體開發基本流程,製作一個USB轉RS232的模組(三):設計原理圖筆記
- 大象的轉身,HP LaserJet 印表機韌體研發團隊的 DevOps 轉型記dev
- 重溫手冊(四):流程控制
- 什麼是IPD專案管理模式?聊聊IPD下的產品研發流程專案管理模式
- 【本週四線上研討會預熱】IBM ELM—嵌入式系統工程研發管理解決方案IBM
- 雲擴RPA研習社 | 流程設計指南(上)
- 敏捷迭代流程下,如何解決產品質量和研發週期的衝突?敏捷
- 【轉】交換機開發(四)—— ARP 基礎知識解析
- 轉型大資料及操作流程大資料
- 從Android到React Native開發(四、打包流程解析和釋出為Maven庫)AndroidReact NativeMaven
- 曝蘋果TouchID研發取消,相關團隊已轉移至FaceID工作蘋果
- 為了更好的 Flutter | 2021 第四季度開發者調研Flutter
- 從0到1,馬蜂窩大交通團隊如何構建高效研發流程體系?
- Latch free等待事件四(轉)事件
- [譯] 三人研發小組的高效研發嘗試
- 3.系統呼叫跳轉流程
- Asp.net Core啟動流程講解(四)ASP.NET
- npm發包流程NPM
- Django開發流程Django