關于KAIZEN項目改進程式自動化程序的分析

李文娟

摘要：在現在社會的各種服務器生產行業，服務器生產逐步復雜化，面對要求越來越高的服務器行業，生產線也逐漸復雜化，生產工位越來越多，人員培訓越來越困難，人工出現錯誤的幾率越來越大，針對在生產過程中的良率提升，針對人員“浪費”，時間“損耗”，以及過程“損耗”，本人在公司提出并主持了“KAIZEN生產管理持續改善項目”，做出了一系列改善，通過將各個模塊進行分析整理并歸納，設計出了程序自動化程式，從而提高了產線的良率，減少了公司各種“浪費”現象，最終達到了降低了公司運營成本的目的。

關鍵詞：程式自動化程序;模塊種類;運營成本

1.引言

KAIZEN以標準化、5S和消除“浪費”，來達到企業的QCD（質量、成本和交貨期）目標。它是以持續減少搬運等非增值活動、消除原材料浪費、改進操作程序、提高產品質量、縮短產品生產時間、不斷地激勵員工為主要目的而進行持續改善，在設計過程中確定的產品各功能和企業各部門的目標成本，是產品制造及銷售過程的成本控制依據。

在本人主持的該項目中，利用KAIZEN理念改進了操作程序來逐步降低公司運營成本，以達到或超過這一目標，并分階段、有計劃地達到預定的利潤水平。主要針對生產良率FPY的提升，客訴的減少，針對生產過程中的時間浪費，人力浪費和物料浪費等，進行了一系列的改善，成功達到了節省公司運營成本的目的。

針對公司的具體情況，統計了近半年的客訴情況，與程式相關的客訴有17項，與程序相關異常工時數1743小時，面對機種多樣化問題，TE的需求人員也增加了，針對單一機種設計程式越來浪費時間，操作工誤判概率也比較高。針對以上公司存在的實際問題，急需設計出一款能容納所有機種共通性的程式出現，因此，本人提出了利用KAIZEN的理念，改進操作程序，設計出程序自動化程式來解決以上問題。

2.設計程序自動化程式

2.1難點和前提

a.設計多樣化，客戶要求各異，料號種類多，模塊種類多

b.針對新客戶或新機種，單獨開發一個程式時間太長，消耗大量TE資源，程式質量也參差不齊

c.人工操作多，人為誤判不良多，處理時間久，人員離職對良率造成影響

2.2各部門的需求和聲音整理歸納

面對公司要開展KAIZEN以節省運營成本的大步驟，面對各個部門的迫切需求，本人從生產部、品質部、技術開發部、倉庫、RMA、維修、計劃、產銷等8個部門收集了各部門人員的聲音，對各種需求并整理歸納，針對完成程式自動化程序，各部門達成以下一致要求：

a.要求開發速度快

全部用模組化架構和模組化程式;用0/1的方式來表示測試項目是否需要測試;試產階段開發在3天內完成，量產測試開發在1天內完成，不可出現BIOS setting和OS錯誤。

b.程序coverage高

以單個測試項目測試率到達95%;以單個站別，測試率達到90%;客訴（包括產線）小于10%。

c.程序自動化智能化標準化

用不同的顏色提示操作工進行操作步驟;把所有需要人員操作的測試項目集中;盡量減少人員操作;不同機種要有統一的變量和腳本命名方式，log存放格式，顯示格式。

d.程序準確度

清楚明確指明錯誤項目和錯誤原因，比如是第幾根內存料用錯了，組裝位置錯了，是哪個位置跟哪個位置錯誤;程式誤判率為0;Runin時間誤差限定在半小時以內;不可出現BIOS setting和OS錯誤。

e.程序兼容性

程式在不同機種上都可以使用，不受限于某一種特定機型，或某一種特定廠商commodity;不受限于測試環境。

f.程序項目可單獨測試

程式可拿來直接使用，比如用于FAT/FDT/RACK/維修，不需做額外的操作;不受制于測試環境。

g.程序可追溯性

有詳細的測試log，SFC有詳細的記錄，各種記錄有備份機制，便于后續可追溯。

面對以上各部門的各種需求，程序設計難度比較大，要同時滿足以上所有需求，則需要把程設計的各個目標分階段的完成，根據反饋不斷改進程序。

2.3程序改進過程

從2014年3月到2014年10月期間，共計有719個料號生產，設計多樣化，供應商多，不同廠商和FW行為未統一，客戶要求也各異，常出客戶有21個，測試工具和環境多樣。所有的測試都是針對硬件，所以先從硬件角度把機器分解，并對機器HW進行分類。

本人收集了8個部門的意見共計23條（生產部、品質部、技術開發部、倉庫、RMA、維修、計劃、產銷），并將其歸類細化。先制定了思維路線：從測試此硬件受哪些因素影響→建立程式邏輯判斷圖→程式開發→程式驗證思維路線著手，經分析后決定從服務器的整個組裝過程將其一一分解，制定了模組化程式規范，針對不同料號做細微修改，使命名規則統一，接口規則和管理方法一致。所進行的措施如下：

2.3.1變量名命名規則

全部用小寫字母和_組成，數據類型_大類_小項，如bios_ver_chk.sh，我們在不同料號間做了細微修改，使命名規則一致。

2.3.2統一程序的路徑，接口，提示格式

例如：顯示狀態信息到屏幕上

P=PASS，綠色;

F=FAIL，紅色;

R=REMIND，枚紅色，提示操作工操作

S=STATUS，藍色，提示當前的測試狀態

此顯示方法通俗易懂，使產線操作工很容易理解所發生的的狀態，并及時做出處理。

2.3.3針對模塊的分解

由于該自動化程序需要滿足各部門的需求，程序設計比較復雜，因此需要分階段完成各個目標，于是本人將程序模塊進行了分解，包括輸入模塊、解析模塊、調用模塊、測試模塊、判斷模塊、顯示模塊、輸出模塊。本人對各個模塊進行了因果關系分析，便于從全局掌握和設計程序。

a.輸入模塊：

產品工程師定義測試項目及測試標準，標準化;提示讓操作工輸入程式需要的值/判斷結果。比如需要操作工輸入各類LED燈（是否閃爍，閃爍順序，顏色等）;按鍵是否有效，需要操作工實際按，并反饋結果;話筒是否響，需要操作工實際聽并反饋結果;輸入外殼Barcode，程式確認Barcode有沒有貼錯等等。

在設計輸入模塊時，各項測試活動盡量減少操作工的主觀活動意識，而改為程序自動化操作，操作工只需要判斷指令，這樣大幅度減少了誤判概率。

b.解析模塊：

解析操作工輸入的值;解析產品工程師定義之測試項目及測試標準，解析程式運行結果。

c.調用模塊：

能夠根據實際測試項目調用相應的測試模塊;調用客戶預先定義的測試標準。

d.測試模塊：

測試對應HW的功能;反饋正確或具體錯誤信息。將料號和HW分類，將HW模塊分為48類，所有模組分為81個測試模塊。

測試模塊種類繁多，需要將其一一分類，并一一突破，本人對各個模塊也進行了分類歸納，使自動化程序能滿足各模塊要求目標。其中測試模組的分類是比較困難的，本人將機器一一分解，分為81個功能模塊，包括FAN，FRU，FW，Button，LAN，CMOS等等。

e.判斷模塊：

判斷測試結果。字體不同顏色顯示，容易辨識，對比性的畫面更清楚。可以綜合判斷錯誤原因、類型和位置等。

該模塊設計使用易辨識的字體顏色，是操作工能速度的進行綜合判斷，節省了站別工作運行時間。

f.顯示模塊：

以操作工及其他用戶能夠理解的方式顯示;把測試結果和信息準確顯示。

g.輸出模塊：

測試結果輸出到test log以記錄;測試結果輸出到SFC以記錄。如顯示當前的測試狀態為何？測試的是哪一個站位？測試的是哪一片主板？是什么人（員工工號）在什么時間進行測試的？

輸出模塊未設置權限，查詢log不需要通過TE或產線，隨時隨地可查詢，任何時間都可以隨時了解產線測試狀況。

2.3.4將客戶需求輸入系統

為將客戶需求輸入系統，需要獲取各個客戶的需求信息，產品工程師定義需求標準，質量工程師復查標準，共同制定出程序可識別語言，建立邏輯圖，分組開發和驗證，制定出配置代碼和項目代碼。

2.3.5培訓產線操作工及新進員工

根據自動化測試流程，重新制定了軟件開發作業指導書，發布新的測試網站，并對版本進行管控，形成系統化的培訓教材。在制作作業指導書時也考慮到了該作業指導書的通俗易懂性，并在其中附上相關的圖文便于直觀性的理解。在此基礎上培訓了產線操作工、測試員及新進人員如何進行操作和測試，包括測試范圍，測試目的，未測試的影響程度，測試方法及測試工具介紹，模塊化程序介紹等。

2.4專案成效

本人設計的該程式，專案成效如下：

（1）程式自動化使程序運行時間從10%減少到5%;

（2）與測試相關的客訴比例從29.89%降低為13%;

（3）與測試相關異常工時比例從9.14%降低為3.58%;

（4）針對新料號、增加測試項目、導入FW等，程序開發時間短縮36倍;

（5）降低了TE入門門檻，培訓時間減少;

（6）減少了離職人員對產能效率的影響;

（7）客人從下單到上線測試整個過程全部自動化;

（8）降低了公司產線運營成本，達到了降低公司成本的目的。

3.結語

本人在該項目中通過積極組織各個部門之間進行跨部門的合作，進行頭腦風暴，加入流程和觀念的創新，通過分析設計出自動化程式模板。在工作中不斷分析解決各項難題，尤其是面對物料和產品種類繁多，客戶要求各異的情況下能夠細致化的分析整理并歸類，通過實際效果觀察專案是否有成效，根據使用人員的反饋不斷的修改完善，使程式及檢測更好、更快、更準備，從而成功達到了為公司產線節省成本的目的，使生產成本得以有效控制。

經財務合適，該項目專案共為公司節省69723 RMB。該項目完成后，公司的生產線運營成本比之前降低了20%。該項目中的各類方法和系統，均被后續生產過程中工作人員和技術人員加以沿用，并持續為公司后續生產創造價值。