簡介制造執(zhí)行系統(tǒng)MES處于企業(yè)資源計劃ERP與車間底層設備之間承擔著從工單下達到產(chǎn)品完工的全過程管理。明確的系統(tǒng)邊界與結(jié)構(gòu)化需求是MES落地的核心前提。一份合格的需求文檔需拆解生產(chǎn)工單、排產(chǎn)調(diào)度、物料追溯、數(shù)據(jù)采集等模塊并定義追溯粒度、設備接口、斷網(wǎng)兜底等非功能性指標。本文結(jié)合真實項目經(jīng)驗從功能模塊拆解、接口關(guān)系、術(shù)語統(tǒng)一到需求評審驗收系統(tǒng)梳理MES需求文檔的編寫方法與避坑指南幫助甲方與實施方對齊預期降低交付風險。 去年年底我給一家機加工企業(yè)做MES選型咨詢對方項目負責人發(fā)來一份PDF文件名就叫“車間制造執(zhí)行系統(tǒng)(MES)---需求說明(參考).pdf”。我當時掃了一眼第一反應是這年頭能拿出一份像樣需求說明的甲方不多了。看完后發(fā)現(xiàn)這份文檔雖然是“參考版”但結(jié)構(gòu)、顆粒度都挺到位基本把MES項目前期最容易扯皮的事都講清楚了。這份需求說明并不長但對“MES系統(tǒng)有哪些功能”“MES和ERP怎么分工”“現(xiàn)場數(shù)據(jù)怎么采”這些問題都有明確回答。這篇文章我就以這份需求說明為引子結(jié)合我在多個MES項目里踩過的坑把車間制造執(zhí)行系統(tǒng)需求文檔該怎么寫、怎么讀、怎么落地這件事掰開揉碎聊一遍。不管你是甲方項目經(jīng)理、車間主任還是剛?cè)胄械膶嵤╊檰栔灰阆敫闱宄﨧ES項目到底要做什么、需求要細化到什么程度這篇文章應該能幫你省下不少彎路。1. 需求說明究竟解決什么問題先別急著談功能定位比功能重要MESManufacturing Execution System制造執(zhí)行系統(tǒng)被夾在ERP和底層設備之間很容易被誤解成“ERP的子系統(tǒng)”或者“高級版報工軟件”。我見過太多企業(yè)上ERP時覺得夠了后來發(fā)現(xiàn)車間里全是信息孤島才回頭補MES。這份需求說明的第一頁就在講這件事MES管的是從工單下達到產(chǎn)品完工之間的所有執(zhí)行過程核心目標是讓車間“透明化、可追溯、能改善”。1.1 用一個車間調(diào)度員的視角理解MES的邊界你可以把ERP理解成企業(yè)的“大腦”它負責算物料需求、下采購計劃、排財務賬。但大腦下了指令之后手腳怎么動是MES的事。工單到車間之后先做不做、先做哪個、這臺設備夠不夠、物料齊不齊、加工到哪一步了、這個批次用了哪些原料、質(zhì)檢有沒有過——這些在ERP里往往是黑盒而在MES里是逐條記錄、實時反饋的。需求說明里寫得比較清楚MES要承接ERP的生產(chǎn)訂單向下要采集設備、人員、物料、質(zhì)量數(shù)據(jù)向上要把完工信息反饋給ERP。這句話聽起來簡單但真正落地時大部分吵架都發(fā)生在邊界問題上。比如ERP已經(jīng)下了生產(chǎn)訂單但車間臨時調(diào)整了加工順序這個信息要不要回傳質(zhì)檢不合格要返工ERP庫存怎么扣如果需求文檔里沒有提前定義這些交互規(guī)則后面就是無休止的接口扯皮。1.2 一份合格需求說明的三層結(jié)構(gòu)這份PDF的結(jié)構(gòu)我拆解下來無非三層業(yè)務現(xiàn)狀與目標、功能需求按模塊分、非功能需求性能、接口、權(quán)限、追溯要求。很多企業(yè)寫需求文檔時只寫功能列表比如“要有排產(chǎn)模塊”“要有質(zhì)量模塊”這其實只是目錄不是需求。真正的需求要能回答三個問題誰來用角色、做什么動作功能、出了問題怎么辦異常流程。比如“班組長可以在Pad上對工單進行開工操作并錄入實際開始時間”——這算一條能落地的需求。而“系統(tǒng)應支持生產(chǎn)調(diào)度”這種純屬浪費紙張。需求說明里最好每個功能項都帶編號、帶優(yōu)先級、帶驗收標準后面做UAT用戶驗收測試時才能逐條核對避免“做完之后才發(fā)現(xiàn)不是我要的”。2. 核心功能模塊的拆解從工單到追溯每個模塊都有隱藏的坑這份需求說明把MES功能分成六大塊生產(chǎn)工單管理、排產(chǎn)與調(diào)度、數(shù)據(jù)采集與追溯、質(zhì)量管理、設備管理、績效與看板。這基本覆蓋了市面上主流MES的標準范圍。但每個模塊里都有一些細節(jié)需求文檔里未必會展開而恰恰是這些細節(jié)決定項目成敗。2.1 生產(chǎn)工單與排產(chǎn)調(diào)度需求要從“異常場景”寫起工單管理不只是把ERP的訂單接進來再轉(zhuǎn)給車間它還要處理拆單、合并、插單、改單這些日常操作。比如一個1000件的大訂單車間不可能一次投料往往要按批量拆成多個生產(chǎn)批。需求里要明確拆單規(guī)則按數(shù)量拆還是按工藝路線拆拆出來的子工單要不要單獨算成本插單加急單進來后原有排產(chǎn)計劃怎么調(diào)整我在一個項目里就吃過虧客戶提“系統(tǒng)要支持插單”結(jié)果實施時才發(fā)現(xiàn)他們的“插單”不是把新單排到最前面而是要把某條產(chǎn)線上正在做的半成品全部下線換成急單做完再換回來。這個操作涉及物料回退、工時重算、質(zhì)量狀態(tài)變更遠比“調(diào)整優(yōu)先級”復雜。如果需求階段沒把這些異常場景聊透開發(fā)到一半需求變更項目周期直接翻倍。排產(chǎn)調(diào)度這塊需求說明一般不會要求“自動排產(chǎn)”大多數(shù)企業(yè)現(xiàn)階段能接受的是“排產(chǎn)輔助”。也就是系統(tǒng)展示設備負載、工序工時、物料齊套情況調(diào)度員人工拖拽調(diào)整。真正全自動的APS高級排程牽扯約束條件太多不是MES的核心任務。寫需求時建議把“人工排產(chǎn)為主、系統(tǒng)提供可視化輔助”作為默認基調(diào)能省掉很多不切實際的預期。2.2 物料追溯與數(shù)據(jù)采集追溯粒度是第一個要拍板的事凡是涉及追溯的需求第一件事就是定粒度批次級追溯還是單件級追溯。批次級的意思是這一批料用到哪個生產(chǎn)批、成品去了哪能追溯到“一批”的層面單件級則是每一件產(chǎn)品都有唯一SN碼能查清楚這個SN用了哪個爐批的鋼材、哪臺機床加工、哪個操作工做的、檢測數(shù)據(jù)是多少。這兩個方向的工作量天差地別。批次級一般靠“工單物料批次號”綁定掃描工作量小單件級則需要每件產(chǎn)品貼碼、每道工序掃碼對產(chǎn)線節(jié)拍有要求。需求文檔里如果只寫“實現(xiàn)正反向追溯”而不寫粒度報價和排期都沒法估準。我建議在需求階段就明確“追溯的最小單元是什么”“追溯到工序還是追溯到設備”“是否要求首件記錄和過程參數(shù)綁定”。數(shù)據(jù)采集方式也要提前定。常見的三種PLC自動采集設備有接口、掃碼槍半自動采集人工掃工單和SN、Pad手動錄入適用于沒有自動化條件的工位。需求文檔里要對每個數(shù)據(jù)項標注來源方式比如“設備狀態(tài)通過PLC每5秒采集一次”“完工數(shù)量操作工在Pad上手工錄入”。這個細節(jié)決定了現(xiàn)場的網(wǎng)絡布點、硬件選型甚至影響整個項目的預算量級。2.3 質(zhì)量、設備與績效那些容易被忽視的隱性需求質(zhì)量管理模塊大多數(shù)需求文檔會寫“來料檢驗、過程檢驗、完工檢驗、不合格品處理”。但真正決定質(zhì)量模塊好用不好用的是它和工單、物料、設備的數(shù)據(jù)打通程度。比如過程檢驗發(fā)現(xiàn)一批料不合格系統(tǒng)能不能自動鎖定相關(guān)工單、禁止繼續(xù)投料返工流程走完之后檢驗記錄能不能保留原始數(shù)據(jù)而不是覆蓋這些都值得寫進需求。設備管理重點不只是“點檢保養(yǎng)”更是OEE設備綜合效率的計算口徑。需求文檔里要定義清楚OEE的時間損失怎么算計劃停機比如保養(yǎng)、換型算不算進理論運行時間一條產(chǎn)線有多臺設備OEE按瓶頸設備算還是按產(chǎn)線整體算不少企業(yè)看到系統(tǒng)里的OEE覺得“不準”原因就是口徑?jīng)]在需求階段鎖定?？冃c看板模塊需求文檔里容易寫成“展示產(chǎn)量、合格率、設備狀態(tài)”。但實際實施時如果工位、班組、產(chǎn)品的關(guān)系沒定義清楚看板上的數(shù)據(jù)分分鐘錯亂。我建議績效報表的需求先梳理“組織和崗位維度”也就是誰看這張報表、按什么維度分組、數(shù)據(jù)刷新頻率是多少。MES看板的技術(shù)棧用C#開發(fā)后臺、Web前端展示是非常常見的組合因為工廠里Windows生態(tài)占主流運維團隊熟悉.Net的比熟悉別的多需求文檔里不用規(guī)定語言但可以寫明“看板需支持網(wǎng)頁訪問方便投到車間大屏”。3. 非功能性需求和接口決定系統(tǒng)能不能真正活下來功能需求決定系統(tǒng)“有沒有”非功能性需求決定系統(tǒng)“好不好用、能不能用住”。很多需求文檔重功能、輕性能結(jié)果系統(tǒng)上線后天天被車間吐槽“轉(zhuǎn)圈圈”。這一部分我重點聊三件事性能與可靠性、接口關(guān)系、術(shù)語統(tǒng)一。3.1 性能指標、斷網(wǎng)兜底和數(shù)據(jù)安全性能指標必須量化。比如“掃碼響應時間不超過1秒”“看板數(shù)據(jù)刷新延遲不超過3秒”“支持200個并發(fā)用戶在線操作”。這些數(shù)字不用多專業(yè)但一定要寫因為它直接決定架構(gòu)設計和硬件選型。工廠車間網(wǎng)絡環(huán)境不比寫字樓經(jīng)常有電磁干擾、跨廠房光纖距離遠的問題需求里最好明確“無線網(wǎng)絡覆蓋所有作業(yè)區(qū)域關(guān)鍵數(shù)據(jù)采集點有線備份”。更關(guān)鍵的是斷網(wǎng)兜底。車間里設備可以停網(wǎng)絡不能保證永遠不抖。需求文檔里最好寫明“當MES服務不可用時現(xiàn)場客戶端應支持離線緩存網(wǎng)絡恢復后自動補傳數(shù)據(jù)”。這個需求如果不提供應商大概率不做因為離線邏輯做起來很麻煩。但是產(chǎn)線不能因為MES掛了就停擺所以離線能力必須白紙黑字寫進合同。數(shù)據(jù)安全方面需求里至少明確三件事操作員權(quán)限分級比如工藝員能改工藝參數(shù)、操作工只能報工關(guān)鍵操作留痕誰在什么時間改了什么數(shù)據(jù)數(shù)據(jù)庫定期備份策略。很多工廠的MES最后淪為“大號Excel”就是因為權(quán)限太亂誰都能改數(shù)據(jù)數(shù)據(jù)失去公信力。3.2 與ERP、測試軟件、看板的接口關(guān)系MES的價值很大程度體現(xiàn)在跟周邊系統(tǒng)的連接。需求文檔里要單獨列“接口清單”每個接口寫清楚系統(tǒng)名稱、接口方向數(shù)據(jù)誰給誰、同步頻率、觸發(fā)方式、異常處理。和ERP接口是重頭。常見的交互包括ERP下發(fā)生產(chǎn)訂單給MESMES回傳完工數(shù)量、不良數(shù)量、工時信息MES請求物料信息ERP回傳庫存可用量。這里要特別注意主數(shù)據(jù)的歸屬問題物料編碼、BOM、工藝路線到底以哪個系統(tǒng)為準我見過最混亂的項目ERP一套編碼、MES又建一套兩個系統(tǒng)對不上賬。正確做法是主數(shù)據(jù)統(tǒng)一由ERP分發(fā)MES只讀不新建。文中熱詞里還有“mes與測試軟件”“l(fā)anggraph結(jié)合mes布置在工廠”前者是測試數(shù)據(jù)回傳比如產(chǎn)品檢測設備測完自動把數(shù)據(jù)發(fā)給MES做SPC分析后者是今年圈里炒得比較熱的方向——把大模型Agent用在工廠排產(chǎn)和異常處理上。說實話這類需求目前屬于“探索性項目”需求文檔里可以不寫但如果企業(yè)有數(shù)字化團隊想試點可以考慮預留一個“具備調(diào)用外部算法服務的能力”這樣的擴展性條目。3.3 術(shù)語表讓業(yè)務和技術(shù)講同一種語言需求文檔里一定要有術(shù)語表這不是湊頁數(shù)。MES行業(yè)里的英文縮寫實在太多而且同一個詞在不同企業(yè)可能含義不同。比如工單和生產(chǎn)批有的廠認為是同一個東西有的廠嚴格區(qū)分SN是序列號指單件唯一碼**批次號Lot No.**則對應一批物料**工位Workstation和設備Equipment**也不是一回事一臺設備可以對應多個工位需求里如果不區(qū)分后面排產(chǎn)和質(zhì)量追溯都會亂。還有**Andon安燈**這個熱詞在MES里指的是異常呼叫系統(tǒng)比如員工發(fā)現(xiàn)物料短缺或設備故障按一下按鈕看板上就亮燈報警。這個詞從豐田生產(chǎn)系統(tǒng)來的很多工廠叫“呼叫”“報警”但需求文檔里統(tǒng)一用Andon大家就不會誤解。**SPC統(tǒng)計過程控制**也是一種常見需求用控制圖監(jiān)控生產(chǎn)過程穩(wěn)定性。建議需求文檔最后附一張術(shù)語對照表把中英文、解釋、舉例都列出來評審的時候能省一半解釋的時間。4. 從需求說明到落地評審要點、驗收標準和避坑實錄需求文檔寫得好不好最終要拿到項目里去驗證。我見過太多MES項目需求文檔寫得像小說真到開發(fā)階段每個模塊都返工。下面這部分是我在實際項目里的經(jīng)驗總結(jié)圍繞需求評審、功能編號、驗收標準再放幾個真實的坑。4.1 需求評審時必須當場確認的十個問題拿到一份需求說明去做評審不用逐字讀抓住十個關(guān)鍵問題問清楚基本就能判斷這份需求水平如何追溯粒度是批次級還是單件級工單拆分的觸發(fā)規(guī)則和權(quán)限歸屬是誰插單/改單的作業(yè)流程系統(tǒng)怎么支持數(shù)據(jù)采集哪些靠自動化、哪些靠人工設備狀態(tài)數(shù)據(jù)從哪來PLC點位是否已有點表質(zhì)檢不合格后的處理流返工/報廢/讓步接收誰審批OEE和績效報表的計算口徑是否跟財務口徑一致斷網(wǎng)、宕機時的業(yè)務連續(xù)性方案是什么主數(shù)據(jù)物料、BOM、工藝路線由哪個系統(tǒng)維護項目驗收依據(jù)哪條需求清單逐條核對還是只做演示這十個問題里最容易被忽視的是第二和第三。很多車間管理靠車間主任“人肉記憶”你問他插單怎么處理他說“到時候現(xiàn)場臨時安排”。需求評審階段如果不把一個具體的場景按流程走一遍開發(fā)出來的功能大概率是拍腦袋的。4.2 功能需求編號化每一條都得有驗收標準一份好的需求文檔每個需求都應該有唯一編號、優(yōu)先級、驗收標準。比如“F-M-01優(yōu)先級高生產(chǎn)主管可在工單列表頁對未開工工單進行批量拆分拆分后子工單繼承父工單的物料清單和工藝路線驗收標準1000件工單拆成3批操作耗時小于2分鐘ERP接口不產(chǎn)生重復數(shù)據(jù)。”有了這種寫法開發(fā)階段才有據(jù)可依測試階段才能寫用例驗收階段才不會爭議。我推薦用“模塊縮寫-功能序號”的方式編號比如“F-WO-01”代表工單管理模塊第一條需求“F-QC-02”代表質(zhì)量管理模塊第二條需求。這樣一條條列下來哪怕300條需求管理起來也不亂。優(yōu)先級一般分三類P0不做就不能上線、P1重要但可后續(xù)優(yōu)化、P2錦上添花。需求文檔里有了優(yōu)先級供應商做報價和排期時就不會把所有需求都按P0算企業(yè)也能看明白錢花在哪些刀刃上。4.3 常見問題與排查技巧實錄我把這幾年在MES需求階段和上線初期遇到的問題整理一個速查表每一條都是真金白銀換來的教訓問題表現(xiàn)根因分析解決建議看板產(chǎn)量數(shù)據(jù)和ERP庫存對不上工位定義混亂同一批產(chǎn)品被多個工位重復報工需求階段統(tǒng)一“工位-設備-工序”關(guān)系一個報工動作只能關(guān)聯(lián)一個工位追溯查不到某個批次掃描節(jié)點缺失某道關(guān)鍵工序沒設采集點畫工藝流程圖時嚴格走查“物料經(jīng)過的每個節(jié)點”設備和MES之間數(shù)據(jù)斷斷續(xù)續(xù)現(xiàn)場網(wǎng)絡有線無線混用跨廠房光纖丟包需求里明確全網(wǎng)有線覆蓋關(guān)鍵點位無線僅用于移動掃碼報表數(shù)據(jù)看起來“不對”報表的口徑和業(yè)務規(guī)則不一致每個報表需求附一個口徑說明舉一個具體計算示例系統(tǒng)上線一個月后沒人用了操作工覺得錄入麻煩一線不認可需求里預留“操作友好性”要求移動端優(yōu)先減少純鍵盤錄入還有一個容易被忽略的點需求說明不要寫成“甲方爸爸的夢想清單”。比如有人會寫“系統(tǒng)應實現(xiàn)車間全面智能化”這類話對開發(fā)毫無指導意義。我在評審時就遇到過這種情況最后只能一條條追問硬是把“全面智能化”拆成了“設備數(shù)據(jù)采集點位表”“異常自動報警規(guī)則”“生產(chǎn)日報自動生成”這三個具體需求。需求文檔的讀者是開發(fā)團隊不是領(lǐng)導所以每一句話都要能指導編碼和測試。4.4 需求文檔的篇幅和寫法建議以這份參考PDF為例企業(yè)級MES需求說明建議控制在30到60頁太短說明沒想清楚太長說明需求提煉能力不行。功能模塊部分多用表格每條需求一行比大段文字好維護得多。文檔里盡量放流程圖描述業(yè)務現(xiàn)狀但不要空談目標要畫清楚“現(xiàn)在怎么走”“將來怎么走”兩條路徑這樣供應商能快速理解差距。另外需求文檔寫完后一定要組織一次跨部門評審生產(chǎn)、工藝、設備、IT、財務都要到場。生產(chǎn)代表確認現(xiàn)場操作流程工藝代表確認工序和參數(shù)設備代表確認采集接口財務代表確認和成本相關(guān)的數(shù)據(jù)要求IT代表確認和ERP、OA的接口范圍。我每次做MES項目啟動會最頭疼的就是“需求文檔簽字確認”這一步但這一步省不了它決定后續(xù)變更怎么談。5. 寫在最后一點個人體會我在實際項目里看過太多需求文檔最大的體會是MES項目失敗很少是技術(shù)不行大多是需求沒對齊。車間里的人以為系統(tǒng)“全自動”管理者以為系統(tǒng)“立刻透明”IT部門以為系統(tǒng)“接上ERP就能跑”三撥人抱著三個預期最后做出來的東西誰都不滿意。而一份像樣的需求說明恰恰是逼著所有人把預期攤到桌面上一條條確認這是省錢省時間的最好方式。最后再分享一個小技巧拿到任何MES需求文檔先別急著看功能清單先找“術(shù)語表”“接口清單”“非功能性需求”這三章。如果三章都有實質(zhì)內(nèi)容這份需求大概率靠譜如果沒有哪怕功能寫得再漂亮后面都有足夠多的坑等著你。MES是個慢工出細活的領(lǐng)域需求階段多花一個月實施階段能少折騰半年。本文還有配套的精品資源點擊獲取