• Contact Us
  • Japanese

亚洲变化无常?IT报告 in 中国

为您带来如何在中国进行系统实施的启示,以及本公司所举办的活动安排等信息。

第1回 「浅谈ERP系统实施常见问题」

2015/04/21

  大家好!我是B-EN-G上海的周引弟。

  非常荣幸能作为中文博客第一棒,在这儿留下鄙人的一些爪印。那么这第一棒我能为大家贡献些什么呢,左想右想这第一回目就接接地气,与大家聊一聊在以往ERP系统的项目实施过程中,我自己的所感所想吧。如果与曾有类似经验的人能产生共鸣,甚至可以为即将实施系统的用户们带来启发或警示,将不胜荣幸。


  因为篇幅的关系,今天先挑两件我认为比较常见的事儿说说吧。

1. 究竟是谁想上系统,简而言之上了这个系统之后想实现的效果是什么?

  →明确"目的"并清晰主要必须需求,这一点首当其冲。

2. 系统实施,只是客户项目体制内人员的事儿吗?

  →大错特错。


  首先,关于系统实施的"目的",我发现有时候不仅是客户直接参与项目的团队成员,甚至连客户方的最终负责人都会渐渐迷失方向。我通常把这种情况理解为"需求膨胀"。为什么会有膨胀,说得言简意赅一点,就是需求分析阶段各个部门站在自己的立场恨不得把所有的功能都统统在一个系统中实现。其实,从客观角度来看,"膨胀"这个过程是很正向且很有趣的,并意味着客户团队带着很强的积极性在参与,这本身是一件好事情。


  现在重点来了,"膨胀"发生时的处理方式,才是真正体现项目经理价值的考量。

a)任由继续膨胀,直至项目不受控,一拖再拖项目何时完工遥遥无期。

  →导致客户项目总实施费用大大超出预期,用户无法顺利体验系统整体运用效果。


b)死守完工计划,膨胀归膨胀,项目推进归推进,两条平行线,虽然有交集但故意忽略。

  →导致客户新系统运用满意度低下,渐渐系统变成无人问津的鸡肋。


c)所有膨胀需求都一股脑儿认认真真记录下来,通过业务课题与系统课题的区分、短期·长期对策区分、需求内容合理收缩等等方式有效分析,在确保原项目正常推进的同时兼顾帮助客户进行中长期规划,达到整体良好运用效果。

  →非常显而易见,C选项是最负责最有价值体现的,但是C却要付出多倍努力,特别是"沟通"能力直接成为衡量这支IT实施团队是否优秀的砝码。


  那么接下来我们来聊聊"系统实施,真的全权丢给公司相关部门成员再加一名Leader就成了吗?"我的答案是:No!必须不是!我举两个例子吧,一个是在中国的外资子公司,一个是中国的本土企业。


  先来说说中国外资子公司的类型,经常遇到的情况是以总部为首,全球范围内统一对含物品代码在内的一系列编码体系的调整更新。由于编码往往是系统中的主键信息,也是构建业务数据的最基础信息,明确之后就需要用户尽快着手准备整理业务基础数据,并根据实施日程安排准确快速地完成系统中的数据登录作业。一旦用户开始着手整理业务数据,或者开始系统数据录入作业,再想要进行编码体系的调整,就会导致用户的努力付之东流,需要重新再来。最直接的效果就是影响项目日程,变成毫无意义的拖延以及实施费用增加。

  可能有人会说,既然这么重要一开始强调规避不就行了吗?是的,我相信绝大多数称职的项目经理都一定会反复向用户强调这一点,但"计划不如变化"同样很适用于国外总部。通过事前提醒·事中确认·事后跟进,当发生项目计划之外的突然变化时,这个时候如何与客户加强沟通;如何帮助客户不影响项目日程推进实施;结合系统特点与用户业务情况,如何向客户提出更好的灵活方案,则要看系统实施团队的随机应变能力了。


  然后再来说说中国本土企业的类型,绝大多数情况是一开始上层领导充分授权,但项目中后期领导突然某一天感兴趣或者有点空了,偶尔参与一下进度讨论。这个时候矛盾来了。领导突然大发雷霆严重不满意:花了这么多钱怎么只做了这么点儿事情啊?这个功能为什么这么使用啊?这个业务流程怎么没有更好的改善啊?等等等等。为什么,因为领导没能一开始就参与进来,如果客户内部的上传下达再出现任何问题,那么这个项目极有可能中途夭折,前期的所有方案全部推翻重新来过,甚至直接导致项目以失败告终。

  作为任何项目经理看到这一幕都是非常痛心疾首的,因此我相信绝大多数负责任的项目经理都会很开心公司高层领导从一开始就能抽身到项目中共同探讨。但是现实生活中企业高层因为决策工作繁多,往往很难参与或跟进,那么这个时候优秀的项目经理与IT实施团队,其所付出的沟通努力与言简意赅的不定时报告水平,就显得至关重要。


  以上罗哩罗嗦讲了二条,没想到文字已超出篇幅太多,今天先聊到这里吧。如果各位有兴趣继续听我自言自语,下一次敬请期待"产品选型"方面的话题。谢谢!~5月25日咱们博客接着聊!