《推荐-方案-标书怎么写》由会员分享，可在线阅读，更多相关《推荐-方案-标书怎么写（13页珍藏版）》请在金锄头文库上搜索。
1、方案、标书怎么写 历时一个星期的地税数据仓库投标书从昨天开始受到了各位领导严重批评，总体来说我写的方案一无是处，只能作为陪标的一份标书。心里很不是滋味，一周的辛苦白费不说，给领导留下的印象一定是能力极低。思前想后，觉得各部门领导们的意见还是很有道理的，从不同的高度，用不同的方式看待一份投标文件应该具备的内容，侧重点在哪里，哪些客户最关心，哪些应该具体描述。总结一下，死也要死个明白：首先再说一下为了尽量改进一下我的标书，昨天上午临时添加了一份点对点应答书，书中对于投标要求中的所有问题一一进行了简单的描述，很多都是“见标书XX小节”，因为时间的关系。在写这份点对点应答书的时候，就发现一些问题在我的
2、投标书中没有对应的描述，或者没有很明确的回答。所以在以后做投标书的时候，一份点对点应答书是必须的： 可以检查你的方案是否涵盖了需求书中全部的内容 可以最直观的反映出方案中你用什么技术、方法来实现这些具体的问题 也许因为问题没有连贯性，所以如果在投标书中体现的话，整个标书的结构会很散，所以单独一份点对点应答书是必要的下面总结一下投标书应该包含的内容： 总体目标每个项目都应该有一个明确的目标，业务上的，技术上的。目标应该是高层次的，概括的。一个项目的目标可以有多个，比如业务和技术的目标就是两个，技术是为业务服务的，分开写会显得比较专业。每个目标都应该用一句话就可以说明白，要精练到只用一句话描述每一
3、个目标。 总体规划规划就是你打算如何实现这个项目。在下面有一个详细的实施规划，总体规划应该是实施规划的概括，比如说计划分N步实施，每一步都要达到什么效果，实现什么目标或者子目标。在投数据仓库的项目时，因为客户对数据仓库的认识和使用本身就是一个逐步认识、体验的过程，所以数据仓库一般会包括数据仓库基础平台的建设（数据集中、数据规范、数据质量等等）、报表、关联查询、主题、数据挖掘、决策支持这些步骤，对每一个步骤的认识、应用、和实现都可以是由简到繁的，可以把几个步骤合在一起，先进行简单的实现，然后在通过使用过程中随着认识的加深，再通过迭代的方式重新实现。提到重新实现，就会出现两种方式：推倒重来还是在上
4、次的基础上更新。这就是下面推荐精选体系架构应该考虑的问题。 业务分析怎么分析业务呢？其实我也不知道，业务分析对我来说是木桶理论里面最短的一根。对于现在我经常遇到的税务行业的数据仓库项目来说，每个项目都会出现大量的报表，这些报表大多都是税务征管系统（OLTP系统）中报表，一般是按照功能模块分类的。业务分析也许应该包括两大部分：客户的日常业务需求和用于统计分析的业务需求。n 日常的业务需求在需求报告里面都可以得到，这也是客户最熟悉的，怎么分析，那真要业务很熟练才行，瞎编可不行！我就没编，所以领导们都看出业务需求分析这部分我写的非常不够，没错！我是真不知道怎么分析。n 统计分析的业务需求，现在税务行
5、业主要是各种主题分析，指标分析，再多说点就是怎么利用数据挖掘来挖掘和预测新的需求和行业变化。上面都是和业务直接相关的，还有重要的一点要说明的是要明确方案建议书和投标书的区别，文档的目的不同，导致文档中要突出的重点不同。个人感觉投标书比起方案建议书来说，目标更加明确，项目的范围界定比较清楚，所以在进行上述三点描述时侧重点不一样。投标书应该紧紧围绕着需求书中的具体需求来写，与点对点应答书中的答案相对应；方案建议书就可以略微天马行空一些，但一定应该是熟悉业务人来行空才行！推荐精选下面应该是和技术相关的内容： 技术架构n 整体架构最近一段时间写的都是和数据仓库相关的建议书和方案，其实从数据处理的角度来
6、说，数据仓库技术只是处理数据的一种手段，它采用的技术和一般的业务系统（事务型业务系统）不同，所分析的数据的数据结构也和业务系统不同。但是它应该是和业务系统并列的，对于客户来说，它们完成的是不同的业务需求。从技术角度来看，它和其他业务系统一样，都要有一些基础的、共享的基本架构。 二层架构 三层架构（jsp + servlet 或者 J2EE） 安全架构 日志、审计架构 监控架构我这次写投标书把这部分忘了，虽然以前做了N年的三层架构，也许是因为公司以前的数据仓库建议书里面没有写这部分，需求里面写了，但我看了没有引起太多的注意。数据仓库好比是魔术大变活人里面最后变出的美女，而这些基础架构就是魔术中使
7、用的其他道具，每个人都期望变出不同的东西来满足自己不同需求，不管是金钱、美女还是野兽。n 数据仓库架构这部分相对来说是最容易掌握的，对于喜爱技术的人来说。在设计数据仓库架构之前，应该清楚的了解现在客户面临的实际的技术难点是什么，要解决和担心的问题是什么。数据仓库涉及的技术问题无非就那么几种： 架构上的：EDW还是数据集市、ODS还是非ODS、实时的、准实时的还是不带实时帽子的推荐精选 设计上的：数据集成、数据规范、数据的处理、数据流程的定义、元数据的管理 性能上的：抽取的速度、抽取的数据量、数据仓库存储的数据量 安全上的：数据的质量、数据的监控 模型上的：MOLAP、ROLAP 展现上的：图表
8、、仪表盘、钻取、旋转、切片在描述这部分的时候，非常容易写的比较原理化，俗话说先礼后兵嘛，对于不很了解数据仓库的客户这部分多写一些，通俗一些，我觉得挺好。但是如果写的是投标书的话，那么应该把如何实现说清楚，因为需求中会有清楚的要求和建议，希望做到什么程度，希望你用什么来实现，希望到达什么效果。但是与点对点应答书相比，如果按照点对点应答书的顺序或者思路来描述的话，可能在结构上会比较松散。我觉得还是应该按照上面的分类来描述，把如何实现放在每部分的内容中去。图文并茂效果最佳先在头脑里面把这些问题想清楚，在头脑中逐渐形成大致的轮廓，落实在纸上用图的形式体现，要能从图中清楚的表达你的意思。图可以分多个层次
9、，high level的，low level的，整体的，描述某一部分的。曾经看过一遍报道，讲一个华裔的联合国IT职员，他在写系统的用户手册时，手册的第一个读者是大厦的清洁工，如果清洁工明白了，手册就算通过了。当然联合国的清洁工也许学历也满高的呢。图画出来了，文字围绕图来运筹，就能让读者看着明白，读着舒心。以终为始，这句话真好。不过说的容易，做起来要多练才行。推荐精选 实施规划实施的规划如同方案的编写，同样都是从需求入手、分析需求、整理规范、设计、开发、测试、维护，再加上如何进行项目管理，突出管理的重要性，因为其他的部分前面都描述过，只要条理清楚就行。 案例介绍以前还真没好好想为什么写案例，如何
10、写好案例？这次通过写方案得出的教训是案例不是凑数的，是有目的的。目的是告诉客户你不光有能力写好方案，还曾经做好过类似的项目。所以案例分析除了介绍案例的业务、技术、环境、项目过程等情况，还要分析已经做过的项目和现在要做的项目的异同，也应该从业务、技术、环境、项目过程来分析。所谓突出重点，这就是重点。其他还可能包括： 项目预算 产品清单 技术支持和服务再说说写方案、标书时应该注意的几点习惯和方法：写方案、标书最大的威胁之一，就是拷贝粘贴。拷贝粘贴的目的是为了节省时间，不是为了迷惑客户。在拷贝粘贴前要清楚这些内容是完全符合你的要求、还是部分符合你的要求、还是帖不帖都一样、再不是就是为了迷惑客户使他不
11、清楚你在讲什么。有的时候是因为时间紧，或者没有太好的词语表达自己的意思，copy没有什么过错，错在不知自己在copy什么，知道了就没错了。替换也是在修改方案时会用到的操作之一，千万不要完全替换，除非你非常有把握，否则浪费的不止是时间，还可能使你的内容变得千疮百孔，面目狰狞。就像河间的驴肉烧饼、天津的煎饼果子一样，蓬天的方案和标书在业界是有名的优秀，要深度有深度，要厚度有厚度，希望大家集思广益，说出自己的心得体会，努力维护和发扬蓬天公司特色中的特色。推荐精选我写这个可不是为了传授或布道哦，我写过一些投标方案，但是总想听听大家是怎么写的，都注意些什么。所以，兄弟我先扔块砖，大伙儿有玉的砸过来前面几
12、天在写一份投标方案。连续几天搞到晚上10：00以后，周末还搞了个通宵，昨天去投了。总算一个包袱卸了下来，结果怎么样也顾不上了，大家都说：尽人事，听天命吧。呵呵这个方案我主要负责技术方案部分，商务部分另一个同事负责。由于是个没人做过的东西，所以模型、框架得自己砸破脑袋想。方案的名称是：中小学学生学习质量监测系统。招标方明确说了，这不是题库，这是要监测学习质量！人家还说，关键在于对教育理念的理解！在这个方案投出去了我都有很多觉得不合适的地方，但是时间实在来不及了，也怪自己没法考虑周全。所以我总觉得，就一个投标方案制作来说，应该至少有3个人，一个负责商务，另两个负责技术方案。一个人做技术方案总是顾此
13、失彼。两个人可以相互讨论，相互审阅，可以避免很多问题。两个人还有分工，一个钻研用户需求分析，另一个负责技术架构。但是要相互讨论，这样起码虽然某一部分是一个人来写用的确实两个人的脑袋。从写的步骤上来说，一般不适宜上来就动笔。这个和写文章一样嘛，总得要构思一下。我想这样应该比较合适：（1）分析清楚业主真正想要的是什么。这个如果拿捏不准就惨了。（2）分清楚这个系统的用户有哪些角色。这将有助于找出业务内容。（3）确定这个方案的产品的最终部署结构、网络结构。这是大问题，因为如果开始不考虑这些，后面再考虑会很难；（4）确定这个方案的重点在哪里，因为有的重视业务模型，有的重视技术实现（这个有时很难做，而且要
14、看评标人的背景）。（5）讨论确定投标方案的框架，这中间要特别熟读招标要求，需要注意的地方特别画出来。（6）接着就疯狂的到网上搜索资料吧，然后根据自己的思维和框架把方案的内容丰满起来。一般来说，很多方案都是这样推荐精选“拼”起来的，不过好的方案还是要自己花功夫在里面。一分钱一分货嘛！（7）相互审阅。这一点很重要，因为这么短的时间写这么多内容（还有很多内容是“拼”来的），很难保证内容“圆润”。别人看一遍能够找出很多显然的毛病和问题；能够从内容的全面性、通畅性等方面找出问题。这期间最好能再反复阅读招标需求。（8）投标方案各部分合成，审阅。（9）打印、装订、签字敲章、密封。这个其实有专门的公司做装订的，有条件的话可以交给别人去做，因为这个过程其实还是蛮痛苦的。从内容上看，一般包括（但不限于）：（1）概论：说一些方案书目的、项目背景等。（2）用户需求分析：通常会对业主的相关系统做个业务建模。（3）系统设计：对业主的状况做一个解决方案，可能是一个系统的功能设计说明，也有可能是一些设计模型。（4）项目技术方案：对技术平台路线、相关设备需求（技术参数）、技术架构、关键技术等进行说明和设计。（5）根据需要，通常还有系统的安全解决方案、存储方案、备份与恢复方案等。（6）系统项目实施方案：主要包括项目计划、质量保证计划、配置管理计划、售后服务计划等等。
