产品方案设计：理财系统MVP方案设计思考(2)

用户的理财操作行为，需要有相关的后台运营管理进行支持，保证业务进行，一般来说运营管理会有以下岗位的人进场，包括运营、财务、销支、销售、客服，随着任务细分，会有更多不同的角色，每个角色的立场不一，其需求也不尽相同。一般来说理财后台包括产品管理（产品基本信息管理、产品收益管理、产品份额管理等），订单管理（分为购买订单和赎回订单），系统对账（包括购买订单对账和赎回订单对账），财务会计（资产总览，清算结算），业务配置（如上下架、热门产品等）

理财基础信息主要包括产品信息、用户信息，根据业务模式不同，还包括渠道信息、销售信息等。基础信息是支持理财业务的基本信息，所有的业务形成都离不开基础信息的稳定。

理财系统中包含的重要逻辑处理模块，如理财购买环节，包括订单生成逻辑、订单状态变更逻辑、失效订单自动处理，若该环节涉及多个系统，还包括信息分发逻辑；理财赎回环节，根据产品类型和用户操作不同，可分为用户主动赎回、到期自动赎回，根据业务不同，还包括赎回续投、违约赎回等逻辑，同时赎回中，还包括服务费计算等；收益计算，是根据用户形成的购买订单，进行收益计算，包括活期浮动收益计算，定期收益计算等；对账清账逻辑，则根据业务需要，设计对账匹配逻辑、数据去重逻辑、定时任务等。

在理财系统中，支付功能是必不可少的环节，由于支付功能的复杂性，一般有独立的支付系统提供稳定的支付服务。支付系统对理财系统的支持，不仅体现在支付通道的支持，后续包括理财订单对账功能也需要支付系统提供数据。根据不同业务需要，其他相关业务系统还包括财务系统、风控系统等。

若理财系统对接多个资产源，需要在产品设计过程中考虑多资产类系统接入，如基金、保理类资产等。

本文所述理财系统的核心业务信息流主要为理财认购、赎回及收益展示，所描述的信息流主要为关键的正向信息流设计，相关边界情况及状态变化不在本文中详细展开。

理财认购流程设计

理财认购流程，由用户在前台进行发起，在前台认购过程中进行初步的购买条件判断，如用户登录状态、认购金额大小、理财产品是否处于可购买状态等，将用户信息、购买信息封装后传后台，由后台进行更加严格的校验。

理财购买过程中，投资单创建生成购买订单将形成唯一编号，根据不同的产品来源进行分发完成额度判定、锁额等动作；完成份额锁定后，返回用户可进行支付信息，一般该流程在程序中执行是比较快的，用户完成结算后进入支付环节发起支付，根据支付系统的各个状态标识订单状态，该过程与接入不同的支付系统有关；对账环节是确认用户资金是否实际到账环节，根据自身业务需要，标记订单状态，该过程订单状态的流转将反馈给用户。

理财的购买订单具有完整的生命周期，并且认购订单对账成功后，仅是进入认购成功状态，该购买订单还未进入终态，根据理财类型活期和定期不同，该订单还需要标记赎回状态。产品初期定期产品自动返回用户账户，无续投动作，购买订单状态的终态可标识为已完成；活期产品赎回则需要确定日切时间，并根据每日的本金、收益动态更新。

理财赎回流程设计

本次的理财系统设计中，设计的赎回流程仅针对定期理财固定返回原账户的流程，由于业务结构不同，目前很多产品设计了多种赎回规则和方式，本文暂不详述。定期产品到期后自动赎回原账户，是依据购买订单信息自动生成的，关键信息包括订单需要生成赎回单的购买订单状态、起息时间、结束时间，通过定时任务生成赎回订单，并进入赎回订单系统。赎回打款包括系统自动打款和财务打款，根据依赖的支付系统查询标记赎回订单状态。

理财收益展示设计

理财的购买和赎回是理财系统两个重要的环节，用户在购买和赎回两大流程中，收益的查看是中间流程。用户从生成购买订单状态开始，就具备的收益计算的初始条件，而用户查看收益包括单笔订单收益、持有收益以及历史收益等场景，不同的业务结构可能有预期收益展示的需要，对于本金变动，也有不同的计算规则，因此收益计算系统也应该具备不同的模型计算不同产品的收益，对外提供标准的收益查看数据。

产品工作过程中，接触到的大部分任务均是在现有功能基础上进行迭代优化，而对于一个产品从0到1的搭建，是非常考验一个产品逻辑思维能力和产品视野的。在面对一个从无到有的系统搭建过程中，需要在众多的业务信息中，在理解需求背景的基础之上，梳理出关键的流程。

我总结了一下面对一个产品设计的思考过程，从大的格局上说，需要明确产品是否真的有价值，而具体实施过程中，有以下环节：

文章作者系 @小T 未经许可，禁止转载。

（编辑：ASP站长网）