东电商务标书制作 ——东电商务服务平台

首页 行业知识 正文

方案、标书怎么写

来源:本站 时间:2019/1/14 553

全国标书服务

今天给大家分享一篇文章,希望大家从中能学到一些东西

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

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

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

可以检查你的方案是否涵盖了需求书中全部的内容

可以最直观的反映出方案中你用什么技术、方法来实现这些具体的问题

也许因为问题没有连贯性,所以如果在投标书中体现的话,整个标书的结构会很散,所以单独一份点对点应答书是必要的

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

总体目标

每个项目都应该有一个明确的目标,业务上的,技术上的。目标应该是高层次的,概括的。一个项目的目标可以有多个,比如业务和技术的目标就是两个,技术是为业务服务的,分开写会显得比较专业。每个目标都应该用一句话就可以说明白,要精练到只用一句话描述每一个目标。

总体规划

规划就是你打算如何实现这个项目。在下面有一个详细的实施规划 ,总体规划应该是实施规划的概括,比如说计划分 N 步实施,每一步都要达到什么效果,实现什么目标或者子目标。在投数据仓库的项目时,因为客户对数据仓库的认识和使用本身就是一个逐步认识、体验的过程,所以数据仓库一般会包括数据仓库基础平台的建设(数据集中、数据规范、数据质量等等)、报表、关联查询、主题、数据挖掘、决策支持这些步骤,对每一个步骤的认识、应用、和实现都可以是由简到繁的,可以把几个步骤合在一起,先进行简单的实现,然后在通过使用过程中随着认识的加深,再通过迭代的方式重新实现。提到重新实现,就会出现两种方式:推倒重来还是在上次的基础上更新。这就是下面体系架构 应该考虑的问题。

业务分析

怎么分析业务呢?其实我也不知道,业务分析对我来说是木桶理论里面最短的一根。对于现在我经常遇到的税务行业的数据仓库项目来说,每个项目都会出现大量的报表,这些报表大多都是税务征管系统( OLTP 系统)中报表,一般是按照功能模块分类的。业务分析也许应该包括两大部分:客户的日常业务需求和用于统计分析的业务需求。

日常的业务需求在需求报告里面都可以得到,这也是客户最熟悉的,怎么分析,那真要业务很熟练才行,瞎编可不行!我就没编,所以领导们都看出业务需求分析这部分我写的非常不够,没错!我是真不知道怎么分析。

统计分析的业务需求,现在税务行业主要是各种主题分析,指标分析,再多说点就是怎么利用数据挖掘来挖掘和预测新的需求和行业变化。

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

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

技术架构

整体架构

最近一段时间写的都是和数据仓库相关的建议书和方案,其实从数据处理的角度来说,数据仓库技术只是处理数据的一种手段,它采用的技术和一般的业务系统(事务型业务系统)不同,所分析的数据的数据结构也和业务系统不同。但是它应该是和业务系统并列的,对于客户来说,它们完成的是不同的业务需求。从技术角度来看,它和其他业务系统一样,都要有一些基础的、共享的基本架构。

二层架构

三层架构( jsp + servlet 或者 J2EE )

安全架构

日志、审计架构

监控架构

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

数据仓库好比是魔术大变活人里面最后变出的美女,而这些基础架构就是魔术中使用的其他道具,每个人都期望变出不同的东西来满足自己不同需求,不管是金钱、美女还是野兽。

数据仓库架构

这部分相对来说是最容易掌握的,对于喜爱技术的人来说。在设计数据仓库架构之前,应该清楚的了解现在客户面临的实际的技术难点是什么,要解决和担心的问题是什么。数据仓库涉及的技术问题无非就那么几种:

架构上的: EDW 还是数据集市、 ODS 还是非 ODS 、实时的、准实时的还是不带实时帽子的

设计上的:数据集成、数据规范、数据的处理、数据流程的定义、元数据的管理

性能上的:抽取的速度、抽取的数据量、数据仓库存储的数据量

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

模型上的: MOLAP 、 ROLAP

展现上的:图表、仪表盘、钻取、旋转、切片

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

图文并茂效果最佳

先在头脑里面把这些问题想清楚,在头脑中逐渐形成大致的轮廓,落实在纸上用图的形式体现,要能从图中清楚的表达你的意思。图可以分多个层次, high level 的, low level 的,整体的,描述某一部分的。曾经看过一遍报道,讲一个华裔的联合国 IT 职员,他在写系统的用户手册时,手册的第一个读者是大厦的清洁工,如果清洁工明白了,手册就算通过了。当然联合国的清洁工也许学历也满高的呢。图画出来了,文字围绕图来运筹,就能让读者看着明白,读着舒心。以终为始 ,这句话真好。不过说的容易,做起来要多练才行。

实施规划

实施的规划如同方案的编写,同样都是从需求入手、分析需求、整理规范、设计、开发、测试、维护,再加上如何进行项目管理,突出管理的重要性,因为其他的部分前面都描述过,只要条理清楚就行。

 案例介绍

以前还真没好好想为什么写案例,如何写好案例?这次通过写方案得出的教训是案例不是凑数的,是有目的的。目的是告诉客户你不光有能力写好方案,还曾经做好过类似的项目 。所以案例分析除了介绍案例的业务、技术、环境、项目过程等情况,还要分析已经做过的项目和现在要做的项目的异同,也应该从业务、技术、环境、项目过程来分析。所谓突出重点,这就是重点。

其他还可能包括:

项目预算

产品清单

技术支持和服务

再说说写方案、标书时应该注意的几点习惯和方法:

写方案、标书最大的威胁之一,就是拷贝粘贴 。拷贝粘贴的目的是为了节省时间,不是为了迷惑客户。在拷贝粘贴前要清楚这些内容是完全符合你的要求、还是部分符合你的要求、还是帖不帖都一样、再不是就是为了迷惑客户使他不清楚你在讲什么。有的时候是因为时间紧,或者没有太好的词语表达自己的意思, copy 没有什么过错,错在不知自己在 copy 什么,知道了就没错了。

替换 也是在修改方案时会用到的操作之一,千万不要完全替换,除非你非常有把握,否则浪费的不止是时间,还可能使你的内容变得千疮百孔,面目狰狞。



服务范围 联系方式 免责声明 关于我们 留言反馈

电话:13021927778      联系人:盖小姐      地址:吉林省吉林市丰满区紫光绅苑 

版权所有©吉林省东电商务服务有限公司    ICP备案编号:吉ICP备18005811号-1