互联网公司如何管理实施项目.docx

互联网公司如何管理实施项目 由于中后台系统开发成本高，但是通用性较强，因此对于大部分企业来说，采购成熟商业套件进行实施，从成本和时间上都更为合算。即便是某些一线互联网企业，他们早期的后台系统也采用了Oracle这样的商业化套件。 但是，相对于自研，外采系统往往潜藏着更大的风险。特别是互联网企业，由于业务调整迅速，组织集权度低，用户体验要求高，外采系统的风险远高于传统企业。因此，互联网公司外采项目的实施管理，是一个颇有挑战性的课题。 01 外采项目的风险 外采项目的风险主要体现在两个方面。一是自研系统往往是小步快跑，从核心功能出发，再不断进行迭代。而外采系统则追求一步到位，需要在相对短的周期，一次性形成相对完整的解决方案，系统交付的范围往往较大。另一方面，由于外部系统和外部团队等不可控因素，也使得外采系统的实施雪上加霜。 1. 旧城改造不容易 为了降低交付成本，商业化软件必须追求产品的标准化。在信息化时代，SAP、Oracle都是用一套产品实现多个行业的解决方案，这除了导致产品复杂度的大大增加，用户体验也受到较大影响。 到了数字化时代，SaaS厂家往往专注于少数行业，这使得行业贴合度和用户体验有了大幅度提高，但是软件的二次开发能力也受到了很大限制，导致用户的个性化诉求无法得到有效满足。 互联网公司自研的产品在设计之初就是为企业贴身定制的，其后又不断进行迭代，其业务切合度和用户体验都是商业化软件所难以比拟的。因此，商业化软件的二次开发难以避免。但是，由于商业化软件的固有架构和封闭性，使得其改造难度和成本都远大于自研系统。 曾经有一家国外企业想要优化实施系统的用户体验，最后发现必须对所有界面都进行重新开发，可以想象这样的工作量有多么巨大。 2. 可怕的60分原则 实施公司的目标是盈利。这就意味着，在合同金额确定的前提下，如何控制成本和风险是实施公司的管理重点。 实施项目是一个“需求逐步明晰化”的过程，因此也无法通过合同条款明确所有细节的要求，这就导致交付团队所认为“应交付的内容”，往往小于甲方所认为“应交付的内容”。 同时，反正只要项目能够交付，合同金额都是确定的，这也导致交付团队“多一事不如少一事”，这就是所谓的“60分原则”。 60分原则的危害性很大，很容易导致风险被遗留到项目后期。经历过实施项目的小伙伴可能都有这样的经历：一个实施方自己很容易发现的问题，但是一直拖到上线前用户抱怨，实施方都没有主动提出来。但是，这是实施类项目所固有的风险，我们只能选择去面对，想办法去规避。 3. 不可控的团队 外采项目难度大风险多，对团队的要求也是很高的。除了个人能力，团队协作和紧张的氛围也是必不可少的。 由于实施团队属于外部团队，我们并不具备人事权和赏罚权，也就意味着没有办法按照我们的要求去管理团队。 曾经在一个项目中，实施团队的一个核心骨干因为各种个人理由不断请假。后来我才得知，一部分请假其实是支援其他项目。毫无疑问，这种行为都是实施公司授意的，但是作为甲方，也很难抓住他们的把柄。 4. 风险转移漏斗 从合同签署的那一刻起，风险就开始像漏斗一样，从实施团队的一端转移到甲方项目组团队。 因为一旦项目启动，甲方项目组团队就有责任推动项目成功上线。即便项目后期出现重大风险，为了项目成功，甲方项目组团队也只能选择去承担和解决。这就是所谓的风险转移漏斗。 风险转移漏斗可能导致实施团队存在侥幸心理，拖延问题的发现和解决，最终影响项目的交付质量。 5. 跨部门协作的陷阱 大型实施项目往往需要多个部门的协作。 在传统企业，会从各部门抽调核心骨干脱产投入项目，这在很大程度上解决了跨部门协作的问题。 在互联网公司，各个部门都有苛刻的业务KPI指标，每个核心骨干的工作量都是饱和的，这就决定了让他们脱产几乎是不可能的。另外，由于项目工作会占用较多资源，影响到他们自身KPI的达成，也增加了跨部门协作的难度。 在曾经的一个数据中台项目中，需要各业务系统配合改造并接入数据中台。我们投入了大量时间进行协调，最后请CTO帮助每周review各个团队的改造进度，才保证了项目的按时推进。 02 实施项目的管理重点 实施项目的诸多风险，决定了我们需要在各个阶段重点部署，并从制度和机制上防范风险。 1. 项目立项 1.1 项目价值与风险明确 实施项目最大的风险，来自于高层不切实际的期望。 由于外部公司专业售前的早期介入，很容易将高层对项目的期望值抬高，而一旦项目达不到预期，最终受伤害的可能是内部团队。比如，高层可能很期待项目的管理咨询效果，同时默认系统的用户体验是互联网级别的。但实际上优秀又懂特定行业的管理咨询顾问其实是非常稀缺的。而实施项目是旧城改造，用户体验很难在短期得到根本性改善。 在这个阶段，建议通过安排投标方讲解具体咨询案例、演示系统操作等环节，帮助高层获取更多有价值的信