编辑导语：企业级应用设计对于解决企业内部不同部门间的业务诉求十分重要，本篇文章作者分享了企业级设计应用的设计框架以及具体设计步骤，详细地讲述了企业级应用设计的相关内容，一起来学习一下吧，希望对你有帮助。

一、企业级应用定义

在介绍企业级应用设计流程之前，我们首先要明白什么是企业级应用。

所谓企业级应用就是指那些提供给大型企业内部使用的软件系统，而这些软件系统的一个典型的特征就是，企业级应用不仅仅解决一个具体的业务问题，而是要解决一个领域在企业内部不同部门间的所有业务诉求，故此企业级应用往往需要横跨多个模块。

例如企业订单管理系统（OMS），就是将企业内部所有业务的订单进行汇总至一处进行统一管理。

再从侧面理解，与之相对的是各业务线内的一个个业务系统，只且仅解决某个具体的业务问题，这二者关系如下图所示。

例如业务线中的订单，首先在业务系统中将订单接收，随后传导至企业的OMS中进行统一汇总，由OMS进行统一透传与路由至下位系统。

二、企业级应用设计框架

讲完了企业级应用的定义后，接下来我们就来谈下具体的设计框架。在我的《中台产品经理宝典》一书中我曾提出过一个面向企业级应用设计的通用MSS模型。

这里最核心的部分可以被摘录为如下图的四步：

接下来让我们一个个展开来看：

1. 步骤01：需求梳理框架

这里需要注意的是，不同于业务系统我们需要将整个领域的完整需求梳理出来。

在领域梳理的范畴中我们需要掌握两个边界：业务边界，系统边界。

1）业务边界

按照领域梳理业务需求时，最关心的便是领域到底有多大？例如订单领域，库存领域。

我们在这一步要做的就是清晰的理出订单的生命周期到底是什么？虽然我们要整理整个订单领域，但是我们页不可能一味的让一个订单系统去管理所有与订单相关的事务。

例如，在订单管理的履约环节，虽然预约是严格按照订单的要求进行执行的，但是在此时我们不应该去以订单在下游系统中流转。

而是应该生成对应的出库单或履约单据，由他们去全新开启一个新的领域的工作，而在他们工作完成之后，只需要将工作结果也就是送达结果回传给订单。

这样就将我们的订单业务边界做了清晰的划分：

这里梳理业务边界我给大家一个方法：根据业务场景种类来进行划分，各类场景独立切分。

例如订单就是用户场景内的产物，而库内作业是企业内部仓库场景这两者就应该划分开并独立由不同系统承载，这也就是在软件设计中解耦思想最简单的一个应用。

当然在用户场景中还会包含若干个子场景，比如订单生成，订单金额计算等等。

2）系统边界

接着上面的思想继续展开，一个系统理论上应该只去解决一种问题。而这类问题就是我们这个系统的核心，例如企业级订单管理系统，它解决的就是订单的所有用户场景下商品单据的问题。

介绍完了边界，下面我们来谈谈如何来梳理，这里我们按照下图的公式进行拆解：

1. 角色：当前系统参与的业务实际人员角色是什么？用户角色的岗位是什么？每个岗位的具体日常工作又是什么？
2. 场景：这些角色参与的场景有哪些？在各个场景下都分别有什么需求？在当前场景为了完成什么样的工作？
3. 路径：将前面的角色与场景进行串联，就能得到每个角色在场景下的任务以及希望得到的工作结果，同时各个场景之间的依赖关系是什么？完成一件事都需要有哪些角色和场景的参与以及怎样路径流转？

通过这样的分析后，我们就可以将一个抽象化的业务，得到了一个结构化的业务流程图：业务起点是什么，包含哪些环节，各环节依次有哪些角色参与，最终业务结果是什么。

2. 步骤02：产品框架设计

所谓产品框架设计，本质就是在设计系统的功能架构，那么要如何设计一个系统的功能架构呢？

功能架构设计的第一步，就是要将一个抽象的业务领域划分为不同系统模块，让每个系统模块可以解决一个领域中的独立环节。

还是以订单的例子来说，订单处理的完整业务领域，我们可以将其划分为下面6个环节：

1. 接单环节：指记录用户所需要的商品或服务，并计算各种优惠及总价。
2. 提单环节：由接单环节用户确认后，提交并尝试生成订单，此时需要处理商品的库存锁定，生成付款单等操作。
3. 付款环节：指订单生成后，用户支付订单金额。
4. 路由环节：订单付款完成后，生成有效订单，此时根据订单所购商品或服务流转分单到对应仓储或门店，为下一步履约做好准备。
5. 履约环节：订单此时转化为出库单或履约单，由下游系统接收进行处理，并在完成后回传履约状态。（只负责下传订单至下位系统）
6. 逆向环节：订单完成后，在指定有效期内可进入售后阶段，此时便是逆向环节。

通过环节的划分，我们就可以得到在订单领域需要的系统模块，如下图所示：

但是截至到现在我们仅仅得到了一堆杂乱无序的功能模块。还不算完成我们的功能架构设计，我们还需要按照上一步梳理出的不同阶段，将对应的模块功能进行聚合整理，也就是将功能进行分层or分块。

例如在订单中我们可以分为三层：售前、售中、售后，如下图所示：

随后再将起初得到的各个模块放入刚才划分好的各层级中，便得到如下图所示最终结果：

可以看到，至此我们就很轻松完成了一个产品框架的定义。

在完成了产品框架设计后，我们对一个系统要包含哪些模块以及系统边界要做到哪些，我们就有了非常清晰的认知了，接下来我们就需要从宏观走向微观，开始逐个去梳理每个模块内部的功能流程。

3. 步骤03：产品流程设计

这一步我们就是要将前面所得到的模块进行逐一拆解，来逐个梳理功能流程是什么样子的？这和我们日常的工作就非常相似了。

具体来说，在这一步我们需要画出两个流程图：

1. 功能流程图：每个功能的基本处理流程是什么样的？在这里我们重点需要梳理每个流程中详细的业务规则，并将每个规则以流程图的形式表示出来。
2. 页面流程图：在绘制完页面后，各个页面的跳转逻辑是什么样的？

补充：所谓的页面流转图就是指各个页面中是什么按钮或组件触发页面跳转的，用以描述页面之间的跳转逻辑，此处的示例如下图所示：

还是以订单模块为例，我们需要在这里产出：

1. 订单优惠的计算逻辑流程；
2. 订单库存的锁定逻辑流程；
3. 订单转出库单逻辑流程。

这样我们就将一个功能完整且具体的表示出来了。

如法炮制，我们将第二步产品框架中所涉及的功能都依次描绘出来，这样一个完整的系统就表述完毕了。

4. 步骤04：功能版本设计

到了这一步其实就比较简单了，我们只需要将前面的产出，按照最小可迭代原型（MVP）规则进行拆分，并制定版本计划即可。

具体来说我们此处要做的工作可以分为下面三项：

1. 需求清单：将产品蓝图中的功能罗列，得到功能清单；
2. 需求管理：使用KANO进行需求优先级分类，在制定第一个版本时要注意尽可能将主流程的功能排入，以便快速上线验证业务逻辑是否正确；
3. 版本规划：详细定义随后的各版本以及包含的功能。

至此一个完整的设计框架就为大家介绍完毕了。

三、总结

综上企业级应用由于涉及面广，系统复杂度高，要能成功设计必须要有成熟的模型予以指导，从而帮助我们能有条理且渐进的完成产品设计工作。

#专栏作家#

三爷，微信公众号：三爷茶馆，人人都是产品经理专栏作家，2019年年度作者。《中台产品经理宝典》作者，原万达高级产品、MBA特约讲师、独立创业者，现叮咚买菜B端产品线负责人，拥有多款集团项目从零到一经验并带领实现商业化布局。

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

题图来自Unsplash，基于CC0协议。