角色地图:干系人识别与分类

业务流程的数字化转型往往涉及多个角色的利益交织。遗漏任何关键干系人都可能导致需求遗漏、验证失败或产品上线后无人问津。本章的任务是建立一张“干系人地图”,按角色类型拆解其立场、关注点与信息输入方式,以便在后续用户访谈与需求拆解中做到精准对齐。

五类关键干系人定义

在一个典型的B端业务流程中,干系人可归纳为以下五种角色。每个角色在需求链中的位置不同,决定了其访谈策略与方案表达方式。

角色 核心利益 常见职位 访谈关键词
决策者(买方/高管) ROI、合规、战略对齐、组织效率 CEO/VP/业务线总经理 降本、增效、风控、报表
执行者(一线用户) 操作效率、易用性、减少重复工作 客服坐席/采购专员/仓管员 麻烦、太慢、总是出错、能不能自动化
审批者(合规/风控) 流程可追溯、权限清晰、异常预警 财务审批人/法务/安全主管 审批流、合规检查、日志、留痕
技术对接人(集成方) 接口标准、数据格式、部署方式、维护成本 架构师/开发主管/运维 API、同步/异步、幂等性、容错
最终受益者(间接用户/客户) 服务体验、透明度、结果质量 内部使用部门/终端客户 等待时间、准确率、通知方式

干系人交互关系与信息流

以下流程图展示了一个典型B端采购审批场景中,五类干系人之间的信息流向与需求输入关系。

采购审批场景——干系人信息流与需求输入关系 决策者 CEO / 采购总监 审批者 财务 / 法务 执行者 采购专员 技术对接人 IT / 开发 最终受益者 业务部门 / 客户 战略要求 预算范围 采购计划 提交采购单 审批结果通知 交付货物/服务 接口状态回传 虚线箭头:系统间数据回传 实线箭头:业务流转方向
实用洞察: 当执行者与最终受益者之间存在大量手动沟通时,往往意味着产品需要一个“消息通知”或“状态看板”功能来替代人工传递。

每类干系人的用户访谈策略

针对不同角色,访谈的切入点和问题设计必须差异化。以下是针对每类角色的典型访谈场景与需求拆解方式。

1. 决策者:关注宏观价值

  • 业务问题:“目前采购流程中最大的成本浪费在哪里?哪些环节完全靠人工经验判断?”
  • 用户访谈:采用高层访谈法,以“投资回报率”为话题起点,不要抛技术细节。
  • 需求拆解:将“降低成本”拆解为“减少采购单审核耗时”和“降低手工录入错误率”。
  • 验收标准:“月均采购审批周期缩短30%”或“采购单录入错误归零”。

2. 执行者:关注操作痛点

  • 业务问题:“每天处理一张采购单平均需要多少时间?最让你头疼的重复性操作是什么?”
  • 用户访谈:安排“跟随观察+情境访谈”,直接查看执行者的工作桌面,记录操作步骤。
  • 需求拆解:将“操作太复杂”拆解为“自动带出历史供应商信息”、“表单字段默认值”和“批量导入”。
  • 验收标准:“创建采购单的点击次数从15次减少到5次”或“日均处理单量提升2倍”。

3. 审批者:关注合规与审计

  • 业务问题:“目前审批流程中,哪些单据经常需要退回修改?理由是什么?”
  • 用户访谈:要求审批者提供“最常见被拒原因TOP5”列表。
  • 需求拆解:将“合规检查麻烦”拆解为“自动校验采购单价是否超出预算”、“缺失附件自动拦截”。
  • 验收标准:“审批一次性通过率从70%提升至90%”或“平均审批时长减少50%”。

4. 技术对接人:关注集成与数据

  • 业务问题:“当前系统采购数据如何同步到ERP?是全量还是增量?出错后如何恢复?”
  • 用户访谈:采用“接口文档复审”方式,要求对方提供当前系统接口定义或数据字典。
  • 需求拆解:将“对接困难”拆解为“明确接口鉴权方式、数据格式、重试机制和日志记录”。
  • 验收标准:“接口响应时间 < 200ms”且“同步失败率 < 0.1%”,并提供失败重试日志。

5. 最终受益者:关注体验与结果

  • 业务问题:“从提报到收到货物,平均等了多久?过程中是否收到过任何进度通知?”
  • 用户访谈:由于数量多,建议采用“满意度问卷+抽样回访”。
  • 需求拆解:将“等待焦虑”拆解为“采购进度自动推送”和“预计到货时间倒计时”。
  • 验收标准:“NPS(净推荐值)≥ 60”或“主动查看进度率降低80%”。
避坑指南:避免仅采访执行者就定下全部需求。执行者往往只关注个人效率提升,可能忽略审批者需要的审计痕迹,或决策者需要的全局报表。始终用“干系人地图”来交叉验证需求。

交付物模板:干系人分析工作表

在完成本章用户访谈后,应输出以下模板,作为下一章节“需求拆解”的输入。

干系人分析工作表

项目名称:__________________    日期:__________________

| 角色分类 | 具体姓名/岗位 | 核心利益与关注点 | 当前主要痛点 | 成功标准/验收指标 |
|----------|---------------|------------------|--------------|-------------------|
| 决策者   |               |                  |              |                   |
| 执行者   |               |                  |              |                   |
| 审批者   |               |                  |              |                   |
| 技术对接 |               |                  |              |                   |
| 最终受益 |               |                  |              |                   |

关键业务问题定义(一句话描述):______________________________
关键总结:干系人识别不是一次性的静态工作。随着项目推进,新的利益相关方可能浮现(如安全审计部门或第三方供应商)。保持干系人地图的更新,是需求管理的基础动作。