簡介這是一份面向電信運營商、CRM項目實施團隊及企業(yè)信息化規(guī)劃人員的系統(tǒng)設(shè)計文檔圍繞中國電信CRM系統(tǒng)建設(shè)進行全景式梳理。內(nèi)容涵蓋系統(tǒng)建設(shè)背景與必要性分析、基于原型法的自上而下實施策略、客戶需求分析、信息共享與客戶細分等設(shè)計關(guān)鍵要素并針對現(xiàn)有系統(tǒng)在信息資源利用率、部門協(xié)作、客戶流失管理、大客戶經(jīng)營分析、潛在客戶開發(fā)等方面的短板提出明確改進方向與落地路徑。文檔既闡述CRM作為管理理念與軟件技術(shù)的雙重屬性也給出分階段、分步驟推進的系統(tǒng)建設(shè)建議可直接用于方案編寫、需求梳理或項目規(guī)劃參考幫助讀者快速把握電信CRM系統(tǒng)設(shè)計的核心框架與實施重點。資源為單個docx文檔壓縮包約264KB內(nèi)容結(jié)構(gòu)完整、條理清晰適合學(xué)習(xí)借鑒。已有328人瀏覽學(xué)習(xí)具有較高參考價值。1. 中國電信CRM設(shè)計系統(tǒng)docx先想清楚這是一張業(yè)務(wù)藍圖不是一篇作文拿到《中國電信客戶關(guān)系管理(CRM)設(shè)計系統(tǒng).docx》這個標題很多人第一反應(yīng)是打開Word找模板。真正做過運營商項目的人會告訴你這份文檔最難的不是排版而是你有沒有把電信業(yè)務(wù)獨有的三戶模型講清楚。客戶、賬戶、用戶三者關(guān)系捋不順后面的數(shù)據(jù)模型、流程設(shè)計、接口定義全是空中樓閣評審會上被業(yè)務(wù)一句話就能問倒。這篇文章按我自己做電信BSS項目的習(xí)慣把一份能過評審、能指導(dǎo)開發(fā)落地的CRM設(shè)計系統(tǒng)文檔拆開講業(yè)務(wù)域怎么分、數(shù)據(jù)模型怎么建、核心流程怎么畫狀態(tài)機、docx本身怎么編排才不挨罵外加五個我踩過不止一次的坑。適合正在寫課程設(shè)計或畢業(yè)設(shè)計的學(xué)生也適合要出系統(tǒng)方案給客戶評審的產(chǎn)品經(jīng)理和售前。你不用懂Java也能跟下來但如果你會讀SQL收獲會更大。2. 從業(yè)務(wù)域到數(shù)據(jù)模型電信CRM的骨架怎么搭寫設(shè)計系統(tǒng)的第一件事不是畫架構(gòu)圖是劃分業(yè)務(wù)域。我一般把電信CRM拆成四個域客戶域管誰在用產(chǎn)品域管賣什么訂單域管怎么賣出去工單觸點域管誰來服務(wù)。計費賬務(wù)單獨劃出去這一點后面專門說。域分清楚了ER圖、功能模塊、菜單結(jié)構(gòu)就都有了掛靠的地方評審人也知道該去哪里找他要的內(nèi)容。很多人上來先畫一張 Spring Boot Vue 的技術(shù)架構(gòu)圖結(jié)果業(yè)務(wù)域沒定義評審人看完只知道你用了微服務(wù)不知道這套系統(tǒng)到底管什么。2.1 三戶模型客戶、賬戶、用戶為什么要分開建模三戶模型是電信CRM區(qū)別于普通電商CRM的根本?？蛻鬋ustomer是法律意義上的簽約人賬戶Account是賬單和付費的歸屬實體用戶Subscriber才是真正使用業(yè)務(wù)的那個標識——手機號、寬帶賬號、固話號碼。舉一個最常見的家庭場景張三作為戶主簽了一份融合套餐?？蛻羰菑埲~戶是這個家庭每月的賬單歸屬用戶是名下的兩個手機號加一條寬帶。欠費停機時是按賬戶停還是按用戶停正確答案是賬戶級凍結(jié)賬戶下所有用戶一起停。你要是把三戶拍平成一張客戶表這個邏輯在數(shù)據(jù)模型層面根本表達不出來。-- 客戶表簽約主體個人或企業(yè) CREATE TABLE cust ( cust_id VARCHAR2(32) PRIMARY KEY, -- 客戶編號全局唯一 cust_name VARCHAR2(128) NOT NULL, -- 客戶名稱 cust_type CHAR(1) NOT NULL, -- 1個人 2政企 cert_type CHAR(2), -- 證件類型 cert_no VARCHAR2(64), -- 證件號碼 create_date DATE DEFAULT SYSDATE ); -- 賬戶表賬單與付費主體一個客戶可掛多個賬戶 CREATE TABLE acct ( acct_id VARCHAR2(32) PRIMARY KEY, cust_id VARCHAR2(32) NOT NULL, -- 歸屬客戶 acct_type CHAR(1) DEFAULT 1, -- 1個人賬戶 2企業(yè)賬戶 pay_method CHAR(1), -- 支付方式 status CHAR(1) DEFAULT 1, -- 賬戶狀態(tài) CONSTRAINT fk_acct_cust FOREIGN KEY (cust_id) REFERENCES cust(cust_id) ); -- 用戶表業(yè)務(wù)使用標識手機號或?qū)拵з~號 CREATE TABLE subs ( subs_id VARCHAR2(32) PRIMARY KEY, acct_id VARCHAR2(32) NOT NULL, -- 歸屬賬戶 access_no VARCHAR2(32) NOT NULL, -- 接入號手機號/固話/寬帶賬號 product_id VARCHAR2(32), -- 訂購的產(chǎn)品 status CHAR(1) DEFAULT 1, -- 有效狀態(tài) CONSTRAINT fk_subs_acct FOREIGN KEY (acct_id) REFERENCES acct(acct_id) );建表順序是 cust → acct → subs外鍵全部向下引用。這樣設(shè)計的一個直接好處是做客戶360視圖時三張表 JOIN 就能拿到一個客戶名下有哪幾個賬戶、每個賬戶掛了哪些號碼而不是在一張大表里用冗余字段硬湊。字段說明里我特意標注了 access_no 是接入號而不是手機號因為寬帶賬號、固話也是 access_no命名語義要能覆蓋全部業(yè)務(wù)類型。提示設(shè)計文檔里凡是出現(xiàn)客戶手機號客戶寬帶賬號這種把實體合并的寫法評審時我都會打回去。字段歸屬實體不清開發(fā)建表必亂。2.2 產(chǎn)品目錄與訂購把套餐變成可配置的銷售品很多初次寫電信CRM的人分不清產(chǎn)品和銷售品。產(chǎn)品Product是原子能力比如寬帶接入、語音通話、流量包銷售品Offer是面向客戶的可售組合比如全家享199元套餐。同一個產(chǎn)品可以被十幾個銷售品引用同一個銷售品也可以包含多個產(chǎn)品加優(yōu)惠。這個區(qū)分直接決定訂購模塊怎么設(shè)計。如果設(shè)計文檔里只有一張?zhí)撞捅砟沁\營一上促銷活動開發(fā)就得改表結(jié)構(gòu)、改代碼然后被業(yè)務(wù)追著罵。正確做法是把產(chǎn)品目錄設(shè)計成可配置的層次結(jié)構(gòu)。-- 銷售品表可售的套餐/優(yōu)惠組合 CREATE TABLE offer ( offer_id VARCHAR2(32) PRIMARY KEY, offer_name VARCHAR2(128) NOT NULL, -- 銷售品名稱 offer_type CHAR(1), -- 1基礎(chǔ)產(chǎn)品 2組合套餐 3優(yōu)惠 price NUMBER(10,2), -- 標準價格 status CHAR(1) -- 上下架狀態(tài) ); -- 銷售品與產(chǎn)品的關(guān)系表一個銷售品包含多個基礎(chǔ)產(chǎn)品 CREATE TABLE offer_prod_rel ( rel_id VARCHAR2(32) PRIMARY KEY, offer_id VARCHAR2(32) NOT NULL, -- 銷售品ID product_id VARCHAR2(32) NOT NULL, -- 產(chǎn)品ID effective_date DATE, -- 生效日期 expire_date DATE -- 失效日期 );兩個關(guān)鍵參數(shù)要特別說明。effective_date 和 expire_date 控制產(chǎn)品和銷售品的有效期這直接決定了一個老套餐到期后已訂購客戶還能不能續(xù)費新客戶能不能下單。很多翻車現(xiàn)場都是因為文檔里漏了有效期設(shè)計導(dǎo)致老套餐下架時存量用戶跟著遭殃。另外 offer_type 里我把優(yōu)惠單獨列出來因為優(yōu)惠往往是限時疊加的和普通套餐的生命周期管理完全不同。2.3 CRM與計費賬務(wù)的邊界哪些需求不能寫進這份文檔這是評審會上最容易被拍磚的地方。需求方經(jīng)常把所有BSS業(yè)務(wù)支撐系統(tǒng)需求都叫成CRM于是設(shè)計文檔里混進了出賬規(guī)則、賬單打印模板、月租計算邏輯。這種混寫會導(dǎo)致文檔范圍失控而且評審時會被反問CRM要是算月租那計費系統(tǒng)干什么我的做法是在文檔第二章就放一張邊界表明確這份文檔管什么、不管什么能力域歸屬系統(tǒng)本文檔處理方式客戶/產(chǎn)品/訂單受理CRM詳細設(shè)計促銷活動配置CRM營銷模塊詳細設(shè)計月結(jié)出賬、賬單生成計費賬務(wù)系統(tǒng)只約定接口不展開繳費、銷賬收費系統(tǒng)只約定接口欠費停機管控信控系統(tǒng)引用外部規(guī)則裝維施工工單調(diào)度系統(tǒng)流程協(xié)同設(shè)計邊界表的價值不只是給評審人看更是給開發(fā)團隊看的。它告訴后端團隊哪些表歸你建哪些表你只能調(diào)用接口。我在實際項目里見過最迷惑的代碼就是CRM服務(wù)里自己寫了個定時任務(wù)去生成賬單——因為設(shè)計文檔沒寫邊界開發(fā)順手就把賬務(wù)邏輯實現(xiàn)了。2.4 觸點與工單協(xié)同營業(yè)廳、裝維、客服共享一份客戶視圖電信CRM的觸點比一般企業(yè)系統(tǒng)多得多營業(yè)廳坐席是B/S端裝維師傅用的是手機App客服在呼叫中心還有網(wǎng)上營業(yè)廳和自助終端。設(shè)計文檔里必須有一節(jié)專門講觸點協(xié)同核心訴求是所有觸點看到的是同一份客戶360視圖。裝維場景最能說明問題。師傅上門裝寬帶掃設(shè)備條形碼、掃用戶裝機地址現(xiàn)場拍照回傳這就是現(xiàn)在常見的crm管理系統(tǒng)結(jié)合掃碼采集落地形態(tài)。設(shè)計上需要明確掃碼采集的數(shù)據(jù)走移動端安全接入通道回傳設(shè)備編碼回傳后自動關(guān)聯(lián)訂單和客戶ID師傅端只看到工單關(guān)聯(lián)的客戶信息證件號碼要做脫敏展示。觸點的數(shù)據(jù)權(quán)限矩陣建議用表格收斂否則后期上線必出權(quán)限事故觸點使用人數(shù)據(jù)范圍典型操作營業(yè)廳坐席營業(yè)員本區(qū)域全量客戶開戶、變更、銷戶受理裝維App裝維師傅僅本人工單關(guān)聯(lián)客戶掃碼采集、回單客服工作臺客服全量客戶證件脫敏查詢、外呼、工單發(fā)起網(wǎng)上營業(yè)廳客戶本人僅本人名下自助查詢、繳費工單是訂單在服務(wù)環(huán)節(jié)的延伸。訂單進入施工狀態(tài)后生成裝維工單工單回單觸發(fā)訂單狀態(tài)流轉(zhuǎn)。文檔里要定義工單與訂單的關(guān)聯(lián)字段order_id 是必填外鍵并說明一個訂單可以拆成多個工單的場景——比如寬帶加IPTV同時施工就拆成兩條工單。這一步不寫清楚開發(fā)階段就會爭議工單到底算訂單的子表還是獨立表。3. 把設(shè)計裝進docx章節(jié)骨架、字段字典與排版規(guī)范系統(tǒng)設(shè)計做完了接下來是把設(shè)計裝進docx。這一章是很多人最容易糊弄的但恰恰是評審體驗的關(guān)鍵。一份排版混亂的文檔哪怕內(nèi)容是對的評審人也只會覺得這人還沒想清楚。3.1 設(shè)計文檔的章節(jié)骨架八段式結(jié)構(gòu)我寫這類設(shè)計系統(tǒng)文檔固定用八段式結(jié)構(gòu)覆蓋從背景到落地的完整鏈路章節(jié)內(nèi)容評審人關(guān)注點1 引言背景、目標、范圍、術(shù)語表范圍和術(shù)語是否一致2 總體架構(gòu)邏輯架構(gòu)、部署架構(gòu)、技術(shù)選型架構(gòu)是否合理、是否過度設(shè)計3 功能設(shè)計按業(yè)務(wù)域拆模塊、用例功能是否覆蓋需求4 數(shù)據(jù)設(shè)計ER圖、字段字典字段是否完整、命名是否規(guī)范5 接口設(shè)計系統(tǒng)間接口清單、報文邊界是否清晰6 非功能需求性能、安全、可用性指標是否可度量7 實施計劃里程碑、分工排期是否現(xiàn)實8 附錄評審記錄、變更記錄留痕是否完整術(shù)語表這一節(jié)很多人不寫但在電信項目里幾乎必被問?？蛻簟①~戶、用戶、銷售品、產(chǎn)品、工單、竣工——這些詞在不同人口中含義完全不同。我見過評審會上業(yè)務(wù)方說用戶指的是手機號開發(fā)說用戶指的是登錄賬號吵了十分鐘才對齊。術(shù)語表放在第一章評審前先花兩分鐘過一遍能省掉大量無效爭論。3.2 字段字典表實體屬性的唯一事實來源ER圖只畫實體和關(guān)系字段定義必須以字段字典為準。字段字典是設(shè)計文檔的唯一事實來源開發(fā)建表、前端表單、接口報文全部以它為準。前后端對字段有疑問先查字典查不到再討論而不是各說各話。字段名類型長度必填默認值業(yè)務(wù)說明cust_idVARCHAR232是無客戶編號全局唯一cust_nameVARCHAR2128是無客戶名稱cust_typeCHAR1是11個人 2政企cert_noVARCHAR264否無證件號碼脫敏展示statusCHAR1是10失效 1有效命名規(guī)范要寫死在文檔前面一律小寫下劃線禁止大小寫混用主鍵統(tǒng)一叫 xxx_id狀態(tài)字段統(tǒng)一用 CHAR(1) 并注釋枚舉含義時間字段統(tǒng)一 DATE 類型。這些規(guī)則看起來瑣碎但能避免聯(lián)調(diào)時他這張表叫 custId我那張表叫 customer_id的經(jīng)典慘劇。3.3 Word排版規(guī)范讓評審人十分鐘找到他想找的docx 的排版規(guī)范不需要花哨核心是可導(dǎo)航、可追蹤。我一般要求文檔滿足以下幾條硬性規(guī)則第一標題必須用 Word 內(nèi)置的標題1/標題2/標題3樣式禁止手動調(diào)字號加粗。只有用了內(nèi)置樣式導(dǎo)航窗格和自動目錄才能工作評審人才能按目錄跳轉(zhuǎn)。第二多級編號用 1 / 1.1 / 1.1.1 的自動編號不要手打數(shù)字否則中間插入一章后面全部要手動改。第三所有流程圖統(tǒng)一用 draw.io 或 Visio 導(dǎo)出 PNG畫布大小統(tǒng)一禁止截圖糊成一片。第四表格統(tǒng)一樣式字段字典表、狀態(tài)表、接口清單的列頭格式保持一致。還有一條很多人忽略交付時同時給 docx 和 PDF。docx 給項目組做批注修訂PDF 給評審人和外部專家防止格式漂移。Word 在不同版本間打開字體和行距會變PDF 不會。3.4 版本管理與評審意見留痕設(shè)計文檔不是寫一次就完事它要跟著評審迭代。文檔第一頁必須放版本記錄表版本日期修改人修改說明v1.02024-06-01張三初稿v1.12024-06-08李四按第一輪評審意見修訂數(shù)據(jù)模型v2.02024-06-15張三增加接口設(shè)計章節(jié)文件名規(guī)范建議CRM設(shè)計系統(tǒng)_v2.0_20240615.docx。版本號加日期杜絕最終版最終版2打死不改版這種命名。評審意見留痕用意見表每次評審一張序號、原文位置、評審意見、處理結(jié)果接受/拒絕/延后、責(zé)任人。不要口頭改完就算了沒有留痕的評審等于沒評?；仡^出了爭議意見表就是決策依據(jù)。4. 核心流程的狀態(tài)機設(shè)計開戶、變更、銷戶三條主線CRM的功能設(shè)計里開戶、變更、銷戶是繞不開的三條主線。很多文檔在這部分畫三張粗箭頭流程圖就結(jié)束了評審時看著沒問題開發(fā)做起來全是窟窿。我的建議是流程必須落到狀態(tài)機把每個狀態(tài)的合法轉(zhuǎn)移和異常分支寫死。4.1 開戶流程選品→訂單→施工→竣工的狀態(tài)機開戶不是營業(yè)員點一下保存就完事。一個典型的寬帶開戶要經(jīng)歷選品、下單、受理、派單施工、竣工確認五個階段。設(shè)計文檔里用狀態(tài)機表表達比流程圖畫得清楚得多當前狀態(tài)觸發(fā)動作下一狀態(tài)責(zé)任人待受理客戶提交訂單已受理營業(yè)員已受理系統(tǒng)派發(fā)施工施工中系統(tǒng)施工中裝維回單已竣工裝維師傅施工中裝維上報失敗施工失敗裝維師傅施工失敗改派重試施工中調(diào)度系統(tǒng)已竣工系統(tǒng)歸檔已歸檔系統(tǒng)待受理/已受理客戶撤銷已取消營業(yè)員狀態(tài)機表之后我習(xí)慣再配一段極簡的狀態(tài)轉(zhuǎn)移校驗代碼目的是告訴開發(fā)狀態(tài)流轉(zhuǎn)要寫合法性校驗不能隨意跳轉(zhuǎn)# 開戶訂單狀態(tài)機合法轉(zhuǎn)移關(guān)系開發(fā)照此實現(xiàn)校驗邏輯 ALLOWED_TRANSITIONS { 待受理: [已受理, 已取消], 已受理: [施工中, 已取消], 施工中: [已竣工, 施工失敗], 施工失敗: [施工中, 已取消], # 改派重試或最終取消 已竣工: [已歸檔], } def can_transit(current: str, target: str) - bool: return target in ALLOWED_TRANSITIONS.get(current, [])這段代碼的核心邏輯是當前狀態(tài)只能轉(zhuǎn)移到白名單里的目標狀態(tài)其他一律非法。有了這張白名單開發(fā)就不會寫出已竣工還能改回施工中這種匪夷所思的代碼?？⒐幼饕瑫r觸發(fā)設(shè)備開通指令這個細節(jié)也要在文檔里寫明狀態(tài)機只負責(zé)訂單狀態(tài)真正的業(yè)務(wù)動作掛在轉(zhuǎn)移邊上。4.2 變更流程訂單拆分、回退與異步寫卡變更比開戶更容易翻車因為一次變更往往涉及多個動作。比如客戶申請換套餐加裝副卡表面上是一個請求實際拆成三個子訂單套餐變更單、副卡開卡單、寫卡單。設(shè)計文檔里必須定義訂單拆分規(guī)則。子訂單類型業(yè)務(wù)動作完成標志套餐變更單舊銷售品失效、新銷售品生效生效時間到達副卡開卡單新增一個用戶標識并關(guān)聯(lián)賬戶用戶狀態(tài)變?yōu)橛行懣▎蜸IM卡寫號寫卡設(shè)備返回成功回退規(guī)則是和拆分同樣重要的設(shè)計點。主訂單回退時子訂單怎么處理我的習(xí)慣是定義級聯(lián)回退主訂單取消所有未竣工的子訂單自動作廢已竣工的保持不變但生成反向單。這塊如果文檔里不寫開發(fā)遇到回退場景就會各自為政有的刪數(shù)據(jù)有的改狀態(tài)最后數(shù)據(jù)全對不上。異步寫卡是一個經(jīng)常被忽視的設(shè)計點。寫卡是外部設(shè)備操作耗時且可能失敗所以不能放在訂單受理的事務(wù)里同步做。設(shè)計上應(yīng)該是受理成功先落庫訂單狀態(tài)保持已受理寫卡結(jié)果通過回調(diào)或輪詢更新。文檔里寫明異步執(zhí)行、失敗可重試這八個字后端團隊就不會把寫卡寫進主事務(wù)。4.3 銷戶流程欠費校驗、在途單攔截與挽留銷戶是三條主線里最敏感的一條直接關(guān)系到客戶資產(chǎn)和收入。設(shè)計文檔里要把銷戶的校驗順序?qū)懬宄樞蝈e了就是事故第一步校驗在途訂單?？蛻裘逻€有未竣工的工單或未完成的變更單不能直接銷戶系統(tǒng)提示存在在途業(yè)務(wù)。第二步校驗欠費。有欠費的客戶引導(dǎo)先繳費這里只做校驗不處理賬務(wù)繳費走收費系統(tǒng)接口。第三步確認銷戶。客戶確認后賬戶狀態(tài)改為凍結(jié)所有關(guān)聯(lián)用戶停用。第四步觸發(fā)拆機工單。裝維上門拆設(shè)備回單后賬戶歸檔。第五步挽留。高價值客戶在確認環(huán)節(jié)插入挽留流程派發(fā)外呼工單給客服。挽留這條線很多設(shè)計文檔完全沒寫。實際運營中銷戶確認頁面彈一個為您保留號碼的挽留提示能留下相當比例的離網(wǎng)客戶。文檔里至少要有觸發(fā)條件客戶價值等級高于閾值、執(zhí)行方式生成挽留工單給客服、超時處理48小時未聯(lián)系則繼續(xù)銷戶流程。5. 電信CRM設(shè)計文檔的5個高頻踩坑點以下五個坑來自我實際做過的電信項目每條都按現(xiàn)象到原因再到解決寫清楚。這些坑的共同點是評審會上看不出來開發(fā)階段集體遭殃。5.1 三戶模型被拍平成一張大表現(xiàn)象設(shè)計文檔的ER圖里只有一張客戶表字段里同時塞了客戶名稱、手機號、寬帶賬號、賬單地址、欠費金額。原因?qū)懳臋n的人拿普通電商CRM的經(jīng)驗套電信業(yè)務(wù)沒理解三戶模型的業(yè)務(wù)語義。解決文檔里強制畫三戶關(guān)系圖客戶、賬戶、用戶三張表必須分開并在數(shù)據(jù)設(shè)計章節(jié)說明賬戶凍結(jié)則關(guān)聯(lián)用戶全部停用這條業(yè)務(wù)規(guī)則。評審時我把這條列為必查項。5.2 計費賬務(wù)需求混進CRM設(shè)計文檔現(xiàn)象文檔的功能設(shè)計里出現(xiàn)了月租自動扣費賬單打印模板滯納金計算這些內(nèi)容。原因需求方把所有BSS需求都叫CRM寫文檔的人照單全收。解決在文檔總體架構(gòu)里放一張系統(tǒng)邊界表明確CRM負責(zé)受理和客戶管理計費賬務(wù)只做接口約定。一旦發(fā)現(xiàn)功能清單里有賬務(wù)類需求直接劃到接口設(shè)計章節(jié)或者明確不在本系統(tǒng)范圍。5.3 流程圖只畫happy path現(xiàn)象開戶流程圖從選品畫到竣工一路到底沒有回退分支。開發(fā)實現(xiàn)時發(fā)現(xiàn)客戶中途撤銷、施工失敗、設(shè)備缺貨統(tǒng)統(tǒng)沒有狀態(tài)定義。原因畫圖時只沿著正常流程走了一遍沒有逐節(jié)點問這里失敗了怎么辦。解決每個流程節(jié)點旁邊標注異常分支用狀態(tài)機表兜底。我在文檔里有一句硬性要求凡是流程圖涉及狀態(tài)變化必須附狀態(tài)機表沒有狀態(tài)機的流程設(shè)計不予評審。5.4 字段字典與ER圖對不上現(xiàn)象ER圖里實體叫 user_id字段字典里同一個字段叫 subs_id開發(fā)按ER圖建表前端照著字段字典做接口聯(lián)調(diào)時對不上。原因多人協(xié)作圖和字典各改各的沒有做一致性檢查。解決交付前用腳本從docx里提取兩處定義逐一比對。具體做法下一章展開核心原則是圖和數(shù)據(jù)字典必須出自同一版本且由同一個人負責(zé)維護。5.5 權(quán)限設(shè)計漏掉渠道隔離和掃碼采集現(xiàn)象裝維師傅拿著手機App能查到客戶的完整證件號和付費賬戶信息。原因權(quán)限只按角色設(shè)計沒按渠道數(shù)據(jù)范圍設(shè)計。裝維角色和營業(yè)員角色都配了客戶查詢權(quán)限但沒有區(qū)分數(shù)據(jù)邊界。解決文檔里加觸點權(quán)限矩陣按觸點×角色×數(shù)據(jù)范圍三要素定義。裝維App的數(shù)據(jù)范圍限定為僅本人工單關(guān)聯(lián)客戶且證件號、銀行卡必須脫敏掃碼采集只回傳設(shè)備編碼和定位信息不拉取客戶全量資料。6. 交付前最后一道工序用字段字典反向校驗設(shè)計文檔寫到最后別急著發(fā)出去。我每次交付前都會做一道反向校驗工序?qū)ｉT抓文檔自相矛盾的問題。第一步從ER圖里抽出所有實體清單列成一張Excel每個實體一行。第二步打開字段字典逐個實體核對字段是否齊全。重點查三件事主鍵有沒有定義、外鍵有沒有指向、狀態(tài)字段的枚舉值有沒有寫注釋。第三步核對命名一致性——ER圖里的實體名和字典里的表名必須完全一致差一個下劃線都算不合格。第四步把這份核對表附在文檔附錄里評審人可以自己復(fù)核。這道工序抓出過不少問題。有一次我發(fā)現(xiàn)字段字典里 subs 表有 acct_id但ER圖里這兩張實體之間沒畫關(guān)系線——開發(fā)照著ER圖建表外鍵就漏了。這種問題靠人眼很難發(fā)現(xiàn)所以我還習(xí)慣用腳本做一次docx的標題層級檢查from docx import Document doc Document(中國電信客戶關(guān)系管理(CRM)設(shè)計系統(tǒng).docx) last_level 0 for p in doc.paragraphs: if p.style.name.startswith(Heading): level int(p.style.name.split()[-1]) # Heading 1 - 1 if last_level and level last_level 1: print(f標題層級跳躍: {p.text} ({p.style.name})) last_level level這段代碼用 python-docx 讀取文檔里的段落樣式找出標題1直接跳到標題3的層級斷層。如果你用的是Java技術(shù)棧原理一樣用 Apache POI 遍歷 XWPFParagraph檢查 getStyle() 的樣式名再按段落順序做層級比較。目的不是炫技是保證目錄結(jié)構(gòu)干凈——我見過一份設(shè)計文檔的目錄里同一層級的標題有三種不同格式評審人翻目錄就失去了耐心。除了腳本檢查還有一個懶辦法很管用找一位沒參與過前期討論的同事只給文檔和一份開戶流程走查清單讓他按文檔內(nèi)容模擬走一遍開戶、變更、銷戶。他卡在哪哪里就是文檔的缺口。這個方法我每次都用每次都能逮到一兩個我以為寫清楚了其實沒寫的地方。最后提醒一句字段字典是文檔的錨點ER圖、接口報文、測試用例全部要向它對齊。這個反向校驗的工序我已經(jīng)養(yǎng)成習(xí)慣它幫我避免了好幾次上線前一天才發(fā)現(xiàn)字段對不上的尷尬。希望幫到你。本文還有配套的精品資源點擊獲取