一、理想的结构
先说一下理想化的方案架构，特别是针对有一定体量规模和行业地位的重要客户，方案的完整性与全面性是体现专业度的重要表现。所以我给出一个较完整的结构框架。
1、公司介绍：一开始介绍公司，让甲方先在“兴头”上记住你们公司，特别要用对标案例去获得甲方好感与兴致。
2、业务方案：首要先阐述客户该如何做电商业务，这部分是方案的核心，下文将重点展开。
3、技术方案：因为具体的系统构建内容在上一部分中已经有表达，所以技术方案部分则把笔墨重点花费在对技术架构/机制的介绍；硬件拓扑结构与设计思路、配置要求的详细陈列；以及我方所提供的技术服务（包括基础运维、SLA等）
4、服务方案：针对上述业务和技术方案内容，我方所提供的服务内容，可以包括软件维护（就是那些堆人头卖工时的内容）、知识转移（其实就是软件的操作培训、技术培训等）、其他服务（如果外包代运营、协运营、仓储服务、物流服务，可一并涵盖）
5、项目管理：因为是定制项目，所以怎么干这个项目的表达一定少不了。一般都会包括项目管理方法论、项目管理组织结构、人员介绍、所使用的项目管理工具、概要项目计划等。
一般在竞标阶段都是以这样的方案结构来投标。
二、业务方案框架
业务方案的表达是本文的重点，一般用来做项目提案，常规按照以下结构来编写这部分。由于是以系统建设为核心，所以业务的表达与处理，都和系统能力关联。以后有机会再分享业务运营型方案的结构。
1、业务理解：这部分主要是用来和甲方爸爸去“确认眼神”。如果能把业务背景阐述清楚，执行当前业务的商业思想剖析到位，业务设计的合理性能有效梳理。这部分是能否有效说服客户启动项目的前提。
2、业务概述：尽量用扼要的表达呈现当前业务的结构或全景，用以总述性表达这个业务是怎样的结构，一般我们都用业务全景图来展示对业务的总览。这部分最好是具有高度概括的特征，把业务最关键的点呈现出来。有时这部分不太容易图形表达，可可以整理关键要素，进行概要型表达。
3、角色模型：方案必须将业务与系统涉及的各类角色方描述出来，并说明在业务和系统中这些角色之间的关系。比如，B2C业务是买家卖家两方角色，虽然卖家中可以定义分子权限的角色（如，商品管理员、订单管理员、超级管理员等），但总的来说，他们还都属于同一类角色。
4、应用特征：应用特征是描述业务的关键内容，业务和系统的特殊性都会体现在这里。举个例子，在MarketingPlace（多商家平台）业务中，收银环节就存在统一收银和分布式收银两种应用特征，前者是钱收到平台方，然后通过定期结算给商家；而后者则是实现实时或准实时的商家收银，与平台分账。这种应用特征的描述是把业务特点和系统要求定义清楚。这一部分的详略就会影响方案表达的精细程度和篇幅，如果进行全局表述又没有积累，是相当累人的。所以有时会用具有概要特征的业务逻辑图来表达，在讲解时一张图可涵盖80%以上的应用特征。
一张“古老”的BBC业务逻辑图，近10年前画的竟然还有人在用
5、系统架构：所谓电商业务必然会涉及系统，所以讲清业务之后，就要说明业务支撑系统是什么样的。后续内容都会围绕系统来讲。所以系统架构部分一般讲系统的功能结构和与外部系统的关系，可以用两张图来各自表达。前者讲明大致的功能布局与范围，后者讲清与哪些外系统进行哪些数据的交互。
6、数据关系：遇到复杂的数据关系，则需要对数据关系的理解进行表达。比如以前我们做汽车后市场业务，商品数据是关联车型、服务、供应商、内容知识点，所以必须讲明其中的关联，客户就清楚你已经理解他的需求了。一般不是复杂项目售前方案不会涉及，那是概要设计中的内容。
7、典型应用/流程分析：由于涉及业务定制，在没有系统可POC演示的前提下，会通过业务流程图的方式把业务流程或系统处理流程勾画出来。建议采用泳道图方式有角色特征进行描述。流程图辅以文字描述，强化其特征点。
8、原型设计：由于电商类项目大多涉及客户端界面与流程，有些苛刻的或不专业的甲方，会希望乙方在售前阶段呈现直观的界面展现与操作。类似于广告领域的比稿。如果现有的原型产品不能便捷配置出POCDemo，就只能通过原型工具制作低保真或高保真原型，用来演示操作流程。方案PPT中可进行截图展示。通常这是在项目实施中的设计工作，如果售前阶段做这类活，那说明乙方已经不惜血本了，如果竞争失败就只能权当作为以后其他项目积累一些原材料。
9、二开分析：对于用原型系统进行开发的项目，二次开发工作量分析也是相当重要的，这也是对外报价的基础。所以，我们以前通常会做差异化需求分析，陈列二开功能列表，将各种需要修改和增加的显性化、非显性化功能逐一整理出来，供技术人员进行工作量评估。这要求方案人员需要相当了解原型系统。
10、运营设计：系统讲完了，一般业务方案就到此结束，但是有些项目会要求乙方进行运营规划。通常涉及运营领域可以从：运营框架、核心任务、运营策略、组织分工、管理制度进行分解阐述。