作者：陆晓松
接下来要说的这个项目，是我至今做过的项目时间最长，系统最为复杂，涉及部门最多的一个项目。
通过这个项目，提升了自己做大型项目的能力，提升了和不同部门同事沟通的能力，也收获了很多的友谊。
虽然过去了将近3年半的时间，但是当初做项目的点滴还是历历在目，我想这样的项目一生可能也就这样一次，我很幸运能够参与其中。
抒发完情感，我将开始做项目回顾和复盘。
首先是项目背景
这是一家运动服饰企业，之前是一家合资公司，因为企业性质变更，要成为一家独立的子公司。
因此，所有的业务流程，软硬件系统等都要做更新。
这里的业务流程主要包括供应链，零售（包括电商），批发以及财务，而我主要负责供应链和企业资源计划(ERP)系统的升级。
这里的所说的供应链，指的是端到端的供应链，就是我们通常所说的——“进” “销” “存” 或者 “产” “供” “销” ，覆盖了从工厂端的生产制造，到仓储运输，到上游的需求计划，到下游的库存管控。
记得我是第一位到岗的项目组成员，领导给了我一个重要的任务--分析现有的业务流程，并且做成流程图分享给大家。
流程图不仅仅包括供应链流程，还包括公司主要业务部门（包括批发，零售，电商等）的流程图。
做项目之前，我通常有个习惯——确定项目的边界，或者说项目的范围。应用到流程图这件事情上来说，就是确定哪些关键流程和系统需要被包含进去。
比较幸运的是，手头上有一份粗略的草图，虽然不是最新的，上面也列出了一个大致的框架，大部分内容需要修改或者增加，我所要做的就是查缺补漏，及时更新。
我仔细研究了草图，确定了几个关键点：
1) 流程图按照矩阵图Matrix的形式展现，横向的是业务部门，纵向的是系统及接口；
2) 核心系统是企业的ERP系统，所有的业务接口都以此为核心，互相串联起来；
3) 电商系统和物流系统因为相对特殊和独立，需要单独绘制详细流程图；
大方向确定了，接下来就是找到各个业务部门的负责人，去详细了解他们的业务流程和系统。
这不是一件容易的事情，首先要找到对的人，这个人必须对系统和流程都了解，其次要在尽可能短的时间内完成对所有业务部门的“访谈”。
在这一点上，领导给了我很多的帮助，一方面和我大致讲解了公司目前的系统和流程，一方面告诉了我每个部门的负责人，并且提前和他们沟通，这对我接下来的工作开展，起到了至关重要的作用。
根据领导给到的信息，我大致确立了如下几个需要“访谈”的核心部门：
计划部门，合规部门，零售部门，批发部门，电商部门，物流部门，财务部门，第三方物流公司
并且制定了每个部门的访谈时间，这个其实还蛮有讲究，不能随意的决定。
我的原则是先从自己所在的部门开始，因为相对比较熟悉，时间上也比较好把控。
然后再和其他部门的负责人提前约好时间，邮件确认的同时及时发送会议邀请，会议的时间尽量避开“高峰”时段，安排在下午比较靠后的时间。
安排好了会议时间以后，针对不同部门，我首先根据之前的草图做了一下“头脑风暴”，把所有能够想到的问题都一一罗列出来，再依次排出优先级别，把问题集中在10个左右，这些问题围绕公司的核心ERP系统以及每个业务独特的流程展开。
我还“别出心裁”的想到了一点，就是各个部门对现有流程和系统的Pain Point(痛点)，这些都是后续做系统升级和流程改善重要的着力点。
所有前期工作都准备好了以后，开始了“漫长”的“访谈”过程。
就如同之前预料的那样，计划赶不上变化，有时候约好的时间可能因为其他原因而被迫延期，或者访谈对象可能“所托非人”，需要接洽其他的同事进一步了解，前后还是耽误了不少时间。
另外一方面就是自己对于业务流程还不够熟悉，访谈结束以后还需要进一步去和对方澄清和求证。
为了节省宝贵的项目时间，我都是在每次访谈结束后，把业务流程图绘制出来，并且发给业务部门做确认，然后再准备下一个业务部门的访谈。
比较幸运的是，各个业务部门都特别的配合，尽其所能和我讲解业务流程和系统。
就这样，前后差不多1个多月的时间，所有的核心业务部门我都详细的了解了一遍，并且把现有的流程图做了完善。
下面是所有核心部门的流程图——横向的是业务部门，纵向的是系统及接口，当中的黄色椭圆部分就是公司的核心ERP系统：
第一个任务算是完成了，通过和业务部门的访谈，梳理清楚了现有流程和系统，而这一步仅仅算是前期准备工作的一小部分，在此基础上，项目组成员需要详细的去了解自己所在部门的详细的业务流程，系统操作，存在的问题，并且记录在案。
接下来是项目框架和时间线
为了确定项目时间线，前后修改了接近20个版本，整个项目从当年的3月份开始，一直到第二年的5月份上线。项目计划都一直在调整。
调整的原因主要有两个方面——资源和范围。资源主要指的是人力资源，范围指的是项目所涉及的范围。
前面提到项目的背景——公司性质变更导致系统和流程发生变化。其实在中国区开展项目之前，在日本也在做类似的项目。不过由于某些原因，那里的项目进展不顺利，而中国的项目只有在日本完成以后才能进行。
这样就带来一个问题——所有项目资源都放在日本，中国区必须等待。
为了平衡好各个区域之间的项目进度，公司的高层决定暂停日本的项目，把资源都集中到中国区的项目上来，这才有了相对成形的项目计划。我其实一直想知道日本地区的项目进展缓慢的原因，后来一个机缘巧合，从总部同事那里了解到了部分原因。
原来和他们的文化息息相关，其实日本是一个文化高度统一的国家，每一个人都抱着一种合群的想法在社会上生存，不愿给他人制造麻烦，极端的压抑自己的本性，每一次开项目会议的时候，他们通常表现的非常合作和认可，谁也不愿意首先提出自己的意见，特别是当领导在场的情况下，然而会后，却提出很多问题和想法，让人有些措手不及。
特别是当项目进展到关键阶段时。长此以往，项目的进度肯定受影响。
回到本项目，项目大致按照如下步骤进行：
1. 了解并分析现有业务流程和系统(1个月)
2. 学习并归纳未来业务流程和系统(3个月)
3. 比对现有业务流程和未来流程，找到差距(1个月)
4. 对差距进行分析，并按照业务需求排优先级(1个月)
5. 开发解决方案(4个月)
6. 测试解决方案(总共3轮)(6个月)
7. 系统切换(总共3轮)(6个月)
8. 新系统上线
每一步后面我都放了所需要的时间，可以看到学习未来业务流程和系统，开发，测试解决方案，以及系统切换占据了大部分时间，后续章节也会围绕这几个部分做进一步的展开。
最后我想指出这个解决方案所遵循的原则
这个是一切开发的基石和参照：
通过改变现有工作流程，从而顺利对接新的系统和业务流程
Reports
设计报表，从而替代目前的系统或者流程，从而对接新系统和流程
Interfaces
通过修改或者增加系统的接口，对接新系统和流程
Conversions
通过做数据格式或者内容的转换，实现新系统和流程对接
Enhancements
通过做系统或者流程的提升，做到业务流程的无缝衔接
Forms
通过设计或者改良各种表格，实现新系统和流程对接
简而言之就是通过以上5种方法的一种或者几种设计解决方案。
未完，待续……
想了解更多大商品管理的秘诀，请持续关注欧睿数据专栏“深度实践-晓松奇谈。
欧睿数据关键词：
数据智能决策,决策智能化,智慧需求链,oIBP算法,供应链管理,上海欧睿,需求驱动时尚业供应链数据智能服务,FMDS,,欧睿智慧供应链