简介面向深圳市政府投资信息化工程项目的初步设计及概算编制指南用于规范初步设计报告的投资估算控制、内容深度与文档组织适合信息化项目设计单位、造价咨询机构及建设单位管理人员参考。资源包共1个docx文件大小413KB内容按总则、一般要求、编制内容等章节展开涵盖需求分析、总体设计、分项设计、集成与招标方案、项目管理、运行维护、概算编制及风险效益分析等模块并明确了如何利用已有资源、避免重复建设要求初步设计概算原则上不超过可研批复投资估算的10%。已有1166人学习下载。该指南尤其强调报告的前引、正文和补充部分结构以及流程图、术语、保密标注等格式规范可帮助读者快速把握深圳市政府投资信息化工程从需求调研到概算报批的整套编制要求减少返工和审批风险提高项目申报与实施效率。 最近好几个团队拿着同一份文件来找我就是那份《深圳市政府投资信息化工程建设项目初步设计及概算编制指南.docx》问法几乎一模一样“这份指南我们翻了几遍也知道要按它来写可真到自己动笔的时候还是不知道初步设计该写多细、概算该按什么算、哪些地方评审专家最在意。”说实话这类问题不只在深圳本地出现。我参与过不少财政性资金安排的信息化项目评审也帮人复核过几十本初步设计和概算文本大家的困惑基本都集中在三个方面第一初步设计正文的框架和深度把握不准第二概算费用不知道按什么逻辑去估算第三提交后被打回却不清楚问题出在哪。这篇就围绕这份指南文件把我在实际项目里摸索出的经验拆开讲清楚顺便也把docx这种格式在老旧办公环境里的编辑问题一起解决掉。1. 先搞清楚这份指南管的是什么项目阶段与适用边界很多人拿到指南后第一反应是把它当成“模板大全”想在里面找到一个可以直接套用的初步设计文档骨架。这是一个常见的误判。指南的核心作用不是给你一份万能模板而是告诉你两件事初步设计要做到什么深度概算要按什么口径来编。先看“初步设计”这个阶段。在信息化工程建设项目里初步设计是衔接“需求确认”和“详细设计/招标采购”的关键环节。它的输入是已批复的项目建议书或可行性研究报告输出则是可供后续施工图设计或招标采购使用的技术方案和投资额度。也就是说初设阶段必须把“做什么、怎么做、花多少钱”这三件事说得足够清楚不能再用“待定”“大概”“后续细化”这类模糊表述。再看“概算”。概算的本质是在初步设计技术方案确定之后对整个项目投资进行的一次全面测算。它比可研阶段的投资估算更精确但又没到施工图预算那种按定额逐项精算的程度。在政府投资类项目中概算一旦经过评审和批复基本就锁定了项目的投资上限后续招标、变更、结算都要在这个框架内执行。所以概算编制最忌讳三件事漏项、拍脑袋估价、前后数据对不上。明确了这两层定位你就能理解指南文件里那些看起来“很啰嗦”的章节为什么会存在了。它不是文档规范在自我表演而是每一个条目背后都对应着评审时会被实际核查的点。比如技术方案部分写得不细概算里的设备清单就没有依据实施计划写得不具体进度管理费和人月数就没有支撑。关于适用范围指南通常适用于新建、扩建、改建类的信息化工程建设项目有些文件也会把运维类项目单独拿出来规定。这个边界很重要因为运维类和建设类项目的概算口径完全不一样前者重点是服务费和人月数测算后者重点是软硬件购置和集成费用。如果你手上的项目是运维类却照着建设类指南来编评审阶段基本必被打回。2. 初步设计正文的核心框架评审专家真正会逐字看的部分初步设计文档的章节结构不同地区、不同行业会有些差异但主干部分高度一致。以我看到的这类指南要求和实际评审反馈来看下面几个部分是整个正文的命门。2.1 现状分析和需求描述最容易被低估的第一道关卡很多团队的初设文档里这一部分通常写得非常“虚”常见句式是“随着业务发展现有系统已无法满足需求”然后就没有然后了。但评审专家看这一章实际是在找三个东西一是现有信息化家底是否盘点清楚二是业务痛点是否有数据支撑三是需求描述是否可量化、可验证。现状部分至少要覆盖现有网络、硬件设备、业务系统、数据资源、安全防护这五个维度每个维度都要给出明确结论——哪些能利旧哪些需要改造哪些必须新建。只用“现有系统老旧”这种表述是过不了关的要写清楚老旧在哪里比如说“现有OA系统基于XX架构不支持移动端访问数据库版本已停止安全更新”这才叫有信息量。需求部分则需要把用户需求转化为可度量的技术指标。比如“系统并发能力需要支持多少人同时在线”要落实到“峰值并发1000用户TPS不低于50”而不是写“满足业务高峰需求”。评审专家看需求分析是否合格就看你给不给得出数字。给不出数字的需求后面所有设计都是空中楼阁。2.2 总体架构设计技术路线选择要有对比、有理由总体架构是初步设计中最体现功力的部分也是评审问询最密集的地方。需要覆盖的架构维度包括业务架构、应用架构、数据架构、技术架构、部署架构和安全架构每个架构既要有图也要有文字说明。这里的常见错误是直接画一张“大而全”的总架构图然后每个架构一两句话带过。正确做法是分层展开先给总体架构图再把每一层拆开细化。比如数据架构要说明数据从哪里来、经过什么处理、存到哪里、如何共享还要回答数据的标准化策略、数据质量规则、主数据管理方式。技术架构则要明确技术选型而且每个关键技术选型最好有对比分析——为什么选A不选B、A在什么方面更适合本项目、是否有同类项目落地案例。需要特别提醒的是初步设计阶段的技术选型不能写成“点菜式”罗列。评审专家非常反感那种没有对比直接给出结论的方案这会让人质疑选型的客观性。哪怕你的对比只有一张表格也能证明你做了功课。2.3 分项建设方案和软硬件清单一字一坑的部分分项建设方案是初设里篇幅最大的部分将总体架构里的每个子系统逐一展开。每个子系统需要包含建设目标、功能清单、业务流程、接口关系、数据需求、部署要求、性能指标等。功能清单不能只是功能名称列表每个功能最好附上简要描述和用户角色。软硬件配置清单则是评审核查和概算编制的交汇点最常见的问题就是清单与正文技术方案对不上。比如正文写了“部署双机热备”清单里却只有一台服务器正文说“需采购国产数据库”列表里却出现了非国产数据库产品。这类低级错误杀伤力很大轻则退回修改重则影响专家对整份文档专业性的判断。建议做法是在清单里给每项设备加上“对应方案依据”列标注它在正文哪个章节有说明。这既是给自己做检查也是给评审提供便利。2.4 实施计划、培训方案、运行维护看似边缘实际常被扣分实施计划部分要给出明确的阶段划分、时间节点、里程碑标志、组织分工和验收标准。常见问题是甘特图画得很漂亮但关键路径看不清人员投入数也明显不合理比如30个人月的项目只规划了2名开发人员。培训方案要覆盖培训对象、内容、方式、时间、考核标准运维方案需要说清楚运维组织、服务范围、响应时间、服务级别和费用测算。这两块在很多初设里都写得很敷衍但实际评审时如果缺项或明显不合理同样会被作为“设计内容不完整”的打回理由。3. 概算编制的正确逻辑从算量到报价不是一个填表游戏概算是最能看出“老手”和“新手”差异的地方。新手往往把概算理解成“给每个东西标个价加总”老手则会在动笔之前先梳理一套完整的测算逻辑。3.1 费用构成先理清后面才不会漏项信息化工程项目概算通常包括以下几大类费用硬件设备购置费、软件购置及开发费、系统集成费、机房及配套改造费、工程建设其他费含咨询设计费、监理费、检测测评费、项目管理费等、预备费。有些项目还会包括数据资源建设费、标准规范编制费、网络安全等级保护测评费。复盘无数被打回的概算最集中的问题就两个一个漏项另一个是费用归类错误。漏项最常见的是漏掉等保测评费、第三方检测费、数据迁移费、上线后的运维费归类错误则常表现为把系统集成费强行塞进软件开发费里或者把培训费放在设备费里。3.2 三类估算法要掌握按项目情况灵活选用第一类是比例测算法适合在还没有详细清单时做粗线条估算。比如以一个城市级或行业级的典型信息化项目经验来看硬件费用占项目总投资的比例通常在30%到50%之间软件开发和数据资源建设占30%到40%服务类费用占10%到20%。不同行业、不同建设性质的偏离度很大但可以作为一个快速判断概算结构是否均衡的参考。第二类是工作量估算法也就是人月测算法主要用于软件开发和数据治理类工作。核心是先把需要开发的子系统按功能点或用户故事拆解再结合团队历史生产率给出合理的人月数最后乘以人月单价。这里的关键是明细要可追溯比如“A子系统包含30个功能点按每个功能点1.5人月估算合计45人月”评审专家一看就知道你有测算依据而不是随手填了一个数。第三类是市场询价法主要适用于硬件设备和成熟软件产品。操作方式是多渠道收集至少三家供应商的报价或公开市场价格形成询价记录并留档。可靠的市场询价记录不仅是概算编制的依据也是后续招标时设置拦标价的重要参考。3.3 与初步设计正文的对应关系概算不是独立于技术方案之外的表格。每一项费用都应该能在正文里找到对应的方案描述同时正文里描述到的建设内容也必须在概算中有资金体现。建议在编制概算时做一张“技术方案与概算对应关系表”把建设内容、费用名称、计价依据、金额四列列清楚。这张表既是自查工具也是评审专家最爱看的核心内容。如果做不到逐项对应至少大项之间不能出现错位。4. 评审环节最容易被驳回来的问题清单和对策我梳理了一下近年评审中见过的驳回问题有共性的就那么几条。提前对照自检能省掉一轮又一轮的修改时间。4.1 需求分析空泛支撑不了后续设计决策表现为需求描述全是“提升效率”“加强管理”这类正确的废话没有业务现状、没有调研记录、没有数据测算。对策是在写需求之前先做一轮用户调研和现有数据分析把调研记录、数据量、并发量、响应时间等论据写进去。哪怕只是引用一组现有业务系统的统计报表也比空泛描述有说服力得多。4.2 技术方案缺少比选结论显得武断比如直接写“本系统采用微服务架构”但没有和单体架构做任何对比也没有说明为什么在这个项目里微服务更合适。对策是建立简单的比选矩阵从扩展性、维护成本、团队技术栈、部署复杂度等维度做对比并给出评分和结论。这里不需要长篇大论一张表即可。4.3 硬件配置缺乏容量测算依据服务器配几台、CPU几核、内存多大这种决策如果没有流量估算和数据量估算支撑就会显得完全是拍脑袋。对策是写出简要的容量测算过程例如“根据业务预测系统年新增数据量约500GB考虑备份和增长因子建议存储配置为XXTB”。4.4 概算依据不完整评审无法验证报价要么没有来源要么来源单一。对策是建立完整的计价依据文档设备类附询价单或报价单开发类附人月测算过程服务类附收费标准或服务内容说明。4.5 安全设计流于形式不少初设的安全章节照抄安全等级保护标准条款没有结合系统实际梳理安全需求。对策是按照定级结果逐个落实安全措施说明每个安全控制项在本系统中如何落地比如“通过部署XX实现日志留存满足等级保护三级要求中的XX条款”。5. 实操补充docx指南文件在老办公环境下如何正常编辑前面讲了很多编制思路这节聊一个非常现实但容易被忽略的问题——文件本身打不开或者编辑不便。现在拿到的这份指南文件名后缀是.docx这是Office 2007及以上版本使用的默认格式。但我发现许多单位的内网办公电脑还装着Word 2003双击打开后要么直接报“文件格式无效”要么弹出一堆乱码提示根本没法正常看更别说改。如果遇到这种情况有三种比较靠谱的解决办法。第一种是安装格式兼容包。微软官方提供过“Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats”安装后Word 2003就能直接打开编辑.docx文件。这个方案适合不能随便换软件的办公环境装完一劳永逸。需要注意兼容包在旧系统环境下可能需要以管理员身份安装。第二种是用WPS Office打开后另存为.doc格式。WPS对Office老版本格式兼容得很好打开docx后选择“另存为”把文件类型改成.doc即可。操作上几乎没有任何门槛。需要提醒的是另存后最好逐页检查一下排版变化复杂表格和公式可能出现细微错位。第三种是用LibreOffice等开源办公套件这类工具在老旧电脑上运行更快也不涉及授权问题。LibreOffice可以直接编辑docx同样可以另存为.doc格式。有一点特别想强调政府投资项目的指南文件往往涉及内部工作口径和敏感信息不建议传送到非办公环境下的在线格式转换网站处理。哪怕只是嫌麻烦也不要图省事。本地装个工具几分钟就解决安全边界不值得去试探。另外这类指南文件在实际使用中建议养成两个习惯。一个是拿到文件后先把目录结构读一遍搞清楚你关心的问题在第几章评审时被问到哪里能立刻翻到对应位置。另一个是多轮修改时开启修订模式每一轮意见在哪个版本改了、改了什么、有没有漏改留痕清楚。配合WPS和Word都有的文档比较功能合并不同人修改过的版本也很方便。从我自己的经验来说初设和概算编制这件事最怕的不是不熟悉技术而是不知道该在什么深度上做文章。指南文件的价值恰恰在于它把所有编制要求都写在了明面上。把指南读透、把评审关注点列成检查表、每一条对着自查提交前再自己当一次“挑剔的评审专家”把文档过一遍项目顺利通过评审的概率就会高很多。本文还有配套的精品资源点击获取