位置: 首页 > 数字化课程 > 国产化ERP到底有没有机会击败SAP

国产化ERP到底有没有机会击败SAP

发布日期: 2022-06-05 来源: Trade7788.com

当年也是机缘巧合,从开发人员转到Sap上面,也是经历了开发、业务顾问、财务顾问、项目经理,也是甲方、乙方、自由全做过了。
在甲方的经历,也是什么流程再造、供应链优化、什么精益管理(说到这里,在大型企业里真的是如果有机缘能学好多东西的)、智能生产线等等不管是什么项目都参与不少,当年内部的Sap也能让我们独立实施(完全没有外部顾问),想想领导担心,我们也是傻大胆啊,一个人平均两个甚至是三个模块,居然硬是把几个规模上亿的子公司干上线了,而且使用起来还特别好,想想既是运气好,也是不知道之前默默打下来多少基础啊....

因为企业集团的性质,从70年代就开始信息化了(入职前就对企业非常熟悉,经常去,别问为什么,反正是在上高中时就帮忙做过他们的系统)
后来入职了就做信息化的工作。其实在上Sap之前,用友用过(几个子公司,产值过50亿),金蝶也用过(子公司总部都用),infor的前身也用过,Sybase的产品等等都用了,而且我们自己也有一定规模的自开发能力。所以,在后来的Sap上线,我们是直接内部顾问,属于直接上手做方案和配置的,也是既有培训我们的意思,也有降低后期实施费用和运营成本的意思(但是后来在负责的领导退休后,这些做Sap的人员都离职了...)
所以我们一般运维这用友和金蝶,一边做着Sap和这些系统的接口,例如金蝶后来的就相对于一个财务报表系统。我们的当时与金蝶的关系还是毕竟紧密的,金蝶有一个产品线就是在我们那里做试点,长期驻扎了一个开发的团队。这些都是前提....

1. 先说Sap的特点

有人说ERP是一个管理思想,一个管理模式,而不是一个系统。也对也不对,因为信息系统的现实映射,首先必须是一个思想或模式,然后才是信息系统的抽象。
所以,可以理解是系统的思想模式的具体实现,两者相互影响相互依存。一个做指导,一个做执行。因此,在ERP中一个关键的一点就是,思想先行(目标),然后才是实现(功能化),这个顺序不能弄反了,要不然ERP怎么都不好用,而Sap就是这种集大成者。

其实,纯粹的技术想追赶还是毕竟容易的,难的是那些思想模式,因此精益管理都去学,几十年了,不能说没人学到,但是应该是学到的不多。反而是技术上,相当一部分领域有赶超的局势,Sap就处于这种境地。 单从Sap ECC的技术框架上,不能说老套,但是真的是不能说新的(但是S4新啊)
但是ERP的这种东西,技术框架如果没有特别致命的短板,其实它其他方面的优势很容易就把问题掩盖住了,这也是S4上了这么多年,为什么大多数都还在EHP6的版本上。如果没有十分的必要,象更替这个的成本和风险都是极高的(如果不了解,去认真学习一些系统学,以及兼容和向前兼容的相关知识)。
Sap的模块(可以叫做套件或组件)的功能太丰富了,经过历代升级,大多数的常规功能都能实现。其实,如果要求不高,采用标准的流程,其实一个多月就可以搭建出一个标准的系统功能出来,加上数据收集、切换,3个月就可以完成一个单位的上线(别要求个性,因为这部分的工作没做)。

其实,现在对Sap有一种误解,觉得Sap难用,这个是给管理层用的,不是给执行层和作业层用的。
不知道这个是否是因为是用户刚刚用还没习惯呢,还是实施团队不行,如果用户长时间觉得难用,那是不可思议的。因为Sap的标准界面也是可以配置的,很多界面和元素都是可以控制增加或隐藏的,很多也可以对登录的用户做个性化配置,对应的报表格式布局等等都是可以因人而异进行调整的。所以,不好用是各什么情况呢?!
如果有极端要求,那么可以完全把标准的功能替换下来,你想做什么界面就做什么界面,如果还对Win或Web的界面情有独钟,那也可以将界面前端化,让你一点都看不出来Sap的痕迹,这还不满意么?!当然,这些是要成本的,但是不是不能...
而对于业务流程改动,啊,最近被用户逼得没办法,口头禅变成”只要逻辑可行,技术上不是问题“,当然潜台词是成本要付出。
因为不说大话,只要你想要实现的功能和流程,都是可以做的,要实现一键清账么?可以!要实现自动投料么?可以!要实现根据采购订单类型或物料类型拆分会计凭证么?可以!
要实现自动预测库存进货量么?可以!要实现销售订单发票后自动传输金税并开票么?可以!要实现根据用户支付类型自动计算折扣么?可以!要根据用户的地区进行铺货预测和调整信用额度么?可以!
就两点需求,功能设计上的逻辑是可以描述的,是可行的(举一个不可行的例子,就是当一个产品是双路线的情况,至于是要生产还是采购,那么需要有一个标准,及供应商的供货及时性或成本核定标准等,有一个优先级和阈值的条件);另一个就是成本。满足以上两个,只要你想,没有不行。

补充一点,国产软件开发也是可以,但是各模块间衔接不紧密,如果是底层开发,风险和周期较大,非常考验现场的实施经理(或产品经理)和开发人员的水平。后面再讲金蝶的另一个事情。

2. 国产ERP的特点

国产ERP就不特别说了,因为大多数都是一个显著的特点,就是大多数知名的ERP都是财务系统出身,然后在逐渐发展到业务等环节。
要说,国产ERP的优势,主要还是两点

一个是便宜,起码中小规模的便宜(不过现在Sap的中小公司和自由团队也能在100万以下的市场上有力竞争,但是快速部署上还是国产软件更快)

另一个是操作符合国内习惯,包括集成了Win的操作习惯,非常符合国人,也包括这些系统就是本土建设的,就是为本地财务量身打造的,符合财务的习惯和方法,比如一个显著的例子就是Sap没有科目的钩稽关系,而金蝶用友就有,可以很好的在所有的功能点上实现科目的勾稽合并,对于财务人员来说是非常方便的,不用花时间去熟悉了解。
不过,Sap上大家也想到了办法,科目本身不行,但是可以在报表也很好的实现了,具体怎么做这里就不说了,不过比起国产ERP的原生功能,最少还要考虑如何去改造它。

所以,国产的ERP在中小企业上有很强的竞争力,在一些新兴行业也有比较强的竞争力,比如电商领域。而Sap在这方面不是不能做,而是要适应这中小企业,花费的成本比较高(遵循二八原则),对于企业来说可能会得不偿失。

接Sap中补充的那一点,在13还是14年,曾经参加过一个金蝶省级的二次开发环境演示会,其实就是象Sap的Abap一样有一个在底层之上的开发环境(如果不了解这个作用,是没办法成为资深顾问的),因为它快速解决了各业务层面集成的问题,以及快速个性化需求实现的问题(相对于底层开发),但是后来不知道为什么无声无息了,要说是挺遗憾的,这可能是就是中型和大型系统的中一个必要分水岭条件之一。

3. 国产ERP替代Sap的可能性

做了快20年的信息化,好多事情看的很淡,技术层面的事情和思想层面的事情感觉只要想积累都不是问题(说到这里也比较反感面试时有人盯着具体问操作,我给别人面试时就只列举应用场景问方法,大概知道就行,事务码等操作可以上项目来再查,觉得这不是技术问题),不过要面临一个先发者通吃的局面,尤其是先发者的功能积累和用户积累都占优的情况,国产ERP只能厚积薄发。

虽然这几年都在说替换,但是感觉还是在边边角角的事情,感觉考虑是GUI的替换,去提升用户的体验。
这些说重要么,也重要,说不重要么,也不太重要。因为这种工作谁做都行,象10年以上的顾问,有业务、财务和开发经验,有一笔资金,拉出来一个团队做,这些都不是个事情。
而真正核心的那部分,是各模块相交集的部分,复杂度很高,而且需要大量的实施案例、方案及思路理念支持,所以也可能在这些公司外面吧,不知道他们真正的战略部署,但是确实没看到有啃硬骨头的态度(有可能还是在厚积薄发,那就不知道了)。不过,最关键的是给人的感觉,一直说是要吸收Sap的资深顾问过去做全面的布局搭建系统框架等,但是实际上还是有点雷声大雨点小的感觉....

最近几件事情很有感悟,也发现这个行业其实也是存在很大的问题,用户说的问题也真实存在,或许是产品的问题,或许也是顾问自身的问题,感触很深。

唱衰Sap的声音一直都在存在,就像头上悬着一把达摩克利斯之剑,说实话确实不能无视,而无视他的无非两种人,一种是只存在Sap世界没向外看看的人,而另一种是明显知道但是想还能赚钱就不想那么多的人,其中第一种人往往还是对管理理论不感冒的人。
起因还是谈起顾问未来的问题,和老板谈,老板的看法是顾问不值那么多钱(其实和大数据等不好说到底值不值得问题),但是到底是真实想法还是劳资视角的问题说不清楚。但是,和同在业内的朋友谈起,话题就真的很深入了,Sap如果仅限于本身,真的说不清是否还有未来。原因有二:

1、系统架构体量太大
部署的成本高、风险大(指的是架构的灵活性)、系统复杂。总之,就是既不符合现在电商的环境的管理模式,在系统架构上有过于厚重,需要专业细分领域的顾问才能解决问题(后续会阐述与开发软件的产品设计上的专业领域不同点)。因此,对于快速变化的市场所造成的产品、渠道、资源、计划等管理,其实是反应迟钝的。更多的采用的是一种模式化的解决方案。

2、实施方式过于传统
常规的方式就是先调研,进行可研和需求分析;然后现有蓝图和设计蓝图,以确定功能及流程;然后是系统配置和系统开发;下来是系统的测试和培训;再下来就是系统的收集、整理;最好是系统上线和问题消缺、运维优化。
总体来说,对于一个一定规模的企业,轻则半年,多则一两年的实施,关键是这些流程是顺序的,也就是从调研到系统测试可能才发现最开始的方向错了,甚至是到系统上线才发现。
项目失败的风险比较高,全靠资深的顾问进行风险把控,对实施顾问的依赖程度非常高。如果是关键节点还好,但是这个基本上是贯穿一半的进程,最致命的是无法实现系统设计的快速迭代....
风险基本上都只能落实在后半段才能发现和解决,在非标准化甚至是较为复杂的标准流程或功能中都无法很好的利用之前的项目经验。
而从软件工程的角度来说(我之前是出身于Win的开发人员),快速迭代、轻量设计开发、敏捷、系统原型等都是应对软件项目中必要的手段。而现在无论系统本事还是Sap实施方法论上都过于厚重,成本和风险控制能力都比较差。

4. 咨询还是技术?

有一天,经历了几场面试,有聊的透彻的,也有草草收尾的,发现一个特别有意思的事情。和一个事业部的老总聊起来(面试的岗位是项目经理),就是说到从企业出来的实施顾问和一开始在外部做项目的实施顾问大体上还是有很多不同的,虽然不是绝对,但是能明显发现两者的差异。企业内出来的顾问一定概率重视管理,重管理咨询,轻系统操作;而一直在外部成长的顾问重系统,系统的操作非常熟练,重系统的模式化推广,不喜欢了解或挖掘用户的需求。因此两者在项目落地上的风格差异非常大。

在上一个项目任经理时(兼方案设计负责人),发现一个有趣的事情,我的一个顾问给用户解释为什么有的科目要输入成本中心时,给出的答复时,因为系统的CO必须要求输入,比如设置成本要素的需要,没有设置的不需要。要用户接着问,什么是成本要素,为什么要设置成本要素,顾问答复是CO的要求,用户直接找我投诉。
我给用户说的大体理由是我们会计的核算原则要求所致,这里采用的概念是会计的主体假设,也就是我们要进行核算的范围。这个范围有公司、利润中心、成本中心,成本要素的概念是要求以成本中心这个核算主体进行核算的标记,简要的说就是需要核算到成本中心的科目就需要设置成本要素。
那么为什么有的设置有的不设置呢?是因为需要对相关的费用进行归集和分摊,这类就需要设置成本要素。
例如如果我们的办公费需要分摊到各个部门上的,基于这个核算管理要求,就需要对办公费设置成本要素,如果统一都有办公室发生费用(例如费用结构简单或金额小),这种情况就不需要成本要素。
一个非常特殊的例子,有些公司的财务费用是需要设置成本要素的,因为他们采用独立部分(往往是事业部等独立经营部门),这种为某个产品线、销售区域等进行贷款等费用,就需要归属到这个部门上。
引申一下,会计核算体系的建立都可以基于这种要求进行特别的设计,例如科目及科目层级设置、辅助帐的设置等等。

以上是举了一个小小的例子,其实在我们做财务、采购、销售、生产等各个方面,都有这方面的管理需要,需要对用户出局相关的咨询意见,实现供应链管理、生产计划、销售预测及三包等等各种管理需要,不是基于实施模块的技术实现,而是基于Sap提供的方案进行灵活搭配和扩展(各种增强),从而实现更为复杂和灵活的功能需求。

但是,一件事很快给我上了一课。在去年的时候,和一个朋友就咨询还是技术展开了一个长达三个小时的讨论,朋友认同我的观点,但同时也打击了我的观点,告诉我Sap行业基本上不存在咨询,行业评价顾问水平高低是基于你对系统的了解,更多的是你对具体系统操作的熟练度。这个讨论也是事出有因的,是一家公司谈了一个公司的项目的实施,后来不欢而散了,因为认识那家公司的管理层,所以简单聊过,总体来说就是用户觉得实施公司不尊重他们,用模板套用在他们的管理需求上,但实施公司却觉得觉得用户应该采用标准的先进的(顾问是这么认为的)现有方案实施项目.....
其实,这和之前有的用户对Sap的抨击基本差不多,这个我检讨,因为我还和那个知乎较真争论过。用朋友的话说:“你不要把其他人想象的和你一样,一样的经历,一样的领悟。你经历过win开发、Sap开发、做过win下的各种管理系统、做过sap的各个模块,有做过财务,所以对他们来说,现有模式就是最好的,最有效的,风险最低的....”。
结果,前天,面试了一个中台项目,在我放弃了其他几个的项目经理的offer(因为频繁交付觉得没有意思),想深入做一款涵盖管理思想的产品出来(以前做win时做过产品经理)的时候,结果告诉我,面试没过.... 问题是,这在我所有的工作技能中,建立系统平台是我水平最高的能力,也是经验最丰富的地方,比做实施顾问和项目经理都要好多的。
好吧,和朋友聊起来,面试的时候,一开始几个基本的事务码答不上了可能是主要原因,后面在说方案上是行云流水的,应该是一开始的印象太不好了。但是,我面试别人的时候,这部分从来不作为评判标准,基本上简历一看觉得经历没问题就可以了,面试的过程是看对方简历是否造假了。没有明显出入,简历审过的就可以面试通过。

最关键的是,我面试的时候是做一个一连串场景让对方说方案,细节从来不关系(因为都不是3月内的短期项目)。
而之前面试我的老顾问(其实事后也了解到好多都是企业出来的顾问,因此有相同思路),好几个开场第一句话就说,你做这么项目,类型有这么多,我还有什么可问的,基本上3分钟就搞定了。
因此过关率很高,而接触的年轻顾问的面试,过关率明显下降,哈哈。

这里举例只是说明了两种顾问的思维差异,而在项目实施上的方式就差别非常大了,就看用户遇到了那种。就当前遇到的顾问,大概率还是企业出来的倾向于咨询,因为他们所处于的环境经历所造成的思路不同,只不过总体市场这种人将对比较少,当然也存在老顾问逐渐退出行当的原因所致吧。
但是,咨询是否和技术冲突,原则上是不存在的,但是技术存在两个方面,一个是Sap的构建技术,另一个是ERP领域的技术,而操作却不在此列(起码我个人认为,可能有失偏颇,勿喷)。

Sap的技术不谈了,因为大家都可以直接去了解,在S4后还有是有很多新技术出来的。而ERP领域的技术可以说是替代Sap的说法来由,这里暂时不想做大篇幅说明了,其实及时类似Saas、Paas以及其他类似微服务等搭建的平台,在实现快速系统构建、原型、迭代(概念,请不要咬文嚼字,理解万岁)等上具有巨大的优势,便于部署和实现,成本和风险降低很多,而且也可以快速进行方案分发、集成等
在一些轻量级的应用上具有之前Sap无法实现的优势。当然,因为轻量,所以一些复杂的流程应用还是无法直接实现,还是需要利用Sap等系统实现接口对接实现,这里也有一点感慨,就是如果在这些平台上如果堆砌了重方案时,是否也会出现屠龙勇士终变龙的情况呢?!个人感觉还是有方法解决这个问题的,其实还是利用了软件工程的方法,利用面向对象的设计(不是面向对象的开发啊!)
以低耦合高内聚的方式形成一个个独立的功能应用(之前做了一个财务和物资的简要设计方案,按照现在的项目经验,自我评估是可以落地的),但是如果上升到一个ERP级别,这种体量的系统设计也是非常惊人的(涉及功能、架构等非常多的方面),需要巨量的投资。

5. 系统国产化的需要

最近的俄乌事件,一系列的国际反应,让国内的Sap市场也受到了波及,具体情况大家也知道或可以去细节了解,总而言之是国产化的一波浪潮明显看着又来了。这么的技术、框架、方案的内容特别多,一个之前我负责的项目上的顾问半个月前给我诉苦,说他刚刚上的项目给分到了一个组,工作是自开发一套系统,将解决现有国际成熟产品的经验、模式、方案等构建新的系统。
他是Sap顾问,没有做过其他的软件设计产品或项目,对于两套系统的核算方案不同,如何建立一套设计方案来解决这个问题,他和这个组的很多顾问都在头痛,问我去不去,但是实在是太远了.....

国产化还有很长的路,即使现在的层出不穷的市场模式和管理概念,以及其他成熟的技术,但是管理模式(抽象系统)通过系统落地(现实系统)并不是一件容易的事情,还需要大量的磨合,方向没错,但是还需要我们很多人的努力.....

关注公众号,免费领取更多数字化资料!

快速入口

外贸数字化联盟是外贸行业数字化解决方案的交流服务平台,为外贸工厂、跨境电商、国际物流、海外仓等企业,提供数字化整体解决方案和交流服务!

关注或联系我们

咨询电话:18813677073

关注公众号
微信客服

网站地图

COPYRIGHT © 2022 Trade7788.com 粤ICP备2021067853号