关于ERP项目如何才能算是成功的条件和标准，一直是ITer们最关心的话题。国内的IT界流行这样一句话“中国的信息化项目没有失败的，因为谁都不敢轻言和直言失败。”其实信息化项目想成功因素很多，甚至不是一本书能写完的。这么大的话题为什么还要再写呢?在个人能力有限的情况下如何帮助项目一步一步走向成功是非常关键的。前一篇“戏说”的现象在很多企业中都出现了，比较具有代表性。
前级提要：小M的悲催经历
小M加入某企业不久，负责ERP系统的维护，但经过短时间的“补课”发现项目虽然项目尾声，但是问题却不少。面对小M提出的项目问题，可能是由于工作压力等问题企业中ERP项目负责人并没有提供足够的支持和指导，并让ERP项目的实施方项目负责人分配小M的工作，小M只好迷茫的接受了工作，开始了自己迷茫之路。
(如果没看过小M的故事请：猛戳这里)
这样的ERP项目，在时间上貌似没有拖延很久，在功能上貌似没有人提出异议，可能性能也只是乙方公司一纸报告了事。但不管怎么说，乙方工作人员勤勤恳恳的工作，让甲方负责系统运维的人员看上去还是心理稍微平衡一些的。
但这样的项目算是成功的么?在前一篇文章中，我们分析了项目实施过程中，甲乙双方扮演着什么样的角色?什么人应该站在怎样的立场?这一篇我们讨论什么呢?业务需求，管理需求，这些都应该由谁来确定，看似很大的话题如何化解呢?也许看了本篇的内容可能会有所启发。
作为新人需要摆脱作为刚刚加入企业的新人常常暴露出来的通病：要么初生牛犊不怕虎的乱撞冒进，要么自保式的消极接受。但是这里不是职业发展的讨论，而是要讨论如何才能让项目顺利完成并投产，如何才能让未来的ERP运维工作能够顺利开展。所以作为小M可以做的有很多。
1. 摆清位置，借力发力
因为组织结构的不同，不可能所有公司的项目配备都非常清晰。遇到小M的情况那么就按照公司给你的定位执行，要么就要自行判断，项目这种事情，自保的话少做一点，学东西的话多做一点。虽说是看个人意愿驱动，但是仍然有些问题需要注意。
辨别项目的核心干系人很重要，在小M的这场戏中现在扮演的角色有足够的能力直接“叫板”历史问题吗?显然是不行的，一来作为新人，话语权并不高;二来项目管理的过程中ERP运维人员的较色，并不占主动和主导位置，所以要找到能够起到主导项目的关键人，阐明观点并做好利弊的分析。根据项目管理权力象限的划分，像小M这样的角色的建议很难得到最直接的采纳。所以甲方自己的项目负责人如果对项目不足够了解，那么一定找到一个或一些权力适中、话语权足够的人员阐明问题严重性。
2. 看清问题，让业务说话。
作为新人，ERP项目的问题一定要从业务入手才有说服力，何况项目问题往往很难一眼看清，而且业务并不是几天就能熟悉的，所以与其直接关注项目的历史问题不如快速熟悉业务，让业务印证自己的观点。当然这个熟悉业务的过程可长可短，很难说这个过程的最初的看法会不会随着时间的推移而发生转变。
但作为ERP项目运维人员必须要做的一点就是对于ERP项目的交付物的梳理。
3. 理清交付物，为以后铺路。
信息系统的交付物无外乎是软件产品本身，另外就是项目执行过程中的过程资产和知识的沉淀。对于系统运维来说关注软件本身，不如更多的经历去关注过程资产和知识的沉淀，毕竟乙方公司早晚有一天要撤出，系统运维的重担要落在甲方的运维人员身上。
·关注操作说明，虽然乙方会有软件产品的操作说明，但是能否与当前版本的一致、根据甲方企业的定制开发是否有足够的功能和操作说明是非常关键的，这直接决定了未来运维工作和团队的效率。当然，仅靠乙方的交付物是很难完成整个系统的运维工作的，需要有自己对系统的认识和理解。即使不能模拟所有流程，也势必要在上线之前摸清主要业务流程的操作，以便清楚的知道上线后业务与系统的差异并加以应对。
·关注验证结果，系统上线以前肯定会产生很多验收报告，不要小看这些验收报告，如果不是亲身经历其中的一些过程，真的很难相信这些报告因此当甲方能力不足以参与验收的时候，这些文档理解一定要清楚，必要的时候可以请乙方的项目负责人出面解释和演示验证结果的过程。
·关注用户体验，甲方信息系统上线后决策者往往不是最终使用者。因为不同的业务人员对系统的要求和关注点不同，这就需要运维人员做好准备，要根据不同的角度逐一处理，乙方的交付物已然“标准化作业”了，这就要求系统的运维人员提高自己的水平深入的理解系统和用户需求，为最终用户排忧解难需要从用户出发。
其实，作为ERP项目的项目经理首先分析双方企业的需要和期望，合理并且经过充分沟通后，书面签字认可的项目的目标是信息系统成功的开始。在项目实施过程中，设置关键检验点、细节工作成果要达到质量目标是过程控制和质量控制的过程，对于目前普遍的情况而言，在时间、成本在预期的权衡中，让项目实施范围内可控已经难能可贵了。但是这只是企业信息化万里长征的一小步，之后长期的维护、支持工作涉及的范围更广更复杂。至于很多人讨论的成功模式，那么项目成功最终的成功模式是什么?我要说成功没标准，千万莫参照!
前级提要：小M的悲催经历
小M加入某企业不久，负责ERP系统的维护，但经过短时间的“补课”发现项目虽然项目尾声，但是问题却不少。面对小M提出的项目问题，可能是由于工作压力等问题企业中ERP项目负责人并没有提供足够的支持和指导，并让ERP项目的实施方项目负责人分配小M的工作，小M只好迷茫的接受了工作，开始了自己迷茫之路。
(如果没看过小M的故事请：猛戳这里)
这样的ERP项目，在时间上貌似没有拖延很久，在功能上貌似没有人提出异议，可能性能也只是乙方公司一纸报告了事。但不管怎么说，乙方工作人员勤勤恳恳的工作，让甲方负责系统运维的人员看上去还是心理稍微平衡一些的。
但这样的项目算是成功的么?在前一篇文章中，我们分析了项目实施过程中，甲乙双方扮演着什么样的角色?什么人应该站在怎样的立场?这一篇我们讨论什么呢?业务需求，管理需求，这些都应该由谁来确定，看似很大的话题如何化解呢?也许看了本篇的内容可能会有所启发。
作为新人需要摆脱作为刚刚加入企业的新人常常暴露出来的通病：要么初生牛犊不怕虎的乱撞冒进，要么自保式的消极接受。但是这里不是职业发展的讨论，而是要讨论如何才能让项目顺利完成并投产，如何才能让未来的ERP运维工作能够顺利开展。所以作为小M可以做的有很多。
1. 摆清位置，借力发力
因为组织结构的不同，不可能所有公司的项目配备都非常清晰。遇到小M的情况那么就按照公司给你的定位执行，要么就要自行判断，项目这种事情，自保的话少做一点，学东西的话多做一点。虽说是看个人意愿驱动，但是仍然有些问题需要注意。
辨别项目的核心干系人很重要，在小M的这场戏中现在扮演的角色有足够的能力直接“叫板”历史问题吗?显然是不行的，一来作为新人，话语权并不高;二来项目管理的过程中ERP运维人员的较色，并不占主动和主导位置，所以要找到能够起到主导项目的关键人，阐明观点并做好利弊的分析。根据项目管理权力象限的划分，像小M这样的角色的建议很难得到最直接的采纳。所以甲方自己的项目负责人如果对项目不足够了解，那么一定找到一个或一些权力适中、话语权足够的人员阐明问题严重性。
2. 看清问题，让业务说话。
作为新人，ERP项目的问题一定要从业务入手才有说服力，何况项目问题往往很难一眼看清，而且业务并不是几天就能熟悉的，所以与其直接关注项目的历史问题不如快速熟悉业务，让业务印证自己的观点。当然这个熟悉业务的过程可长可短，很难说这个过程的最初的看法会不会随着时间的推移而发生转变。
但作为ERP项目运维人员必须要做的一点就是对于ERP项目的交付物的梳理。
3. 理清交付物，为以后铺路。
信息系统的交付物无外乎是软件产品本身，另外就是项目执行过程中的过程资产和知识的沉淀。对于系统运维来说关注软件本身，不如更多的经历去关注过程资产和知识的沉淀，毕竟乙方公司早晚有一天要撤出，系统运维的重担要落在甲方的运维人员身上。
·关注操作说明，虽然乙方会有软件产品的操作说明，但是能否与当前版本的一致、根据甲方企业的定制开发是否有足够的功能和操作说明是非常关键的，这直接决定了未来运维工作和团队的效率。当然，仅靠乙方的交付物是很难完成整个系统的运维工作的，需要有自己对系统的认识和理解。即使不能模拟所有流程，也势必要在上线之前摸清主要业务流程的操作，以便清楚的知道上线后业务与系统的差异并加以应对。
·关注验证结果，系统上线以前肯定会产生很多验收报告，不要小看这些验收报告，如果不是亲身经历其中的一些过程，真的很难相信这些报告因此当甲方能力不足以参与验收的时候，这些文档理解一定要清楚，必要的时候可以请乙方的项目负责人出面解释和演示验证结果的过程。
·关注用户体验，甲方信息系统上线后决策者往往不是最终使用者。因为不同的业务人员对系统的要求和关注点不同，这就需要运维人员做好准备，要根据不同的角度逐一处理，乙方的交付物已然“标准化作业”了，这就要求系统的运维人员提高自己的水平深入的理解系统和用户需求，为最终用户排忧解难需要从用户出发。
其实，作为ERP项目的项目经理首先分析双方企业的需要和期望，合理并且经过充分沟通后，书面签字认可的项目的目标是信息系统成功的开始。在项目实施过程中，设置关键检验点、细节工作成果要达到质量目标是过程控制和质量控制的过程，对于目前普遍的情况而言，在时间、成本在预期的权衡中，让项目实施范围内可控已经难能可贵了。但是这只是企业信息化万里长征的一小步，之后长期的维护、支持工作涉及的范围更广更复杂。至于很多人讨论的成功模式，那么项目成功最终的成功模式是什么?我要说成功没标准，千万莫参照!
扫一扫
1355
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
