业务咨询方案 + IT落地方案建议设计 近期，在深入探索咨询方案的实施与落地路径时，体会到了一系列心得与启示，旨在为未来的项目实践提供可借鉴的蓝本。咨询方案的精髓，在于“业务引领，IT支撑”的核心理念。所以方案的前提是在于业务的梳理；
探索接口平台框架：构建高效数据交互的桥梁 奇门模式，顾名思义，是一种遵循特定标准或规范设计的开放接口平台。它提供了一套标准化的接口协议和数据交换格式，确保不同系统间能够基于统一标准进行沟通。这种模式的优势在于降低了接口对接的复杂度，提高了系统的兼容性和可扩展性。PI模式，即Process Integration模式，允许用户根据实际需求自定义接口字段的映射关系。这种模式打破了传统接口框架的固定格式限制，提供了高度的灵活性和定制性。通过配置字段映射规则，可以轻松实现复杂的数据转换与集成需求。
领导变革与危机感的树立——从一家企业的真实体验说起 因此，作为领导者和管理者，我们需要不断思考和探索如何更好地树立危机感、激发员工的积极性和凝聚力，为企业的发展注入新的动力和活力。在业绩下滑的背景下，新员工对公司的忠诚度确实较低，他们更多地关注自己的利益和发展；这种“上忧下安”的状态，让我想起了书中提到的观点——当企业中有20%的员工具备危机感时，整个企业的凝聚力和行动力将大为增强。今年，我们企业所处的市场环境尤为严峻，业绩不尽人意，质量问题频发，然而在与同事的交流中，我发现了一个令人担忧的现象：尽管领导层深感危机，但底层员工却似乎对此毫无感知。
打造重量级团队：跨越壁垒，引领主数据事业的新篇章 本文将结合我所在公司成立的重量级虚拟组织，探讨如何打造一支真正的重量级团队，并突破团队间的壁垒，共同推动主数据事项的顺利推进。与轻量级团队不同，重量级团队的领导必须是有实权的公司领导。在团队运作过程中，我们需要明确团队目标与责任、建立良好的沟通机制、制定统一的工作标准，并打破团队间的壁垒。1、调整团队领导：公司高层意识到问题的严重性后，迅速调整了团队领导的人选，选派了一位有实权的公司领导担任团队领导。2、明确责任与分工：在新的团队领导下，我们重新梳理了各部门的责任与分工，明确了各部门在项目中的定位和角色。
业务中台IT内部拉通会分享 举个例子，如果我们计划在下下周进行UAT测试，那么本周我们需要做的工作就包括：向项目经理提出关于UAT培训人员的拉通需求、制定培训计划、收集UAT测试用户，产品经理应该提供培训文档、测试用例、或提前准备好期初数据，研发经理应提前准备好UAT培训环境。此时，我们需要一个能够整合所有产品、研发和项目资源的人。关于会议文档的内容，我们设计得非常简单，只有序号、事项、计划开始时间、计划截止时间、责任人和备注等字段。在前期规划阶段，由于项目计划和模块负责人已经提前确认，各小组都能专注于自己的工作，一切井然有序。
组织权限收集表 在我们的项目中，权限涉及页面权限、按钮权限和数据权。为了确保每个角色具备适当的权限，我们采取了一种综合方法。接着，产品经理根据业务需求预设各个角色的权限。最后，核心业务团队会对这些预设的权限进行审核确认，以确保其准确性和适用性。通过这种方式，我们可以更全面地了解各个角色的职责和权限，为后续的上线配置提供支持。同时，这也确保了系统的安全性、稳定性和可靠性，为用户提供更好的使用体验。在组织角色收集过程中，主要分为两个重要环节：用户信息的收集和角色定义。其中，用户信息的收集相对简单，而角色定义则更为复杂。
PRD文档参考 在我们当前的项目中，我们采取了模块化的划分方式。因此，PRD（产品需求文档）也是按照各个模块进行组织和编辑的。虽然各个模块在功能细节上可能有所差异，但整体风格还是保持了一致性。这种风格使得文档结构清晰，易于理解和使用，从而提高了团队协作的效率。说明：在非功能性需求中，我们有单独设计一套系统配置功能，所以在非系统性需求中只需定义即可；
业务中台-UAT测试用例示例 而流程性测试则需要按照业务流程来编写，例如从创建订单到审核订单，再到推送WMS、WMS发货回传，最后变更单据状态等整个业务流程的测试。在实际的测试过程中，我们会根据实际情况选择适合的测试方式，结合功能性测试和流程性测试，对业务中台进行全面的测试，确保其稳定性和可靠性。功能性测试主要是对某个功能进行详细的测试，例如新增、修改、删除、导出、导入和显示等功能是否正常。对于UAT测试用例，我们理解应该存在两种不同的编写方式，一种是功能性测试，另一种是流程性测试。
【业务中台-上线总结篇】 项目总结会是整个项目的复盘环节，也是评估项目成果的重要会议。项目验收时则需签订验收报告。1、期初库存：上线当天需要进行初始化库存操作，包括处理历史差异库存、库存合并、整理和导入。在上一章我们提到有制定详细规划的切换计划，在实际切换过程中，我们也是严格按照既定时间节点进行。2、在上线后的首个星期内，产品团队需每天进行业务复盘，确保当天确认的需求事项能在次日提交给研发团队。3、当遇到用户需求无法满足的情况时，应避免过多的争论，迅速将问题上报处理。上线总结篇：从项目切换、问题处理、项目总结、项目验收环节展开。
业务中台-上线切换计划篇 业务中台上线，是一项涉及众多复杂环节的重大任务。以我们当前的项目为例，新增接口多达50多个，原系统接口需调整30多个，同时还需要处理流程、期初数据、数据迁移、人员、权限等各个方面。结合我在项目中的实际经验，本文将重点探讨如何制定上线切换计划、其包含的内容以及上线启动会的核心要点。
业务中台-UAT篇（业务测试） UAT阶段，是产品验收确认后的关键环节。上一节，我们谈到了产品经理对研发内容的验收，验收完成后，便正式进入UAT阶段。这一阶段是项目上线前的核心环节，业务部门的意见对于项目能否成功上线具有决定性的影响。
业务中台-研发篇 在业务中台项目中，我们采取了领域划分的策略，成立了商品、订单、库存、客户和促销等小组。二是如果存在新的需求，产品经理不能直接要求研发团队调整，而应与研发经理共同评审，以防止项目出现偏差。第四点，对于导出和导入功能，我们要求导入文件的文件名必须与原文件名一致，导出的字段如果是数字类型，则导出的内容必须是数字而不是文本，同时导入/导出的内容需要符合标准控件的要求。项目研发质量是交付物的保障。
业务中台-项目规划篇 因此，我们的项目目标是重构企业销售链路流程，实现业务财务闭环，确保合法性和合规性。在规划阶段，我们没有直接与具体操作人员沟通，而是与各部门总监级别的人员进行了交流和确认。当然，某些具体流程可能需要与关键用户进一步探讨，但所有决策都经过了部门负责人的确认，为后续实施工作奠定了坚实的基础。在上一章中，我们谈到了一个项目从规划到最终上线的过程，历时9个月，其中2个月用于规划。2、基于未来的业务需求，我们规划了业务中台所需的功能模块，涵盖了系统标准功能、档案、商品、库存、客户、订单、财务、预测、报表等各个部分。
【业务中台-前言】 企业是做零售相关业务，涉及到第三方系统有OMS、WMS、TMS、ERP、COA等应用系统，项目从规划到最终上线历时9个月，其中2个月用于规划，2个月用于产品设计（穿插研发框架的搭建），4个月用于产品研发和内部测试，最后1个月进行用户测试。从2018年开始接触业务中台，截止目前，我已经参与了四五个业务中台项目建设，并在项目中担任过不同的岗位职责，如项目经理、产品经理和第三方对接负责人等。最近几年，我主要在甲方公司工作，并在实施业务中台时，既有乙方实施的项目，也有甲方自研的项目。
关注
