所有文章在公众号“MZ信息化咨询杂谈”同步更新，习惯公众号阅读的朋友可直接关注公众号哦。
最近忽然发现现在顾问面试也换了套路了，以前一般是问具体的技术问题，比如什么业务、什么功能在系统如何实现，系统某一块功能的逻辑是什么。
估计是现在ERP发展时间厂了，顾问多了，技术普及了，所以现在顾问面试已经不是仅仅问技术问题了，更关注了是对业务层面的理解以及项目中如何克服困难、推动项目落地，或者说对ERP某一块功能结合业务谈谈个人的理解。
好吧，凡事都得与时俱进，对吧。那我们也来模拟面试官问问这些问题，尝试自己回答一下呗，做到有备无患。
说明：业务层面、项目管理层面很多问题并没有标准答案，只要讲清楚自己的理解和逻辑即可。
问题开始！
问题1：如果你来做我们的这个项目，从你的角度（项目经理或者顾问）来看你的优势是什么？答：我个人看法谈优势最好是谈的让人觉得不是自夸。回答具体：根据我对我们（说我们会亲切一些，强烈建议）XX企业的调研情况和自身经验，我认为我有两个（或者三个，不要大于三个了，多了没重点）方面的优势。
哪两个呢，我认为一个方面就是硬实力方面，一方面是软实力方面，所谓硬实力就是结合企业调研情况和信息化的重点、痛点，谈技术能力的优势，就是我有技术能力把这个项目做好，最好能举以往项目中使用过的一个类似的案例（实际上这个例子有没有呢，自己去想好了），就更有说服力。
比如财务上说报销太麻烦了，手工审核，还要手工输入凭证，那就可以说我们以前做过OA填写报销单，在OA审核后，和ERP集成后生成会计凭证的案例，提高效率不少。
软实力就是项目当中需要的沟通能力、表达能力、项目推动、风险把控等，关于这一点，其实通过现场的沟通，客户是能感觉到的，如果需要举例，比如说XX项目，某个模块用户热情不高，要求的数据要么无法提供要么提供数据质量很差，培训经常以忙为理由无法参加，平时邀请见效不大，我们采取了两个办法，一个是我们表示理解忙，但是比较坚决的表达了项目也是工作的一部分，公司已经安排，那么这部分工作就是项目期间工作职责的一部分（这一点一般都会达成一致的，这一点达成一致就好办了，剩下的就是加班干完或者换人干，一般人都不会去走向换人这条路的，因为总得想想领导怎么想吧），如果白天没有时间，我们晚上可以一起加班。如果觉得实在忙无法承担项目工作，我们将向公司上层反映请求更多的资源配合项目。
另外一个周会中我们会展示每个项目模块的工作进度或者展示未完成事项，把问题暴露出来，让所有项目相关的人员都知道哪个模块是比较落后的，并在周会上当着大家的面问落后的进度什么时候可以赶上，并请对用的用户承诺时间。经过两次周会后，赶上了正常进度（这种案例也可以用来回答项目中配合度不高的用户处理方法，对于不配合的用户，只要不是项目最重要的干系人，比如公司高层，那是要通过具体沟通的，如果是关键用户层面，我觉得都可以通过这种方法处理，我把它称之为“暴露法”，一般只要有些自尊心的，经过暴露后，都会主动赶上来的。如果暴露后仍没效果，请求PMO换人吧）。
问题2：假设你参与了此次项目，你认为项目中可能遇到的最大风险是什么？
答：我思考了一下这个问题，我们从项目阶段来划分的话，我觉得不同阶段可能遇到的风险是不同的，以下是个人思考的一些东西。
上线前阶段：调研阶段：细节没有重视或者有些业务没有调研到，导致后期影响重大。建议：顾问严格按照调研清单仔细调研并根据调研情况修正调研问卷，调整调研方向。
蓝图阶段：ERP实施过程中，势必会重新梳理流程，打破部门间壁垒，甚至影响部门间利益重组，风险点在于跨部门流程的设定和讨论，流程节点达成一致，任务分配达成一致。建议：顾问的角度是不强调部门任务多寡和不关注部门利益，而是从公司层面讨论优缺点以及给出建议，只要从公司层面来说是有利的，那么就是最大的依据。
记住！ERP是整个公司层面的甚至是整个集团层面的ERP，ERP分模块，ERP结果和目标不分模块，顾问更要注重整体效果，不能局限于本模块。
实现阶段：风险在于原来设想的方案无法在系统中实现或者实现复杂程度、成本增加。
建议：在方案确定前尽量在测试系统把方案进行测试，方案走通后再在蓝图中确定方案，现在随着方案已经越来越成熟，这方面的风险在减少。
上线准备阶段：此阶段没有什么大的风险，如果有，主要是数据方面的问题，因此检查数据是此阶段的重点。
建议：仔细检查数据，尤其是物料主数据的单位、价格等信息，最大程度保证数据的准确性。
上线后：如何把成功上线变为上线成功，流程执行加配套规章制度、奖惩制度让流程执行真正落地。也就是说，在上线前，除了靠监督流程保证业务落地外，还需要根据流程制定相关的公司规章制度和奖惩制度，以保证业务按既定流程落地。
问题2：假设你参与了此次项目，你认为项目中可能遇到的最大困难是什么？
答：首先要表达的是，任何项目都会存在困难，关键点不在于遇到什么样的困难或者说在哪里遇到困难，而是实现对困难的预计以及对客服困难的方法、信心。
个人理解，一般来说，项目的困难从内部来说最大的困难一般在于业务、财务的协调统一，对外，则是业务模式变化带来的供应商、客户等合作伙伴操作变化，这些都要在项目前期考虑到。如果从组织、流程、数据的角度来说，则这个顺序就是困难大小的顺序。
问题3：假设你参与了此次项目，你觉得从你的角度来说此次项目能给带来的价值有哪些？
答：其实我个人看法首先要回答的是，价值要从不同角度看，可能从某个部门来说增加了工作量，从另外一个角度说是减少了工作量，因此很难从某个部门角度去衡量价值，必须从公司整体去衡量价值，另外，有些价值并非短期内马上看到效果，可能需要一段时间才能显现。
总的来说这个问题不好答，说到底，ERP的价值不像做销售，每成一单都是看得到的数字。
ERP很多东西无法量化，能量化的主要是操作层面（操作是否方便和节省时间比较容易直观体验和感受到熬）和数据层面（数据准确性和实时性还是可以比较明显的看出来的），再往深了说，降低了库存什么的，因素很多，怎么确定这就是ERP的功劳？
只能根据调研的情况，找出企业目前信息化的薄弱点，针对性的回答，比较笼统的回答就是提高效率，降低成本，快速结账，简化操作，提高客户满意度，其实后面两个也算是提高效率，其实就是效率和成本，要么花同样的钱，做的事情多了，要么做的事情一样，花的钱少了。
问题四：在项目过程中如果遇到了你无法处理或者说超出你能力之外的事情怎么办？
答：首要原则是找项目经理，都超出能力范围外了，不找组织干嘛，组织就是让我们依靠的嘛。不要强行试着解决，解决好了，不是功劳，解决不好，肯定是锅。
问题五：谈谈你对ERP或者说ERP某个模块某个功能的理解？
答：多年的顾问都会对ERP或者ERP的某个模块某个功能有自己的理解，这种理解是结合项目经验和实际业务的理解，并非教材上的标准答案。
我个人的理解是ERP不是一个过程管理的软件，或者更准确的说不是一个精细过程管理的软件，ERP是一个粗过程管理着重结果管理的软件。
这是它的使命，它的定位决定了它无法完全下沉到业务执行层的细节，因为那样的话系统会过去复杂和庞大。
为什么呢，因为ERP的核心还是财务，假设没了财务模块，ERP还能叫ERP吗？恐怕不能了，基于这个前提，这就导致了业务层无法下沉太多，下沉太多对系统反映的要求越来越高，同时业务执行层并非所有数据都要保存的，至少不是长久保存的，这些和ERP的设计目的都是矛盾的，是用ERP无法实现的。
现在有去ERP业务模块的倾向，为什么呢，因为业务模块的要求越来越灵活，越来越多变，所以有不少的公司开始在ERP外围搭建很多的外围系统，这样的好处是灵活满足了，但信息又变成割裂了。
总而言之，从企业应用层面来说，ERP就是个中间层的产品，上有企业数据仓库，下有业务执行系统，ERP定位就是如此了。
未来，ERP可能会演化为财务系统为主，业务执行系统通过中间件与财务系统按时按需（也就是说根据业务发展的阶段只有业务数据需要反馈到财务系统了，就把数据传输到财务系统生成凭证）连接过账。
备注：此篇最初发表于2018年3月。
