實(shí)踐:WBS編碼、掙值分析與質(zhì)量閉環(huán))
簡(jiǎn)介《三峽工程管理系統(tǒng).ppt》是一份系統(tǒng)介紹三峽工程管理信息化實(shí)踐的演示文稿面向工程管理、信息系統(tǒng)建設(shè)及水電行業(yè)從業(yè)者與研究者。內(nèi)容重點(diǎn)闡述三峽工程管理系統(tǒng)的建設(shè)背景、開發(fā)過(guò)程、實(shí)施路徑與運(yùn)行特點(diǎn)涵蓋建設(shè)監(jiān)理制、招標(biāo)承包制、企業(yè)法人負(fù)責(zé)制、合同管理制等現(xiàn)代管理體制以及WBS工作分解結(jié)構(gòu)、關(guān)鍵路徑法CPM、計(jì)劃評(píng)審技術(shù)PERT、甘特圖等項(xiàng)目管理工具在巨型工程中的實(shí)際應(yīng)用同時(shí)展示系統(tǒng)在進(jìn)度控制、成本控制、質(zhì)量控制、合同管理、物資管理、文檔管理等業(yè)務(wù)模塊中的功能劃分與協(xié)同機(jī)制有助于讀者理解大型復(fù)雜項(xiàng)目信息化的整體架構(gòu)與落地經(jīng)驗(yàn)。資源僅含1個(gè)PPT文件壓縮包大小11.14MB圖表完整、結(jié)構(gòu)清晰。已有81人瀏覽學(xué)習(xí)適合需要借鑒特大型工程管理信息化案例的產(chǎn)品、項(xiàng)目及研究人員。1. 三峽工程管理系統(tǒng)為什么先要立數(shù)據(jù)口徑大型工程項(xiàng)目的管理系統(tǒng)第一個(gè)要過(guò)的坎往往不在技術(shù)而在數(shù)據(jù)口徑。三峽工程這種體量標(biāo)段幾十個(gè)、參建單位上千家、工期跨十年同一段壩體物資部叫“左岸3號(hào)倉(cāng)”質(zhì)檢部叫“EL100-3-4”財(cái)務(wù)部只有一筆付款憑證——對(duì)不上。三峽工程管理系統(tǒng)就是把WBS、合同、進(jìn)度、質(zhì)量、檔案放進(jìn)同一個(gè)數(shù)據(jù)模型讓各級(jí)管理者看到同一組數(shù)字。這篇文章不討論工程本身只講可以復(fù)用的技術(shù)邏輯編碼怎么定、進(jìn)度和費(fèi)用怎么在一個(gè)模型里算、質(zhì)量流程怎么固化、報(bào)表怎么給決策層看。適合正在搭工程項(xiàng)目管理平臺(tái)、或者準(zhǔn)備給施工企業(yè)做數(shù)字化系統(tǒng)的工程師。2. 先立規(guī)矩再寫代碼三峽工程管理系統(tǒng)的WBS與編碼體系2.1 WBS是系統(tǒng)里第一個(gè)要定死的主數(shù)據(jù)接手工程管理系統(tǒng)需求第一周不應(yīng)該去討論技術(shù)選型應(yīng)該拉著工程部的計(jì)劃工程師一起把WBSWork Breakdown Structure工作分解結(jié)構(gòu)定下來(lái)。工程管理系統(tǒng)和普通業(yè)務(wù)系統(tǒng)最大的區(qū)別是幾乎所有單據(jù)都要掛到某個(gè)WBS節(jié)點(diǎn)上。合同按標(biāo)段簽、計(jì)量按單元工程報(bào)、質(zhì)量按倉(cāng)號(hào)驗(yàn)、成本按部位歸集如果沒有一個(gè)公共的分解結(jié)構(gòu)業(yè)務(wù)模塊各自長(zhǎng)出一套口徑后面做匯總時(shí)全部對(duì)不上。常見做法是直接從概算書和施工組織設(shè)計(jì)反向推導(dǎo)WBS層次。水電工程習(xí)慣按“樞紐工程—單位工程—分部工程—分項(xiàng)工程—單元工程”來(lái)拆這本來(lái)就是施工規(guī)范里定義好的層級(jí)。管理系統(tǒng)要做的是把這些層級(jí)落成一張表、分配穩(wěn)定的ID、再讓所有模塊引用它。這張表上線后再改層級(jí)牽動(dòng)的往往是幾十萬(wàn)條業(yè)務(wù)數(shù)據(jù)所以建表時(shí)就要把“口徑優(yōu)先”寫進(jìn)設(shè)計(jì)原則。WBS節(jié)點(diǎn)表的核心結(jié)構(gòu)CREATE TABLE wbs_node ( wbs_id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT WBS節(jié)點(diǎn)全局唯一ID, wbs_code VARCHAR(64) NOT NULL COMMENT WBS編碼語(yǔ)義化且分段, parent_wbs_id BIGINT NULL COMMENT 父節(jié)點(diǎn)ID根節(jié)點(diǎn)為NULL, lft INT NOT NULL COMMENT 嵌套集左值用于快速取子樹, rgt INT NOT NULL COMMENT 嵌套集右值, node_level TINYINT NOT NULL COMMENT 層級(jí)從1開始, node_name VARCHAR(255) NOT NULL COMMENT 節(jié)點(diǎn)名稱, responsible_org VARCHAR(128) NULL COMMENT 責(zé)任單位編碼, budget_amount DECIMAL(18,2) NULL DEFAULT 0 COMMENT 該節(jié)點(diǎn)對(duì)應(yīng)的概算金額, is_leaf TINYINT NOT NULL DEFAULT 1 COMMENT 是否葉子節(jié)點(diǎn), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_wbs_code (wbs_code), KEY idx_parent (parent_wbs_id), KEY idx_lft_rgt (lft, rgt) ) ENGINEInnoDB COMMENTWBS節(jié)點(diǎn)表;這段建表語(yǔ)句里有三個(gè)點(diǎn)值得注意。lft和rgt是嵌套集模型的左右值查某個(gè)部位下的整棵子樹只需要一條范圍查詢。工程系統(tǒng)經(jīng)常要按標(biāo)段匯總、按單位工程逐級(jí)鉆取這是讀多寫少、結(jié)構(gòu)幾乎不變的場(chǎng)景嵌套集比parent_id遞歸要快得多很多團(tuán)隊(duì)一開始圖省事只留parent_wbs_id數(shù)據(jù)量上萬(wàn)之后報(bào)表接口就明顯變慢。node_level與施工規(guī)范的層級(jí)對(duì)應(yīng)從1開始一般用于限制業(yè)務(wù)單據(jù)只能掛到葉子節(jié)點(diǎn)。budget_amount存的是概算金額它是后續(xù)掙值計(jì)算里計(jì)劃值的基準(zhǔn)在編碼階段就要保證它有值否則后面算SPI全是0。WBS表建好之后要立刻做一次完整性檢查。最常見的臟數(shù)據(jù)是同一編碼重復(fù)插入一條SQL就能掃出來(lái)SELECT wbs_code, COUNT(*) AS cnt FROM wbs_node GROUP BY wbs_code HAVING cnt 1;2.2 編碼規(guī)則的三條經(jīng)驗(yàn)工程管理系統(tǒng)的主數(shù)據(jù)紀(jì)律WBS的編碼規(guī)則決定了系統(tǒng)能不能被現(xiàn)場(chǎng)的人用起來(lái)。我見過(guò)不少項(xiàng)目編碼規(guī)則畫了十幾頁(yè)文檔到了現(xiàn)場(chǎng)沒人按規(guī)則填最后系統(tǒng)里全是手工錄入的別名。工程管理系統(tǒng)里編碼規(guī)則要遵守三條經(jīng)驗(yàn)。第一全局唯一。不同標(biāo)段完全可能出現(xiàn)兩個(gè)“3號(hào)倉(cāng)”所以編碼必須帶標(biāo)段前綴不能用流水號(hào)直接打頭。第二分段語(yǔ)義化。每一段對(duì)應(yīng)一個(gè)管理維度讓人看到編碼就能讀出部位和標(biāo)段而不是面對(duì)一串無(wú)含義的數(shù)字。第三編碼發(fā)布權(quán)集中在系統(tǒng)管理員手里不允許各標(biāo)段自行申請(qǐng)?zhí)柖巍,F(xiàn)場(chǎng)人員只能從系統(tǒng)里選擇已發(fā)布的編碼不能手動(dòng)輸入。這里給出一種水電工程常見的WBS編碼分段分段位置含義位數(shù)示例1標(biāo)段/工區(qū)碼2位字母XZ 表示左岸2單位工程碼3位數(shù)字0013分部工程碼2位數(shù)字024分項(xiàng)工程碼2位數(shù)字035單元流水號(hào)4位數(shù)字0014組合出來(lái)就是XZ-001-02-03-0014。每段位數(shù)預(yù)留少一點(diǎn)沒關(guān)系但段與段之間的分隔符必須統(tǒng)一因?yàn)楹竺嫠袌?bào)表都會(huì)用LIKE或SPLIT去解析這個(gè)字段。分隔符不統(tǒng)一統(tǒng)計(jì)口徑就全亂。2.3 合同與WBS之間為什么必須用關(guān)聯(lián)表合同是工程管理系統(tǒng)里另一類核心主數(shù)據(jù)。但很多系統(tǒng)在合同主表里直接加一個(gè)wbs_id字段這就埋了一個(gè)坑大型施工合同經(jīng)??缍鄠€(gè)WBS節(jié)點(diǎn)比如一個(gè)開挖合同同時(shí)覆蓋兩個(gè)單位工程。合同和WBS一旦變成一對(duì)多主表上的單字段就不夠用了。正確做法是單獨(dú)建一張分?jǐn)傟P(guān)聯(lián)表CREATE TABLE contract_main ( contract_id BIGINT PRIMARY KEY AUTO_INCREMENT, contract_code VARCHAR(32) NOT NULL UNIQUE COMMENT 合同編碼, contract_name VARCHAR(255) NOT NULL, party_b VARCHAR(128) NOT NULL COMMENT 承包方編碼, sign_amount DECIMAL(18,2) NOT NULL COMMENT 簽約合同額, currency CHAR(3) DEFAULT CNY, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-已簽訂 1-執(zhí)行中 2-完工結(jié)算中 3-關(guān)閉, sign_date DATE, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB COMMENT合同主表; CREATE TABLE contract_wbs_rel ( contract_id BIGINT NOT NULL, wbs_id BIGINT NOT NULL, amount DECIMAL(18,2) NOT NULL DEFAULT 0 COMMENT 該合同在本W(wǎng)BS節(jié)點(diǎn)的分?jǐn)偨痤~, PRIMARY KEY (contract_id, wbs_id), KEY idx_wbs (wbs_id) ) ENGINEInnoDB COMMENT合同-WBS分?jǐn)傟P(guān)聯(lián)表;contract_wbs_rel里最關(guān)鍵的是amount字段。按WBS匯總投資完成情況時(shí)計(jì)量金額要分?jǐn)偟骄唧wWBS節(jié)點(diǎn)上否則會(huì)出現(xiàn)一個(gè)合同整體進(jìn)度完成50%但沒有人能說(shuō)清是哪一段完成的。分?jǐn)偪趶揭崆昂透鳂?biāo)段約定一般按概算單價(jià)或合同清單價(jià)格來(lái)攤不能由使用者隨意填。建好之后還要加一條約束邏輯每份合同的分?jǐn)偨痤~之和必須等于sign_amount防止財(cái)務(wù)對(duì)賬時(shí)出現(xiàn)合同額與分?jǐn)傤~不一致。3. 進(jìn)度與投資雙控三峽工程管理系統(tǒng)的掙值模型怎么落地3.1 為什么工程管理系統(tǒng)要內(nèi)建掙值分析只看進(jìn)度或者只看錢都管不住大型項(xiàng)目。進(jìn)度形象超前可能只是錢花得多、干得快進(jìn)度落后也可能只是錢沒花出去兩者本身無(wú)法互相說(shuō)明。工程管理系統(tǒng)普遍把計(jì)劃與費(fèi)用放進(jìn)同一個(gè)模型里算這個(gè)模型就是掙值管理EVM。掙值管理的核心是三個(gè)值。PV是到統(tǒng)計(jì)日按計(jì)劃該完成的預(yù)算工作量EV是實(shí)際完成的預(yù)算工作量AC是實(shí)際發(fā)生的費(fèi)用。有了這三個(gè)值就能推出兩個(gè)最常用的指標(biāo)CPIEV/AC衡量成本效率SPIEV/PV衡量進(jìn)度效率。CPI小于1說(shuō)明錢花虧了SPI小于1說(shuō)明工期落后了。指標(biāo)含義數(shù)據(jù)來(lái)源PV截止統(tǒng)計(jì)日按計(jì)劃應(yīng)完成的預(yù)算工作量WBS計(jì)劃任務(wù) × 預(yù)算單價(jià)EV實(shí)際完成且通過(guò)驗(yàn)收的預(yù)算工作量已審核通過(guò)的計(jì)量單 × 預(yù)算單價(jià)AC實(shí)際發(fā)生的費(fèi)用財(cái)務(wù)成本臺(tái)賬工程管理系統(tǒng)里最容易出問(wèn)題的是EV。很多團(tuán)隊(duì)把AC和PV做得非常精細(xì)唯獨(dú)EV靠人工在Excel里填那掙值分析就廢了。正確做法是讓EV從計(jì)量模塊自動(dòng)帶出來(lái)——計(jì)量單審核通過(guò)那一刻這筆金額就已經(jīng)是系統(tǒng)公認(rèn)的“已完成工作”。口徑一開始就要和服務(wù)方講清楚未經(jīng)監(jiān)理審核的計(jì)量單再大也不算EV。3.2 從業(yè)務(wù)表算掙值指標(biāo)實(shí)際業(yè)務(wù)庫(kù)里的掙值計(jì)算通常不是一張表能搞定的。最少要三張表wbs_plan存放每個(gè)WBS節(jié)點(diǎn)按月的計(jì)劃金額measurement_daily存放計(jì)量單明細(xì)cost_actual存放已發(fā)生的實(shí)際成本臺(tái)賬。按WBS節(jié)點(diǎn)鉆取時(shí)SQL可以這樣寫SELECT w.wbs_code, p.pm AS pv, m.ev_amount AS ev, c.ac_amount AS ac, ROUND(m.ev_amount / NULLIF(c.ac_amount, 0), 4) AS cpi, ROUND(m.ev_amount / NULLIF(p.pm, 0), 4) AS spi FROM wbs_node w LEFT JOIN ( SELECT wbs_id, SUM(plan_amount) AS pm FROM wbs_plan WHERE plan_date 2024-06-30 GROUP BY wbs_id ) p ON w.wbs_id p.wbs_id LEFT JOIN ( SELECT wbs_id, SUM(approve_amount) AS ev_amount FROM measurement_daily WHERE approve_time 2024-06-30 AND audit_status 1 GROUP BY wbs_id ) m ON w.wbs_id m.wbs_id LEFT JOIN ( SELECT wbs_id, SUM(actual_amount) AS ac_amount FROM cost_actual WHERE cost_date 2024-06-30 GROUP BY wbs_id ) c ON w.wbs_id c.wbs_id WHERE w.wbs_code LIKE XZ-001% AND w.is_leaf 1 ORDER BY w.wbs_code;三條子查詢分別處理三套口徑。計(jì)劃金額按計(jì)劃日期過(guò)濾EV金額按計(jì)量審核通過(guò)時(shí)間過(guò)濾實(shí)際成本按成本發(fā)生日期過(guò)濾。統(tǒng)計(jì)截止日必須統(tǒng)一否則三個(gè)值跨了不同月份算出來(lái)的指標(biāo)沒有意義。audit_status1這個(gè)條件不能省計(jì)量單只有監(jiān)理審核通過(guò)才能算作有效工程量。NULLIF函數(shù)用來(lái)避免除零當(dāng)某個(gè)WBS節(jié)點(diǎn)還沒有成本或還沒有計(jì)劃時(shí)結(jié)果返回NULL而不是報(bào)錯(cuò)前端展示為空比展示一個(gè)巨大的假數(shù)字更安全。WHERE條件里帶上is_leaf1保證只統(tǒng)計(jì)葉子節(jié)點(diǎn)避免中間節(jié)點(diǎn)因沒有掛接任何計(jì)量單而顯示空的計(jì)劃值。3.3 偏差閾值參數(shù)怎么設(shè)CPI和SPI算出來(lái)之后系統(tǒng)要自動(dòng)判斷該不該報(bào)警。閾值不能寫死在SQL或業(yè)務(wù)代碼里要放到參數(shù)配置表讓計(jì)劃部門每個(gè)月能調(diào)整。水電工程里我一般會(huì)按這樣一組初始值來(lái)配閾值區(qū)間狀態(tài)觸發(fā)動(dòng)作0.95 - 1.05綠正常月度例會(huì)上只需要列數(shù)0.90 - 0.95黃標(biāo)段項(xiàng)目部分析原因下月例會(huì)上匯報(bào)糾偏措施0.85 以下紅啟動(dòng)專項(xiàng)核查重點(diǎn)檢查計(jì)量單和成本臺(tái)賬是否真實(shí)超過(guò) 1.10需要復(fù)核檢查是否有超前計(jì)量、虛假報(bào)驗(yàn)閾值區(qū)間用表驅(qū)動(dòng)好處是調(diào)整閾值不需要發(fā)版。注意黃區(qū)和紅區(qū)不只觸發(fā)顏色變化還要通知到具體責(zé)任人。系統(tǒng)里可以在配置表里維護(hù)一個(gè)threshold_owner字段哪個(gè)值的超標(biāo)通知發(fā)給誰(shuí)避免預(yù)警郵件發(fā)到公共郵箱里沒人看。提示SPI大于1不一定是好事。計(jì)量超前、實(shí)體未完工的情況在工程現(xiàn)場(chǎng)很常見所以對(duì)SPI持續(xù)大于1.10的標(biāo)段要做專項(xiàng)復(fù)核不能只表?yè)P(yáng)。4. 工序報(bào)驗(yàn)與檔案閉環(huán)三峽工程管理系統(tǒng)的質(zhì)量主線怎么建模4.1 質(zhì)檢流程適合用狀態(tài)機(jī)來(lái)建大型工程的質(zhì)量管理底子是“上道工序不合格下道工序不開工”。這句話落到系統(tǒng)里就是一組質(zhì)檢單的狀態(tài)流轉(zhuǎn)。每個(gè)單元工程從開工到被后續(xù)工序覆蓋至少要經(jīng)過(guò)未開工、施工中、待報(bào)驗(yàn)、監(jiān)理驗(yàn)收、通過(guò)、被覆蓋這么幾個(gè)狀態(tài)。很多團(tuán)隊(duì)一上來(lái)就選重型工作流引擎把每個(gè)質(zhì)檢動(dòng)作都包成一條流程。工程系統(tǒng)里其實(shí)更依賴狀態(tài)機(jī)。原因很直接質(zhì)檢流程高度固定審批角色就那么三五個(gè)沒有太多自由流轉(zhuǎn)的需求而狀態(tài)機(jī)能把“未經(jīng)監(jiān)理驗(yàn)收直接進(jìn)入下一道工序”這種非法數(shù)據(jù)擋在數(shù)據(jù)庫(kù)之外。一個(gè)精簡(jiǎn)的質(zhì)檢狀態(tài)機(jī)可以這樣定義states: - OPEN # 未開工 - SELF_CHECK # 班組自檢完成 - APPLY # 已提交監(jiān)理報(bào)驗(yàn) - SUPERVISOR_APPROVE # 監(jiān)理驗(yàn)收中 - REJECTED # 驗(yàn)收不通過(guò) - CLOSED # 驗(yàn)收通過(guò) - COVERED # 已進(jìn)入下道工序 transitions: - from: OPEN to: SELF_CHECK event: SUBMIT_SELF_CHECK # 班組提交自檢結(jié)果 - from: SELF_CHECK to: APPLY event: APPLY_INSPECT # 標(biāo)段項(xiàng)目部提交報(bào)驗(yàn) - from: APPLY to: SUPERVISOR_APPROVE event: INSPECT # 監(jiān)理接受報(bào)驗(yàn)并到場(chǎng) - from: SUPERVISOR_APPROVE to: REJECTED event: REJECT # 監(jiān)理判定不合格 - from: REJECTED to: SELF_CHECK event: RECTIFY # 整改完成重新進(jìn)入自檢 - from: SUPERVISOR_APPROVE to: CLOSED event: APPROVE # 監(jiān)理驗(yàn)收通過(guò) - from: CLOSED to: COVERED event: NEXT_POUR # 后續(xù)工序開工當(dāng)前單元被覆蓋states定義合法業(yè)務(wù)狀態(tài)transitions定義狀態(tài)之間允許的遷移事件。REJECTED只能回到SELF_CHECK重新自檢CLOSED只有覆蓋工序才能進(jìn)入COVERED這樣就從數(shù)據(jù)上避免了先澆筑后驗(yàn)收的問(wèn)題。實(shí)現(xiàn)時(shí)建議把狀態(tài)機(jī)定義存到配置表或獨(dú)立JSON字段里業(yè)務(wù)代碼只負(fù)責(zé)校驗(yàn)當(dāng)前狀態(tài)下事件是否合法。4.2 質(zhì)檢表單與文檔怎么串起來(lái)質(zhì)量閉環(huán)到驗(yàn)收通過(guò)還沒結(jié)束。工程結(jié)束后的竣工檔案里每一倉(cāng)混凝土都要能追溯到自檢記錄、監(jiān)理驗(yàn)收記錄、整改通知和現(xiàn)場(chǎng)照片。所以質(zhì)檢表單和文檔必須是強(qiáng)關(guān)聯(lián)不能等做檔案時(shí)再線下找。文檔表的設(shè)計(jì)要服務(wù)歸檔不只為在線預(yù)覽CREATE TABLE quality_doc ( doc_id BIGINT PRIMARY KEY AUTO_INCREMENT, quality_task_id BIGINT NOT NULL COMMENT 質(zhì)檢任務(wù)ID, doc_type TINYINT NOT NULL COMMENT 文檔類型見碼表, file_path VARCHAR(512) NOT NULL COMMENT 對(duì)象存儲(chǔ)路徑, file_md5 CHAR(32) NOT NULL COMMENT 文件內(nèi)容MD5用于完整性校驗(yàn)和去重, uploader VARCHAR(64) NOT NULL, upload_time DATETIME DEFAULT CURRENT_TIMESTAMP, is_archived TINYINT DEFAULT 0 COMMENT 是否進(jìn)入檔案系統(tǒng), archive_no VARCHAR(64) NULL COMMENT 檔案編號(hào), KEY idx_task (quality_task_id) ) ENGINEInnoDB COMMENT質(zhì)檢文檔表;doc_type用數(shù)字枚舉而不是直接存中文類型名避免歸檔程序被五花八門的用戶輸入干擾。枚舉約定要寫進(jìn)字段注釋也建議做成一張碼表值文檔類型歸檔時(shí)是否必傳1班組自檢表是2監(jiān)理驗(yàn)收表是3整改通知及回復(fù)否4影像附件是file_md5是容易被忽略的字段??⒐n案對(duì)文件的真實(shí)性有要求歸檔時(shí)通過(guò)MD5比對(duì)可以確認(rèn)文件沒有被替換過(guò)也用來(lái)在重復(fù)上傳時(shí)去重。影像附件往往單個(gè)文件十幾兆上傳時(shí)要在服務(wù)端算MD5不要等歸檔任務(wù)去重新讀整個(gè)文件。4.3 歸檔前用腳本做完整性校驗(yàn)檔案管理員最煩的一件事是調(diào)閱時(shí)發(fā)現(xiàn)某單元工程缺了監(jiān)理驗(yàn)收表。與其等人發(fā)現(xiàn)不如在系統(tǒng)里設(shè)一道歸檔前檢查。用Python腳本把所有狀態(tài)已經(jīng)是CLOSED但文檔類型不完整的質(zhì)檢任務(wù)拉出來(lái)import mysql.connector REQUIRED {1, 2, 4} # 自檢表、監(jiān)理驗(yàn)收表、影像附件為必傳 conn mysql.connector.connect( userqms, password****, host127.0.0.1, databasehydro, charsetutf8 ) cur conn.cursor(dictionaryTrue) cur.execute( SELECT t.task_id, t.task_code, GROUP_CONCAT(d.doc_type) AS types FROM quality_task t LEFT JOIN quality_doc d ON t.task_id d.quality_task_id WHERE t.status CLOSED AND t.is_archive_checked 0 GROUP BY t.task_id, t.task_code ) for row in cur: got set(map(int, row[types].split(,))) if row[types] else set() missing REQUIRED - got if missing: print(f{row[task_code]} 缺少文檔類型: {missing}) # 實(shí)際系統(tǒng)中寫入補(bǔ)交通知并阻止該質(zhì)檢任務(wù)進(jìn)入歸檔隊(duì)列 else: cur.execute( UPDATE quality_task SET is_archive_checked 1 WHERE task_id %s, (row[task_id],) ) conn.commit() cur.close() conn.close()腳本依賴mysql-connector-python庫(kù)核心邏輯是取所有已閉環(huán)但尚未歸檔質(zhì)檢的任務(wù)把文檔類型聚合成一行再和REQUIRED集合做差集。腳本只做檢查不直接補(bǔ)數(shù)據(jù)真正的修復(fù)動(dòng)作走補(bǔ)交流程。歸檔檢查放在凌晨定時(shí)跑第二天早上檔案室拿到缺件清單比等項(xiàng)目驗(yàn)收時(shí)補(bǔ)材料輕松得多。5. 報(bào)表與看板三峽工程管理系統(tǒng)的決策視圖怎么設(shè)計(jì)5.1 指標(biāo)按管理層級(jí)分層工程管理系統(tǒng)做到后面真正拉開差距的是報(bào)表層。數(shù)據(jù)都在一個(gè)庫(kù)里但不同層級(jí)的人需要的東西完全不同??偛款I(lǐng)導(dǎo)關(guān)心整體投資完成率和全局預(yù)警項(xiàng)目公司經(jīng)理關(guān)心標(biāo)段排名和整改情況標(biāo)段項(xiàng)目部關(guān)心的是自己手頭還有幾張審批沒有走完??窗逶O(shè)計(jì)要適配角色而不是把一張明細(xì)表打印給所有人。一個(gè)可落地的分層統(tǒng)計(jì)層級(jí)核心指標(biāo)刷新頻率總部總投資完成率、完工標(biāo)段SPI/CPI分布每日項(xiàng)目公司月度投資計(jì)劃完成率、質(zhì)量整改完成率每日標(biāo)段項(xiàng)目部待審批計(jì)量單、待報(bào)驗(yàn)質(zhì)檢單、工序預(yù)警實(shí)時(shí)給決策層看的視圖指標(biāo)數(shù)量要克制??偛靠窗迳现环盼鍌€(gè)以內(nèi)的大數(shù)字和一張預(yù)警清單超過(guò)五個(gè)指標(biāo)看板就變成報(bào)表了。標(biāo)段級(jí)反而可以多放幾張待辦列表因?yàn)槟鞘乾F(xiàn)場(chǎng)干活的人需要盯的動(dòng)態(tài)數(shù)據(jù)。5.2 用月度快照表替代實(shí)時(shí)統(tǒng)計(jì)工程管理系統(tǒng)最讓報(bào)表變慢的查詢是反復(fù)對(duì)跨好幾張表的業(yè)務(wù)流水做SUM和GROUP BY。比如投資完成曲線用戶每次刷新都要重新掃一次整年的計(jì)量明細(xì)。更麻煩的是口徑不穩(wěn)定早上的數(shù)字和晚上的數(shù)字可能對(duì)不上這對(duì)財(cái)務(wù)審計(jì)來(lái)說(shuō)不可接受。常見做法是每天夜間定時(shí)跑批把各WBS的月度計(jì)劃、計(jì)量、成本匯總到一張快照表CREATE TABLE summary_wbs_month ( stat_month CHAR(7) NOT NULL COMMENT 統(tǒng)計(jì)月份格式Y(jié)YYY-MM, wbs_id BIGINT NOT NULL, plan_amount DECIMAL(18,2) DEFAULT 0 COMMENT 該月計(jì)劃金額, measure_amount DECIMAL(18,2) DEFAULT 0 COMMENT 該月經(jīng)審核通過(guò)計(jì)量金額, cost_amount DECIMAL(18,2) DEFAULT 0 COMMENT 該月實(shí)際成本, PRIMARY KEY (stat_month, wbs_id) ) ENGINEInnoDB COMMENTWBS月度匯總快照表;跑批插入邏輯是第3章三條子查詢的按月版本結(jié)果落庫(kù)成快照這里不再重復(fù)貼??煺毡淼氖找嬗腥c(diǎn)報(bào)表接口不再JOIN業(yè)務(wù)明細(xì)表響應(yīng)時(shí)間從秒級(jí)降到毫秒級(jí)每天的數(shù)字固定業(yè)務(wù)人員上午看和下午看一致審計(jì)時(shí)能指認(rèn)“這是某日的快照”歷史月份數(shù)據(jù)不會(huì)被后續(xù)調(diào)整污染哪些計(jì)量單是事后補(bǔ)錄的一眼就能看出來(lái)。5.3 看板接口只查葉子節(jié)點(diǎn)工程看板還有一個(gè)常見的性能浪費(fèi)統(tǒng)計(jì)到中間節(jié)點(diǎn)時(shí)SQL先取一個(gè)節(jié)點(diǎn)的所有下級(jí)再循環(huán)嵌套著去SUM。WBS樹如果很深這種寫法會(huì)讓接口一次請(qǐng)求發(fā)出幾百條SQL。把查詢口徑改成只查葉子節(jié)點(diǎn)再在上層做匯總查詢量會(huì)下降很多SELECT w.wbs_id, w.wbs_code, w.budget_amount FROM wbs_node w WHERE w.wbs_code LIKE XZ-001% AND w.is_leaf 1;只取葉子節(jié)點(diǎn)有幾層好處葉子節(jié)點(diǎn)上掛的計(jì)量單和成本臺(tái)賬最細(xì)匯總出來(lái)的數(shù)字在向下鉆取時(shí)不會(huì)出現(xiàn)“父節(jié)點(diǎn)有數(shù)、子節(jié)點(diǎn)明細(xì)對(duì)不上”的矛盾稀疏的WBS樹不會(huì)在報(bào)表上出現(xiàn)大量空值節(jié)點(diǎn)。看板需要展示中間層級(jí)時(shí)直接用summary_wbs_month按WBS祖先鏈累加不要回到業(yè)務(wù)明細(xì)表現(xiàn)場(chǎng)算。6. 從巨型工程到常規(guī)項(xiàng)目三峽工程管理系統(tǒng)的三條實(shí)施經(jīng)驗(yàn)6.1 先跑通主數(shù)據(jù)再談流程不管項(xiàng)目是千萬(wàn)級(jí)還是億元級(jí)上線順序都一樣先把WBS、單位、人員、合同四張主數(shù)據(jù)表通過(guò)批量導(dǎo)入填好跑一遍檢查腳本確認(rèn)沒有孤兒數(shù)據(jù)——比如計(jì)量單掛在不存在的WBS上、合同沒有分?jǐn)偨痤~——然后再開放流程審批功能。主數(shù)據(jù)是地基地基沒整平就上流程后面等于帶著臟數(shù)據(jù)做業(yè)務(wù)。這個(gè)順序反過(guò)來(lái)的項(xiàng)目我?guī)缀鯖]見過(guò)不返工的。6.2 用Excel模板過(guò)渡不強(qiáng)推在線填報(bào)對(duì)施工單位、供貨商這些外部角色第一天就要求他們?cè)诰W(wǎng)頁(yè)表單里錄入數(shù)據(jù)阻力非常大。常見方案是系統(tǒng)提供固定格式的Excel模板外部單位填好后上傳由服務(wù)端腳本解析并校驗(yàn)把錯(cuò)誤行連同原因一起返回。等外部單位習(xí)慣了這套模板再逐步引導(dǎo)他們用在線填報(bào)遷移成本會(huì)低很多。6.3 上線驗(yàn)收用數(shù)據(jù)對(duì)賬腳本不靠點(diǎn)頁(yè)面最后一條看起來(lái)簡(jiǎn)單但最容易翻車。上線驗(yàn)收時(shí)與其演示十幾條流程不如直接跑一遍數(shù)據(jù)閉環(huán)檢查把漏掉的關(guān)聯(lián)關(guān)系一次性暴露出來(lái)SELECT contract AS biz_type, contract_id AS id, 合同未掛接WBS節(jié)點(diǎn) AS problem FROM contract_main WHERE contract_id NOT IN (SELECT DISTINCT contract_id FROM contract_wbs_rel) UNION ALL SELECT measurement, measure_id, 計(jì)量單缺少WBS節(jié)點(diǎn) FROM measurement_daily WHERE wbs_id IS NULL UNION ALL SELECT quality_task, task_id, 質(zhì)檢單閉環(huán)但無(wú)任何文檔 FROM quality_task WHERE status CLOSED AND task_id NOT IN (SELECT DISTINCT quality_task_id FROM quality_doc);這條檢查腳本把工程管理系統(tǒng)最核心的三條數(shù)據(jù)約束寫死了合同必須有WBS掛接、計(jì)量單必須有部位、質(zhì)檢閉環(huán)必須有文檔。把這三條檢查腳本掛到每周的數(shù)據(jù)質(zhì)量巡檢任務(wù)里和業(yè)務(wù)例會(huì)放在同一天跑。發(fā)現(xiàn)問(wèn)題當(dāng)天處理工程管理系統(tǒng)就不會(huì)在半年后變成數(shù)據(jù)越填越亂、報(bào)表越看越虛的狀態(tài)。本文還有配套的精品資源點(diǎn)擊獲取