如何从零规划一个解决方案级产品矩阵(二)

10 评论 8430 浏览 47 收藏 20 分钟

在没有完整产品规划经验的情况下,如何从零规划一个解决方案级产品矩阵?本文从制订产品路线图和产品设计功能两个维度出发,总结相关经验方法,希望对你有所启发。

一、制订产品路线图

1. 资源约束下的范围裁剪

至此,我们已将智慧能耗解决方案的实现路径有了基本概念,下面就开始根据战略愿景开始第一阶段的产品设计。但第一阶段需要并行完成计量与采集的前端设备,IoT平台,设备管理平台,以及能耗管理平台,工作量依然庞大。公司资源特别是软件资源无法覆盖,必须对范围及功能进行裁剪,否则会变成一个裹脚布项目。

智能硬件部分,策略是利用之前的技术积累,将之前的预研成果进行排列组合,快速实现硬件 demo。后期再针对上层应用需求,调整升级嵌入式程序。极大减轻硬件部门压力。

IoT 平台简化为仅保留基本功能的后台服务,南向对接公司内部硬件,北向对接能耗管理应用平台,功能上简单实现设备上下行数据接入与协议转换,数据上打通应用软件与智能硬件。后期根据市场及公司资源情况,再考虑是否将其升级为通用型的 IoT 服务平台。

将设备管理拍扁,简化为基本的设备资产管理并入能耗管理平台。将有限的应用软件团队,全部投入到最核心也最复杂能耗管理应用平台。

通过以上裁剪,将第一阶段的战略目标转换为下图所示的三层简结构。软硬件团队互为黑盒,独立并行开发,中间通过轻量的数据服务提供桥接,形成数据闭环。

https://image.woshipm.com/wp-files/2022/10/SxQNIcBFaHeJG2MbI0JS.png

现在,项目团队在怀揣方案全景的前提下,可以各自轻装急行了。

2. 目标用户的核心场景分析

自此,已完成从行业,到企业,再到项目的顶层设计。现在,我们将拿起扩大镜,对具体业务场景进行更细致的观察分析,识别出典型需求,进而开始功能规划。

通过市场调研分析,我们把用户使用场景,按是否计费与是否实时监控两个维度,划分为如下 4 个象限,并对对能耗管理典型场景的核心述求进行的简单勾勒。

https://image.woshipm.com/wp-files/2022/10/OEAoLV24bZTl774wa2MY.png

数据远程采集及基础数据接入场景: 如货场,仓库等,此场景下,只需对表端数据进行远程采集,仅提供原始数据在线显示及设备资产管理,系统不参与任何业务处理。这是最简单的使用场景,涉及的系统功能为基础功能,其它场景也需要使用。

自管物业等能耗抄收场景: 比如水电自管的老旧小区,公寓出租物业等,此场景下,存在管理方与使用方。管理方需要对使用方信息进行管理,对使用方的水电气热消耗量进行计量及收费。分户计量及费用收缴是其主要诉求,设备运维不太关注。系统目标是覆盖多种收费场景,兼容水电气热多种表计,做到采集,计量,计费,收缴费自动化。

商场园区等综合能耗管理场景: 商业园区场景下,同时存在收缴费及能耗设备监控的需求。希望在一个平台对水电气热用量及费用进行统一管理,同时对节点设备进行监管,但设备监控的实时性与复杂性工业能耗监控低得多。

  • 对水电气热多类型表具的运行健康进行监控
  • 对设备端异常状况进行报警及管理
  • 覆盖二级抄表市场一表一户,一户多表,公摊,等商务租赁场景
  • 兼顾后付费用户与预付费用户的远程抄收缴费。
  • 自动抄收,自动账单,线上线下缴费支持。
  • 方便用户自助查询缴费充值。
  • 对能耗数据进行分级分时多维分析
  • 成员及权限管理

工业能耗监控场景: 此场景下,主体是同一企业,目标对重点区域,重点设备能耗及运行等监控,无内部租户概念,不涉及收缴费流程。因业务需求,可能存在多种非能耗设备的接入需求,从而形成一整天监管系统。此场景下,能耗监管,设备状态特别是异常状态监控是其主要诉求。系统目标是事前预测,事中监控,事后分析。

  • 设备实时监控及管理
  • 异常状况报警及管理
  • 运行参数捕获分析
  • 能耗分级分时多维分析
  • 数据可视化展示

3. 构建核心业务概念模型

我们将能耗管理典型业务环节进行抽象,得到如下概念模型已便于观察分析。模型中红色矩形为关键业务实体,矮圆柱为关键数据,连线为他们间的关系。

https://image.woshipm.com/wp-files/2022/10/JALUdA6RfoJzPcc4pWkf.png

通过观察分析发现,能耗管理的业务本质是数据管理,其核心业务可抽象为三条数据流。

  1. 一条是由设备检测的实时能耗数据和硬件检测点的时空坐标所构成的,水电气热消耗量的时空数据流。这是研究能耗区域与时间分布的主线,能为企业生产销售上的分析决策提供时空上的四维视角。
  2. 一条是由计量点位的用户归属,及归属用户所对应的计量计费方案,所构成的能耗费用数据流。计算能耗经济成本,主要依赖这条数据流。
  3. 一条是由设备状态,监控事件,环境传感等实时数据流构成的,设备监控数据流。对设备运行的监控,主要依赖这条数据流。

以上三条数据流,分别对应1,2,4象限的应用场景中的核心业务。三条数据流合起来,就构成了第三象限的核心业务。我们将上述洞察丰富到概念模型上,于是构建出如下识别度更高的概念模型,用以指导进一步的产品设计。

https://image.woshipm.com/wp-files/2022/10/Lo1z0gZPWuX97w03ljfe.png

4. 产品路线图

通过对典型场景下业务概念模型的进一步分解与取舍后,得出第一阶段的核心功能范围,制定出如下产品路线图,用以指导后续设计研发工作。

https://image.woshipm.com/wp-files/2022/10/hct6ysDVa9pnQR3IAw80.png

二、设计产品功能

1. 设计功能结构

现在让我将视角再切回起点,提出智慧能耗解决方案的原因,是因为市面方案存在架构老旧,兼容困难,业务割裂,数据孤立,扩展受限,售后及维护成本高昂等问题。

而我们的方案定位,是提供一套软硬件一体,水电气热综合管理,抄收缴管一条龙服务,后付预付全覆盖,能耗数据全打通的一站式解决方案。能耗管理云平台的设计目标就是解决现状问题,实现方案定位所设定的目标。 在进入功能设计之前,我们需要确定一个相对灵活的系统结构,这个结构需要有如下特点:

https://image.woshipm.com/wp-files/2022/10/Odbl8BGGnVA68CfEiVgb.png

从上述要求出发,兼顾预留后期扩展的基础上,对智慧能耗系统进行拆分。以使用人员的类型差异为拆分线索,将智慧能耗系统划分为商户管理端,企业业务管理端,用户远程查缴费客户端。其中企业业务端暂时只实现 web 版,后续再行实现移动版。这是极简关系架构关系图。

https://image.woshipm.com/wp-files/2022/10/XngvhhvzcvwBwSx3F9Hc.png

各端的目标用户及大致功能描述如下: 商户管理端: 目标用户为我司及其它具备客户承接能力的表具厂,系统集成商,渠道商等合作服务商。提供设备管理,客户管理,客户设备类型及功能配置等管理功能。

企业业务管理端: 目标用户是『园区物业管理方』等我方或服务商客户。提供用企业内部能耗用户管理,能耗设备管理,能耗数据的远程抄收,费率配置及费用收缴业务,并提供数据分析及报表下载等管理功能。

用户查缴费应用: 目标用户是能耗商户下属的终端用能用户。提供用户自行远程查询能源使用情况,缴费账单及远程充值缴费等业务。减少企业及其用户的交易成本。

将系统结构与功能范围结合,制订出如下功能结构图。图中不同颜色代表功能的不同优先级。蓝色优先级最高,其后依次为青,橙,黑,灰。

https://image.woshipm.com/wp-files/2022/10/Qtn9xchxBFsWatJqecVx.png

从上述认知的基础上,做进一步分析梳理,设计了各端权限控制及数据流转架构。

https://image.woshipm.com/wp-files/2022/10/8OTS3WWaDWJaI4O0aq9h.png

2. 设计数据基座

有了前面工作的铺垫,现在开始进入具体的业务设计。在进入具体业务设计前,让我们再次观察之前所抽象出的业务概念模型。不难发现,这是一个典型的,由数据驱动的 AIoT 业务流。

全部业务由红,绿,黄,紫四条数据链组成,覆盖了四种典型的业务场景。其中红色数据链是关键数据输入。其它三条数据链都是在红色数据链的基础上,辅以不同业务规则而发展出来的数据应用。

https://image.woshipm.com/wp-files/2022/10/Lo1z0gZPWuX97w03ljfe.png

也就是说,红色数据链是整个业务的数据基座,我们需要确保它的健壮性,挖掘它的可能性。

红色数据链的外部输入是各类传感与智能设备。我们通过“设备档案”,记录设备的类型,归属层级,网络类型,关键参数等数据,为后续构建设备的节点网络进行数据构建。

每个设备节点都有独立 ID,而它们上传数据都会带有时标,也就是说,每个设备节点都是一个天然的时序数列发生器。而每个智能设备都会有一个物理上的安放点或检测地点。这样我们就能将设备上一维的时序数据,关联上三维的空间数据,升维成四维的时空数据。

我们引入了“最小计量区”这个概念,用来代表具体设备的检测点,并关联空间坐标。因为我们关注的是园区管理,需要更细的空间划分。所以在地理位置的基础上,进一步拓展出楼栋/楼层/区域三级空间维度。结合行政区划上的省/市/区县/乡镇/村组,我们构建了 8 级空间,用于以后的数据切片及分层统计。

通过上述方式,我们已经将设备上的单一的原始数据加工成有6个时间深度(年月日时分秒),8 个空间深度,带48 个切面的原子数据。再加上节点网络维度的划分。我们有了一个可能性极大的数据基座。

下面以智能电表为例,说明下红色数据链的在实际系统中的加工过程。

https://image.woshipm.com/wp-files/2022/10/LWuJcVG7BVhdMOTrK1Ll.png

3. 设计业务实现方案

之前,我们通过是否计费与是否实时监控两个维度,将纷繁复杂的业务场景划分为了四个场景类型。并抽象了关键业务模型,提炼出了 4 条数据链。同时将设备输入通过红色数据链加工成了数据基座。下面,我们将在数据基座的基础上,开始具体业务实现方式的设计。

https://image.woshipm.com/wp-files/2022/10/OEAoLV24bZTl774wa2MY.png

这里选择既有设备监控又需计费的商务园区场景为目标,进行能耗业务设计。因为这个业务场景,涉及到数据基座中的全部数据链的使用。完成这个场景的设计后,其它 3 个场景,只需此基础上配置各自的业务规则,就可以完成各自的业务设计。为简化问题,我们将设备这块内容折叠变换将核心业务抽象为如下模型。

https://image.woshipm.com/wp-files/2022/10/X1LDPlPthNUOlIB73JIH.png

从模型中可以看出,统计最小计量单元的实时用量,就能得出不同区域在不同时段用量。通过查询用户使用区域,就能统计到用户的耗能情况。通过计费规则与出账规则的计算,就能得到用户账单费用。

大的逻辑是这样的,但实际情况远比这复杂。就拿支付账单举例:商务园区场景下有先用后付及预付后用两种业务形态,支付方式可分线上与线下两种方式。同时因为管理方式不同,预付业务有充值及退还,费用不足提醒,透支额度授予,自动阀控反制等业务管理需求;后付业态有滞纳账单等罚性手段等业务管理需求。下图是对能耗费功能的大体描述。

https://image.woshipm.com/wp-files/2022/10/JulIVfGBsdFx1l6EmCMK.png

拆分到上面这个程度,我们已经对这块的业务建立起了总体印象,对后续功能的总体走向有了把握。但认知还是停留在宏观层面,业务逻辑的颗粒度太大,不足以指导系统开发。需要进一步细化挖掘,才能形成对业务的微观层面的理解,最终提炼出实现业务的关键路径,进而设计出对用户真正有用的功能。

下面抽出付费模式这个业务点举例,其进一步细化分析如下:

后付费模式(1:1,1:n,n:1):

https://image.woshipm.com/wp-files/2022/10/EcwHiPCy9k8sBdqsZ8FV.png

预付费模式(1:1):

https://image.woshipm.com/wp-files/2022/10/2DRQ50OWhFdBZL7hKvhY.png

通过上述的细化分析后,我们才真正认识到实际场景下用户需求的多样性,才能设计出覆盖全面,从容应对多种业务场景的能耗收费功能。而不是一个漏洞百出,需要频繁打补丁才能运行的收费模块。

综合上述分析与业务模型,与设计按用户类型配置个性收费方案的功能,覆盖典型业务场景下的所有业态。对于无需收费的内部能耗监控场景,不配置收费方案即可。

https://image.woshipm.com/wp-files/2022/10/pjcwwIonsZGrofvVXUVb.png

对于需要收费的场景,我们提供自动抄收,自动出账,自动扣费,远程缴费,以及自动催收,自动阀控等自动化能耗计量计费及收缴一条龙服务。并且覆盖了水电气热多种能耗类型。

https://image.woshipm.com/wp-files/2022/10/ZVTZq1xmbWMDpnurJ9W1.png

文章内容较长,将分成三个篇章输出。后续篇章会在上述内容的基础上,对 2B 类产品的 PRD 输出示例与项目总结等内容进行输出。

如何从零规划一个解决方案级产品矩阵(一)

如何从零规划一个解决方案级产品矩阵(三)

本文由 @李金尧 原创发布于人人都是产品经理,未经许可,禁止转载

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 作者你好,看了你的文章,觉得总结得很系统和精炼,能否联系您为我们的产品进行交流,价格可双方协商

    来自陕西 回复
  2. 大佬,s端中的商户管理中的商户 就是b端的企业吗?

    来自陕西 回复
    1. 你好,是SaaS系统。S 端被管理的商户就是 B 端企业账号。

      来自上海 回复
    2. 感谢大佬解惑

      来自陕西 回复
  3. 大佬,看你分为三类用户,还有个商户管理端,你这个产品是一个SaaS化的产品吗?

    来自陕西 回复
  4. 都是干货!求更新!

    来自浙江 回复
  5. 可以分享一下原图吗?好几张图看不清了

    来自四川 回复
    1. 这里主要是分享思考思路,里面图片没特意设计,部分不太清晰也是刻意为之,原因是有些可能涉及业务内容。实际项目中涉及的文档比文章描述的多上一个数量级,同样是上述原因,设计细节不便公开。

      来自上海 回复
    2. 理解,感谢!

      来自四川 回复
  6. 厉害 很细致

    来自湖北 回复