管理软件智能核算的实现对传统“模块”概念的影响

管理软件智能核算的实现对传统“模块”概念的影响

李劲波Ljbitopen@sina.com

用户若同时面对一大堆单据，既有应收又有应付，又有其它需入帐的普通业务单据，还有数量帐的核算，那么用户的做法有：

1. 打开总帐、应收、应付、存货至少这四个模块系统同时工作，否则你在总帐系统中输入“应收帐款”科目时，系统会很“友好”的告诉你：“请转换到应收模块工作”
2. 和领导说：“我忙不过来，加两个会计吧”，或者“领导，上次我不是说过上了财务软件后要减人增效吗？能不能先等一等再说。”

第1种方法，有谁会认为它很方便的请举手；

第2种方法，有谁认为领导听了这话以后会高兴的对你说：“干的不错”的请举手。

产生问题的根本原因在哪里？

这是因为现在的财务软件一是没有做到从原始单据着手，二是对会计行为的分类根本不彻底，也即现在的财务软件在系统分析阶段就存在重大的方向性问题。

现行的传统财务软件的工作对象是会计人员处理过后的信息，而不是会计事项，也即如果人告诉机器“采购业务的入库单到了”这么一个事项，系统是无法做出任何处理的，系统只能处理会计人员对这个事项处理过以后的数据信息，我可以用数学上的例子来打比方：

有三道题，“X+1=2”、“A+A=0”、“求X*A+6”

第一道是一元一次方程，第二道是一元二次方程，第三道是四则运算，解第三道题必须先解前二道，对应到财务工作：

1. 拿到题目相当于会计获得原始单据
2. 解前两道题的过程相当于会计对一个会计事项进行会计处理
3. 解第三题的过程相当于会计对已处理的信息进行再处理（比如帐表核算等等）

很明显，传统的财务软件只能做第三道题，它无法代替人做前两道题，当类似的题目数量很多时，只能是将这些题目分类并给具体人员分派任务，即-将类似于第一道题的题目归为解一元一次方程类的工作，类似第二道的题目归为解一元二次方程类，然后给解一元一次方程的工作安排一个工作环境，给解一元二次方程的工作安排一个工作环境，再将一元一次方程分配给甲做，一元二次方程分配给乙做，并且规定在一个工作环境中只允许做一种类型的工作，这样，模块及模块化工作的概念就产生了。

能不能让系统没有那么多的“模块”，让系统智能的判断什么情况下应该给予操作人员什么样的工作环境呢？能，我们已经在实验中正式解决了这个问题。

解决问题的关键是我们让系统懂得如何去解前两道题。

我们知道人解题是有逻辑性的，即人是按某种方法做事的，软件系统有了“方法”、有了解题逻辑以后，自然也能解题，如何让系统有“方法”呢？

看过我的“管理软件的思维革命”一文的人应该知道“核算方法库”的概念，所谓的“核算方法”在会计上就是“遇到什么样的会计事项应该怎么去处理”，会计处理与解数学题有一点点不同，会计处理方法的一部份表现为处理结果的一部份，即会计分录既体现了人的处理方法的一部份，又实在的反映了处理结果的一部份，也即人先告诉系统“这是一个某某类型事项”，然后告诉系统该类事项的处理方法，系统不就有针对于该类会计事项的处理“方法”了吗？这样讲，大家可能会误会我所讲的系统是否需要做很多的预定义工作。

在我们的设计中，系统具备自动学习的功能，它并不需要人事先定义这个事项怎么做那个事项怎么做，人要定义的是这种事项需要做什么类型的核算（往来核算？数量核算？计税计息或其它核算？），当人输入一个事项时，系统首先判断人告诉它的这个事项它会不会处理，如果它不懂如何处理，则自动跳到人工处理环境，当人处理的时候，系统自动在后台学习处理方法（规则），也即人做帐的同时就在定义会计事项的处理方法，人仅只感觉到自己在做手工帐而已，而当人下一次输入的事项被系统判断为已学习过处理方法的事项时，系统在人无任何感觉的情况下自动处理。

用武侠小说的语言来说，传统财务软件的模块设计相当于先想好对手出招时人会怎么挡（即会计事项发生时人会怎么做），再把人的可能的挡法都列出来归归类，然后按这些分类设计出一个个擂台，当人过招的时候计算机在一边仅仅只做记录的工作，并且还规定对手出招时若人用这种挡法就必须在这个擂台上挡，用那种挡法就必须在那个擂台上挡，否则就出示“请到那边擂台去挡”之类的“友好”对话框，如果对手出的招出新出奇，人准备用新招法回挡，计算机就只好告诉你：“我这里没有合适的擂台让你过招，所以我无法做记录”（简直不合逻辑），怎么办呢？找厂家呀，厂家会很热情的说：“我帮你定制一个擂台（模块）吧，不过不加钱总不行，这个需求以前你们又没提出过。”

我们提出的系统只给一个擂台，把对手在擂台上所有的行为归为“出招”（在帐务处理系统中称之为输单），计算机见招中的具体变化（单据信息）而拆招（即代人过招），计算机遇到没见过的、不会挡的招，自动让到一边，教练上来把招拆一遍，计算机看完学会，注意，只要有权限，出招人可以做教练，当然，教练教的是西洋拳，计算机学得就是洋套路，教练教的是散打，计算机学的就是散打套路，也就是说，系统绝不干涉人的工作意图，而是完全根据实际管理者的要求工作，如果教练不合格，也就别指望计算机会做得好，不过企业可以从系统记录中查得这个教练的水平，企业可以随时换教练（财务主管）或者请教练哦（请来的教练可以是财务代理机构、税务代理机构或是管理咨询机构，也就是说任何具体管理方案的提供者与实施者都可以成为该系统的合作伙伴）。

大家可以看出，这样的处理使得传统意义上的模块消失无踪，所有的帐务处理工作在一个工作环境中完成，人要做的工作是按原始单据输入（抄入）原始信息（注：符合做帐要求的原始信息事实上就已确定了一个事项的归类），定义该种事项应该采用的核算方法是什么（定义一次就够了），以后的工作中系统会根据“方法”自动进行帐务处理，比如有数量帐核算要求时自动请求输入数量明细（数量帐与金额帐是一体的，由此我们不必做任何其它工作就可以进行物品帐的帐龄分析，比如“A物品在途15天以内的有多少数量、金额；压库50天以上的有多少数量、金额”等，具体在以后相关的文章中再谈），有项目成本核算要求时自动请求输入记项明细（自底向上式，仅在试验系统中采用，新系统中取消了“项目核算要记项”的概念，项目核算将只是对原始信息进行的一种查询方案而已，具体见以后的相关文章），有往来核算要求时自动稽核往来帐（不再需要手工查找相关单据，系统会自动显示给你），有数量帐冲销要求时自动按物品的出库计价法冲销（可以为每一物品单独设置出库计价方法），即有什么工作需要系统就自动给出什么样的具体工作层面，没有要求时就不出现任何不相关的事物，可以称之为“单环境多层次按需动态配置工作环境”模式，这就是我们所倡导的智能核算的基本概念之一。

再来看看所谓的销售模块、采购模块或其它等等模块，传统财务软件在这里将工作流程与帐务处理混拼在了一起，用户在使用时毫无自由度可言，事实上类似的模块应该描述为“一个工作流包含了帐务处理模块”。

在我们的设计理念中，“工作流自定义”就是一个模块，企业可以自定义一个工作任务，在这个任务中要进行什么样的工作行为（即工作内容是什么），这些行为的先后（并列）次序是怎样的，相互的关联又是怎样（比如审核行为必须在输单行为之后，订单传入后自动发送到A、B、C部门等等）全部是可自定义的，并完全采用图形化拖放式操作，使用者不会感到自己在编程，而只是在画工作流程图，系统呈现的只是在这个基础上所预设的一个建议性的工作流程模板，并且是可更改的（我想有一定管理知识的人画个工作流程图总不是问题吧？！）。

大家可能感觉的到，在我们提出的系统中，模块真正代表了任务，既可以小到把一个按钮所起的功能称为一个模块，也可以把一个自定义的工作流称为一个模块，而“定义工作流”本身也是一个模块，其实用一句话就可理解：“任务可以包含子任务，子任务可以包含子子任务……”。

在这里，每一个按钮可以称之为局部相对的最底层功能模块，而所谓的“最底层模块”就是指管理上认为不需要或无法再细分的任务，事实上就是人的一个动作所表达的命令意义，这样，权限的设定可以针对任一包含或不包含子任务的任务，也就是从理论上讲，权限的控制可以细到规定一个人在某一工作环境（界面）中不能按什么钮的程度，想想看，是不是与SAP的某些地方有点象？不过SAP可没有自学习的功能哦，SAP在帐务处理上也是采用了预定义的工作方案（这样看来国内现行的一些财务软件不过是在抄洋人的东西，并且还抄的变了很大的样）。

暂先聊到这里，若大家有兴趣，我将在以后向大家逐步介绍我们对管理软件设计的思路及已经成功的与正在进行的研究内容。

本文由作者向AMT提供