方案,标书怎么写

方案,标书怎么写

方案、标书怎么写

历时一个星期的××地税数据仓库投标书从昨天开始受到了各位领导严重批评，总体来说我写的方案一无是处，只能作为陪标的一份标书。心里很不是滋味，一周的辛苦白费不说，给领导留下的印象一定是能力极低。

思前想后，觉得各部门领导们的意见还是很有道理的，从不同的高度，用不同的方式看待一份投标文件应该具备的内容，侧重点在哪里，哪些客户最关心，哪些应该具体描述。总结一下，死也要死个明白:

首先再说一下为了尽量改进一下我的标书，昨天上午临时添加了一份点对点应答书，书中对于投标要求中的所有问题一一进行了简单的描述，很多都是“见标书XX小节”，因为时间的关系。在写这份点对点应答书的时候，就发现一些问题在我的投标书中没有对应的描述，或者没有很明确的回答。所以在以后做投标书的时候，一份点对点应答书是必须的:

可以检查你的方案是否涵盖了需求书

中全部的内容

可以最直观的反映出方案中你用什么

技术、方法来实现这些具体的问题

也许因为问题没有连贯性，所以如果在

投标书中体现的话，整个标书的结构会很散，

所以单独一份点对点应答书是必要的

下面总结一下投标书应该包含的内容:

总体目标

每个项目都应该有一个明确的目标，业务上的，

技术上的。目标应该是高层次的，概括的。一

个项目的目标可以有多个，比如业务和技术的

目标就是两个，技术是为业务服务的，分开写

会显得比较专业。每个目标都应该用一句话就

可以说明白，要精练到只用一句话描述每一个

目标。

总体规划

规划就是你打算如何实现这个项目。在下面有

一个详细的实施规划，总体规划应该是实施规

划的概括，比如说计划分N步实施，每一步都

要达到什么效果，实现什么目标或者子目标。

在投数据仓库的项目时，因为客户对数据仓库

的认识和使用本身就是一个逐步认识、体验的

过程，所以数据仓库一般会包括数据仓库基础

平台的建设(数据集中、数据规范、数据质量等等)、报表、关联查询、主题、数据挖掘、决策支持这些步骤，对每一个步骤的认识、应用、和实现都可以是由简到繁的，可以把几个步骤合在一起，先进行简单的实现，然后在通过使用过程中随着认识的加深，再通过迭代的方式重新实现。提到重新实现，就会出现两种方式:推倒重来还是在上次的基础上更新。这就是下面体系架构应该考虑的问题。

业务分析

怎么分析业务呢,其实我也不知道，业务分析对我来说是木桶理论里面最短的一根。对于现在我经常遇到的税务行业的数据仓库项目来说，每个项目都会出现大量的报表，这些报表大多都是税务征管系统(OLTP系统)中报表，一般是按照功能

模块分类的。业务分析也许应该包括两大部分:客户的日常业务需求和用于统计分析的业务需求。

日常的业务需求在需求报告里面

都可以得到，这也是客户最熟悉的，怎么分

析，那真要业务很熟练才行，瞎编可不行～

我就没编，所以领导们都看出业务需求分析

这部分我写的非常不够，没错～我是真不知

道怎么分析。

统计分析的业务需求，现在税务行

业主要是各种主题分析，指标分析，再多说

点就是怎么利用数据挖掘来挖掘和预测新

的需求和行业变化。

上面都是和业务直接相关的，还有重要的一点要说明的是要明确方案建议书和投标书的区别，文档的目的不同，导致文档中要突出的重点不同。个人感觉投标书比起方案建议书来说，目标更加明确，项目的范围界定比较清楚，所以在进行上述三点描述时侧重点不一样。投标书应该紧紧围绕着需求书中的具体需求来写，与点对点应答书中的答案相对应;方案建议书

就可以略微天马行空一些，但一定应该是熟悉

业务人来行空才行～

下面应该是和技术相关的内容:

技术架构

整体架构

最近一段时间写的都是和数据仓库相关的

建议书和方案，其实从数据处理的角度来说，

数据仓库技术只是处理数据的一种手段，它采

用的技术和一般的业务系统(事务型业务系统)

不同，所分析的数据的数据结构也和业务系统

不同。但是它应该是和业务系统并列的，对于

客户来说，它们完成的是不同的业务需求。从

技术角度来看，它和其他业务系统一样，都要

有一些基础的、共享的基本架构。

二层架构

三层架构(jsp + servlet 或者

J2EE)

安全架构

日志、审计架构

监控架构

我这次写投标书把这部分忘了，虽然以前做了N年的三层架构，也许是因为公司以前的数据仓库建议书里面没有写这部分，需求里面写了，但我看了没有引

起太多的注意。

数据仓库好比是魔术大变活人里面最后变出的美女，而这些基础架构就是魔术中

使用的其他道具，每个人都期望变出不同的东西来满足自己不同需求，不管是金

钱、美女还是野兽。

数据仓库架构

这部分相对来说是最容易掌握的，对于喜爱技

术的人来说。在设计数据仓库架构之前，应该

清楚的了解现在客户面临的实际的技术难点是

什么，要解决和担心的问题是什么。数据仓库

涉及的技术问题无非就那么几种:

架构上的:EDW还是数据集市、ODS

还是非ODS、实时的、准实时的还是不带实

时帽子的

设计上的:数据集成、数据规范、

数据的处理、数据流程的定义、元数据的管

理

性能上的:抽取的速度、抽取的数

据量、数据仓库存储的数据量

安全上的:数据的质量、数据的监

控

模型上的:MOLAP、ROLAP

展现上的:图表、仪表盘、钻取、

旋转、切片

在描述这部分的时候，非常容易写的比较原理化，俗话说先礼后兵嘛，对于不很了解数据仓库的客户这部分多写一些，通俗一些，我觉得挺好。但是如果写的是投标书的话，那么应该把如何实现说清楚，因为需求中会有清楚的要求和建议，希望做到什么程度，希望你用什么来实现，希望到达什么效果。但是与点对点应答书相比，如果按照点对点应答书的顺序或者思路来描述的话，可能在结构上会比较松散。我觉得还是应该按照上面的分类来描述，把如何实现放在每部分的内容中去。

图文并茂效果最佳