近期有几个跳槽去友商的同事回来和我说，“老吴你分享的怎么写方案挺有效，解决了不少写方案的困惑。”所以，觉得这套方案编写的思路可能帮到更多的乙方苦逼顾问们，在这里和大家分享一下。这套结构基本是匹配电商类系统建设的解决方案，enjoy~

之前任职的是一家电商软件产品公司，很典型的乙方特征。由于是KA业务，基本的业务应对思路是把客户的业务诉求通过一套以我方产品为原型进行定制开发的系统来支持。所以会遇到各种甲方爸爸一上来就要求给方案，给标准产品方案呢，“爸爸们”认为不精准对标不满意；要好好写呢，需要补充大量内容，不知如何下手，对售前顾问来说就是一篇大作文。因为当时业务并不聚焦行业，所以客户业务差别会很大，一篇优质方案攒出来，费脑又费时，往往吃力还不一定讨好。最关键的，很多人还不知道该怎么写。

方案，顾名思义是需要用书面化、结构化形式，把怎么做目标事情的完整构想描述出来，以让阅读者明白如何做才能达成目标。所以，那些靠堆砌篇幅而不说清楚做什么？怎么做？

下文我主要针对电商业务领域，以业务支撑系统为主要供应物的方案架构思路与大家共享。本文主要分享PPT方案，WORD方案可参照结构脑补，以后有机会再与大家分享。

一、理想的结构

先说一下理想化的方案架构，特别是针对有一定体量规模和行业地位的重要客户，方案的完整性与全面性是体现专业度的重要表现。所以我给出一个较完整的结构框架。

（1）公司介绍

一开始介绍公司，让甲方先在“兴头”上记住你们公司，特别要用对标案例去获得甲方好感与兴致。

（2）业务方案

首要先阐述客户该如何做电商业务，这部分是方案的核心，下文将重点展开。

（3）技术方案

因为具体的系统构建内容在上一部分中已经有表达，所以技术方案部分则把笔墨重点花费在对技术架构/机制的介绍；硬件拓扑结构与设计思路、配置要求的详细陈列；以及我方所提供的技术服务（包括基础运维、SLA等）

（4）服务方案

针对上述业务和技术方案内容，我方所提供的服务内容，可以包括软件维护（就是那些堆人头卖工时的内容）、知识转移（其实就是软件的操作培训、技术培训等）、其他服务（如果外包代运营、协运营、仓储服务、物流服务，可一并涵盖）

（5）项目管理

因为是定制项目，所以怎么干这个项目的表达一定少不了。一般都会包括项目管理方法论、项目管理组织结构、人员介绍、所使用的项目管理工具、概要项目计划等。

一般在竞标阶段都是以这样的方案结构来投标。

二、业务方案框架

业务方案的表达是本文的重点，一般用来做项目提案，常规按照以下结构来编写这部分。由于是以系统建设为核心，所以业务的表达与处理，都和系统能力关联。以后有机会再分享业务运营型方案的结构。

（1）业务理解

这部分主要是用来和甲方爸爸去“确认眼神”。如果能把业务背景阐述清楚，执行当前业务的商业思想剖析到位，业务设计的合理性能有效梳理。这部分是能否有效说服客户启动项目的前提。

（2）业务概述

尽量用扼要的表达呈现当前业务的结构或全景，用以总述性表达这个业务是怎样的结构，一般我们都用业务全景图来展示对业务的总览。这部分最好是具有高度概括的特征，把业务最关键的点呈现出来。有时这部分不太容易图形表达，可可以整理关键要素，进行概要型表达。

（3）角色模型

方案必须将业务与系统涉及的各类角色方描述出来，并说明在业务和系统中这些角色之间的关系。比如，B2C业务是买家卖家两方角色，虽然卖家中可以定义分子权限的角色（如，商品管理员、订单管理员、超级管理员等），但总的来说，他们还都属于同一类角色。

（4）应用特征

应用特征是描述业务的关键内容，业务和系统的特殊性都会体现在这里。举个例子，在MarketingPlace（多商家平台）业务中，收银环节就存在统一收银和分布式收银两种应用特征，前者是钱收到平台方，然后通过定期结算给商家；而后者则是实现实时或准实时的商家收银，与平台分账。这种应用特征的描述是把业务特点和系统要求定义清楚。这一部分的详略就会影响方案表达的精细程度和篇幅，如果进行全局表述又没有积累，是相当累人的。所以有时会用具有概要特征的业务逻辑图来表达，在讲解时一张图可涵盖80%以上的应用特征。

（5）系统架构

所谓电商业务必然会涉及系统，所以讲清业务之后，就要说明业务支撑系统是什么样的。后续内容都会围绕系统来讲。所以系统架构部分一般讲系统的功能结构和与外部系统的关系，可以用两张图来各自表达。前者讲明大致的功能布局与范围，后者讲清与哪些外系统进行哪些数据的交互。

（5）数据关系

遇到复杂的数据关系，则需要对数据关系的理解进行表达。比如以前我们做汽车后市场业务，商品数据是关联车型、服务、供应商、内容知识点，所以必须讲明其中的关联，客户就清楚你已经理解他的需求了。一般不是复杂项目售前方案不会涉及，那是概要设计中的内容。

（6）典型应用/流程分析

由于涉及业务定制，在没有系统可POC演示的前提下，会通过业务流程图的方式把业务流程或系统处理流程勾画出来。建议采用泳道图方式有角色特征进行描述。流程图辅以文字描述，强化其特征点。

（7）原型设计

由于电商类项目大多涉及客户端界面与流程，有些苛刻的或不专业的甲方，会希望乙方在售前阶段呈现直观的界面展现与操作。类似于广告领域的比稿。如果现有的原型产品不能便捷配置出POC Demo，就只能通过原型工具制作低保真或高保真原型，用来演示操作流程。方案PPT中可进行截图展示。通常这是在项目实施中的设计工作，如果售前阶段做这类活，那说明乙方已经不惜血本了，如果竞争失败就只能权当作为以后其他项目积累一些原材料。

（8）二开分析

对于用原型系统进行开发的项目，二次开发工作量分析也是相当重要的，这也是对外报价的基础。所以，我们以前通常会做差异化需求分析，陈列二开功能列表，将各种需要修改和增加的显性化、非显性化功能逐一整理出来，供技术人员进行工作量评估。这要求方案人员需要相当了解原型系统。

（9）运营设计

系统讲完了，一般业务方案就到此结束，但是有些项目会要求乙方进行运营规划。通常涉及运营领域可以从：运营框架、核心任务、运营策略、组织分工、管理制度进行分解阐述。

写一篇高质量的方案其实是挺累人的，特别在需要大量“原创”表达的时候。所以，在初次见面，甚至没有见面的时候，就要求乙方提供方案的情况，销售人员应当有一套应对甲方的“组合拳”，而不是拿着鞭子抽打顾问。这里也善意的提醒甲方爸爸们，若要乙方给出有价值的方案，应该要分享更多本方的业务思考和资源信息。一般知名外企，针对乙方提案都会提供一份RFP，虽说也见过名企写的超烂RFP，但如何做事的基本认知是有共识的。而大部分国企和私企，是需要加强这种认知的。

总结一下

个人在电商系统类方案上的经验，我强调以下三点：

（1）怕写文章的人，写不好方案

你想写好方案就不能怵写文章，更多的写作表达训练可以形成方案构思编写的感觉。

（2）写好方案的核心是逻辑+结构，多用总分结构

用清晰的表达层次和有说服力的内容表达，是方案表达的关键点。所以建议大家分解好方案的总体顺序，多用总分结构表达。大结构尽量扁平化，减少过多的总分层次。

（3）规整的方案呈现是基本要求

一篇被认可的方案，必然在表达上是有规范性的。字体字号的运用标准、标题规范、布局规范，用色统一、图形风格统一，都是尊重阅读者和体现专业编写的体现。本人很讨厌那种字体字号不统一、剪贴痕迹浓重的PPT，在我的逻辑里，你的诚意就暗示了你的质量。

本文由 @老吴 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pexels，基于 CC0 协议