|
看完这个案例，我的第一反应是：这又是一个准备不充分的项目。和许多企业在信息化过程中走过的弯路一样，A企业的选型过程显得仓促而不完善，看起来这样可以节约一些时间，但具体实施的情况表明：该做的准备工作，一个都不能少。 项目管理者联盟
A企业的案例可以引申两个话题，首先是充分的准备工作应该是什么样的？其次是在当前的现状下，A企业如何顺利地完成项目？ 项目管理者联盟
需求与解决方案不匹配
a企业在实施过程中所出现的问题集中体现在a企业的需求和b企业的解决方案不匹配，具体体现在以下方面： training.mypm.net
◆ 新系统和a企业的遗留系统在集成方面的不匹配。
◆ CAPP和a企业的需求出现了较大的不匹配。 项目管理者联盟
因此，如何使项目的推进很顺利，从根本上取决于a企业所能接受的需求变化范围。需求的不匹配是几个基本的事实，很难通过什么行动来回避。因此，说到底，项目能否顺利推进取决于a企业自身的态度。 项目管理者联盟
重新调研和规划转自项目管理者联盟
a企业应该补做的一个工作就是重新做一次细致的需求调研和规划工作，通过这个工作可以明确a企业期望通过PDM、CAPP等系统的实施究竟解决什么问题。这个工作应该是深入而细致的，基本上能把系统实施的底线搞清楚，同时做到不遗漏。 项目管理者联盟
通过这样的分析，可以摸清楚a企业对系统的需求究竟是什么。比如，落在上述矩阵右上角的部分，代表对a企业而言非常重要的那些系统功能与需求，代表着a企业对新系统的基本期望。一般来说，企业往往希望这些功能能够得到不折不扣的实现。在选型过程中，在这些方面的匹配程度往往会作为最重要的评价标准。
具体到a企业，因为选型已经在一定程度上成为定局，那么，在看到b公司软件功能有一定差距的现实情况下，a企业应该首先寻找上述矩阵中右上角的那些功能，尽量要求b公司在这些方面，通过二次开发等手段尽量实现需求。如果实在差得太多，中止与b企业的合作是一个明智的选择。 项目管理者联盟
a企业只是将风险延迟service.mypm.net
尽管在案例中，我们可以看到，到目前为止，a企业与b企业在该项目中似乎还很和谐，但表面上的和谐并不意味着合作的顺利，这只是将风险延迟而已。既然是风险，迟早是要爆发的，只不过，破坏程度会更大而已。项目管理领域有一个经典的谚语：不要试图拯救一个正在下沉的船，说的就是这个意思，如果不能在现有的框架内解决问题，那就跳出这个框架，尽管这样可能意味着a企业要遭受一定的波折。 service.mypm.net
有意思的是，就这个案例，我们可以进一步追问一下，a企业为什么会在选型过程中出现一定问题的呢？我觉得，仅仅用准备不充分是不能回答这个问题的。 项目管理论坛
案例似乎在告诉我们，a企业信息化的相关人员（高层领导、业务人员、IT人员）在沟通上并不充分。在信息化的不同阶段，每一种角色应该做什么工作似乎并不清楚，也就是说出现案例中的这种现象：a企业没有说了算的领导在场，干活的技术人员在提出质疑后，听取了软件方所谓的“合同里只要求标准版，而标准版里确实不提供这两个模块”的解释后也就作罢。最后只能感叹，“那么多钱原来大部分还是给设计部门上CAD和PDM，工艺上CAPP，成为两个系统……” 项目管理者联盟
我觉得，a企业的相关负责人应该仔细思考这样一个问题，如何建立一个稳定的架构来推进信息化工作。而案例中的这个现象也似乎在告诉我们后续的结局：技术人员会发现越来越多的不匹配和不和谐的现象，直到项目出现重大危机时，领导才会出面，然而，已经失去解决问题的最佳时机。
service.mypm.net 项目管理者联盟
|
