千万级项目的正确打开方式

小编没见过什么大世面，从业至今只参加过一次千万级的项目，就是某大型商业银行渠道整合（包含数据整合和业务创新）的项目，知道的朋友不要点破哦，至于为啥有这个项目，都是大家所熟知的：

1、部门多、业务多、对客渠道多、功能分散、数据存储分散

2、同一功能多渠道重复开发、开发周期长、成本高、客户体验差

当时小编作为第三方的身份进入项目组（既不是甲方，也不是咨询方或开发者），有幸参与了项目前期和需求阶段，故分享的内容有限却是不掺假的

第一阶段、启动阶段

开启动会。

该项目的组织架构很完善，每个渠道的业务专家和技术骨干都参与到了项目中，得力于发起项目的是渠道管理的业务部门及技术部门，这种合作方式迄今为止小编还没见其他所谓的国企这么做过。由于组织架构庞大，自然得到了行领导的高度重视，资源和跨部门配合啥的不用说，妥妥滴搞定。另外这样合作的好处是避免了“屁股决定脑袋”的情况，因为后续其他公司参照模仿的时候出现过，结果都不尽人意。

制定计划。

没错，是自己制定的实施计划，有序滴分批次释放。自信源于实力，它知道怎么去调研同业和调动分行的力量，知道业务的痛点在哪里，并分析的井井有条且能给出具体的解决方案。

梳理现状。

在咨询公司入场前，行方用3个月的时间按照统一的模版完成了近20个系统的业务和技术现状及痛点的梳理。现状和痛点梳理这项工作为整个项目打下了坚实的基础，也是当时项目重要的产出。（多说一句，它在用人方面都很有章法，知道谁能给梳理出最贴近事实的现状。）

制定项目管理办法。

这一点不多赘述，做项目的人儿都知道它的重要性。

第二阶段、需求阶段

规划

做银行业务的都比较谨慎而且知道怎么拿捏分寸，故而一开始定的基调是“步子不要迈得太大”，量力而行。什么客户价值、营销活动之类的都放在了最后，一开始只做打基础的数据整合和核心业务优化。  银行的数据比其他行业的都规整、标准还统一；它一开始就有以客户为维度建立的数据库表，每个客户什么时间开户的、有哪几个账号、开了什么业务、通过什么渠道交易的的通通有。这里的整合就像收拾屋子一样，把物品分门别类的摆放，比如书架、花架、衣架，衣架（产品中心）里还可以细分为长袖、短袖、裤子、裙子等等；能把这些串在一起的就是房子的各位主人啦（客户中心），当然还有其他好几个中心，都是围绕客户展开的（支付、额度啊）。核心业务就是最基础的最常用的支付交易（此处不多赘述，如有问题可私信小编）

磨合期

前面讲到做足了准备工作，所以咨询公司入场后，给了1个月的时间让他们看各种现成的文档去熟悉现状，并在这一个月的时间充分和各渠道的业务、开发商磨合（各种微信群、联系方式也是在此前就准备好的）

情景梳理

依据现状文档，咨询方给做了一个情景矩阵，倒不如说做了个报表表头，让业务部门去填内容，大体是你这个业务，针对什么客户，现在在哪个渠道应用，将来部署在哪个渠道上，希望做流程模型、数据模型还是什么模型（原谅小编当年年少无知，这个模型和你想的模型不是一个），这也是为渠道整合做铺垫。

建立产品清单

基于情景那个产出，咨询方给出了个术语定义清单，美其名曰“分组”；在此之前没有产品包或者打包收费的概念，都是按不同产品单个收费的。为了实现产品组合，先梳理了可以对外卖的产品清单（此处不多赘述，如有问题可私信小编）

包装

以支付业务流程为基准，建立统一的UI设计及交互设计标准和风格，后续所有业务都参考这一个标准。

最后

如果你想知道这个项目最后干了啥，干成什么样子，请给小编打赏点个赞或者留个言吧，一般人我不告诉ta~

你想知道小编为啥知道的这么详细，因为小编的客户就是（带小编入行，并带教了小编5年）做的多，管的多，操心的事儿多的业务中台的负责人。。。

#篇外# 如果大家想进一步了解这个项目或者银行中台相关内容，请尽情点赞，超过20个小编再下一篇文章总结，