簡介面向制造企業(yè)車間信息化建設(shè)與MES系統(tǒng)選型的需求說明參考文檔適用于制造企業(yè)IT人員、MES實施顧問、產(chǎn)品經(jīng)理及車間管理人員。內(nèi)容以技術(shù)規(guī)格書形式組織覆蓋項目范圍、總體架構(gòu)、系統(tǒng)模塊功能需求等部分對生產(chǎn)建模、生產(chǎn)排程與調(diào)度、物料管理、現(xiàn)場作業(yè)、質(zhì)檢、設(shè)備、看板、人員、數(shù)據(jù)采集及系統(tǒng)集成等模塊均提出具體功能要求。資源為1個PDF文件大小約454KB文件雖少但內(nèi)容密度較高可直接作為撰寫MES需求說明書的藍本或評審對照清單。已有334人學習下載適合在MES項目前期用于快速梳理需求邊界、明確功能項與集成關(guān)系也可作為編制招標技術(shù)要求的參考依據(jù)。1. 這份需求說明到底在解決什么問題先聊點實際的。我之前經(jīng)手過不少制造企業(yè)的信息化項目幾乎每一家上MES之前都會有一份或多份需求說明文檔在群里傳來傳去。名字通常都很直白就叫“車間制造執(zhí)行系統(tǒng)(MES)---需求說明(參考).pdf”但你真正打開之后才會發(fā)現(xiàn)這份PDF的分量直接決定了后面項目是順風順水還是雞飛狗跳。所以這篇就圍繞這樣一份典型的MES需求說明來展開。我會基于制造業(yè)里最常見的需求撰寫邏輯把里面的核心章節(jié)、關(guān)鍵字段、容易踩坑的地方逐一拆開并且補上我在實際交付過程中總結(jié)的經(jīng)驗。不管你是甲方車間主任、IT負責人還是乙方實施顧問、剛?cè)胄械腗ES項目經(jīng)理這份解讀應該都能幫你少走不少彎路。先明確一個基本概念MESManufacturing Execution System制造執(zhí)行系統(tǒng)。它管的是車間這一層也就是從生產(chǎn)工單下達到產(chǎn)品完工入庫之間的所有執(zhí)行環(huán)節(jié)包括排產(chǎn)、派工、報工、質(zhì)檢、物料拉動、設(shè)備數(shù)據(jù)采集、異常處理、績效統(tǒng)計等等。ERP管的是“計劃層”MES管的是“執(zhí)行層”兩者是上下游關(guān)系。你光有ERP車間里到底做得怎么樣ERP是不知道的你光有MES不跟ERP打通排產(chǎn)數(shù)據(jù)、物料需求、完工入庫又對不上賬。所以MES需求說明的核心任務(wù)就是把“車間執(zhí)行”這件事講清楚讓業(yè)務(wù)方和技術(shù)方對同一件事達成共識。2. 需求說明的功能模塊怎么拆才不虛一份真正有價值的MES需求說明從來不是把系統(tǒng)功能羅列一遍就完事而是要回答“車間到底有哪些事需要系統(tǒng)管起來”。以我看到的絕大多數(shù)參考模板來說核心會包含這樣幾個模塊生產(chǎn)計劃與排程、物料追溯、質(zhì)量管理、設(shè)備管理、績效分析與看板。每個模塊缺一不可但每個模塊在需求文檔里的寫法深淺直接暴露了寫文檔的人有沒有真正下過車間。2.1 生產(chǎn)計劃與排程MES的“大腦”所在幾乎所有需求說明的第一章都會寫“生產(chǎn)管理”但很多寫得特別泛什么“支持生產(chǎn)計劃下達、支持工單分解、支持排程”就帶過了。這其實是不夠的。真正的生產(chǎn)計劃模塊至少要回答三個層級的問題第一MES接收什么類型的工單是ERP下發(fā)的生產(chǎn)訂單還是現(xiàn)場手工錄入的臨時訂單第二工單如何拆分是按工序拆還是按批次拆還是按工位拆第三排序規(guī)則是什么是交期優(yōu)先、插單優(yōu)先還是設(shè)備負載均衡優(yōu)先我這里給一個我在項目里經(jīng)常用的“工單信息模型”示例需求文檔里最好能明確到這種顆粒度字段說明示例工單編號唯一標識規(guī)則需統(tǒng)一MO20250612001產(chǎn)品編碼關(guān)聯(lián)物料主數(shù)據(jù)P10086計劃數(shù)量排產(chǎn)與報工的基準5000件交期決定優(yōu)先級2025-06-20當前工序跟蹤生產(chǎn)進度OP30 鉆孔批次號用于追溯和批次管理B20250612-01如果你拿到的需求說明里類似這種字段都沒有定義那后面實施的時候一定會吵翻。系統(tǒng)上線第一天車間說找不到工單計劃員說數(shù)量不對質(zhì)量說批次對不上全是因為需求階段沒把這些基本字段釘死。2.2 物料追溯一條產(chǎn)品從生到死的“身份證”MES需求說明里另一個容易寫虛的就是追溯。大家都知道要做正反向追溯但很少有人把追溯粒度說清楚。是追溯到批次還是追溯到單品是條碼追溯還是RFID追溯是裝配一件掃一次還是工單完工統(tǒng)一記錄這些完全是不同的實現(xiàn)路徑工作量差別也極其巨大。我舉個例子。一個電子裝配車間做PCBA追溯如果只需要追溯到批次那每個環(huán)節(jié)掃一下料盤上的批次條碼就夠了追蹤粒度到“這一批板子用的是這一批物料”這一層。但如果客戶要求追溯到單品也就是每個電路板上的每一顆關(guān)鍵物料都能通過板子的唯一序列號反查出來那幾乎每個貼片機、回流焊爐都要做數(shù)據(jù)采集對接還要考慮SN與物料批次號的綁定時機。這兩種追溯深度成本和系統(tǒng)復雜度差別是數(shù)量級的。所以在需求說明里必須要有類似這樣的追溯矩陣業(yè)務(wù)對象追溯維度記錄時機載體原材料來料批次收貨時供應商批次條碼半成品/在制品工單批次工序完工時工序流轉(zhuǎn)卡成品單品序列號包裝時成品SN標簽2.3 質(zhì)量管理與SPC別把質(zhì)檢數(shù)據(jù)做成臺賬質(zhì)量模塊是需求說明里的“戲眼”也是最容易兩極分化的地方。做得差的需求說明就是寫“支持來料檢驗、過程檢驗、完工檢驗”然后就沒了。做得好的需求說明會把檢驗項目、判定規(guī)則、不合格品處理流程一條條列清楚。我特別要提醒的是很多需求文檔里寫“SPC過程統(tǒng)計”只會寫“支持SPC”但SPC落地真正難的不是畫控制圖而是采樣規(guī)則。你有沒有明確哪個工序、哪個參數(shù)要做SPC是每半小時抽5件還是每批次抽20件控制限用經(jīng)驗值還是通過初始數(shù)據(jù)計算這些不寫清楚系統(tǒng)就是一擺設(shè)。車間工人每天倒是點得很勤快但控制圖上的點全部在界內(nèi)毫無分析價值。我建議需求文檔里至少附一張“關(guān)鍵CTQ/關(guān)鍵參數(shù)表”把每個受控工序的受控特性、規(guī)格上下限、采樣頻率、控制圖類型都列出來。這個表雖然做起來頭疼但做完之后后續(xù)質(zhì)量模塊的實施效率會翻倍。2.4 設(shè)備管理與OEE數(shù)據(jù)采集是分水嶺設(shè)備管理模塊在需求說明里通常會出現(xiàn)兩派。一派是“臺賬派”只寫設(shè)備臺賬、點檢保養(yǎng)、維修工單管理另一派是“數(shù)據(jù)派”要求接入PLC、OPC UA、Modbus TCP自動采集設(shè)備狀態(tài)和運行參數(shù)。說實話很多企業(yè)一開始只想要臺賬派但上了系統(tǒng)之后看到別人家的OEE自動算出來自己還要人工錄卡就開始后悔。所以需求文檔里關(guān)于設(shè)備模塊我建議必須思考清楚一個問題哪些設(shè)備要聯(lián)網(wǎng)聯(lián)網(wǎng)之后采什么數(shù)據(jù)數(shù)據(jù)采了之后要不要自動算OEE。如果暫時不聯(lián)網(wǎng)那設(shè)備狀態(tài)是人工報工還是掃碼切換這些選擇會直接影響硬件預算和項目邊界。OEE的計算公式得在需求說明里寫清楚。我見過不少項目上了MES半年OEE算出來超過95%老板還挺高興后來一查生產(chǎn)日報發(fā)現(xiàn)設(shè)備稼動時間壓根沒扣掉換型時間和休息時間。這個鍋不全是系統(tǒng)的需求說明里沒把OEE公式的定義寫細也是重要原因。2.5 績效看板從數(shù)據(jù)到?jīng)Q策的最后一公里關(guān)于MES看板網(wǎng)上總有人問“MES看板是不是用C#開發(fā)的”。這其實問偏了。MES看板的開發(fā)技術(shù)棧五花八門有傳統(tǒng).NET系的也有前后端分離用Vue或React的還有直接用商業(yè)BI工具如帆軟FineReport、Power BI拉的。真正重要的不是用什么語言開發(fā)而是看板內(nèi)容能不能支撐車間管理決策。需求說明里的看板章節(jié)建議明確到看板分哪幾類車間大屏、班組電腦、管理者移動端每類看板上展示哪些指標指標的口徑是什么刷新頻率是多少秒。比如車間大屏展示工單達成率那“達成率”的分母是計劃數(shù)還是實際排程數(shù)分子是合格入庫數(shù)還是完工報工數(shù)這些都要定義清楚。否則同一塊屏車間主任說是80%計劃員說是95%最后誰也說不服誰。3. 需求說明怎么讀才能不被帶偏拿到一份別人寫的MES需求說明或者自己動手起草時建議不要上來就悶頭寫功能清單。我總結(jié)了一套在實際項目里驗證過的拆解流程分四步做能讓需求文檔質(zhì)量明顯提升。3.1 先畫業(yè)務(wù)流再畫數(shù)據(jù)流這是我做所有MES項目的第一道工序。不要急著寫“系統(tǒng)要支持XX功能”而是先走到車間里把從接單、排產(chǎn)、領(lǐng)料、加工、檢驗、入庫的整個流程走一遍。每一步問三個問題誰做的用了什么單據(jù)/系統(tǒng)做完之后產(chǎn)生了什么數(shù)據(jù)我舉個例子一個機加工車間毛坯入庫用的是ERP的采購入庫單但車間領(lǐng)料用的是紙質(zhì)領(lǐng)料單領(lǐng)完料之后ERP庫存并沒有實時扣減導致MES上看到的物料庫存和實際上差了一大截。這種問題你靠開會在辦公室里是想不出來的必須去現(xiàn)場看。畫完現(xiàn)狀流程之后再畫“未來流程”也就是MES上線后每一步應該怎么做。這時候你會發(fā)現(xiàn)很多原來線下Excel干的事情必須重新分配職責和權(quán)限。職責不調(diào)整系統(tǒng)就是個擺設(shè)。3.2 每個環(huán)節(jié)的核心字段必須現(xiàn)場確認需求文檔不能只畫流程圖還要有字段級的定義。我當年在需求評審會上吃過一次虧客戶說“我們要產(chǎn)品追溯”然后一屋子人點頭。等到開發(fā)完了才發(fā)現(xiàn)客戶說的追溯是“按銷售訂單號查生產(chǎn)批次”而我們開發(fā)的是“按序列號查批次”方向完全反了。所以我的建議是在流程圖的每個節(jié)點邊上標注清楚“這個節(jié)點需要采集的數(shù)據(jù)項”并列表呈現(xiàn)。就拿“完工報工”這個節(jié)點來說至少需要明確誰來報操作工還是班組長、什么時候報每件完工還是每批完工、用什么報工位機掃碼還是手機App、要錄哪些字段數(shù)量、工時、不良數(shù)、設(shè)備號、操作工。3.3 ERP與MES的接口邊界要提前劃線MES和ERP的集成是需求文檔里繞不開的大山但很多需求說明里就一句“支持與ERP系統(tǒng)對接”。這句話等于沒說。你必須搞清楚ERP系統(tǒng)是什么金蝶云星空、用友U8、SAP還是Oracle接口方式是什么API、中間表、消息隊列接口的數(shù)據(jù)流向是什么。雙向接口的典型場景我列在這里方向接口內(nèi)容頻率關(guān)鍵字段ERP → MES生產(chǎn)訂單、物料主數(shù)據(jù)、BOM實時/定時訂單號、料號、數(shù)量、交期MES → ERP完工報工、物料消耗、不良品實時/批次工單號、數(shù)量、工時、不良代碼這里有個非常實用的建議不管需求說明怎么寫實施時一定要先跑通“ERP下工單 → MES執(zhí)行報工 → MES回傳完工 → ERP入庫”這條主線。這個鏈路不斷其他功能再豐富都是虛的。3.4 數(shù)據(jù)采集方式要落到具體設(shè)備MES需求說明里寫“數(shù)據(jù)自動采集”是很容易的真正難的是理清楚每個數(shù)據(jù)到底怎么采。是PLC自動采集是設(shè)備本身就是智能儀表帶通訊接口是掃碼槍人工掃碼是電子秤串口輸出還是干脆用平板手工輸入我見過一個典型案例需求上寫了沖壓設(shè)備要做“設(shè)備狀態(tài)自動采集”結(jié)果進場一看車間里的沖床是80年代的老設(shè)備別說PLC了連個像樣的電氣接口都找不到。最后只能用外貼電流傳感器的方式采集開機狀態(tài)成本從幾千塊一臺直接飆升到上萬一臺項目差點擱淺。這個教訓說明設(shè)備清單和通訊接口清單一定要在需求階段就做實地調(diào)研不能靠預估。4. 需求澄清階段常踩的坑與排查手冊做MES最怕的不是需求多而是需求“看似清楚、實則模糊”。我整理了一張在需求評審和上線初期最容易踩坑的速查表都是真實項目中遇到的問題希望對你有用。4.1 常見問題速查表現(xiàn)象根源對策上線后MES和ERP庫存對不上接口未做物料主數(shù)據(jù)同步或領(lǐng)料、退料不在MES中操作在需求中明確接口主數(shù)據(jù)同步機制把庫存類事務(wù)處理納入MES單據(jù)流程追溯查不到完整鏈條需求里的追溯粒度和實際條碼標識不匹配用追溯矩陣表明確每個環(huán)節(jié)的追溯載體記錄時機車間不愿意掃碼報工工序流轉(zhuǎn)卡設(shè)計不合理掃碼操作繁瑣簡化報工界面支持快捷鍵、自動帶入上一工序信息OEE數(shù)值離譜設(shè)備狀態(tài)判定規(guī)則未定義休息時間未扣除需求文檔要寫清OEE公式明確“計劃時間”的口徑報表口徑大家不認指標定義只寫名稱沒寫公式給每個指標附上“計算公式取數(shù)來源刷新頻率”需求變更太多業(yè)務(wù)流沒跑順邊做邊改需求階段必須用業(yè)務(wù)場景走查而不是功能清單羅列4.2 需求文檔里的“術(shù)語墻”怎么破網(wǎng)上搜“MES系統(tǒng)里的英文術(shù)語”出來的列表往往很長什么WIP、SPC、OEE、BOM、SOP、Rework、Scrap、Q-Time,剛開始接觸很容易被嚇到。說實話這些術(shù)語本身不難難的是很多需求文檔直接拿術(shù)語堆描述不做中文解釋導致車間老師傅完全看不懂評審會變成技術(shù)人員的自嗨現(xiàn)場。我的經(jīng)驗是需求文檔里出現(xiàn)英文術(shù)語的地方第一次出現(xiàn)一定要加中文全稱和一句大白話解釋。比如“SPC(Statistical Process Control統(tǒng)計過程控制)——通過控制圖監(jiān)控過程是否穩(wěn)定的方法”這一句話就能讓一線管理者秒懂。術(shù)語不可怕裝模作樣才可怕。4.3 關(guān)于需求說明的顆粒度到什么程度算“夠了”很多人問我需求說明寫多細算合格我一般拿一個標準來衡量如果這份文檔丟給一家完全沒有做過你們行業(yè)的軟件公司他們拿著文檔能不走樣地把系統(tǒng)做出來那顆粒度就夠了。換句話講文檔的核心是“消除信息不對稱”而不是“展示功能多”。針對這一點一個很實用的技巧是需求文檔里每一個功能點都配一個“業(yè)務(wù)場景示例”。比如寫“不合格品處理”就配一段場景說明“當品檢員在OP30發(fā)現(xiàn)連續(xù)3件孔徑超差時在系統(tǒng)里錄入不合格數(shù)量并觸發(fā)評審流程評審結(jié)果為返工的工單自動生成返工任務(wù)并流轉(zhuǎn)到指定工位?！庇辛诉@種場景技術(shù)團隊就好設(shè)計了。5. 我的一點實踐經(jīng)驗做了這么多個MES項目我最大的體會是MES需求說明文檔的價值不在于它寫了多少頁不在于它用了多少高大上的架構(gòu)圖而在于它有沒有把車間里的“潛規(guī)則”翻到臺面上來。很多工廠的車間管理靠的是班組長腦子里的經(jīng)驗——誰干活快、哪臺設(shè)備愛出毛病、哪個供應商的料容易有問題。MES本質(zhì)上就是把這些經(jīng)驗數(shù)據(jù)化、規(guī)則化、透明化。如果需求階段沒有把老師傅腦子里的東西挖出來系統(tǒng)上線之后必然水土不服。還有一個很實用的小建議需求說明定稿之后一定要讓車間一線的班組長簽字確認。不是走形式而是真的拿著文檔逐條給他們過一遍。別小看這一步它能讓后面實施少扯很多皮。我見過太多項目IT部門拍板定的功能車間根本不認賬最后系統(tǒng)淪為“電子Excel”。如果一線的人從需求階段就參與了后面推動起來完全是兩個狀態(tài)。本文還有配套的精品資源點擊獲取