大B端的难点在于：垂直壁垒太深，很难跟别人说清楚价值在哪里，到底做了啥。
破局核心是对标。
按C端的逻辑介绍B端的产品，行业分析-企业分析-流程分析-用户分析-痛点分析-竞品分析-功能结构图-页面逻辑图-功能架构图-原型绘制-用户访谈-原型修改-数据字典-商业化路径。
以之前做过的云-边协同的电力需求侧响应系统产品为例。
行业&企业分析：需求侧响应是指，在电力调度中心的指令下，电力用户下发改变用电行为，缓解高峰时用电紧张，避免或这减轻系统非正常运行状态。大背景，20年8月广东电力现货市场试运行，电价从静态的变为一小时更新一次动态变化，用户的用电行为会跟随电价实时变化而发生变化，而用户行为的变化又会影响到电价变化，调度中心需要采集-存储-分析各类电力数据，以帮助其制定调度指令下发给用户，缓解高峰时用电紧张，避免或这减轻系统非正常运行状态。
用户：工商业企业（执行、反馈命令）、电网调度（制定、下发命令）
痛点：目前是小范围试点运行，而且调度指令的精度要求较低，云调度中心的算力与通信延迟尚可以支持，如果大范围推广后，有各种类型的用户，发电厂，电力设备接入该系统，数据量、数据维度、计算复杂度指数级上升，云架构下的调度中心算力与通信延时将无法满足要求，因此需要提出一种能低延时高可靠的系统以满足大范围高精度的错峰用电、故障预防恢复等需求侧用电行为调整。
竞品分析：无。
解决方案：业务逻辑+最小原型+架构（双架构模式，IT架构与业务架构）
业务逻辑：利用云-边协同，将可以在局部区域就近计算产生阶段性结论的任务，用边缘侧算力计算，然后只将局部结论和总体结论所需的数据上传给云中心，降低延迟和算力负担。
具体来讲：第一步，分析哪些是在局部区域可以计算的结论，需要什么数据？第二步，总体计算还需要什么数据？
局部区域需要得到：该区域的用电、发电设备的精细动态模型。（工业用户画像），该区域的设备运行状态，用电设备可调节能力定量评估。
局部区域需要数据：发用电设备参数值，用电曲线，电价，局部电网拓扑结构，气象数据温度湿度，风速等
总体计算需要得到：整个区域网络，每个节点每小时的合理电价，判断系统是否有潜在风险，如果有，哪些用户或者发电厂需要做出什么样的改变？然后下发指令。
总体计算需要数据：局部区域的结论+与整体区域互联的外部区域边界条件，包括外部区域可支援本区域的容量，区域交界处的传输容量与风险指标
需要的IT组件：双向电表（采集）-CMQ（传输）-Tbase（HTAP数据库），TDSQL（高并发），CTSDB（时序），HDFS（归档类）-回归拟合、知识图谱-安全套件-数据治理套件-运维套件
最小原型：大B端不可能一次性买很多，所以最小原型就格外重要。好的最小原型：可切入的亮点。在数据源侧接入高精度工业用户画像，在局部区域打造亮点-区域的用电、发电设备的精细动态模型。
最小原型需求：借助高精度工业画像，实现实时电价下的错峰用电行为调整。
局部区域需要得到：该区域的用电、发电设备的精细动态模型。
局部区域需要数据：发用电设备参数值，用电曲线，电价，局部电网拓扑结构
总体计算需要得到：整个区域网络，每个节点每小时的合理电价然后下发指令。
总体计算需要数据：局部区域的结论。
需要的IT组件：双向电表（采集）-CMQ（传输）-Tbase（HTAP数据库），TDSQL（高并发），CTSDB（时序），HDFS（归档类）-回归拟合、知识图谱
功能架构：
IT能力架构：采集-接入-传输-存储-分析需要干什么，哪些组件？
业务能力架构：
全部评论
(2) 回帖