方案,标书怎么写.docx

每个项目都应该有一个明确的目标， 业务上的, 技术上的。目标应该是高层次的，概括的。一 个项目的目标可以有多个，比如业务和技术的 目标就是两个，技术是为业务服务的，分开写 会显得比较专业。每个目标都应该用一句话就 可以说明白，要精练到只用一句话描述每一个 目标。
总体规划
规划就是你打算如何实现这个项目。在下面有 一个详细的实施规划，总体规划应该是实施规 划的概括，比如说计划分 N步实施，每一步都 要达到什么效果，实现什么目标或者子目标。
在投数据仓库的项目时，因为客户对数据仓库 的认识和使用本身就是一个逐步认识、体验的 过程，所以数据仓库一般会包括数据仓库基础
平■台的建设（数据集中、数据规范、数据质量
等等）、报表、关联查询、主题、数据挖掘、 决策支持这些步骤，对每一个步骤的认识、应
用、和实现都可以是由简到繁的，可以把几个 步骤合在一起，先进行简单的实现，然后在通
过使用过程中随着认识的加深，再通过迭代的 方式重新实现。提到重新实现，就会出现两种 方式：推倒重来还是在上次的基础上更新。这 就是下面体系架构应该考虑的I可题。
业务分析
怎么分析业务呢？其实我也不知道，业务分析 对我来说是木桶理论里面最短的一根。对丁现 在我经常遇到的税务行业的数据仓库项目来
说，每个项目都会出现大量的报表，这些报表 大多都是税务征管系统（OLTP系统）中报表, 一般是按照功能模块分类的。业务分析也许应 该包括两大部分：客户的日常业务需求和用丁 统计分析的业务需求。
日常的业务需求在需求报告里面都可 以得到，这也是客户最熟悉的，怎么分析， 那真要业务很熟练才行，瞎编可不行！我就 没编，所以领导们都看出业务需求分析这部 分我写的非常不够，没错！我是真不知道怎 么分析。
统计分析的业务需求，现在税务行业 主要是各种主题分析，指标分析，再多说点 就是怎么利用数据挖掘来挖掘和预测新的 需求和行业变化。
上面都是和业务直接相关的，还有重要的一点 要说明的是要明确方案建议书和投标书的区 别，文档的目的不同，导致文档中要突出的重 点不同。个人感觉投标书比起方案建议书来说, 目标更加明确，项目的范围界定比较活楚，所 以在进行上述三点描述时侧重点不一样。投标 书应该紧紧围绕着需求书中的具体需求来写， 与点对点应答书中的答案相对应；方案建议书
就可以略微天马行空一些，但一定应该是熟悉 业务人来行空才行
！
下面应该是和技术相关的内容：
技术架构
整体架构
最近一段时间写的都是和数据仓库相关的 建议书和方案，其实从数据处理的角度来说， 数据仓库技术只是处理数据的一种手段，它采 用的技术和一般的业务系统（事务型业务系统） 不同，所分析的数据的数据结构也和业务系统 不同。但是它应该是和业务系统并列的，对丁 客户来说，它们完成的是不同的业务需求。从 技术角度来看，它和其他业务系统一样，都要 有一些基础的、共享的基本架构。
二层架构
三层架构（jsp + servlet或者J2 EE）
安全架构
日志、审计架构
监控架构
L我这次写投标书把这部分忘了，虽然以前做了 N年的三层架构，也许是因为 公司以前的数据仓库建议书里面没有写这部分，需求里面写了，但我看了没有引 起太多的注意。
数据仓库好比是魔术大变活人里面最后变出的美女，而这些基础架