个人工作说明书

公开版(已脱敏) · 生成日期:2026-09-17

一、个人职责

岗位信息

称呼镜子
部门流程数智化部
岗位流程管理主管(业财融合与流程交付方向)

六大核心职责

职责说明
1. 流程架构与端到端流程建设对齐公司流程架构规划,统筹 LTC(线索到回款)、OTD(下单到交付)端到端流程的梳理、架构设计与迭代优化;牵头组织流程走查验证、执行差异分析与问题闭环整改,输出流程清单、流程说明等标准化资产。
2. 流程制度固化与财务合规闭环负责所承接流程的制度固化与一致性校验,保障流程执行与制度要求一致;配合内部审计与合规检查,从财务 BP 视角输出流程成本效益分析与优化建议。
3. 流程资产向系统能力转化协同将标准化流程资产转化为系统等数字化工具需求,协同开发团队按业务优先级推进开发与上线落地,以业务反馈反向驱动流程与系统持续迭代。
4. 流程变更管理与台账维护负责所承接流程的变更全流程执行,规范完成变更评审、公示与落地跟踪;同步联动对应制度条款更新。
5. 业财融合流程需求响应响应业务端财务类流程需求,从业财融合视角提供流程解决方案,打通业务与财务之间的流程断点与协同堵点。
6. 流程知识沉淀与培训支持配合流程知识沉淀,输出财务域流程操作指引与培训支持,提升团队对标准化流程的掌握与复用能力。

二、典型一天

以下时间分配基于固定会议安排及工作模式分析,标记 ⏳ 的为待核实项。

周一(周会日)

9:00–9:30
周会材料最后准备、数据核对
9:30–11:30
周度汇报会(固定)— 序时目标回顾、灯号确认、跨组对齐
11:30–12:00
待办事项提取,计划本周工作,跟进待闭环事项
14:00–16:00
跟进开发供应商修复、测试验收
16:00–17:30
需求文档编写 / 串讲会议
17:30–18:00
当日待办梳理、问题清单更新

周二 / 周三(深度工作日)

9:00–9:30
消息处理、优先级排序
9:30–12:00
跨部门沟通(业务/运营/财务)或全链路测试
14:00–16:00
功能模块需求文档 / 数据缺口梳理 / 流程修订
16:00–17:30
与开发供应商对齐进度、串讲演示
17:30–18:20
问题清单沉淀、群待办催办

周四(部门例会日)

9:00–12:00
同周二/三上午
14:00–15:30
同周二/三上午
15:30–16:00
本周工作梳理复盘
16:00–17:30
部门周例会(固定)
17:30–18:20
例会纪要整理、行动项提取

周五(收尾与规划日)

9:00–12:00
本周剩余测试验收、问题闭环
14:00–18:00
同 9:00–12:00,以及同周二/三下午(跨部门沟通、功能模块需求文档、与开发供应商对齐等)
18:00–18:30
周报撰写、下周计划梳理
灵活时间块:会前材料准备(约 1–2h/次)、会后材料总结(约 0.5–1h/次)、临时协调会(平均每周 1–2 次,每次 1h)— 这些穿插在上述时间段中。

三、近期工作线索

核心工作线

工作线关键事件状态
航运管理系统全链路验收本地 demo 演示 → 串联总览定稿 → 应收全链路攻坚(提单/对账/核销/催收/坏账 5 大节点)黄灯
30+ 项功能模块数据衔接数据缺口梳理 → 串联关系汇总定稿 → 逐节点串联规则输出进行中
业财测算平台改造方案定稿并向开发供应商讲解(3 份开发文档),ERP 数据接入排期已定稿
变动成本方案决策2 周内 2 次跨部门 + 管理层会议,第 2 次因第 1 次未邀请关键领导导致结论被推翻而重复已闭环(有返工)
业务部门需求征集向业务、运营、财务发起报表/看板/移动端需求征集,三部门均未响应黄灯
结构化周报每周七段式结构化汇报(实际结果→差距→过程→原因→根因→最佳实践→应对举措)持续

四、协作关系

内部协作

角色协作内容
同组同事 A功能模块开发分工、周报联合担责、串联总览核对
同组同事 B串联总览核对、问题反馈
部门经理集成卡点协调会组织、决策支持
技术对接人开发供应商对接、开发规则确认、数据源对齐
系统管理员航运管理系统调整、demo 差异处理
高管层流程确认、方案决策审批

外部协作

角色协作内容
开发供应商功能模块开发部署、功能修复、系统调整。沟通卡点:修改不到位、反复反馈同一问题
业务部门流程走查反馈、需求征集(未响应)
运营部门流程走查反馈、需求征集(未响应)
财务部门应收应付取数规则确认、需求征集(未响应)
设备管理部门流程走查反馈

五、常见输入与输出

常见输入

常见输出

六、问题与改进机会

改进点 1:与开发供应商的沟通闭环机制

问题:测试修改需求反复截图、列清单给开发人员修改,但总是修改不到位,同样的修改反反复复反馈和测试。存在沟通卡点。

根因:需求传递依赖"截图 + 文字描述",开发理解与业务预期存在偏差;缺乏修改后的自动比对机制,只能靠人工回归测试发现遗漏。

建议改进:

改进点 2:会议决策的参与人完整性检查

问题:某方案在 2 周内举行了 2 次跨部门及管理层会议(第 2 场重复),重复准备方案设计会议材料和会后总结文档。因第一次没有邀请关键领导参与,得出的结论后来被推翻,导致重复工作、重复开会,浪费了人员、时间、开发资源。

根因:会前未做"决策参与人完整性检查"——未识别出该决策需要哪些关键审批人到场,导致会议结论无效。

建议改进:

改进点 3:需求收集的完整性与确认机制

问题:前期收集开发需求、产品原型演示收集修改需求时,用户没有提出的需求,在接近交付阶段给用户演示系统各节点页面功能时,用户推翻前期的结论,或者提出前期没有提出的新的需求,影响交付进度。

根因:用户在看到真实系统前难以想象完整使用场景,"先建后验"模式下需求天然存在滞后性;前期需求确认缺乏"最终确认签字"机制,用户认为可以随时补充。

建议改进:

改进点 4:测试数据准备的自动化

问题:对账单生成链路测试数据不足(已开票、逾期未回款记录少),需多造数据才能测到后续节点。

根因:测试数据依赖真实业务数据,但真实数据在系统未上线前天然不足;人工造数据耗时且覆盖面有限。

建议改进:

七、AI 辅助点

已在使用

环节工具效果
结构化周报撰写AI 周报助手七段式结构化自动生成,大幅减少写作时间 已验证
功能模块串联总览AI 生成初稿30+ 项功能模块串联关系汇总由 AI 产出,人工核对修正 已验证
部署差异迭代AI 截屏反馈复杂功能模块部署后通过截屏反馈让 AI 迭代补充 已验证

可引入但尚未使用

环节AI 可协助方式预期效果状态
问题清单整理从群聊记录自动提取待办事项,生成结构化清单减少手动截图 + 录入时间约 50%待验证
修改前后比对AI 对比修改前后的截图,自动标注差异点减少回归测试时间,提高问题发现率待验证
会议纪要生成会议录音转写 + 要点/行动项自动提取会后整理时间从 30min 降至 5min待验证
测试数据生成基于业务规则自动生成覆盖边界场景的测试数据解决数据不足导致的测试阻塞待验证
需求文档模板填充基于流程清单自动生成功能模块需求文档初稿减少重复性文档编写待验证
会议参与人检查会前自动检查关键决策人日历可用性避免无效会议和重复开会待验证

八、人工确认边界

必须由人确认的决定

决定类型为什么必须人工
需求优先级排序涉及业务价值判断和资源分配权衡
跨部门协调方案涉及部门利益平衡和权责划分
验收标准定义涉及业务风险承担和上线判断
上线时机决策涉及多部门就绪度和业务影响评估
流程变更审批涉及制度合规和审计要求
方案决策会议参与人缺席关键领导导致结论无效(已发生)

— 公开版结束 —
本页面已去除真实人名、客户名、内部标识、金额、账号等敏感信息。