2026-04-29 工作日志
营销活动中心早会
本次会议主要讨论了节后工作安排，明确了B端排期、数据清洗及系统资源检查等事项，并同步了重要项目的进展。 小结 1. 节后工作安排
明确了三个高优排期：B端收货柜距离控制与自主签收、卡券功能、以及产品走查发现的多个优化点。 排期将统一录入PM猫。
2. 重点项目进展
B站出口规则加入方案：已完成SL单，待评审。 消费者重要明细表数据反查：需进行数据清洗，以便后续分析。 系统资源检查：将按模板完成节前系统资源运行情况的检查。
3. 数据问题与修复
B端出货明细表数据异常：因导购及经销商的主数据未同步更新，导致签收人和出货人信息错误或为空。 数据修复进展：主数据问题已知，由小郑负责修复并重新推送数据。
待办 1. 排期与方案跟进
与小达老师沟通，明确各项任务的优先级并录入PM猫。马奇 确认B站出口规则加入方案的评审时间。马奇
2. 数据清洗与修复
清洗“消费者重要明细表”的数据，以便后续分析。马奇 与小郑确认其修复主数据问题的具体时间，确保节前完成。李宝仟
3. 系统资源检查
完成节前系统资源运行情况的检查，并提交给监理老师。张喜
MongoDB 凌晨 CPU 过高排查
问题现象：凌晨 MongoDB CPU 使用率超过 60%，但项目无数据相关处理任务。
排查过程：与云平台确认后，定位原因为 MongoDB 设置了凌晨执行数据均衡（balancer），导致 CPU 飙高。
结论：属于 MongoDB 集群自身维护行为，非业务问题，无需处理。
B端出货控制，码锁产品方案讨论
会议讨论了扫码预冻结方案以解决多签问题，并重点探讨了超时自动解锁的计时基准。 小结 1. 扫码预冻结方案
背景: 解决因多人对同一提货码进行扫码并提交，导致出货流向错乱的“多签”问题。 核心机制: 当业务人员执行出货、退货或调拨等操作时，系统会对扫码的提货码进行实时冻结。若其他用户在此期间再次扫码，系统将提示其联系原操作者解锁。 解锁机制: 包括三种情况：用户完成单据提交后自动解锁；用户主动取消扫码操作后立即解锁；以及根据配置的超时规则进行自动解锁。
2. 单据超时关闭配置
功能: 在营销活动中心的系统管理中，将新增一个“单据超时关闭”的配置项，允许管理员设置单据的超时时间。 配置范围: 目前将对所有适用场景（如大宗团购、日常开单等）使用一套统一的超时规则。
3. 超时时间的计时基准争议
核心议题: 讨论了单据超时时间应从“单据创建时间”还是“最后一次扫码时间”开始计算。 “创建时间”方案: 刘晓娜 认为应使用单据创建时间，这样便于业务宣贯，但可能导致操作不连贯的大单无法及时提交。 “最后一次扫码”方案: 陈祺 认为应使用最后一次扫码时间，能更好地约束用户在完成扫码后尽快提交，但技术实现上需处理好单次扫码间隔和整单失效的逻辑。
4. 数据与主数据一致性问题
会议末尾提及，系统中经销商与区域（5段）的归属关系存在不一致的情况，需通过查询主数据表来排查和修复。
待办 1. 单据超时时间计时基准确定
需要邱毅与业务方沟通，确定最终采用“单据创建时间”还是“最后一次扫码时间”作为超时计时的基准，并进行宣贯。
2. 主数据一致性问题排查
需要编写SQL脚本，查询并排查经销商、地址及区域（5段）主数据之间存在的不一致情况。刘晓娜
数据清洗评审
本次会议讨论了B端出货明细表的历史数据清洗方案，重点探讨了数据处理的技术实现、性能风险及后续的方案优化。 小结 1. 数据清洗需求与方案
背景: B端出货明细表新增了“经销商出货时间”和“签收时间”两个字段，其历史数据为空，需要进行清洗填充。 目标: 通过关联查询“流向信息”，将“签收时间”填充至B端出货明细表中。 范围: 清洗范围覆盖B端出货明细表和作弊明细表的历史数据。
2. 技术实现与性能风险
现有方案: 当前方案采用多线程处理，但经讨论发现，对1.5亿条数据进行逐条更新存在性能风险，可能导致服务崩溃。 优化方案: 应采用“先生成CSV文件，再通过Stream Load命令批量导入”的方式进行更新，以提升效率并降低对服务的影响。
3. 方案文档与后续步骤
方案文档: 当前的技术方案文档未能充分描述核心逻辑，如处理的表名、字段、时间分片依据等，需进行补充和完善。 后续步骤: 方案修改完成后，需在测试环境进行验证，并留存测试过程和结果。
待办 1. 方案文档完善
在方案文档中补充数据清洗的核心逻辑，包括处理的表名、字段、时间分片依据等。潘玉平 在方案文档中补充CSV文件生成与Stream Load批量更新的详细步骤。潘玉平
2. 方案实施与验证
修改代码实现，采用生成CSV文件并使用Stream Load进行批量更新的方式。潘玉平 在测试环境验证方案的可行性与数据准确性，并留存测试过程和结果。潘玉平 贾继伟将后续的测试检查项与潘玉平沟通。
3. 代码清理
清理已废弃的代码注释。潘玉平
TIP
作弊明细清洗职位名称/B端出货明细表清洗经销商签收时间方案，评审记录
- 两个方案分开写→背景、方案，闭环的内容放在一起
- 任务执行的参数补充到技术方案中，包括时间分片对应的表字段及逻辑
- 新开发的定时任务 没有用的代码直接删掉
- 数据更新不能使用单条更新，需要调整为学通要求的 csv + streamload 方式，提升处理效率及避免SR压力
金点子问卷·第一期结果回顾
本次会议旨在回应并解决近期收到的7个高频问题，明确了各项问题的反馈意见、改进方向和后续行动计划。 小结 1. 数字化项目管理与绩效
已将数字化业务价值创造、人才培养、项目质量（如进度符合率、里程碑评审率）纳入事业部及模块负责人的年度绩效考核。 部门内有66人未通过“鸿雁计划”D级认证，需推动全员尽快完成。
2. 会议管理
倡导“简洁高效，非必要不拉会”的会议文化，并强调“四不开”原则（无明确目标不开会、无充分准备不开会、无既定要求不开会、无明确主持人不开会）。 部门将对会议频次偏高、议程不清、材料冗余等问题进行专项调研。
3. 汇报材料与流程
明确了汇报材料的范围：TP4及以上人员必须填写周报，TP3及以下人员无需填写；将整合模块月报与部门月报；废除周报与双周报并存的情况。 合同报审流程正在持续优化升级中，部门将组织法务、财务接口人进行相关解读。
4. 项目管理与协同
强调项目经理需识别关键决策点并明确分工，确保目标一致。 计划在年终绩效评审中引入PMO互评机制，以促进项目协作。 协同办公平台将进行升级并引入智能化场景。
5. 信息沟通与经验分享
部门内部沟通氛围总体良好，但信息传递仍需加强。 将组织不限主题的工作分享会，鼓励模块内部及跨模块的经验交流。
6. 业务理解与一线沟通
已通过业务分享会等形式持续加强一线业务讲解。 鼓励模块组织线下交流，并将为新员工安排“拎包走基层”活动。
待办 1. 专项改进计划
针对本期高频反馈的问题，各模块需制定专项改进计划，明确责任人和完成时限，并在内部执行，无需向部门反馈。韩留阳 在二期“金点子”问卷中，将跟踪各项改进措施的落地成效。
2. 组织后续活动
组织不限主题的工作分享会，时间为每周三下午15:00-15:30。韩留阳 组织财务与法务接口人，就合同报审相关制度进行解读。韩留阳 组织PMO互评工作，并将结果提供给HRBP作为绩效管理参考。韩留阳
3. 后续调研与沟通
将与部分同事进行沟通访谈，深入了解问题的具体背景。韩留阳 整理并反馈领导的意见。韩留阳
物码全员阶段性沟通
液奶高层领导会关注
项目对事业部来讲，是战略级的，是长期的
去年问题频出，网络、系统间、组织、事业部，都出现了未曾出现的问题
孙总-液奶，亲自下场，解决相关问题，要求：
- 事业部+数科中心，负责人都要亲自下场，解决在事业部和职能部门的协同问题
- 加速数业融合
在需求上，聚焦到门店、核心链路
周期内重点工作：
- 100%关注用户体验，由产品牵头
- 用户满意度
- 和事业部建立工单制度
支撑：有个全新的系统支撑。确保数科做的系统让用户感觉有展业力。
架构要升级，包含技术、数据、应用架构，结合历史原因全链路分析物码项目在各个链路上进行重构升级。 架构，邱毅牵头
数据治理，宣春总牵头
需求：明确了需求的沟通的原则和机制，尚、赵会协同事业负责人对齐
整个项目端到端的深度分析，有哪些问题，接着这个机会，在成事的同时，打造优秀的团队，提升项目管理能力
6.沟通，明确的分工和职责。在数科中心内部、事业部，简单真实的沟通。
7.伊利超级助手，镇远牵头。东鹏的产品是在数字化的领域，伊利要在AI领域发力。如赢销助手增加Buddy功能。挑战：场景的选择、事业部的支持。经销商通过语音来获取内部的分析结论。
一定要把重灾区，业务持续更新的内容，需要业务去维护
本次会议旨在对齐“木马项目”的近期进展与后续规划，明确了项目在用户体验、架构升级、数据治理及团队协作等方面的重点工作。 小结
项目总体情况与近期目标 项目已进入攻坚阶段，集团及事业部领导将亲自关注，项目管理将更加规范。 项目核心目标是提升用户体验，确保产品稳定高效，为经销商和业务员带来惊艳的体验。 项目将引入AI能力，如“伊利超级助手”，以提升产品智能化水平。
关键工作方向 用户体验：需100%关注，前端需增加监控，启动用户满意度调研，并建立工单制度以快速识别和解决问题。 架构升级：需全面梳理和升级技术架构与数据架构，目标在未来半年内实现架构的显著优化。 数据治理：需解决当前数据不完整、不准确、不一致的问题，这是影响用户体验的根本原因之一。 需求与协作：需聚焦核心场景，明确需求方向，并建立坦诚、高效的沟通机制，实现团队“一荣俱荣”。
技术与数据盘点进展 产品：已解决线上反馈的多个历史问题，如出货人信息为空、签收信息缺失等，并明确了后续问题的解决方案。 数据：当前主数据质量评分不高，存在大量“沉默数据”和不一致问题。已启动数据治理专项，将从基础数据可用性和各端数据一致性两个维度进行治理。 技术：已完成物理架构梳理，识别出办公网VPN链路带宽紧张、AI图片识别链路性能瓶颈等风险点。 待办
数据治理 由尚总牵头，启动数据治理工作，需尽快明确启动方案。 数据团队需与业务团队协作，从源头梳理人员、门店等主数据的维护逻辑，解决数据不一致问题。 5月份需重点推进人员角色治理专项，解决人员多角色、角色多人员等异常数据问题。
技术架构优化 需尽快完成应用架构的梳理，绘制“全员一张图”，以便于问题排查和后续优化。 需跟进AI图片识别功能的性能问题，探索将图片处理迁移至腾讯云的可行性方案。
用户体验提升 产品团队需持续关注用户反馈，特别是性能类问题，如“转圈圈”现象。 需组织专项讨论，寻找高德地图API调用缓慢的替代方案。
项目协同 各团队需在后续沟通中，围绕明确的问题和目标进行讨论，提高会议效率。