这是一个失败的选型项目,而且在可遇见的未来公司也不会再经历SAP选型,甚至不会再启动erp项目,个中原因很难一言道尽,在此简要的说说我们的选型过程以及在选型过程中对各种因素的考虑。

一、重启选型工作
七月,在刚刚中止了和上一家ERP公司的合作以后,公司决定重新开始ERP的选型工作。中止合约的同时公司内部也总结了上次失败的原因。
1、顾问的流动太频繁。
对于咨询公司来说咨询顾问的流动是正常的,但顾问与顾问之间的交接必须做的很完善。一个项目启动以后,顾问会依据自己与关键业务部门人员沟通的情况定下大致的业务蓝图和自己实施的思路。在顾问流动的同时这些工作必须仔细沟通,使之连贯。

2、售前的宣传和实际的产品有差异
售前对自己产品的吹捧是正常的,尤其在市场竞争异常激烈的今天。没有的功能可以用模拟的方式讲出来,而已有的功能可以描述的更庞大。这样的现象不是一家咨询公司或者几家咨询公司所特有的,而是整个ERP咨询行业所面临的问题。从业务的角度可以理解他们急于拿下订单的心态,但作为客户来说必须清醒的认识到这个问题。你所想象的未必就是所看到的,你所看到的未必就是真正能用的。

3、咨询公司事前的承诺未必真正能完成。
“用最好的顾问、最大的资源来完成这个项目,即使亏损也在所不惜”这样的承诺很多客户都曾听到过,一旦进入了实施阶段,这样的承诺或许就变成了:最少要保障咨询公司的盈利等等各种“可以理解的原因”。

4、坚定自己的信念不要为咨询公司所引导。
选择ERP的过程中客户自己通常都会做些简单的需求调研,但顾问公司在选型的过程中往往会提出各种“善意”的建议:这个功能你们公司肯定会用到,那个功能能为企业产生巨大的效益。只要你听从了他的意见,实际上你已经放弃了自己原有的立场――他所建议的都是自己有的功能,也是竞争对手所不具备的。在听取了若干家公司的建议以后,企业的需求会变的庞大而不切实际。
在总结了上次选型过程中的经验教训以后,我们总结了以下几条原则。
1、事先清楚的调研,分清什么是必须具备的功能,什么是具有改善效益的功能。在确立自己目标的时候必须与公司未来的业务发展所吻合。
2、合作的是顾问,而不完全是顾问公司。即使是业内知名的ERP咨询公司也会有菜鸟顾问,而咨询公司会将这些菜鸟包装成行业精英。所以我们必须加强对咨询顾问的考核。
3、全面的评估产品,我们所规定的流程必须用实际的操作来印证。允许有部分功能缺陷,但必须事先提出解决的方法和解释能达到的效果。
4、大致的目标定在国外中档ERP产品,但对开发量过大的产品不予考虑。

二、转向SAP
因为预算的原因,一开始所确定的目标是国外的中档ERP产品。并就此展开了比较广泛的调查工作,并约见了一批软件咨询公司。
我们考察了国外知名的SAP的SBO产品、SSA的MAX产品,QAD的MFG/PRO等等,并针对自己的需求逐一比较了各个产品的吻合程度。最终得到的结果却不甚满意。
我们企业是典型的电子离散制造企业,这样的企业原本是ERP最容易解决的。但我们企业也有自身特殊的地方:
1、产品的变形品种比较多。除了BOM的变更以外更需要在工艺上发生调整。这就要求ERP产品在配置BOM上能比较灵活的支持。

2、由于产品的售后服务期最少为1年,对于售出产品的序列号管理、售后服务管理、备品备件管理均有明确的要求。而这部分往往是中档ERP做的不够精细的地方。

3、因公司业务的拓展企业的组织结构可能随时发生变化(而这也为SAP选型的失败埋下了伏笔),这就要求ERP产品能有一定的灵活性,能适应这样的调整。

4、公司的中层管理干部大多有国内外知名企业的工作经历,适应了国外大型企业的管理方法和大型ERP软件的管理思路,对中小ERP产品有颇多不满(这也是导致上次ERP实施失败的直接原因之一)
一个偶然的机会某SAP咨询公司了解到了我公司正在选型,并就此与我公司的副总进行了简单沟通,并提出咨询费用可以压缩到公司能够接受的范围之内――尽管这个费用已经超出了公司预算的一倍,但似乎仍可以为公司所接受。在评选ERP产品的过程中副总也随口讲到了这个事情,并得到了在坐几位经理的一致赞同。就此,SAP R/3纳入了公司选型的视野。
要将预算翻一翻,对于公司来说并没有那么简单。公司的总经理自始至终都没有参加过ERP选型的过程,所以与其沟通的工作一直由副总负责。副总做了深入细致的工作,并在一定程度上取得了进展。老总原则上同意提高预算。
尽管如此,公司的高层仍对公司能否上这样大型的系统抱有疑虑。毕竟这样的投资对于企业来说是非常庞大的。同时牵掣到了公司的各个部门,影响非常大。鉴于上次ERP实施失败的经历,大伙也都心有余悸。

三、货比多家
尽管初步确定了公司选型的方向是SAP、ORACLE,但也并不表示公司就一定会选择这个产品,毕竟我们选择的是质优价廉的产品,符合要求才是最重要的。
提升了公司的预算,我便开始了声势浩大的宣传,又有若干家咨询公司参与到了我们的选型中,包括有微软的产品、SAP的R/3和ORACLE的产品。
从IT的角度来看,我对未来的ERP产品有如下的要求:
1、产品本身必须功能强大。
尽管作为ERP的从业人员,也更欣赏庞大的SAP系统。但这并不表示SAP是我们唯一的选择。考虑到公司未来的业务发展方向,我不希望IT部门因为软件的功能问题而陷入无尽的开发漩涡中。在中国,企业内的IT部门通常是难以受到重视的。与业务部门商谈开发内容的时候往往会陷入,业务部门要求开发什么,就必须开发什么的境地,这样只会增加自己的负担。在可供选择的范围内,我建议选择更完善的系统。

2、ERP产品必须极其稳定。
无论选择的是什么ERP系统,或者与谁进行合作。一旦ERP出现了问题,IT部门将直接受到冲击――没有任何理由,没有任何借口。为此我们必须选择最稳定的ERP系统就不难理解了。

3、从成本的角度,我希望这样的软件是一个软件包,而不是按模块卖。
这是一个很特别的要求。时下的ERP产品大多是按软件包卖,卖给你的是一整套产品,想实施什么是你自己的事情。但也有少量的ERP产品是按模块来卖的。这样对于我们IT来说存在一定的隐患――向你宣传的时候是整个产品,而报价的时候按模块来。在二者之间存在差异所产生的后果只能由IT来承担。而作为IT人员,也很难了解到底缺了些什么。这或许是卖软件的技巧吧,但这让我心里没底。

由于本文的重点是描述我们如何选择SAP的实施方,所以对于其他软件的优劣及顾问、售前、销售队伍的素质这些就不再进行讲解。

来参加这次选型的SAP供应商总共有四家。其中两家是业内知名的SAP顾问公司,另两家则没有什么成功案例。在此我将四家公司定为ABCD。AB为知名企业,CD为不知名的小公司。
由于A公司与我们公司的数位中层干部有相当的渊源,且这家公司在业内也有这非常好的知名度和信誉度,我认为这家公司的希望最大。大约只要价格合适项目大约就是他们的了。但人算不如天算,在我事先已经警告过的前提下,他们还是报出了个天价(对于SAP的项目来说可能是正常报价,但已经远远超出了我公司的承受能力)所以公司都没有兴趣再继续和他们沟通。
B公司则相对柔和的多,报出的价位尽管也很高,超出了公司的承受能力,但多少表现出了非常的合作诚意。
C公司和D公司的情况就不再详细介绍了。就价格而言优势是明显的,但令人担心的是顾问团队的素质。
对于SAP咨询公司的选型,我从以下几个方面进行了考虑:
1、SAP咨询顾问的能力。
由于已经基本确定了软件的目标,软件能做到什么样的程度,自己心里已经有了充分的信心,那么更重要的环节便是如何由顾问来实现他了。而SAP顾问的能力表现在:
A、 对SAP软件本身的熟悉程度,尤其是对后台设置的了解。
B、 对我公司所在行业的了解程度――当然,这部分更强调项目经理的能力。
C、 顾问的沟通理解能力和对需求的分析能力。
D、 顾问自身的项目经历。
2、咨询公司对项目的投入情况
这里的投入首先是顾问资源的投入。一个项目能否成功首先考虑的是顾问公司能投入什么样的顾问。在销售的过程中顾问公司一定会承诺提供最好的顾问――但什么是最好?合同签订了以后是否还会遵守承诺?所以,我们必须对顾问进行一一考核。并在合同中指明:项目中将有哪些顾问参与,角色是什么。
其次是价格问题。由于公司预算的限制,要求咨询公司必须有一定的让步,从合同最终谈定(不是签订)的情况来看,顾问公司也的确到了微利的状况(对于顾问公司成本的计算以后会有专门的说明)。
其三是实施的步骤和范围。对于ERP项目,这也是最容易引起争议的部分。大部分情况下,由于对ERP产品了解不够深入,对ERP项目的实施进程不够了解,甚至对自己的需求都无法有效掌握,很多咨询公司在制定实施步骤的过程中花样百出,甚至骗取咨询费用。为此我们特意研究了SAP软件的实施步骤,参考了其他SAP项目的实施步骤,结合我公司的实际情况与供应商提交的方案进行了比对。

四、考核顾问
既然本次ERP选型看重的是顾问的实力,那么对于顾问的考核也就是一个关键点。为此我们进行了充分的准备。
1、审核咨询顾问的简历。
每个项目咨询公司都会提交相关人员的名单。从以前的选型经历来看,通常咨询公司会有两个小动作:
A、假冒咨询顾问的经历。
说到假冒经历无非就是将咨询顾问实施SAP的经验加长,所做的项目虚增,在项目中起辅助角色的描述成项目经理或者主要负责人。由于大多数客户对SAP咨询行业并不是很了解,所以假冒的经历很难被查出。
B、提交一些不相干人员的名单,尤其是资深顾问的名单。
用美丽的词藻来宣传公司在这个项目上的投入非常简单的。在简历中详尽的描述资深顾问的经历,并将其他顾问一笔带过。而在项目中这些资深顾问却是“顾得上才问两句”还要美其名曰“背后支持”,试问,在不了解企业实际情况的环境下,能提供多少支持?
对此,我详细的考察了几乎所有顾问的实际情况。并要求咨询公司在合同中注明所派实施顾问的名单及角色。
比较知名的ERP咨询公司在咨询费的收取上也是有所不同的,他们会标明,资深顾问或项目经理的价格及人天数。既便是这样,在对资深顾问的认定上也存在一些差异,比如我认为咨询顾问的入行时间应该以进入公司担任咨询顾问开始,而咨询公司会以顾问参加工作为起点。更多的时候,资深顾问只是到公司里来转一圈,了解一下实施进度。
比较特别的是某咨询公司提出的:设立专门文档编写人员的建议。C公司在谈到如何实施这个项目时特别强调,他们会聘请一些新手专门来编写我们实施过程中的各种文档。这点时得到我公司上下一致认同的。通常情况下,咨询顾问不太愿意在编写文档上花费功夫。首先这涉及到一个知识转移的过程,其次这样的工作非常繁琐,可能会严重影响他们的心情。而客户自己也很难安排出富余的人员来编写文档。即使能安排人员,能否编写出合格的项目文档也是个问题。混迹于ERP行业也有一定年月了,我也深知文档对于项目的重要性。
在确定了最后两家咨询公司的时候,我开始了对项目顾问的详细调查。或许是这个圈子太小了的缘故吧,大约也能调查到七八成顾问的资料。从调查的结果来看,只有一名顾问在原有项目中评价不是很高,而这个顾问也正好被派到了其他项目中。
为了考察出顾问的实际能力,为此我专门参加了一次SAP的培训,这个培训是针对SAP顾问的认证考试。通过这次培训所了解到的皮毛知识,我与曾经参与过SAP实施的几位经理共同编写了考察的问卷。
限于篇幅,在这里就不详细介绍问卷的内容了。从考察的结果来看,我们对顾问的实力只能说基本满意。

在考核顾问的过程中,我们也发现这样一个现象:资深的顾问也并不如我们所企盼的那样强,更多的时候只是“唬人”罢了。在这,唬人两个字有着特别的意思。
参与评估的PMC经理也算是SAP软件的资深使用者了。从99年开始他就在两个工厂参与过SAP项目实施,并且亲自主导了某个工厂的SAP项目BPR的工作。作为客户方,他对SAP软件有着非常深入的了解。同时他也很清楚自己的弱点在哪――对SAP的后台配置不熟悉,所以在考核顾问的过程中,我们注重了,SAP前台、后台之间关联性的考察。比如,在某个时候出了什么错,应该如何处理,会牵扯到后台的什么配置,为什么?看似一个很简单的问题,咨询顾问却不见得能够答出来。因为现今顾问公司的顾问大多忙于项目,总是重复着相似的劳动,而很少有时间和经历去深挖SAP设置里的内涵。
同时,客户对顾问的期望也与顾问自身的发展不太吻合。客户是需要顾问了解他们实际运作的管理型人才,而顾问往往向技术型人才发展。顾问能知道这个地方应该这样配置,却不知道为什么要这样配置,对于企业的流程来说会产生什么影响,你这样配置的优点在哪。他只能告诉你:这是他的经验。

六、本次选型的得失
本章节特意跳过了商务谈判部分。因为主要负责商务谈判的(尤其是价格部分)并非本人,而我也没有这个权限在商务上有太多的争取。无论从哪个角度来看,我都非常佩服我们的副总的谈判能力。
关于得,无非也就是些选型谈判的经验。由于能系统的全面的参与选型的每个过程,自己从中获益非浅。
尽管最终谈判的结果非常令人满意:非常优厚的价格、非常合理的顾问团队、比较明确的实施范围及步骤,但作为我个人来说仍存在许多不足之处。
1、对顾问的要求太高。
谈到这个问题必须表明我的一个立场:我是站在企业的角度去考察顾问的,而我们为顾问支付的是每个顾问每天数千元的费用,这相当于我们一个员工一个月的工资。如果我们不实施SAP而将这点钱中的一部分发放给员工,也同样能产生非常良好的效果――而实施SAP的效果还是个未知数。
从前文所写的,我们所期望的是个全能的顾问,但通过考核,很快发现这是不现实的问题。一个拥有5~6年SAP咨询经验的顾问竟然只能评到七十来分,另一位有3~4年咨询经验的SAP顾问也只能评到五十多分,不能不说我们对现阶段的SAP顾问咨询团队要求太高。当然,负责考核的人员素质也同样很高,这或许是评分过低的一个原因之一。
也正是因为这次考核使得我对国内的咨询顾问团队有了一个相对客观的认识。

2、未能有效控制谈判的节奏。
所谓好事多磨,尽管我所能起到的决策作用非常小,但我仍未能赶在老板激情消退之前将价格谈到一个相对合适的位置。可以说自己在谈判的技巧上仍有诸多不足。

3、与高层的沟通不足。
大约这也是技术人员常犯的一个错误:沉浸于技术的漩涡中,与高层缺乏有效沟通。当然,这也与公司的特殊情况有关,由于涉及到公司的某些内幕,在此不便公开。也诚如某个朋友所言如果是老板不配合,那就是不应该立项了。

七、对于SAP咨询顾问发展的建议。
其实自己都不懂SAP,要谈对SAP咨询顾问的建议未免有些过于唐突,在这写点东西不过是从甲方的角度善意的提醒SAP的咨询顾问们。
1、SAP软件博大精深,应系统全面的了解SAP的某一模块。
提到这个话题就不得不说说SAP的PA培训了。在考核顾问之前我特意听过两天课,仅从课堂上学到的那点皮毛自认为就能考翻一批顾问。对,没错。在我看来,很多顾问对SAP软件的认识有局限性,局限在自己曾经做过的项目经验中,而没有突破。就用我常拿来举例的条件技术说吧,我们工厂的特色就是,在卖产品的过程中需要附送些配件,同时也应对产品进行保修。而在SAP中要处理这些问题其实是非常简单的――但很多顾问只是知道要这样设置,却说不清楚为什么要这样设置。
做项目的确很累,一个项目做完了,顾问往往能想到的是如何放松放松,即使是在两个项目间的闲暇时间里也很少有顾问研读过SAP的一些标准教材,这不能不说是个遗憾。

2、事前的准备不足。
谈到这个话题,倒不是说这次来考核的顾问没有充分准备,而是回想起自己曾经做顾问时的一些经历。
一个项目启动以后,自己所想到的不过是:哦,要出差了。但对客户的需求通常没有做太深入仔细的研究,总想着,到那先了解了解情况再说。现在回想起来,自己当初的确是比较幼稚。初次会面,客户提出的问题你不能即时很好的回答,很可能他们当场就否定了你的技术,以后要翻身就难了。
所以我建议,顾问在启动项目前应该充分做好如下的准备工作。
A、仔细研读项目的需求文档、项目建议以及销售过程中所牵扯到的所有问答,深入了解客户的需求和思路。我想,这是大多数顾问都能做到的。
B、全面分析客户所在的行业特性,并尽量将这些行业特性整理成文档。为什么我特别要强调这样的文档?因为用嘴说的和打印出来的文档效果迥然不同!说,可以信口开河,而文档不会,在你注明了所引用的资料来源时,客户会觉得你非常专业,并且对这个项目有着充分的准备。
或许你会认为在这我有点吹毛求疵了,但别忘了,作为SAP顾问的您每天是拿数千元的高级顾问,作为客户的我,要求您事先做些小小的准备并不过分吧?对没错,为了能让您到我公司来闲庭信步,我们必须支付每天数千元的高薪――尽管您拿到手的并没有这样多。

3、理性掌握客户的心理。
关于顾问保守的话题,我相信很多人都不是第一听到了。更有趣的是,某些顾问在抱怨以前做客户是遭遇了顾问的冷遇,却也被人投诉过于保守。
其实咱们换个角度去看:作为USER的人,也很难问出什么太高深的问题,绝大多数的问题与其具体业务相关,而这些具体业务或许能关系到他们个人在这个企业的前程。
在此也希望那些有一定水准的SAP顾问,能敞开胸怀。

原文:http://jiangzhiquan.blog.163.com/blog/static/2787788320074318231480/

我所经历的SAP选型的更多相关文章

  1. 我所经历的SAP选型[转]

    这是一个失败的选型项目,而且在可遇见的未来公司也不会再经历SAP选型,甚至不会再启动erp项目,个中原因很难一言道尽,在此简要的说说我们的选型过程以及在选型过程中对各种因素的考虑. 一.重启选型工作七 ...

  2. 再谈ERP选型

    这几天收到老友的消息,谈及他们公司ERP选型的结果,基本上确定了使用Oracle EBS,因此闹了接近一年的选SAP还是选Oracle的纷争落下帷幕. 这家企业我去年曾去交流过,跟他们聊了一下ERP行 ...

  3. 消息中间件选型分析——从Kafka与RabbitMQ的对比来看全局

    一.前言 消息队列中间件(简称消息中间件)是指利用高效可靠的消息传递机制进行与平台无关的数据交流,并基于数据通信来进行分布式系统的集成.通过提供消息传递和消息排队模型,它可以在分布式环境下提供应用解耦 ...

  4. IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?

    1.前言 在IM这种讲究高并发.高消息吞吐的互联网场景下,MQ消息中间件是个很重要的基础设施,它在IM系统的服务端架构中担当消息中转.消息削峰.消息交换异步化等等角色,当然MQ消息中间件的作用远不止于 ...

  5. rabbitmq学习(九) —— 关于消息队列的选型

    转自http://cmsblogs.com/?p=3846 在IM这种讲究高并发.高消息吞吐的互联网场景下,MQ消息中间件是个很重要的基础设施,它在IM系统的服务端架构中担当消息中转.消息削峰.消息交 ...

  6. 应用SAP PI实现SAP BW数据仓库对于第三方系统数据完美集成以及DELTA加载的分析

    注明:本篇的技术性细节参考了SAP SCN上的一篇SAP PI 和BW集成的文章,本篇文章并不打算过多探讨实现的技术细节,因为在SCN上的这篇英文文章已经完全涵盖了技术细节和配置步骤 大家可以通过搜索 ...

  7. rocketmq总结(消息的高可用、中间件选型)

    rocketmq总结(消息的高可用.中间件选型) 参考: https://blog.csdn.net/meilong_whpu/article/details/76922456 http://blog ...

  8. 消息中间件选型分析:从 Kafka 与 RabbitMQ 的对比看全局

    本文转载自消息中间件选型分析:从 Kafka 与 RabbitMQ 的对比看全局 前言 消息队列中间件(简称消息中间件)是指利用高效可靠的消息传递机制进行与平台无关的数据交流,并基于数据通信来进行分布 ...

  9. 我造了个好大的"轮子",居然还不是"圆"的!

      我造的这个"轮子"指的是集低代码开发与运维为一体的平台,为什么说它不是"圆"的,因为它有些与众不同,甚至可以说是有些另类.至于为什么造这个"轮子& ...

随机推荐

  1. 从网页监听Android设备的返回键

    最近搞Android项目的时候,遇到一个比较蛋疼的需求,需要从Client App调用系统浏览器打开一个页面,进行杂七杂八的一些交互之后,返回到App.如何打开浏览器和如何返回App这里就不说了,有兴 ...

  2. hihocoder 1228 Mission Impossible 6

    题意:一个模拟……大概就是模拟一个编辑文档的过程……具体的还是读题吧…… 解法:刚开场就发现的一个模拟……果断敲起来…… 要注意几点与实际编辑过程不同: 1.当用C操作标记一段字符后,只有D会改变这段 ...

  3. java jvm学习笔记十三(jvm基本结构)

    欢迎装载请说明出处:http://blog.csdn.net/yfqnihao 这一节,主要来学习jvm的基本结构,也就是概述.说是概述,内容很多,而且概念量也很大,不过关于概念方面,你不用担心,我完 ...

  4. JTA事务管理--配置剖析

    概述    [IT168 专稿]Spring 通过AOP技术可以让我们在脱离EJB的情况下享受声明式事务的丰盛大餐,脱离Java EE应用服务器使用声明式事务的道路已经畅通无阻.但是很大部分人都还认为 ...

  5. 查看系统或者Jmeter的Properties

    工作台-非测试元件-Property Display,可以显示系统或者Jmeter的Properties

  6. Android和iOS隐藏状态条

    Android: 在 AndroidManifest.xml 里 <activity android:theme="@android:style/Theme.NoTitleBar.Fu ...

  7. Python 代码性能优化技巧

    选择了脚本语言就要忍受其速度,这句话在某种程度上说明了 python 作为脚本的一个不足之处,那就是执行效率和性能不够理想,特别是在 performance 较差的机器上,因此有必要进行一定的代码优化 ...

  8. 【和我一起学python吧】初学Python,版本如何选择?

    早在四年多以前,在我进入英才网之前,去面试过一家海归创业的公司.他们需要的是有unix开发经验的技术人员,但是因为他们当时所处的阶段对很多成熟 技术人员不是很吸引,所以条件放宽为熟悉面向对象的程序开发 ...

  9. CentOS搭建LAMP环境

    最近准备安装roundcube,需要先搭建一个 LAMP 运行环境,从网上搜索了一下,有不少资料.自己也按部就班安装了一遍,把过程整理了下来. LAMP 是Linux, Apache, MySQL, ...

  10. 重新执笔,已是大三!Jekyll自定义主题开发

    前言 “一转眼忘了时间 丢了感觉 黑了世界 再逞强 再疯狂 也会伤 不知 不觉 后知 后觉 然后 发现 失去 知觉 ”——<一吻不天荒> 感言 时间是把双刃剑,什么解决不了,忧烦的,慢慢变 ...