现在的位置: 首页 > 综合 > 正文

如何开发一个灵活的可容错的ERP系统的一些沉思

2018年06月10日 ⁄ 综合 ⁄ 共 3456字 ⁄ 字号 评论关闭

我曾经是一个ERP系统开发程序员. 时隔5年竟然又从事ERP实施.也许这辈子与ERP是分不开了..

在集团从事信息化专员职位已经3个月了.

在此期间所遇到的问题,所经历的事情.以及一些所思所想. 考虑到我靠不住的记性.还是写下来与大家分享一下.

刚入这个公司,最大的目的是为了解决库存不准的问题. 

公司使用的是一个类似 ERP的系统.接手时一片混乱. 数据一点都不准.当然现在还是有些不太准.

一个ERP系统要想走向正确的最好的方法是在刚开始实施的时候就让用户走标准流程.培训好每个流程如何处理. 

这是ERP能够正常实施的根本. 当然这要有个前提----企业愿意为一套系统改变企业的业务流程. 现在SAP就是走的这条路,让企业做出改变.让企业适应系统.

当然SAP做的很强大.已经基本上能够适应任何流程.SAP做到如此强大的关键点我认为在于其二次开发语言ABAP. ABAP 可以快速的开发出针对某种业务的插件程序. 当然企业得高薪聘请一个SAP专业程序员.

SAP出售的不单单是一套系统,更是一套解决方案. 所以SAP能卖的那么好.还那么贵..

但是SAP也有其缺点..

SAP项目实施过程十分昂贵和复杂。 而且,由于其软件的复杂性和封闭式集成,一旦实施后很难改变。另外,SAP在项目实施过程中,经常会期望客户改变商业运做模式以适应其软件, 但有时候,一味迁就软件流程的做法很可能会给客户带来负面结果。一些超大型企业可以投入巨资进行软件的客户化,但是对于中等规模的企业,复杂的项目实施,往往会将客户拖入无休止的泥潭。国内一汽大众的SAP ERP的累计实施投资已经过亿圆,但实施效果其实并不理想。之后一汽又选用了与SAP的ERP "配套" 的CRM供应商SIEBEL软件, 其CRM系统实施了几年, 至今没有上线。

其实SAP的缺点实际上是所有ERP的缺点.每个ERP都有这样的缺点,并不能说是SAP的缺点.

我一直在思考着这个问题.

在多变的业务模式中.如何才能够使得软件灵活的跟得上业务模式的变化.

现在终于有了一些自己的答案.

我们先假设这几个场景.

第一在没有计算机的情况下. 我们的所有业务流转全部靠的纸质单据.和纸质报表.

而自从有了计算机,这种模式开始变的模糊. 有些部分是纸质单据有些部分是计算机数据记录.

有的是全部计算机数据记录.完全没有纸质单据.

我想说的是,在没有ERP软件的情况下.业务流程是灵活的,多变的.但是效率地下.统计困难.查询更困难, 业务越大效率越低.

而自从转变成使用计算机ERP系统 来干统计,记录,查询的活. 效率是得到了飞跃的提升. 但是却丢掉了业务灵活多变的优点.

那么到底是什么原因导致我们丢掉了灵活多变的优点呢?

我想我的答案会引起很多人的反对.

答案是源自关系数据库模式概念的根深蒂固.


数据孤岛与关系数据库.

数据孤岛的一大典型代表是Excel ,数据库的典型代表是目前常见的 mysql oracle

从灵活性方面来考虑.Excel最灵活. 数据库则非常的臃肿和复杂.(复杂是指的面对最终用户)

但是数据库则非常的强大和能力强劲. 因为它的处理能力非常强.查询能力非常强.只是用起来有点麻烦.

而目前我们很多的ERP软件所做的事都是把数据库Excel化. 表单化.再加上一些固定简单的统计等等..这些工作足以耗费一个程序员一年的工作量.

我也看到有很多的软件试图融合Excel和数据库.

那么话题回归到解决方案上.

程序员都知道数据库的设计的三个范式. 

那么第一范式和第二范式是无可厚非的.给我们的系统造成最大问题的就是这第三范式.

第三范式的目的是为了减少冗余. 减少冗余本身无错.错就错在.不应该时时刻刻都要减少冗余..

理清现实世界的业务模型的时候,往往变成了数据库设计. 

ER图和数据库设计最大的区别是,ER图设计不考虑数据如何存储, 只考虑数据结构.不考虑冗余等等数据库问题.

我们考虑一个日志记录.的需求.  按照第三范式是不是要

设计成下面这个样子,这个地方操作人是一个外键.存储的是一个用户表的主键Id

用户表

用户id 用户名 操作内容 最后登录IP
1 张三 insertData 172.0.0.1
2 李四 deleteData 172.0.0.2

日志记录表

时间 操作人 操作内容 IP
2014-06-12 12:12:00 1 insertData 172.0.0.1
2014-06-12 12:12:00 2 deleteData 172.0.0.2

各位读者,是这样设计数据的请举手..

好吧,举手的都是好同学.学习的不错.可是这个地方就造成了一个非常大的问题.

数据黏度增强了.如果没有了用户表,那么这个表就残废了.

同理反推, 只要张三登陆过系统那么, 理论上张三就永远不能被删除.只能被禁用..

否则日志记录就残废了. 他做的各种单据也同样残废了.

同时还带来一个非常严重的问题.每次显示日志记录的时候都要查询用户表.找出这个操作人叫什么.

这就是所谓的数据黏度.

当一个表与其它表之间的数据关系越多,那么其黏度就越强.

越是主要的表其黏度就越强.

而一个系统的设计总是需要从一个表,延伸出5-6个关联子表. 这样才能算是一个完善的系统设计.

那么反过来我们来考虑一下.我们设计的系统是不是真的必须需要这些关系,失去这些关系是不是真的就不能工作了?

注意我说的关系不是指特定数据库的主外键关系,而是指的数据表的黏度关系.

日志记录表 改成下面这样设计是否能起到作用.我们考虑将日志记录表改一下

日志记录表

时间 操作人 操作内容 IP
2014-06-12 12:12:00 张三 insertData 172.0.0.1
2014-06-12 12:12:00 李四 deleteData 172.0.0.2

有的人要反对了,如果有重名的怎么办?

那么我想问你,  张三 和 张三   ?你能分出前一个 张三 和后一个 张三 谁是谁吗? 你都分不清,电脑如何分的清? 也许你会说,他们年龄不一样就可以分清了. 实际上我更愿意让用户把 张三改成 张三1 和 张三2

把姓名设为主键.

这种设计从非常大的程度上减少了数据黏度. 降低了系统模块之间的耦合度. 

作为系统设计师,我们应当如何设计数据结构才算是最合理最灵活的.也许即便是一个终身设计师也无法下结论.系统设计是一个权衡的过程.没有确定的界线和规则.

灵活和庞大之间并不是反义词.理论上是可以做到即灵活又庞大.但一般是庞大的事物必然不灵活.

如何做到灵活首先第一点上就是要减少黏度. 尤其是数据黏度.当然还有代码黏度. 两个黏度任何一个解除不好都无法做到灵活..

谈到解除黏度,自然带来一个问题,如何切割一个个模块.一个模块的界限是什么?

你可以说一个系统是一个模块,也可以说一段程序是一个模块..

而任何一个模块都不可能是独立存在的.

我们如何做才能更好的设计出灵活的系统.

面对两难的抉择问题,我想有个方法是可以借鉴的.

钢筋水泥土结构和砖头结构.做比较的话, 肯定是砖头搭建的房子更灵活.易拆.

我觉得应该先按逻辑功能分模块.独立的去实现某个业务逻辑,他们之间不需要任何的关系.即便是有关系也不要去实现它.

等到这个模块可以单独给用户使用的时候,再做胶水链接.. 采用插件的形式去连接.而我更倾向于使用ajax或者webservice来做胶水代码.

为什么要这么做呢,我举一个例子. 我遇到的例子.

我们的系统是自动从淘宝网下单. 然后打单,再发货的.

但是我们的库存量总是不准.为了找出原因我却发现系统算来算去都是算的自己的.似乎永远都是对的..可实际库存却总是不对.

数据只有一套为什么会不对呢? 为了找出原因.绞尽脑汁. 如果我能把各个过程之间的数据独立起来.相互之间并不关联. 形成相互验证.相互核对的关系,那么就能发现具体的问题点.

我采用的方式是用传统的Excel来核对数据.发现Excel的核对功能还是很强大的. 如果我抛弃系统,完全采用Excel , 除了不能自动从淘宝网下载订单外,几乎所有的业务功能都能做到..而且各个环节自成一体.

伸缩自如设计一个表格简单到如画画. 那么我要系统还有什么用? 除了几个特殊的功能,不能完成外.其它的似乎都能完成.

那么在Excel的基础之上我只要开发几个简单的程序不就完全可以抛弃系统了吗?

说到这里,只是证明了一点,按模块划分独立编写代码使之完全不知道对方的存在是最好的系统实现方式.

等到模块能够独立使用的时候再考虑添加粘合代码.(粘合代码最好放在单独的模块注入进去.外挂的形式)

例如:仓库管理模块和订单管理模块其实完全可以分开独立工作.

就算是真的需要衔接数据, 我宁愿把数据复制一份发给另一方.这样的话还能起到数据备份和相互验证的功能.

未完待续...

抱歉!评论已关闭.