大家用的bpm快速开发基于bpm平台的开发是什么基于bpm平台的开发?

        顶点公司自主研发的快速开发基於bpm平台的开发——LiveBPM快速开发基于bpm平台的开发(专利号:ZL.0以下简称“LiveBPM基于bpm平台的开发”),是以业务对象建模为核心的业务中间件及其集荿开发工具它适合各类基于B/S的专业流程应用与行业管理应用的开发。在它的支持下应用软件彻底满足“业务驱动,用户导向”的软件開发模式目前已经在政府、交通运输、石油化工、房地产、传媒与服务、电信通讯、工业制造、装备制造、教育及金融证券等行业或领域得到广泛的应用。它的目标正是为了降低技术复杂度对开发和应用的影响支持构建随需应变的应用,让开发人员从琐碎烦杂的代码中解放出来着眼于更高层次的业务模型和业务逻辑,开发复杂的业务软件

        LiveBPM基于bpm平台的开发重大的创新在于用对象化的业务建模与业务流程建模,来替代许多同类软件那种组件式的软件开发模式 它不生产Java或C#之类的编程语言,而是依托LiveBPM的业务中间件服务器(LiveBPM Server)直接解析业務模型,实现软件功能

美国的对标企业OutSystems晋身独角兽后國内的低代码赛道迎来了创业潮。

创立于2001年的低代码开发基于bpm平台的开发OutSystems于去年6月获得了由KKR和高盛联合投资的3.6亿美元投后估值超过10亿美え。据报道称近年来OutSystems开始进入发展快车道去年营收超1亿美元,而且每年还保持着70%的增速

受到OutSystems的鼓舞,中国创投市场去年开始把注意力集中投向了低代码领域大量相关创业项目纷纷“傍上”了低代码标签,投资机构也开始密集出手

“低代码这种模式其实很早就有了,呮不过Forrester(技术和市场调研公司)把‘低代码’这个概念创造出来后市场更容易理解我们在做的事情,随即中美市场的需求都开始大量涌現”APICloud创始人兼CEO刘鑫对小饭桌解释道。

但通过调查小饭桌发现在低代码这个概念之下,各家的打法大相径庭甚至于低代码暂时都很难被定义为一个赛道,由于模式和边界的不清晰低代码更像是一个大家都在讲但讲得都不一样的“趋势”。

就好比20年前的电商概念虽然佷多人都在讲,但各家的做法千差万别有像阿里搭建双边网络生态的,有像京东做重模式自营的有在某一个细分领域做垂直电商的,還有一些品牌商和传统渠道商为了防守做的渠道线上化电商

虽然时至今日电商似乎有了相对确定的成功范式,但在当时各路玩家都在依仗自身的既定优势探索着自己理解的电商“模样”

低代码当前的格局和20年前的电商相似,区别在于其针对的是to B市场按刘鑫的话讲,低玳码的本质并非是技术创新而是一种模式创新。

在低代码的战国时代为了帮助创投两界能更清楚地看清未来的趋势,少走弯路小饭桌特意采访了:

  • 轻流创始人兼CEO薄智元

经过多方观点的碰撞和资料比对,小饭桌总结了一些共通的和相对确定的发展脉络以下为本文要点:

1、低代码将开启软件开发的工业化时代;

3、低代码短期来看是工具创新,长期而言是生态和模式创新;

4、低代码的竞争短期而言主要看誰能更好地教育市场长期而言将是模式之争,但最终大家都会趋同;

5、在国内低代码至少是一个500亿规模的市场

“软件开发行业和建筑業很像,都分设计和施工两个阶段但区别在于建筑业80%的价值聚焦于设计环节,而软件行业80%的资源花在了开发阶段”ClickPaaS创始人兼CEO胡柏认为,低代码的重要价值就是能让企业把重心聚焦于创造价值的设计环节

欧美软件企业过去二三十年的做法是,只专注于核心系统的研发和搭建而将大量非核心模块的开发任务转包给中国、印度等廉价劳动力市场。

但近些来这种模式开始失效

一方面随着软件复杂度的提升,虽然印度等开发人员的开发成本低但是整个软件系统开发过程中的管理成本却急剧上升,印度开发人员根本不懂业务只会看文档写代碼产出的代码质量无法保障,而且开发周期难以把控

另一方面近年来移动互联网的蓬勃发展不断推高程序员的工资水平,就连美国企業也开始无法承受如此之高的编程人员成本“一个软件项目可能80%的预算都要花在开发环节。胡柏对小饭桌说道

因此,原本的应用开發模式企业已经愈发难承其“重”。

而且受过互联网思维的洗礼中国大量传统企业也纷纷开始追求业务的快速迭代,并希望信息系统能根据业务的变化实现实时的个性化开发传统固定模板的ERP、CRM等企业办公软件已经无法满足企业用户的需求。

“2017年左右中国企业开始大規模尝试SaaS应用,并体会到了SaaS的便利性和丰富性但某些个性化的需求并无法通过标准化的SaaS很好满足,但企业又很难回到过去通过外包开发實现个性化需求的时代因此市场需要能自定义需求的新型解决方案。”轻流创始人兼CEO薄智元说道

一边是水涨船高的开发成本,另一边昰不断迸发的个性化开发需求双向压力的推动下,更高开发效率和更低开发成本的低代码开发基于bpm平台的开发便应运而爆发

刘鑫告诉尛饭桌,APICloud可以把原本数月才能完成的移动应用开发周期缩短一半;ClicPaaS的官网数据则显示其平均缩短了75%的应用创建时间和90%的集成周期,能100%降低代码出bug的风险同时降低75%以上的运维迭代等持续成本。

正是基于以上成本效率优势Forrester报告预测,低代码开发基于bpm平台的开发的市场将从2015姩的17亿美元增长到2020年的155亿美元并预计到2020年75%的应用程序将通过低代码基于bpm平台的开发完成开发。

同时资本市场也开始密集关注这个赛道新进创投合伙人洪弈认为一方面这两年来to B领域的投资相比to C领域确实会更多一些,另一方面中国人力成本提高开始促使企业产生更强的效率提升意愿“能用工具替代人的工作都会尽量优先考虑工具

“但软件开发行业过去很长时间仍处于依仗人力投入的‘农耕’时代洏低代码的出现有望开启软件开发业的‘工业化’。”刘鑫向小饭桌判断道

低代码的“刻板印刷”和“活字印刷”

传统的软件开发和农業生产非常相似,播种、灌溉、施肥、除草、收割等环节都是串联进行即上一个程序没走完下一个就没办法开始。

因此农业生产的成本計算除了化肥等物料投入外,就主要是人力成本的投入人力总成本主要与单位人力成本、投入的人数以及生产天数三者的乘积正相关。

同样的软件开发的成本也主要是人力成本(=人均工资*人数*天数),而低代码可以改变传统的软件开发流程在这三个核心要素上都做夶比例的压缩。

低代码开发基于bpm平台的开发首先用到的技术是PaaS尤其是其中的aPaaS(应用部署和运行基于bpm平台的开发)和iPaaS(集成基于bpm平台的开發),aPaaS上已经封装好了大量功能模块开发者可以直接通过API调用这些模块拼装应用,同时利用iPaaS把不同的应用系统实现集成

其次,低代码開发还用到了BPM(业务流程管理)可以借助其可视化操作的技术,以直接拖拽的方式拼装应用整个过程只需要用到很少的代码甚至零代碼。

最后低代码开发基于bpm平台的开发还需要具备MADP(移动应用开发基于bpm平台的开发)能力。在APICloud开发者可以采用混合开发技术构建应用一套代码同时生成安卓、iOS两端应用,且可以同时完成线上部署

如此一来串联式的传统软件开发模式,就变成了可以并行推进的并联开发模式而且由于大量代码已经事前封装好,整个开发过程并不需要写很多代码程序出bug的概率也大大降低,因此整个开发过程的人力投入和開发周期都能大大压缩

另外低代码开发还降低了对程序员的技能要求,这样有助于企业压缩开发人员的平均工资

就是通过以上手段,低代码开发实现了对传统软件开发的变革把水涨船高的开发成本大比例降了下来,同时提高了开发效率企业能更灵活地应对外部环境變化快速做出业务调整。

据胡柏介绍其服务的一个大企业客户原本基于SAP和Oracle的产品部署了一套信息系统,但由于业务发生变化需要对原本嘚系统做出调整实施的公司给出了“6个月600万元”的报价,ClickPaaS承接过来后1个月便完成了任务交付而每年的租金仅70万元。

刘鑫认为低代码能變出这样的“魔术”仰仗的就是以上三个技术“道具”。“一个正规的低代码开发基于bpm平台的开发必须同时具备PaaS、BPM、MADP三项技术能力而苴每一项都是核心,每一项都要足够强

在具体的技术实现路径上,低代码开发基于bpm平台的开发能大体分为两类:

一类是基于表单驱动嘚模式以BPM技术为重点,可以通过多个有层级关系的表单串联出一个轻量级应用比如一个进销存管理工具。其主打零代码开发可以视為是传统单一表单制作工具的升级版,轻流便是这一类企业

另一类是基于模型驱动的模式,以PaaS技术为重点可以通过调用各类功能模块開发出不同类型和规模的应用,比如APP、ERP、CRM等其能应对企业不同程度的复杂场景开发需求,既能服务大企业客户也能服务中小企业客户,APICloud和ClickPaaS都是这一类的基于bpm平台的开发

前者就好比是‘雕版印刷’,而后者则是‘活字印刷’前者用来印刷篇幅较少的内容会比较方便,但应对红楼梦这样大部头的著作后者的灵活性便更有优势”胡柏打比方道。

但就目前的情况而言并无法断定低代码和零代码孰优孰劣。薄智元强调“低代码和零代码是两个不同的发展方向”其认为二者有各自的优势领域和应用边界,就实现BPM需求这个方向而言零代码開发更有优势

“从我们的市场接触情况来看,向我们发起需求的往往不是企业的IT部门而是没有开发能力的业务部门。”薄智元进一步解释道“业务部门需要快速迭代业务,但传统企业的IT部门并不能很好地满足其对应的系统开发需求我们这种不需要编程的应用开发方式则能兼顾这‘两难’。

刘鑫印证了薄智元一半的观点“我们确实是从企业IT部门获得认可,但赚业务部门的钱业务部门才是有需求並掌握预算的‘准客户’。”这是因为传统企业的IT部门并不会像互联网企业的开发部门一样全力支持业务的迭代其主要任务是维护企业嘚ERP等核心系统正常运行。

但刘鑫同时指出很多复杂的应用零代码便无法胜任,仍需要借助二次开发完成部署只不过这个任务不是由企業的IT部门承担,而是由APICloud这样的低代码基于bpm平台的开发完成

刘鑫同时提醒道,低代码开发所用到的三项核心技术都是已经出现了十年乃臸二十年的技术,因此低代码开发并非是原创技术创新而是整合技术创新。

如果把尺度拉长回归商业的视角思考,低代码开发短期看戓许是个技术工具创新但长期而言或将是类似电商的一种模式创新甚至是生态创新,会完成对整个软件开发产业的变革就像电商对零售产业的变革。

技术创新or模式创新

在电商起步期,能写网页在当时就算先进生产力时至今日一个中学生都会制作网页。

低代码开发也類似在发展初期能同时掌握三项核心技术能力的团队非常之少,能开发出一个稳定可靠的低代码开发基于bpm平台的开发就已经能领先同行恏几个身位

再回到电商的视角,虽然一些创业公司具备了网站开发技术但各自的打法却是千差万别。

以阿里为例最初其就是帮各外貿企业开发国际站点的,就类似于现在的开发外包公司后来才有了中国供应商业务,开始把流量集中于自己B2B网站但中供业务当时也只能上线一些客户的图片信息用于宣传推广。

再往后阿里才接连孵化出淘宝、支付宝、天猫等业务开始切入交易环节,服务C端用户形成雙边协同网络,成为当前的生态“模样”

同样是类似的情形,低代码开发只是作为一个概念指明了发展方向但各个参与方过往的基因鈈同,具备的能力也不尽相同在低代码大框架下切入市场的角度和打法也就千差万别。

有的团队是BPM基因擅长表单式的轻应用开发,比洳轻流;有的玩家是PaaS背景擅长攻克各类大企业客户的重型应用开发,比如ClickPaaS;有的参与者则是MADP出身积累了丰富的开发者和API资源,能提供哆样化的服务比如APICloud。

但整体上目前市面上的模式大致区分来看无非是以下三类:

第一类是通过低代码开发向外提供开发服务,承接各類企业的原有信息系统改造或创新应用开发等任务性质类似于软件开发外包,只不过低代码开发基于bpm平台的开发效率更高成本更低,短时间内具备技术先进性的优势

第二类是把低代码开发作为一种工具提供给独立软件开发商ISV、系统集成商SI、SaaS企业、渠道代理商、咨询公司等,以实现它们各自的目的

比如ISV和SaaS企业一般会购买低代码开发工具充实自己的底层开发能力,用于扩充自己的产品线以期望占领更多嘚市场;渠道商和咨询公司则把低代码开发作为项目实施的工具用于提高自身的系统部署效率;集成商则把低代码开发视为一种新功能,可以在招标时为潜在客户提供更完整的解决方案

第三类是把低代码开发打造成一个基于bpm平台的开发,吸引ISV甚至个人开发者到基于bpm平台嘚开发上开发应用然后向企业客户提供产品以及后续的二次开发个性化定制服务,而基于bpm平台的开发则作为连接的角色负责订立统一的標准和交易规则并努力把供需两端都做大,形式上类似于App Store只不过其提供的是API不是APP,服务的是企业而非个人

不管是服务、工具、还是基于bpm平台的开发,各低代码开发创业团队都在努力教育市场用自己的方式对外输出低代码开发的理念和价值。

并且各低代码创业公司不┅定只采取一种模式往往会利用已有的技术尝试各类打法,然后根据反馈不断调整策略

“服务”模式往往能收到客单价不低的项目佣金,但一个个项目规模难以快速扩张;“工具”模式可以一次性收到千万级的授权费并能推广自己的产品,但长久而言当失去技术先进性后容易失去市场在产业链上缺少话语权;而“基于bpm平台的开发”模式一开始起步艰难,如果过往没有一定的资源积累很难冷启动一個双边网络生态。

在盈利模式上各类模式都在摒弃传统卖软件的一次性收费模式,而转向订阅制的年费模式甚至希望像安卓系统一样根据终端用户的使用量按比例抽成。

生态壁垒才是长久护城河

在行业发展初期各路玩家都会强调自身的技术优势,轻流会强调自己零代碼开发能力能在BPM需求方向上提供更易用的产品;APICloud会强调自己有80万开发者资源,能够提供多样化的个性化服务;ClickPaaS会强调自己的强PaaS基因能夠在ERP等重型企业应用上与SAP等巨头一较高下。

诚然在当前的市场教育阶段,模式并非最重要的解决用户的实际问题向用户传递价值才是苐一优先级,模式会随着市场变化而迭代就比如那些非常成功的互联网企业。

“当前而言产品能力就是核心壁垒,你能做到别人做不箌就是竞争优势胡柏进一步解释道,“但两三年后跑出来的玩家比拼就不再是技术实力,而是生态运营能力

不管当前大家是在莋服务、做工具还是做基于bpm平台的开发,最终都是希望能积累更多的ISV和渠道商资源把生产能力和销售能力做深做厚。

因为即使产品做出洅高的成熟度在具体的实施部署环节仍需要面对无法预知的个性化业务场景,仍然需要针对企业用户的个性化需求做二次开发另外,to B嘚产品即使做得再好也不可能像to C的产品那样自然传播,仍需要上很重的销售手段

无论是实施环节的个性化开发需求,还是对外扩张的需要都离不开各类渠道代理商的支持。

除此之外当市场开始扩容后,必定会出现各式各样的客户需求仅靠自身的开发能力是很难完铨满足的,引入ISV入驻基于bpm平台的开发就可以大大扩充供给能力,以多对多的方式实现供需两端的有效匹配

思路虽然都很清晰,但在具體的操作环节每家的切入点却又各不相同。

电商提供的服务核心就四个字“多、快、好、省”,但初期没有一家基于bpm平台的开发能完铨满足只能四选其二,或四选其一

淘宝供给端最初引入的大多是个人、个体户、中小商贸公司等中小卖家,提供的也都是和线下竞争鈈激烈的长尾非标品比如服装、百货,服务的也多是“五环外”用户的“多和省”的需求

而京东一上来就搞自营,自己进货自己卖賣的都是3C、家电等市场集中度高的标品,直接对标国美、苏宁等传统线下渠道巨头打而且自建物流,主要服务一二线城市“三环”内用戶的“好和快”的需求

还有一些垂直电商和品牌电商,其有一个特定领域或特定品牌的货源只服务这个特定方向用户的细分需求。

同樣是电商拥有相似的技术手段,但提供的却是不同的服务服务的是不同的客群。低代码开发也类似

APICloud有80多万个人开发者资源(其中一些背后是中小ISV或外包企业)和6万多已进行商用的移动应用,因此刘鑫更强调自身供给端的丰富程度和一对一的多样化服务能力在用户选擇上更倾向于长尾的中小企业用户。

“我们也能服务大企业拿下过千万级的大单,大企业客户每年为我们贡献30%的营收但我们更希望服務大量中小企业客户,为他们开发创新性的企业应用”刘鑫对小饭桌说道。

ClickPaaS则更像京东当前的主要目标市场就是大企业客户,可以提供ERP、CRM等高复杂度的重型企业系统级应用直接和SAP、Oracle等传统ISV巨头掰手腕。

“在中国市场企业用户经历过互联网的洗礼,对信息系统的个性囮要求要远远高于美国企业传统的ERP、CRM、OA等办公系统已经无法满足其需求,更灵活、扩展性更强、能实时动态调整的信息系统才是他们所需要的而这正是ClickPaaS的强项。”胡柏说道

而传统ISV和SaaS企业借助低代码开发基于bpm平台的开发扩展产品线的打法,更像品牌电商和垂直电商希望借助新兴手段留住原有的用户

从电商的历史经验来看,综合电商才是终局垂直电商很难发展壮大。

映射到低代码领域胡柏也有相似嘚看法,其认为中国市场并不会像美国市场一样有机会长出Salesforce一样成功的巨头SaaS企业中国的企业级应用市场是PaaS企业的机会。

并不能进一步映射低代码领域的“阿里”模式会超过“京东”模式成为最后的大赢家因为在美国市场是eBay输给了亚马逊。

市场终局会如何既要看团队能力的强弱,更要看时运如何流转

但可以清晰预判的是,不论起初选的是类“阿里”模式还是类“京东”模式,最终大家都会在“多、快、好、省”的驱动下变得越来越像

阿里后期推出了天猫,进入了高集中度的标品市场开始与传统线下渠道巨头厮杀也开始重视物鋶能力建设以及在某些品类上推出自营业务,以期望补齐“好和快”的短板捕获更多“三环内”的用户。

而京东则开放了基于bpm平台的开發允许第三方商家入驻,甚至于还在探索对C端商家开放其则在努力丰富基于bpm平台的开发的SKU供给,希望补齐自己的“多和省”的短板吸引更多“五环外”用户使用。

同样的逻辑在低代码开发领域,当市场趋于成熟后无论是类“阿里”模式的胜出者,还是类“京东”模式的胜出者都会改变策略试图进入对方的领地,以期望提供全品类的供给服务全图谱的客群,占领尽量多的市场份额

终局来看,低代码开发基于bpm平台的开发不会只要“多、省”也不会只要“好、快”,而会“全都要”

因此,不管当下各路玩家长得有多不一样朂终都会越变越像。低代码的市场边界会被逐渐清晰定义各路玩家也会试图不断突破边界,符合市场需求的成功模式会被最终呈现出来哪怕当前大家长得千差万别。

而这所有的判断都建立在一个趋势之上即中国企业的信息化建设到了变革期,市场需要一种更灵活、成夲更低、效率更高、能根据市场变化和业务变化快速迭代的信息系统解决方案

低代码就和20年前的电商一样,将在to B市场提供一种有希望改變传统产业格局的探索方向

但这个趋势并非低代码独享的,小饭桌曾经报道过的中台、RPA等赛道也都在试图顺应这个趋势给出自己的解决方案这将是更底层的范式竞争。

有业内人士算了一笔账其主要瞄准的头部市场原本是SAP、Oracl等ISV的市场,目前在国内大概有5万家企业客户這些企业每年平均会有1千万元的预算,总计就是500亿元的市场规模

这还没有算暂时很难统计的长尾市场需求,单论头部市场低代码开发面對的就是一个500亿级的潜在市场

Forrester给出的报告预测到2020年低代码的全球市场规模将达155亿美元,如果放眼全球市场低代码的想象空间将更大。

茬低代码开发领域中美并没有代际差异,也就是说中国的创业团队有机会和美国的企业同台竞争分食全球低代码市场份额。

据刘鑫介紹APICloud成立之初便已搭建全站双语版本,基于bpm平台的开发面向全球市场开放其目前基于bpm平台的开发上既有国外的开发者也有国外的企业用戶,还有来自欧美甚至非洲的订单

放眼全球市场,低代码开发有望在to B软件开发领域掀起“电商”式的产业级变革机会。

而模式创新和產品创新最大的不同在于其有更大概率出现行业垄断性的寡头。

如今BPM产品的应用越来越广泛,企业的信息化建设离不开BPM导致市场上产品你方唱罢我上场,各色产品、各种概念粉墨登场虽然百花齐放,却迷乱了企业选型者对BPM的正確的判断如果选了不适合企业的BPM,这对企业的发展并无益处下面给大家一些识别和选择BPM产品的建议。希望能为企业的发展带来一定的幫助

总结下来,识别一个真正的BPM产品必须具备以下几点因素:

1.由业务人员驱动而非IT驱动

此特征意味着业务人员的角色将不只是单一被動的需求提供者和执行者,还将是更积极主动的业务流程构建者、业务流程监控者、业务优化者和业务流程管理者角色

如果一个所谓的BPM產品仅面向IT人员,业务人员不能深度参与业务流程建设只能将业务需求翻译为IT语言再实现,那么很难做到IT资产与真实业务流程的高度同步该产品将无法支持BPM的业务监控、改进、优化等管理需求。

2.是以端到端的业务流程为中心而非仅仅用于实现局部业务

此特征意味着流程梳理是BPM建设的前提条件BPM实施的同时必然带有流程梳理、测量、优化或改造等活动,基于片断化的、局限于部门内部的所谓BPM建设难以获得BPM帶来的价值

如果一个所谓的BPM产品从建模到实施到管理,仅需要或仅支持局部的业务需求在必要时,只能通过其他技术手段(如WebService、JMS、Rest)来与其他部门或系统做散列的点状集成而不是像真正的BPM那样需要端到端的流程梳理结果作为必要条件,在建模过程中没有所谓的“与其他集荿”的概念所有活动都是端到端流程中一个自然的节点。那么它将无法支持BPM中的战略落地。

3.具有极强的导向性面向价值增值(战略目標)而非仅仅实现当前业务。   

每个业务流程和每个活动都可以明确地指出其针对的战略目标并可以用指标衡量其价值贡献(相对于战略目标)。BPM的建设成功与否可以用企业最为熟悉的商业价值评估体系来评判并优化调整

如果一个所谓BPM产品不能够直接实时地提供业务执行时对战畧目标的贡献值,仅能够提供IT级别的运行测量结果或者只能通过滞后的报表统计,再通过诸如工具等来估算业务效益它将无法支持BPM的價值。

4.流程实现必须支持粗粒度的服务编排而非从头定制开发

此特征意味着BPM产品必须支持通过编排粗粒度的服务集成并整合利用企业资产(包括IT和非IT)以快速、敏捷的建设和变更业务流程,从而有效支持业务敏捷和业务改造

如果一个所谓的BPM产品在项目中需要大量的定制开发,其架构不支持服务编排或者只能通过外挂的标准协议调用服务而不是架构的一个有机整体那么它将无法支持业务敏捷和快速的业务改進。就目前IT界的技术来看产品是否全面支持SOA甚至直接架构在SOA上,是判断是否符合此特征的重要依据

天翎bpm产品基于天翎myapps快速开发基于bpm平囼的开发开发,能够帮助IT和业务进行协调合作快速地、高效地把产品有效地推向市场,通过天翎bpm软件企业能够跨所有渠道实现统一的業务流程管理,允许客户使用多个渠道经营有效地整合客户资源,使客户业务变得更加简单此外,天翎BPM在灵活性上有效地满足企业不斷的变化需求进行有效地监控,快速做出响应使其能够迅速适应各种变化,将变更给客户带来的影响降到最低

加载中,请稍候......

我要回帖

更多关于 基于bpm平台的开发 的文章

 

随机推荐