本系列文章还包括:
jxTMS是SaaS模式,按笔者的构想,用户所使用到的软件应该包括如下几个部分:
-
平台软件,主要包括组织相关的基础管理功能,包括组织、人员、角色等相关的管理,还包括最最重要的一个功能:热机刷新,即在线动态加载组织代码等
-
基础软件,和平台软件一起包含在基本月租费中的通用软件包,目前是任务管理,未来可能包括基本的进销存、CRM、人事管理和财务管理等
-
第三方软件,由第三方软件商所开发的领域性软件,如ERP等
-
扩展服务,由平台或第三方所提供的服务性质的软件能力,如企业资格认证、档案、担保、风险预测、智慧办公室等等
-
用户定制的自用软件包,针对用户的业务需求而定制的应用模块
笔者打算着手逐步开发基础软件,任务管理已经有了雏形,所以打算再开发进销存。但真到动手的时候,整整一个多月都毫无进展,因为不同行业该如何通用?!如何取舍?!越想越糊涂,草图画了一张又一张,越看越不知道该如何权衡,太头疼了!!
穷则变,变则通。
最后还是要回到jxTMS在开发方面的基本定位:低成本快速定制的开发工具平台。既然各行各业的需求与业务特性千差万别,那何必强行统一到一套软件中来?!现在有ChatGPT了,以后打造一个模板库,根据用户需求按需剪裁一下不就好了。
所以,在低成本开发支持方面,jxTMS始终应该聚焦在工具化上。即借助进销存来看看jxTMS对复杂业务模块的开发需要提供什么样的支持,应该如何降低定制业务软件的成本和门槛。
因此,笔者再次审视之前所画的那些功能草图,结合之前利用jxTMS开发多个应用系统的得失总结,明确了需开发的两个面向复杂业务的工具:ER模型和业务过程。
因为经过反复的梳理与思考,笔者认为业务所导致的复杂度主要来自两个方面:
-
分工配合所导致的业务连贯性和各职能自身的特殊要求与效率之间的割裂与矛盾
-
业务所涉及到的各种数据类之间存在着复杂的连接关系
这两点,恰好一个是针对业务的逻辑复杂性、一个是针对业务的数据复杂性。
针对业务逻辑的复杂性,笔者开发了文本化定义的业务过程来描述、简化业务价值链各环节的衔接、表达与推动,将各专业的功能用业务过程串联起来。
针对业务数据的复杂性,实现了文本化定义的ER模型,其主要目的是:
-
将原本分散到各sql文件中,面向功能的sql查询进一步整合为面向业务的view【视图】,大幅度降低了编写复杂业务查询sql语句的难度和bug率
-
集成了数据字典能力,即业务语义和数据存储字段之间的自动翻译。开发者可直接使用语义别名执行存取操作,既降低了开发者自行翻译语义的繁琐、也大大降低了手工翻译所带来的bug率
后面几篇文章将逐一详细介绍这两个工具。
目前jxTMS已经开放个人注册试用,欢迎大家注册试用:
下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能:
下面的系列文章讲述了jxTMS的一些基本功能: