前阵子参加一个信息化建设项目的方案评审承建方把PPT翻到“总体架构”那一页一张图塞了两百多个图标防火墙画在图的右上角离核心交换机隔着十万八千里字号缩到6号勉强能看清。台上讲得满头大汗台下专家只问了一句你这台防火墙到底部署在哪条链路上全场安静。这个场景我见过太多次了。信息化项目前期方案编制最见功底的往往不是那几十页文字而是几张图。画图这件事看着简单真正画得好的没几个。这个系列前面聊过需求调研怎么组织、方案框架怎么搭这篇单聊“四张图”。在前期方案编制里最常用的一套图是业务流程图、系统架构图、网络拓扑图和数据流图。这套组合不是强制标准是我在政务和企业类信息化项目实践中验证过比较扛得住评审的一套口径。你说不清楚这四张图各干什么、怎么画、画到什么程度方案评审这关会非常难过。这篇文章把我这些年画图的思路、步骤和踩过的坑一次性说透。1. 为什么前期方案里的图经常被评审一眼看穿1.1 图是“压缩包”不是“装饰画”很多人理解错了图在方案里的作用。前期方案里的图本质是一个信息压缩包——把几十页文字描述的结构关系、流程关系、部署关系压缩到一页纸里让评审专家在30秒内建立对项目的整体认知。它不是文档排版的美化工具更不是凑页数的素材。评审专家的读图习惯和普通读者不一样。普通读者会从左上角开始逐个图标看过去试图理解每个框是什么。评审专家则先看三样东西图的标题和结论、图的边界范围、图里有没有明显的逻辑缺失。然后他会沿着图的主路径走一遍走到某个环节发现断头路或者走到某条连线发现没有标注含义心里就会开始打问号。我见过太多“装饰画”式的架构图每个模块都画了颜色五彩斑斓图标精美但仔细一看模块之间没有连线或者连线没有方向或者连线有方向但没有语义说明。这种图在评审会上根本没有办法回答“这个系统怎么跟那个系统对接”的问题。评审专家看不明白方案被质疑的风险就会急剧上升。1.2 前期方案阶段的图颗粒度怎么拿捏前期方案不是详细设计图切忌沉到接口级、字段级的细节。很多新手画图容易走极端要么画得太粗整个系统一个大方框要么画得太细模块下面的二级功能、三级功能全画上去一张图塞得密密麻麻。这里有一个我自己总结的判断标准图里的每个方框都能在方案正文里找到对应的说明段落每条连线都能说清楚它代表什么含义。如果图里有任何一个要素在文字部分找不到解释那这个要素要么是多余的要么是文字部分漏写了。两种情况都说明图表和正文没有对齐这是评审专家非常反感的问题。颗粒度的经验值供参考系统架构图的信息层级控制在三层以内展现层、应用层、数据层网络拓扑图的网络区域控制在四到五个以内业务流程图的业务环节控制在十五个以内。如果一页A4纸放不下这张图优先考虑拆成总图和分图而不是缩小字体硬塞进去。缩小字体不是解决问题的办法只是把问题从“看不清”变成“看不清且显得很不专业”。2. 四张图的分工业务、系统、网络、数据各回答一个问题2.1 先对齐口径这四张图到底指什么业内对“四张图”说法并不统一有些是架构师视角的“业务架构图、应用架构图、技术架构图、数据架构图”有些是集成商视角的“系统架构图、网络拓扑图、数据流图、部署架构图”。从我参与过的项目来看前期方案编制阶段最实用的组合是业务流程图、系统架构图、网络拓扑图和数据流图。如果承接的项目有甲方明确规定的图清单按甲方的标准执行如果没有明确规定这套组合是经过验证的选择。每张图回答一个核心问题不要互相越界。我画图之前会先跟团队对一遍这个表格图名回答的核心问题图里的核心要素画到什么颗粒度业务流程图业务是怎么跑的角色、环节、表单、判断条件、异常分支到岗位/角色级不是部门级系统架构图系统帮业务做了什么模块、层次、模块之间的调用关系到二级模块级即可网络拓扑图系统部署在哪里、怎么连网络区域、设备、链路、安全边界到设备级不画端口号数据流图数据从哪里来到哪里去数据源、数据流向、存储位置、消费方到数据实体级不画字段这四张图对应了项目干系人最关心的四个维度业务部门关心业务是否被覆盖信息中心关心系统边界是否合理网络运维关心部署和链路是否可行开发团队关心数据从哪来、接口工作量有多大。缺一张图就有一类干系人的问题在评审会上没法被正面回答。2.2 四张图之间是推导关系不是并列关系这四张图不是随便画的四张独立的图它们之间有严格的推导顺序。我画图时的顺序是业务流程图先行系统架构图跟着业务走数据流图从业务流程里抽数据轨迹最后才是网络拓扑图落地部署。这个顺序不能乱。原因很简单业务流程决定系统功能系统功能决定数据流转数据流转和系统部署共同决定网络拓扑。很多团队习惯先画网络拓扑图因为这张图看上去最“技术”、最容易动手画。但如果没有前面的业务和系统设计做支撑画出来的拓扑图只能是一个标准的三层架构模板放到任何项目里都成立也就等于什么都没说。这种没有项目特征的拓扑图在评审会上是立不住的——专家问“为什么这三个服务器放在同一个区域”答案只能是“模板就是这样”这就露怯了。3. 业务流程图一切设计的起点3.1 画图之前先把流程拆成活动清单业务流程图的输入是调研阶段的访谈记录、制度文件、现有系统操作说明书。很多人拿到这些素材直接就开始画图结果画到一半发现流程环节对不上又重新回去翻资料浪费时间且容易出错。我习惯先做一步“流程拆解”把访谈和制度文件里描述的业务过程拆成一条活动清单用表格记录。字段很简单序号、环节名称、执行角色、输入用到什么表单或数据、输出产生什么结果、异常情况备注。以采购申请流程为例这个表格大概长这样序号环节执行角色输入输出异常备注1提交采购申请需求部门经办人采购需求说明采购申请单预算不足退回修改2部门负责人审批需求部门负责人采购申请单审批意见驳回则流程终止3采购专员复核采购部门专员审批通过的采购申请单采购计划草稿资料不全退回补正4分管领导审批分管领导采购计划草稿正式采购计划驳回则回到环节3这个表做到位了画泳道图其实就是把表格内容搬到图上的过程不需要现场再想逻辑。表格还有一个额外的好处它可以直接作为需求调研报告的附件帮助评审专家理解流程拆解的来源。3.2 泳道图的两个画法和四个常见错误业务流程图建议用泳道图跨功能流程图来画每条泳道代表一个角色或一个部门。画法上有两种选择竖向泳道适合环节较少的流程十二个环节以内横向泳道适合环节多、分支多的大流程。优先推荐横向泳道因为大多数方案文档是A4竖版排版横向泳道图更容易控制宽度不会因为图太宽被压缩到看不清文字。画泳道图最常见的四个错误我基本在每个项目里都会遇到第一个错误是把系统画成泳道。人和系统是两个维度的参与者系统不承担业务判断只是人的操作工具。把“系统”当成泳道会导致流程图上出现大量“系统处理”“系统自动判断”这种没有实际业务含义的节点。正确的做法是人所在的泳道负责业务环节系统操作作为环节注解写在节点旁边而不是画一条系统泳道。第二个错误是判断条件写一半。判断框有两个出口但图上只画了“是”的出口或者“否”的出口悬空不知道流向哪里。这是流程逻辑不完整最直观的表现。评审专家只要看到一条悬空的箭线基本就能断定流程梳理没有闭环。第三个错误是只有正常路径没有异常路径。前期的业务流程都是理想状态的流程术语叫做“happy path”。实际业务流程一定有退回、驳回、补正、终止这些异常分支。不一定每个异常都要画出来但影响业务闭环的异常分支至少要画一条比如审批驳回后的去向。第四个错误是流程边界没有切割。业务是循环的、连续运转的但方案里的流程要按项目范围切割。如果项目只做采购管理那流程图就只画从采购申请到采购计划这一段后面的供应商管理、订单管理可以不画。很多人被“流程要完整”困住非要把上游下游全画进去最后画出来的图又大又复杂反而模糊了项目范围。3.3 异常分支与流程边界怎么处理关于异常分支前期方案阶段有一个取舍原则画出影响需求理解的分支省略实现细节的分支。审批驳回、资料退回、校验失败这些影响整体流程闭环的异常分支必须画至于“网络超时”“并发冲突”这类的异常那是详细设计阶段的时序图该关注的内容放前期方案里只会让图变得不可读。流程边界的处理更讲究。我见过很多流程图从“提出需求”开始画到“归档”结束一个流程画了二十多个环节很多环节根本不在项目范围内。这是没有意识到流程图的另一重作用——它是一种需求确认工具。如果你把项目范围之外的上下游环节画进去甲方会默认这些环节也是本次项目要实现的功能后续需求确认时就会产生歧义。所以画图前先划清楚本项目的流程起点是什么终点是什么哪些环节是项目外部衔接点但不需要内部实现。外部衔接可以用“外部系统”或“外部角色”标注一笔带过不要展开。4. 系统架构图与网络拓扑图一块硬币的两面4.1 系统架构图模块、层次和连线语义系统架构图展示的是“系统帮业务做了什么”。前期方案阶段系统架构图通常用分层结构展现层面向用户的门户、PC端、移动端、应用层业务功能模块、数据层数据库、文件存储如果涉及多系统对接还需要加一个接口层或集成层。每一层内部要放什么、不放什么有一个实用的标准放“需求中明确要求的、用户能感知的功能模块”不放“实现机制类的东西”。用户能感知的是“采购管理”“合同管理”“系统管理”这类的业务模块实现机制类的是“权限控制”“消息队列”“缓存服务”这类技术组件。前者应该出现在系统架构图上后者如果硬放上去只会让图变得很“技术”甲方看不懂评审专家又会追问技术选型的细节——在前期阶段这些细节还没有定论问了也白问。模块之间的连线要标注语义。很多图犯了“连线无义”的毛病模块A和模块B之间既没箭头、也没文字两条框用一条线连着。这种线表达的是什么是数据同步、接口调用、页面跳转还是消息通知图上不说评审专家只能猜。不标语义的连线等于没有连线。我要求项目组画图时连线必须带箭头和简短动词比如“调用”“同步”“推送”一条线超过两个字就说明关系没定义清楚需要回炉。4.2 网络拓扑图分区、设备和链路要说清楚网络拓扑图是业主单位的信息中心最关心的一张图也是前期方案里最容易出现“模板痕迹”的一张图。拓扑图要画清楚的关键信息其实就三类区域划分、设备与系统的对应关系、链路与安全边界。区域划分上典型的前期方案网络拓扑图至少要有互联网接入区、核心交换区、应用服务区、数据存储区有第三方对接需求的项目还要画对接区或前置区。每个区域里放什么设备、什么服务器要标注清楚。特别要提醒的是安全设备的位置要精确到“串接在哪条链路上”防火墙画在应用服务区旁边但没有画链路等于没画。评审专家问“你的安全边界在哪里”你如果只能回答“墙在边上”那这个安全设计就没有任何说服力。系统架构图里的每个应用模块在拓扑图里要有对应的部署位置。系统架构图里有“文件服务”模块拓扑图里就要有一台文件服务器或对象存储节点系统架构图里写“与第三方短信平台对接”拓扑图里就要画出这个对接链路从哪里出去经过什么安全设备。让“两张图一一对应”这个要求是我画拓扑图时反复检查的核心项。链路标注是很多图的失分点。拓扑图里每段链路要标线型和带宽互联网接入区的带宽是多少、核心交换机到应用服务器的链路是千兆还是万兆、异地链路是租用专线还是走政务外网。这些信息在前期方案阶段可以被标注为“待定”但不能不标。链路是网络方案的直接成本来源链路不标清楚甲方对预算就没有判断依据。4.3 两张图对不上评审一问就露馅系统架构图和网络拓扑图对不上是评审会上最尴尬的局面之一。我遇到过这样的情况系统架构图上画了三个业务系统网络拓扑图上只有两台服务器方案文字部分写着“与上级平台对接”拓扑图里却找不到任何外部链路的痕迹。专家只要把图往投影上一放逐行对照问题马上就来。为了避免这个问题我建议画完两张图之后做一次“模块-设备-区域”对照检查。具体方法是建一个表把系统架构图里的模块列出来标注它对应的业务系统再到拓扑图里找这台系统部署在哪个区域、用的是哪台服务器或虚拟机最后记录这个系统的对外接口是走哪条链路。跑完这个表两张图有没有缺口一目了然。这个过程也可以顺带验证硬件设备清单是否合理——很多项目的服务器数量就是这么从图里出来的。5. 数据流图最容易被忽略却直接决定开发量5.1 数据从哪里来、到哪里去要画到什么程度数据流图在整个四张图里属于最容易被“简化”掉的一张。业务流程图有业务部门盯着系统架构图有评审专家盯着网络拓扑图有信息中心盯着数据流图经常没人看于是很多方案里直接不画或者用一句话带过本项目数据存储于中心数据库。这句话我见过太多次每次看到都想叹气——数据流图恰恰是后续开发工作量估算最直接的依据省掉这张图麻烦的是后面写代码的人。前期方案阶段的数据流图画到“数据实体级”就够了不需要画到字段级。要表达的内容有四类元素数据源数据在哪里产生、数据处理环节经过什么系统或模块、数据存储位置数据库、数据仓库、文件系统、数据消费方谁在什么场景下使用这份数据。用实体和方向箭头连接起来就是一张可用的数据流图。5.2 数据流图如何帮前期估算接口工作量数据流图最实际的用途是帮前期估算“对接工作量”。一个信息化项目里开发工作量的大头往往不在功能开发而在系统对接——与上级平台对接、与第三方系统对接、与新老系统之间的数据迁移对接。这些对接需求不会出现在业务流程图里业务流程图只描述人怎么干活它们最清晰的体现就是在数据流图里每条跨系统的数据流背后都对应一个接口的开发或配置任务。到了估算阶段可以给每条跨系统的数据流标注一个“风险等级”同一团队内部系统间的对接算低风险与成熟第三方产品的对接算中风险与老旧系统或者未知接口规范的对接算高风险。然后参考历史项目的单接口平均人天做乘法就能得到一个相对靠谱的对接工作量区间。没有数据流图这个估算就完全没有依据只能拍脑袋。5.3 数据流图最常见的返工原因数据流图在前期阶段最容易犯的毛病有三个都是后来返工的根源。第一个毛病是只画正向数据流不画异常和补偿流。比如数据同步失败之后的重试机制、对账数据、退单数据这些数据流在前期不做规划后期开发时就会冒出来一堆“之前没有说过的接口”。在前期阶段至少留出位置标注“含异常处理与对账”不要完全不画。第二个毛病是数据源与业务流程图对不上。业务流程里某个环节明明产生了“审批记录”数据流图里这个数据实体却不存在数据流图里画了“日志数据”业务流程图里完全找不到产生日志的业务节点。出现这种问题说明两张图不是从同一套需求推导出来的这时候需要回头统一需求理解而不是在图上做修补。第三个毛病是存储位置含糊。本地存储、集中存储、云端存储混在一起不区分或者是把“数据存储”画成一个大池子具体哪些数据走哪个存储完全看不出来。数据存储位置直接关系到容灾备份方案和安全合规要求前期不把存储边界画清楚这个专项方案就无从做起。6. 画图工具与方案文档里的绘制规范6.1 工具选型Visio、draw.io还是ProcessOn画图工具没有最好只有最合适。我这些年用过Visio、draw.iodiagrams.net、ProcessOn、亿图图示还有一个偶尔有人用的Enterprise Architect简单对比一下工具优势劣势适合场景Visio功能全面Windows生态成熟和Office联动好正版收费多人协作弱个人为主、交付给甲方的正式文档draw.io免费支持本地文件支持Git等版本管理自带图形库偏基础需自定义样式团队协作、需要版本管理的文档工程ProcessOn在线协作方便模板丰富免费版有数量限制导出清晰度一般团队内部快速对齐、草图讨论亿图图示中文模板丰富导出效果好价格不低性能一般国内政企项目常用我对前期方案编制场景的建议是团队内部用draw.io或ProcessOn快速迭代最终输出到方案文档用Visio或draw.io导出矢量图。一个硬性要求是导出图片必须是无损格式或者矢量格式。在Word或PDF里不要把位图缩放——一缩放就糊糊了评审专家就要眯着眼睛看印象分直接掉。6.2 图例、配色、字体和版本管理图的左下角必须放图例。很多方案里的图没有图例颜色和线型的含义全靠读者猜。我见过一张图里用了十几种颜色每种颜色代表不同的业务系统但没有任何地方说明作者讲PPT时口头解释一遍就翻页了等他讲完评审专家早就忘了绿色代表哪个系统。图例是解决这个问题的唯一办法。配色控制在三到四种以内。建议用一种主色代表项目本身的系统模块用另一种辅助色代表外部系统或第三方对接再用一种警示色标注待定或风险点。不要用颜色表达重要性——重要性应该通过布局位置和大小来表达颜色只表达类别。这一点很多设计出身的人会犯反向错误把架构图画得像海报信息层级反而丢了。字体和线宽也要统一。图内文字建议统一用无衬线字体黑体或微软雅黑字号不小于8号低于这个字号打印出来根本看不清。线条统一两种粗细主要数据流或核心链路线稍微加粗次要参考线用细线。结构规整的图尽量避免大量斜线和曲线直线和正交折线是主流方便对齐和阅读。版本管理这块我强烈建议前期方案的图做“图号标题版本”的命名规范。前期方案阶段图纸改动非常频繁甲方一句话可能让整张图返工。没有版本管理最后你的桌面会堆满“架构图最终版”“架构图最终版-really”“架构图最终版-v3”这样的文件三天之后你自己都分不清哪版是给哪个评审会用的。简单用日期加版本号命名配合一个记录修改内容的表格能省下大量的返工时间。6.3 几条从返工里熬出来的硬经验最后分享几条画图方面的实操经验都是踩过坑之后总结出来的第一每张图配一句“读图引导”。图的图题下面用一句话说明“本图重点表达什么、建议从哪个位置开始看”。评审专家没有义务花时间研究你的图读图引导能降低图被误读的概率。我见过很多好图因为读者没有找到正确的阅读起点而被误解图旁边加一句“建议从左上业务发起方开始阅读”就能有效避免这个局面。第二一图只讲一个主题。一张架构图又想画系统部署、又想画数据流、又想画安全边界结果就是哪样都没画清楚。信息量太大就拆图总图画全貌分图展开局部。方案文档的篇幅实际上并没有那么紧张多一张图、每张图聚焦一个主题远比一张图打天下要好。第三画完做“盲读测试”。找一位没有深度参与项目的人让他只看图不看文字说明然后问几个问题这个图说了什么有哪些看不明白的地方如果对方能大致说清楚图的内容说明这张图合格了如果他第一个问题是“这个框是什么意思”说明图的表达还不够独立完整需要回去改。这个测试成本很低但对图纸质量控制非常有效。第四画图之前想清楚读者是谁。前期方案的图是给评审查、给业主的业务人员和信息中心看的不是给开发人员做详细设计用的。同样一张系统架构图给开发看需要标服务调用关系、接口协议给评审看只需要表达系统有哪些模块、模块之间什么关系、和外系统怎么衔接。读者错了图画的再精致也是浪费工时。我在实际带项目的过程中越来越觉得画图本身就是一种思考的收敛方式。很多项目在写文字方案时感觉逻辑通顺一到画图就发现这里对不齐、那里有缺口这就是图的作用用最少的元素逼着你把关系说清楚。四张图画完项目的信息化建设脉络基本就立住了后面的概算、计划、实施都得从这几张图里顺藤摸瓜。如果非要给个建议的话开始画某一类图之前先问自己一句这张图的读者最在意什么我的图回答清楚了吗问清楚了再动手效果好得多。