比较好用的低代码开发平台有宏天软件、宜搭、简道云等。
创新互联主营潜山网站建设的网络公司,主营网站建设方案,成都app开发,潜山h5重庆小程序开发搭建,潜山网站营销推广欢迎潜山等地区企业咨询
低代码开发平台的核心价值观是为了提高应用程序开发的效率，低代码开发平台主要的使用者是程序员，程序员通过使用低代码平台提高了工作效率减少了IT积压。开发系统的核心目的是为了提升效率，减轻人工的工作量。因此必然要处理很多复杂的业务逻辑。比如开发合同付款管理的时候肯定要计算已付款、未付款。开发物品瓴用的时候要扣除库存，这些都需要编写业务逻辑代码。成熟的低代码开发平台，应该提供完整的入口，让开发人员可以编写各种业务逻辑。低代码开发平台通过配置化的方式搭建系统原型，一边搭建一边运行看效果，根据效果逐步调整和完善。很快就可以搭建出系统原型。即使系统正式上线，也可以随时按照客户的需求，快速修改系统配置。
想了解更多关于低代码的相关信息，推荐咨询宏天软件。宏天软件经过13年的技术与项目积累，bpm相关功能已经非常完善，大型复杂的业务需求都有对应的配置项，且易操作，终端实施人员可以配置实现80%的应用与流程需求，少量企业个性化需求可以由开发人员在线集成开发快速实现，既满足企业低成本快速交付需求，又满足企业个性化需求。【欢迎点击咨询宏天软件！】
决胜工作流程管理
来源：全球业务网 作者：不详
BPM究竟如何变革企业的流程管理？小小的审批流程就能说明一切。
今年，我们的三大任务之一就是流程再造，要建成像海尔集团一样的流程。“吉利集团董事长李书福的决策代表了目前相当一批企业的意向。可现实往往事与愿违：”我们曾经把各个部门找来，谈流程怎么优化，可是各部门一见面就开始互相抱怨，根本谈不出来结果。”
“经过咨询公司的诊断之后，咨询顾问给我们留下了上百个流程，关于各项流程的操作手册几大麻袋都装不下，我们怎么去执行管理？”
“一个简单的书面单据审批却需要一两周……”
以上情景，经常在各家企业上演。这些问题或许跟一家企业的不良文化、管理不善直接相关，但问题的症结却往往出在流程。
BPM应运而生
海尔集团的张瑞敏曾总结，流程再造与企业文化是海尔集团的致胜法宝，其他诸如技术、市场、OEC（OverallEveryControlandClear，日清日高管理系统）等等只是这两个法宝的外延。海尔集团也曾宣称：“中国唯一一家当天付款的企业就是海尔集团”、“唯一一家从一个巨大的仓库演化成了一个高效准时（JustInTime）的仓库的企业也是海尔集团”。可惜的是，相当数量企业学习海尔集团的时候，太看重海尔集团的外延而不是关注其内涵。
不过，今天实施流程管理的企业似乎比海尔集团幸运多了，他们有了新的流程管理工具—BPM（BusinessProcessManagement，商业流程管理以下简称“BPM”）。
自1990年美国MIT的哈默（Hammer）教授提出BPR（BusinessProcessReengineering，商业流程再造，以下简称“BPR”）的概念以来，一直没有间断的实践和理论研究使人们意识到：流程管理不仅是“重组”大拐弯，流程的持续改进更关键，因此提出了阶段性重组BPR和持续改进流程相结合的做法，推出BPM流程管理系统。
“所谓的流程，简单地说，就是做事情的顺序。”作为BPM和工作流程自动化的领先企业，安码商务软件系统公司（Ultimus）提供的跨行业的BPM平台在全球拥有近1，000家成功用户，该公司亚太区副总裁奈德。史密斯（NedSmith）说道。
安码商务软件系统（上海）有限公司总裁崔志立进一步阐释：“其实流程管理理念暗含了一种思想：一家企业更像一个复杂的计算机系统，一种人造生命的整合形式。此种生命是靠数以千计的、由网络连接在一起的大脑来运转的。在这种情况下，一个流程设计就是一个运算法则，计算机就是公司，运作程序就是商业流程，操作系统就是组织的文化。”
而BPM系统就是将企业完成其业务获得利润的过程，如生产流程、业务流程、财务审批流程、质量控制等70%以上需要两人以上协作实施的任务全部或部分交由信息系统处理，并使其简单化、自动化的业务过程。
重塑流程举重若轻
上海施贵宝公司是著名制药企业百时美施贵宝公司（BSMSQUIBB）在中国建立的第一家中美合资制药企业，主要从事心血管、代谢和抗生素类药品的研制、生产和销售。而流程管理曾经一度使该公司副首席信息官（CIO）顾大为等感到束手无策。
以人事审批的“年假申请”为例，许多情况下，员工更愿意根据记忆请假，结果出现只剩余三天假期却请了五天假的情况；而部门主管在不知情的情况下，出现错批也就不足为怪了。
实施BPM系统后，员工在填写申请单时，HR部门的相关规定都能在界面上找到，不仅如此，系统还会自动提示剩余天数，如果员工的申请天数超过了范围，系统就会拒绝发送。而部门领导拿到员工的申请后，只需参考页面资料，而不必再向HR部门咨询。
同时，对于要求审批的申请，下一步应该提交给哪一位主管，该主管应该在什么期限内签署完毕，都非常清楚。涉及到财务审批的，每位主管都可以看到自己的审批额度，如果单据超过了该主管的额度，系统就会自动提示。
每位员工都可以实时看到自己递交申请的状态：到了哪个部门；审批意见是什么；还需要哪些人的签字，以及还需要多少时间最晚审批完毕。
“如此一来，就改变了以往公文经常丢失、不符合规范，超越权限审批等问题，同时缩短了公文流转的周期。”顾大为认为，目前的系统能够带来这些流程变化，是因为BPM系统的开放性很好地实现了与其他信息系统如企业资源计划（ERP）系统、财务系统等的整合，而不仅仅是将流程向自动化迁移。
沈剑军，梅特勒—托利多（常州）称重系统设备有限公司（以下简称“梅特勒—托利多公司”）管理信息部负责人。早在2002年，沈剑军领导的IT部门就曾对公司业务部门进行过业务调研，跟踪了一批具有代表意义的手工纸张单据的审批流程，结果发现一张单据的平均审批时间约为五个工作日左右，如此漫长的审批过程，不仅业务部门难以忍受，公司领导层也对繁复的审批流程头痛不已。
实施BPM系统之后，公司原先审批流程的周期从五个工作日缩短到了两个工作日；异地审批的效率和精确程度反而比以前本地审批还要高。这让沈剑军深为自豪。
除了审批流程，上海施贵宝公司还重新设计并上线了采购、财务报销等多个流程；而沈剑军带领的梅特勒—托利多公司IT团队，还对零星物流采购料、物料清单（BOM）更改流程、固定资产申请审批和固定资产报废申请审批流程和突发性项目审批流程四大流程进行了实施。
其中，突发性项目，也即“预算之外的预算”的审批，普遍令企业的首席财务官（CFO）感到棘手。梅特勒—托利多公司对此做出了一些调整。在实施BPM系统之前，对突发性项目预算的处理基本有两种方式，一是把项目A的预算临时挪借给突发性项目B；二是特事特办，越过公司的财务部门，直接找总经理特批。现在，BPM系统配合公司的财务系统，设计了突发性项目审批流程，并在系统中得以实现，这样既保证了业务的灵活性，又保证了操作突发性项目的规范性。
据称，梅特勒—托利多公司的全球首席执行官（CEO）曾经对这个项目大为赞赏，在集团内部的一次会议上，他专门介绍了公司的BPM项目，引起了梅特勒—托利多集团其他国家分支机构的浓厚兴趣，不久，梅特勒—托利多集团的日本分支机构上马了安码商务软件系统公司的BPMSuite系统。
强调技术，少走弯路
“BPM代表了一种重要的技术转变。”中美施贵宝公司副CIO顾大为对此深有体会，以往流程技术提供的自动化程度都是有限的，因为它们无法把异构的系统连接起来或是执行以人为中心的合作活动，这使得许多工作还需要通过手工来操作。
在流程软件的使用上，中美施贵宝公司曾经走过弯路。
“主要的问题出在流程的再开发、跟踪以及系统的开放性上。”顾大为说。中美施贵宝后来不得不报废原先几百万元的投入，重新进行BPM系统的选型。
据安码系统公司亚太区副总裁奈德。史密斯透露，BPM系统的基础是开放性的流程，这些流程能够在图形界面中组合成更大的流程。这些更大的流程内的数据流通过Java开放来展现。同时，流程具有独立性和可存取性，以及XML创建半结构化数据的能力，可以轻松存取工具软件，并享受E-mail和办公软件的强大功能和灵活性。
尽管上马BPM系统的一次性投入成本并不低，但中美施贵宝公司和梅特勒—托利多公司的信息技术部门目前都已掌握开发实施的方法，能够结合公司新出现的流程，自行开发相应的应用。
“不过，对于尚未实施BPM系统和已实施BPM系统却找不到头绪的企业而言，并不是直接从‘咨询顾问手中接过100多个流程，然后让100多个流程演变成更多流程’。”新华信管理顾问有限公司信息化咨询中心总经理李彤建议，“20%的流程往往决定了企业80%的整体绩效。企业应该找出决定整体命运的关键流程，然后进行贯彻实施。”
“所谓流程，就是做事情的顺序。”奈德。史密斯说。
看我，我是官方，一些基本情况可能用户都说了，这里贴点资料，为网上用户放出来，欢迎@一起补充，关于力软部分基本差不多，迪西客部分请自行判断，不过要使用此类框架需要看公司具体情况，这里仅比较.net.部分。
浏览器兼容性
力软
支持各种主流浏览器，包含IE（微软)、Chrome（谷歌）、Safari（苹果）、Firefox（火狐）、Opera、360、遨游、猎豹等。
迪西客
支持IE8及以上、chrome(谷歌)、Firefox（火狐）、Safari（苹果）、360等主流浏览器。
平台技术
力软
基于ASP.NET MVC技术开发，具有分层逻辑，并且代码编写规范。该框架稳定、高效、成熟，能够保障后期开发系统的稳定性、安全性及良好的性能。
迪西客
基于.NET技术构建，应用MVC设计模式，采用基于浏览器的三层结构(B/A/S)，结合最前端技术HTML+jquery+ajax+json+webservice，为平台的拓展和发展提供了良好的基础和前景。
数据库支持
力软
框架支持Sqlserver、Mysql、Oracle等多种数据库（多个版本）。在同一系统中可同时连接多个数据库、多个数据库可以是不同类型的数据库。
迪西客
低版本的框架只支持Sqlserver，高版本的框架还支持Mysql和Oracle。
支持的设备类型
力软
支持电脑、平板、手机、智能硬件等多种设备。手机支持IOS、Android、支持微信企业号。
迪西客
支持电脑、平板、手机、智能硬件等多种设备。手机支持IOS、Android、支持微信企业号。
可开发的系统类型
力软
可以开发OA、ERP、BPM、CRM、WMS、TMS、MIS、BI、电商平台后台、 物流管理系统、快递管理系统、教务管理系统等各类管理软件。
迪西客
可以开发ERP、OA、CRM、HRM、销售管理系统、资产管理系统等。并有部分价格版本的产品提供部分系统的开发模板。
权限管理
力软
独立的权限管理体系，多套系统可以统一管理权限。集合了组织机构、岗位、职位的权限管理（含盖各个功能模块），提供多种授权模方式；可对功能权限、数据权限、登陆IP及登陆时间进行管控；注重权限安全，拒绝一切非法访问。
迪西客
包括网页权限、应用权限、组件权限、流程权限、列表权限、表单的权限设置、搜索时的权限设置和树模块的权限设置。
主要应用组件
力软
组织架构、权限管理、工作流、自定义报表、快速开发、APP开发、微信组件、即时通讯、访问过滤、单点登录、导入与导出、自定义表单设计、报表图标分析、缓存集群、APP开发。
迪西客
工作流、表单设计、自定义报表、自定义图表分析、列表设计器、“树”设计器、搜索设计器、网页样板、导入与导出、权限设置、APP开发、微信组件。
开源程度
力软
全开源、全源码。
迪西客
最高价格版本有全部源码。
（低价格A方案部分运行源码。
中间价位B方案100%运行源码，无开发源码。
最高价格版本C方案，100%的运行源码和开发源码。）
授权体系
力软
完善的授权体系，购买签订合同后，进行框架所有源码的授权，并且一次授权终身使有效，不会有后期的收费。开发的系统如需出售，无需再次授权。并且不限用户数。
迪西客
所有价格方案都是运行端源码不限授权，可以多次开发，不需要支付额外费用。不限用户数。最高价格版本有开发源码。
免费售后服务
力软
协助安装、指导使用，提供一定期限内免费（视具体版本）的技术培训、版本升级、技术支持服务。
迪西客
提供一年内的协助安装和BUG修正、使用咨询，不提供一定期限内的免费技术培训、版本升级和技术支持服务。
界面UI
力软
前端UI基于Jquery +Bootstrap（后期会改成vue），界面简洁大气，UI底层库提供了大量UI组件开发者轻松就能完成各种炫丽界面的设计。不像EXT、EasyUI那样外观千篇一律，另外也省去了UI的授权费用，因为EXT、EasyUI都需要收费的。多套风格UI可选。
迪西客
dcxCreator全面采用潮流的网页设计理念和技术，时刻关注和参考流行前线的互联网产品体验，简单、漂亮是dcxCreator区别于同行产品的明显特征。
可扩展性及个性化
力软
提供所有源码，可扩展性强，可个性化定制。
迪西客
源码封装深，大部分版本只提供运行端源码，可扩展性一般，个性化开发难度较高。
开发难度
力软
全源码，有技术支持服务，开发过程中遇到的困难基本可以得到解决。
迪西客
简单系统的开发较为便捷。但进行深层次开发时，因为大部分版本只有运行端源码，且封装的很深，技术支持服务不到位，很难自己独立完成开发。但有部分价格方案有部分系统开发模板提供。
后期收费情况
力软
售后服务（超过服务期后）：合同总额的20%/年
上门服务：3000元/天,上门服务所涉及的差旅费由客户方承担。
其余无其他收费情况。
迪西客
远程培训：3000元/时
技术支持：15000元/月或80000元/年
升级服务：1000元/次
API文档：1500元/份
系统迁移协助：2000元/套/次
系统集成：视情况定价
售后服务（超过服务期后）：8800至30000元/年
主要适用客户
力软
开发人员为有一定基础的开发人员和高技术人员的公司，如：中小型软件开发公司、非软件公司的软件部门、需信息化建设的企业。
（力软的敏捷开发框架整合了大量的功能组件和现有的业务逻辑，能够让开发者只注重于功能的实现，而不用浪费时间去进行架构。很大程度上减少了开发的代码量，这使得刚入门的开发者也能进行系统的开发。同时，开源的系统能够自动生成代码，能够让一些资深开发人员进行更深层的扩展和个性化的定制。）
迪西客
对所需开发系统个性化要求不高、且开发能力较差的公司。对开发人员的要求非常低，只需逻辑清晰的项目负责人或其他无基础的人员就能进行开发。但难以进行个性化定制和系统的扩展。
（迪西客大部分产品只提供运行端源码，开发人员接触不到代码，所以开发难度比较低。但是要进行系统的扩展和定制化的时候，开发难度就大大提高了。）
价格透明程度
力软
价格透明度高，不会出现价格虚报的情况。偶尔有优惠活动。
迪西客
价格透明度高，不会出现价格虚报的情况。偶尔有优惠活动。
BPM是一种管理思维，所以软件是其落地方式。
“浏览器式”BPM并不陌生
其实有很多本地软件都已经采用的“浏览器访问”的方式，也就是说很多软件，即使是装在本地计算机中，也可以通过浏览器访问，如微软的MS Dynamics CRM。
“SAAS”BPM特点
最开始的SAAS BPM都是伪SAAS，通过包装本地软件，只是通过云端浏览器运行，并没有完全发挥出SAAS产品的优势。
轻流BPM
轻流的BPM流程引擎是完全基于云端进行自主设计的，基于云端进行了优化，并提升了速度。可以支持电脑、微信、小程序、企业微信、钉钉都能够使用，可以通过浏览器访问网址进行使用。开发方式基本上都是基于云端的一些框架、语言进行开发的。可以来看看：点击进入轻流主页
流程管理：OA或BPM
一、OA难以胜任统一流程中心建设
企业各系统中都存在流程，未来企业需要将各系统流程抽取到统一的流程平台，实现流程中心建设，这需要流程平台极强的整合能力，OA流程管理更侧重于行政流程，集成能力有限，难以胜任企业统一流程中心建设。
二、OA难以担当流程战略支撑平台
流程建设是循序渐进的过程，只要公司存在，流程的需求就会不断拓展与深化，对流程平台的要求会越来越高，OA流程平台的弱点会逐步显现，只有专业的流程平台才能满足日益增长的流程管理需求，持续实现企业流程管理战略目标。
三、OA实现流程管理的战略风险
1、潜在风险
OA实现流程管理，随着应用的深入，OA在流程管理上力不从心将逐渐显现，越来越难以满足企业流程管理需求。当企业认识到OA流程的不足，不得不迁移到新的专业流程平台时，以前在OA流程建设中花费的大量人力、财力、物力都前功尽弃，形成IT系统的重复建设和巨大浪费。
2、业务重点调整风险
OA公司的业务重点一直在调整，当下流程比较热门，所以在流程系统建设中投入了一定的资源，未来随着业务重点的调整，在流程建设上投入多大的人力、物力都难以保障，当业务重点发生变更时，流程系统的持续性与生命力将承受巨大的风险与挑战，难以保障客户在流程系统建设中的投资。
随着微信、钉钉的加入，协同软件的市场格局日益复杂，竞争日益白热化，OA首当其冲，面临来自强大竞争对手的压力，这是一场生死攸关的赛跑，OA企业不得不将更多精力、更优质的资源投入到策略层面的竞争中来，能在流程管理中投入的资源数量与人员质量有限，对流程系统的改进与完善不利。
四、企业信息系统合理架构
五、专业BPM厂商，完整BPM产品线
六、BPM租用模式，减少初期投资——480元/月起
七、他们已纷纷将OA流程迁移到专业BPM系统
FlowPortal BPM 帮助千万企业实现卓越流程管理
BPMN（业务流程管理）是一种用于捕获、设计、执行、记录、测量、监控和控制自动化以及非自动化流程，以满足公司的目标和业务策略的系统方法。
通过BPMN，流程可以与业务战略保持一致，藉由业务部门内部甚至超越公司边界的流程优化，有助于提高公司的运转效率。
BPMN在国内的应用很广泛，但很多企业花费大价钱购买了第三方的流程平台，却没有得到相应的收益；我认为其根本原因还是在于对BPMN本身的理解不足——它远没有看上去那么简单，仅仅是BPMN2.0版本规范文档就已经达到了500页。
因此，在我看来，要想顺利的实施BPMN，一个对它有透彻理解的设计者是必不可少的；同时，设计者还需要兼具业务思维、管理思维，和一定的技术思维。
本文以一个物业维修流程为例，目的在于介绍一个系统的BPMN建模方法，为刚刚踏入这个领域的人提供一个方向和选择。
这是一个典型的物业维修流程，这个流程提供的信息量很少，以至于如果我们要仅仅基于此去设计一个完善的BPMN流程是几乎不可能的，但是即便是最专业的物业管理师，这也是他们仅能提供的流程图了.
为了达到我们的目标，我们需要先建立一个战略层面上的流程，它可能很粗糙，但是它的目的并不是在初期就呈现一个完整详细的视图.
它的作用可能有如下几点:
1.澄清什么是，和什么不是这个流程的一部分
2.为流程确定资源和分配责任
3.确定关键绩效指标并明确其特征
4.在对流程着手优化前先对其进行一个大致的回顾
体积：战略流程模型应当尽可能小，流元素最好不要超过10个，如果一个流程横跨几张纸的话，是没人能理解得了的.
语法：尽可能正确，但是在必要时可以不那么严谨
想要对一个流程进行初步建模，往往比想象的要难得多，有时手头有充足的资料和标准的操作流程可以用，那会好些，但大多数时候都不得不去与客户深入交流.
当产品去和客户开会沟通时，我能很容易的想象到下面的景象——当你只画了一个圈两个矩形：
客户参会人员：
我们的维修流程并不总是这样从业主填写维修单开始的，业主也可能是电话报修
如果维修的工程量比较大的话，我们还得先提出方案，然后交给公司领导审批
如果过了保修期的话，那我们还要收钱的
业主如果是预约的话，我们还得根据他预约时间安排工作
并不一定是业主报修，也可能是在物业巡检的时候发现问题，由巡检员报修
..........
..........
..........
如果没有一个狠人来主持会议的话，产品会很容易迷失方向，也会导致客户的参会人员对你的方案失去兴趣，更差的情况是，其他人糊里糊涂地对一个错误的模型达成了一致.
所以主持会议的人，需要在开始的时候先声明好：所有的流程模型都是不完整的，但是它依然有一些作用.
在一开始找出每一种可能性是不可能的，在这次会议开始前，就应当告诉客户，这第一次的迭代目标是什么.
1.我们要记录流程从开始到结束的过程
2.我们最多只记录这个流程的N个步骤
3.我们只记录这个流程的标准形式
如果会议期间仍有人想跳出圈定的范围，应当立刻阻止.
下面回到正题——物业维修流程.
基于上面的传统流程图，我们可以得到以下信息：
1.这个流程往往是由业主有维修需求引起
2.发起人填写一个维修单，发单部门（也就是行政部）将维修单提交到客户服务中心，客户服务中心的经办人填写工程单汇总表，然后把维修任务下发到维保部门，主任分配工作给维修工，维修工执行任务，并会同发单部门验收以确认维修完成.
3.当维修完成的时候，这个流程也就结束了.
基于关键信息，我们可以构建如下的流程图，这里我们出于BPM原则，要先把结束事件放在需求方的泳道上.
尽管这个模型有很多问题，但是这个阶段我们要确保客户能毫不费力的理解它，因此做到这样就可以了.
接下来，我们可以开始逐步的纠正这个错误的模型了.
首先是泳池和泳道，根据BPMN的规范要求，每个流程都应当有一个最高的统筹者（这个请自行查阅BPMN规范），负责协调流程中的参与人和系统，但这个流程不是由流程引擎控制的（它是由发起人控制的），因此它目前不存在这么一个协调者，当业主报修时候，无法路由到下一个活动 (如果把分配到下一节点的受让人当成一种路由方式的话，那么这时候其实是流程引擎在当协调者).因此这边应该建模成消息流，另外，应当把业主分配到另一个池里.
我们建模越详细，发现的问题也随之增加，比如，业主如果中途不想维修了，在这个模型下流程是无法"正常"地结束的 ，如果需要满足这个业务需求又不希望通过技术手段生硬的结束，那么就会需要用到边界事件；另外，如果维修工需要用到一些材料的话，他该怎么办，是否需要申请，又向谁申请？
对于战略模型，为了尽可能简单，通常不会使用多个池，除非是像上面这种业主是独立于物业公司之外的情况，可是由于我们的关注点依然应当集中在物业公司的内部流程上，因此接下来讲业主的池进行折叠.
任务经常出现在战略流程模型中，但是子流程很少出现. 在战略流程模型中不会去指定任务的类型，也不使用除了循环之外的标记，因为循环相对来说很容易理解.
子流程应该细化流程模型，在维修流程模型中，我们定义的这些任务，背后可能并不简单，他们可能对应着非常复杂的操作。 但是对于发单人填写登记表这类任务，从我们得到的信息来看，只管填就行了，所以我们就还是把它们当做任务. 基于这些考虑，我们可以得到下面的模型.
我们只是对于可能存在复杂逻辑的任务做一个子任务标记，就足够了.
上面给出的模型，只是基于最常见的情况，对于一些确实有必要做分支的情况，我们就需要用网关来对这类情况进行建模，但一般来说不会在战略流程模型中引入网关.
在战略流程模型中使用的事件类型是有限制的:
空类型可以用在开始，中间，结束事件上，中间事件可以记录流程执行过程中的某个状态，客户也很容易理解.
消息类型和定时类型可以被允许作为开始事件和中间事件使用，因为它们的符号一看就能看懂，很容易理解.
至此战略流程模型就可以结束了。
在操作流程模型中，就可以开始呈现出流程关于人和技术的细节了，这里会涉及到一些问题：
1.对于流程设计者：工作是如何完成的?
2.流程开发人员：需要通过流程引擎来实现什么功能？
3.流程参与人员：该怎么完成自己的工作？
要调和这三个角色并不简单，而这也正是操作流程模型需要做的事情，如果很好的回答了这三个问题，那么就可以得到以下好处：
1.操作流程模型的逻辑，在实际操作和技术实现上是一致的.
2.缩小了业务和技术之间的理解沟通的沟壑，双方以流程模型作为共同语言.
3.藉由流程引擎实现的流程，更易于观测.
在这个层面上的模型，就不像战略流程模型能容忍一些语法上的错误了，我们必须按照规范来进行建模.
除了规范之外，必须实现的还有精确性，因为客户需要根据这个流程模型安排工作，同时，我们也应当尽可能的不让这个流程显得过于复杂，毕竟流程参与者关注的是他们的工作本身而不是BPM，流程对于他们只是一种达到目的的手段.
之前有说到，操作流程模型应当足够精确但又不过于复杂，这听起来可能很矛盾. 为此，我们先作一张表格，来看看操作流程模型在三个角色中的视图是怎样的. 流程参与者只需要关注自己需要怎么做，以及什么时候需要等待其他人完成什么，这样就不会被其他人所做的细节分散掉注意力.
操作层面的流程模型的核心思想，在于区分编排和协作，如之前所讲，每个流程参与者都有自己的一个池.
把流程引擎作为一个单独的池，可以让流程开发者更好的关注它.
流程设计者的角色在这边非常重要，需要非常懂BPMN，并且能够从不同参与者的视角对流程进行建模.
设计者的工序可能如下：
1.审查战略流程模型
2.分割泳道到单独的池
3.在不同参与者的视角下进行建模
4.为技术层面的建模做准备
5.进行技术层面的建模，不一定可执行，目的在于细化模型
6.加上必要的注释
当然这也只是一种经验方法而已，你也可以直接在技术层面开始分析和建模，自下而上.
继续我们的物业维修流程例子，为了简化对于每个流程参与者的模型复杂性，我们需要将物业公司下面的三个参与者泳道都分割到单独的池中，同时，我们也要解决一些显而易见的逻辑上的错误，比如:
1.验收没有联合业主一起
2.省略了仓管这一参与者
3.省略了客服专员的每周汇总和进度督促.
4.业主报修的时候更多是电话申报
这里最大的难点在于，由于存在代发起的情况，我们很难把业主的池和接线员的池完全隔离开，虽然在流程引擎的层面上可以用两个流程变量来解决问题（发起人，拥有人），但是在模型展示的层面上这种办法是没法很好的表达出意思的，而且也会增加开发的工作量，因此我们可以采用多个开始事件的形式，来对这一情况进行建模.
这就是将流程参与者分割到单独的池后的模型图，这里依然存在一些问题，比如我们还没有对维修项目做分级，验收未通过的话怎么调整参数等等，但这一步我们也只是澄清各个流程参与者之间的关系，没必要过于深究.
从这一步开始，往往就需要与流程参与人员进行更详细的交流了.
从业主开始，我们可以看到业主相关的参与者有接线员，行政部门和机电维修部门，此时我们可以把这两者的池进行折叠.
根据我们已知的业务场景：
如果业主申报的维修项目是有偿服务，需要由客服与其进行再次确认
如果涉及付费服务，业主需要有一个付款的操作
在更深一步的考虑之后，我们发现业主池还会涉及到客服部门，最终我们得到如下模型.
行政部门的流程比较简单，涉及到的其他池有业主和客户服务中心:
客户服务中心这边应当注意，在客户给出的传统流程图中，有提到定时性质的统计和催促的任务，这种情况我们应当将它作为另一个单独的流程模型，与当前的维修流程模型区分开来.
通过调研可以发现，客户服务中心这边往往在完成物业服务之后还会有一次回访调研的过程，因此在维修结束，确认业主验收完成后，我们也应当加上回访的过程，但是回访并不存在于某个特定的流程中，因此我们在此处暂时省略，后续作为一个独立的流程进行建模.
另外，客户服务中心还需要在派单之前与业主进行事前沟通，需要有一定的规则来给维修事项进行分级：
1.是小修，中修，还是大修？
2.是否需要收费？
经过调研我们可以了解到:
三种类型的维修都有可能会需要收费
中修和大修往往还需要经过额外的审批流程才能继续.
我把维修项目评估任务放在了这里，是因为客服联系业主之前需要知道维修的价格以及其他情况.
机电维修部这边应当考虑以下因素：
主管分配工作的细节
1.是否应当记录返工次数？
2.区分不同级别的维修项目
主管分配工作这个任务的前置条件是收到维修需求，确切的说，是收到由客户服务中心填写的工程单汇总表，当前表中已存在的属性可能有客户的姓名，维修地址，联系电话，维修内容，预约时间等.
主管此时需要根据已知的情况，判断当前的维修方案是否需要走额外的审批流程， 而这个流程，应当与当前的维修流程独立开来. 至于这个额外的流程有着怎么样的过程，目前我无法得知，因此依然用一个子流程来代替.
仓管这边需要考虑验收没有通过的情况下，流程如何进行？ 这里的验收事实上应当是物料仓库的验收，与维修流程无关，但是客户往往无法清晰的表达出来这层意思. 因此这边应当暂时省略验收这个步骤， 作为一个独立的物料仓检流程在下一步的时候进行建模.
最后是接线员，接线员的流程比较简单，接到电话报修后填写维修单就可以:
之前都是讲的人与人之间的流程，从这步开始引入流程引擎，原因之前也提及过，开发者需要知道他们要用流程引擎来做些什么事情，因此这个步骤也会添加包括技术实现上的更多细节，比如对于业主是否已经付款的校验.，但第一版的技术流程模型 不一定是可执行的 .
第一版的技术流程模型如下：
再接下来的设计，就需要考虑更多外部因素了，如果我们发现维修流程中，某个泳道的流程能够被其他的流程模型复用，我们就需要将他们抽离并单独部署，如果我们满足于将这个庞大的维修流程进行单独部署，那我们可能还需要再做更多的修改，尤其是事件类型上（消息事件的用法在这里是违反BPMN规范的，如果部署在同一个流程定义中的话，更适合的是条件事件），情况不同，我们后续的设计和实现也会非常不一样.
对于当前这个维修流程，我更倾向于将所有流程都分开设计和实现，主要理由有如下几点：
1.一个庞大的模型，它的版本迁移过程往往非常复杂，如果将它进行恰当的分解，那么我们只需要对发生了变动的部分进行迁移即可，可以有效的降低迁移成本
2.对于开发者来说，庞大的或者过于复杂的模型会导致理解和开发成本迅速上升，而且一个单体模型，几乎只能由一个开发者来负责，不适合多人协作，而分解的手段可以将一个单体复杂模型分解成多个简单、可独立开发的流程模型，可以提升开发效率和降低理解难度.
3.对于企业工作流来说，多个工作流之间经常会存在共通的部分，就像这里的物业服务的回访流程，将这些公共部分剥离出来，长远来看，可以提升模型的复用率，从而提升开发效率.
但是这种方案的缺点也是显而易见的，主要有:
1.分解到什么程度并不那么容易把握，虽然按照经验来说往往是分解到每一个流程参与者，但在有些时候也可以将一些任务比较简单的参与者流程进行合并.
2.为了实现流程实例之间的通信，往往会存在较多的消息/信号事件或者调用活动，要求开发者对BPMN中的事件有足够的了解
3.流程走向的观测可能会比较繁琐，因为需要在多个流程实例之间来回切换观察
下面给出第一版的技术流程实现，它依然还有很多值得改进的地方，比如支付流程的分离和异常处理，维修主管分配任务的自动化规则，接线员流程的规则化（使用规则任务来根据输入参数判断该发送什么类型的消息事件，可能是代填维修单，也可能是代填其他的表单），但出于成本考虑我们不可能就第一版的实现去无止尽的细化：
