BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Thursday, January 19 2017, 09:53 AM
  4.  Subscribe via email
From Alexander Samarin: in your opinion, is the BPM industry (vendors, consultants, users, etc.) ready for a next "round" of standardization in BPM? Common terminology, several modelling notations on top of a coordination engine, human-task-as-a-process, standard API, styling of processes (like HTML), integration with Business Architecture and Solution Architecture, etc.
John Reynolds Accepted Answer
Not sure if we're really ready, but we're certainly enthusiastic:-)

We all know that the current generation of BPM technology hints a greatness, but leaves our clients hungry for more. Business Agility is still our goal, and we've caught glimpses of it, but it's still to hard to reach it.
Comment
I think many software vendors (not just BPM) get into "feature wars" with their competitors where all participants end up with "bloatware".

I proved this to myself once by adding a fake feature to our product sheets. Soon thereafter, one of my competitor started to promote this feature.

Surely giving a customer a blank operational e-canvas where they can build their workflows using their forms, their rules gives 'business agility".

Same for strategy, hard to get more flexible than a blank e-canvas where you drag and drop and connect whatever you like, however you like.

  1. karl walter keirstead
  2. 2 months ago
RE "it's still to hard to reach it" - is it because each BPM vendor tries to do this alone?
  1. Dr Alexander Samarin
  2. 2 months ago
Sure about "bloatware" - to obtain a bridle one has to buy also a horse and a chariot.
  1. Dr Alexander Samarin
  2. 2 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Walter Bril Accepted Answer
Well... it definitely needs some sorting... Even despite current standards, they still are being, let me say, not used properly...

Especially in the carbon based lifeform space we seem to lack proper standards. But perhaps UPN could finally break through:-).
Comment
And maybe standards between carbon- and silicon-based way of thinking?
  1. Dr Alexander Samarin
  2. 2 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 2
David Chassels Accepted Answer
Yes for a common language in business terms explaining BPM but no for the for the supporting technology. History shows that standardisation has a negative effect on promoting evolution to a mature even commoditization of any product and this certainly applies to enterprise software!
Comment
As a web language not really but such as BPMN would be and frankly has held back moving on to a complete "platform"..?
  1. David Chassels
  2. 2 months ago
Hmm. Do you consider HTML5 and related standards as "the supporting technology"?
  1. Dr Alexander Samarin
  2. 2 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Zachary Kelemen Accepted Answer
I think it entirely depends on what the standardization is looking to achieve from a market level. BPMN did a great job at creating a standardization across the board even if some of the new platforms don't use it. If the market can collectively look inward a solve a pressing need, then standardization is always a good option. Hell, that's what good process is all about isn't it? Creating a standard ways for a business to do things?
Zack Kelemen - Digital Process Practice Lead at Rightpoint
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
E Scott Menter Accepted Answer
Blog Writer
Not sure we've recovered from the last round. :D

There's probably room for some ancillary standards (certain kinds of logging, for example). But I agree with those above (and in a previous Forum post) who suggest that perhaps BPMN put the brakes on innovation for a bit too long. When there's a standard language for business, there can be a standard language for business applications. Until then...
http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
RE “Creating a standard ways for a business to do things?” There are things and things. Core or mission-centric things are open for innovations while supporting or enabling things can be standardised (e.g. as good business practices).

Also unique core business processes are actually assembled from a limited set of process patterns. The latter can be standardised and made explicit in BPM tools so staff members can concentrate on the unique challenges of their business and not waste time re-inventing the wheel.

At present, BPM-suite tools are programmable monolith thus it is impossible to separate their core and supporting capabilities. As Karl said, “bloatware” effect. Migrating from one BPM-suite tool to another becomes comparable to migration from one ERP to another.

Concerning BPMN, I would approach is as one of languages to executed by a standard engine (similar to JVM for which there are many programming languages in addition to original Java). Of course, BPM-suite tools and BPMN, CMN, DMN, etc. must be considered as parts of a bigger system.

I work in the domain of standardisation for healthcare and smart cities as systems. The general approach is the following:
- some system elements are *black-boxes*; a set of standards defines the required functionality, interfaces, performance, security assurance for those system elements
- some system elements are *white-boxes*; a set of standards defines also a reference implementation (e.g. as illustrative processes) for those system elements
- some system elements are *system-forming* ones; a set of standards define those system elements in more details

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
John Morris Accepted Answer
Today's question gets to the heart of the software industry. Software economics, market power, market discourse and technology constraints all together define an indeterminate market system. The discussion this week of DBP ( "digital business platform" ) on BPM.com is another expression of this question.

The notes already on this question capture serious issues around standarization ( e.g. "bloatware" ) and Dr. Samarin's black/white/standard boxes could be mapped to markets.

The software market has the potential for sub-optimization ( i.e. "market failure" ), where users may be locked in to mediocre but high-cost solutions. But a sub-optimal solution today shouldn't be a life sentence -- the software market is indeterminate and individual efforts by pioneering users and vendors alike can make a positive difference. And as the pioneering cadres of positive change, sales people too!
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
David Chassels Accepted Answer
There is general consensus that this question and the DBP one are getting to the heart of big issues for the software industry. Here is not just my take but was at the core our 20 years research and working with early adopters which could form the basis of both a standardisation and the basis for creation a DBP

First what is a business process? It is series of linked tasks where each task is a “step” in the process. It has a clearly defined start point and one or more expected outcomes.

Next what are these “tasks”? Our research established them as follows;

• The Form task is the task that the user will be mostly concerned about. This is where data is entered by people or machines into and extracted out of the database. It can be a “simple” display form or a complex interactive form. This superseded by the web report/form task below but used for quick first cut/ prototype of the application.

• The Web report/form task is used to hold the path for Java Server Pages/forms to run across the web. Utilises Ajax to ensure once only entry of information with intelligent grids. This includes a Tag Library and ability to directly to data stores as required

• The Normal task “halts” the process for an off-line activity. It is a very useful development aid in a process, but should be used sparingly in a “live” environment.

• The Program task allows you to “call” applications such as Word, Excel and specific program used in a process.

• The Pending task places the process into the “Pending” tray of the user concerned. This is a very useful task that is used alongside deadlines and delays in a process.

• The Report task enables a report to be generated via any report application based on a previously defined template.

• The Calculation task can contain calculations involving almost anything including dates, numbers, algorithms, strings etc and aids rules creation.

• The Sub-process task allows the process to move to another, or ‘sub’, process.

• The Event task bundles the same task together in multiple runs and waits for another process to action it. .

• The VB Script task allows the use of Visual Basic code. This task can have many different functions according the requirement of the developer but only used in client server environments.

• The Import/Export task handles the movement of “bulk” loaded data into and out of the database. It can be both completed by the user and/or the system according the specifications.

• The Server Side Message Queue task handles communication between the defined process and many other external systems, such as legacy systems. It’s more popular use is in the sending of e-mails from inside the process.

• The Finish task recognises the process has ended. As far as the user is concerned, the “run” of the process will disappear from the trays. At this point, that particular run will be placed into the “Process History” tray of the manager.


These task need to be “joined” up to create the flow of work information and this requires flexible links. The order in which tasks are processed is determined by the links between the tasks. Each link in a process has at least one source task and at least one target task. When the source task is complete, the link triggers the target task. These links are very powerful in terms of flexibility and conditions as required. This aspect has proven to be a significant contributor to business rules.

At the core of the architectural design to build on these core and complete generic requirements for business was to be able to express as data inside a relational database thus permitting unrestrained connectivity. That’s what we did and against all the odds it worked! There is really nothing this set of defined actions cannot do in terms of supporting business processes. Configuration of the tasks and build takes place in a graphical design/build environment and click ready to run.

So we have very clear standardised actions that enable a Digital Business Platform that builds any business operational requirement and able to use legacy data and system driven by the process where all new information is created. All far too simple for “IT” and that has been the real challenge! Sorry not yet available globally but soon but would encourage others to build no patents allowed not even us with very strong established prior art (as Microsoft discovered!) This is about the start of commoditisation of enterprise software with associated significant benefits for buyers….long over due…
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
RE: what should be in/needs to be in a DBP

Our team has taken our Case-based DBP (assuming we have one) - [ we have been calling our platform a "run-time environment" ] and made different "products" from the original implementation i.e. CiverPsych (1995) -> CiverMed, CiverCertify, CiverIncident, CiverSupplier, CiverManage.

Aside from a name change and a few embedded "add-ins" e.g. a diagnostic algorithm for medical that has no clear use in most other industry/application areas, the products are all basically the same. We get a few raised eyebrows with the word Case, which enjoys universal appeal in healthcare and legal apps, but not always elsewhere.

So, the question we asked ourselves is "what is/what should be in a run-time environment? and the conclusion was an RDBMS where you can establish a cursor position giving users :

a) a work space we call Case that holds anything you care to throw at it, plus the ability to host background BPM, CRM, ECM and a Figure of Merit Matrix (FOMM),

Our Cases open with basically nothing more than a unique ID.

Aside from attaching documents, you have no choice but to invoke a process in the library or invent/insert an ad hoc "process" of one step if you want to record some data. So, little danger of losing a focus on BPM.

Up one level we get to . . . .

b) workflow / workload management across Cases with R.A.L.B. (resource allocation, leveling, and balancing) so that users can work on multiple Cases at a time.

Beyond this, it seems to be a matter of choice as to whether additional functionality is IN the run-time environment (closely coupled) or accessible by reaching out to additional functionality (loosely coupled), except in respect of performance where in-memory computing clearly beats at-a-distance data exchange.

Here is how we rationalize our design approach

"
We would think of a Digital Business Platform as a corporate asset comprising a selection of closely-coupled functions, mainly for reasons of convenience and efficiency, plus, via inter-operability, another collection of loosely-coupled functions.

e,g, for the client base we work with, Case is the operational platform of choice and customers expect BPM, RALB, CRM, ECM and FOMM to be within easy reach.

Not so for CPM, for example, because they only need/want to perform ES-EF-LS-LF calculations for once-through projects, so, here, they are willing to shop around for a CPM environment, make sure it has some way of taking in input other than via keyboard and that it has some way of exporting calculated results.

Our tech staff usually end up being asked to do the inter-connects.

For closely-coupled functions there is, of course, native interoperability, but it is hidden. The customers don't see it, they don't need to understand the details of the mechanism.

They are willing to put up with some minor irritants relating to the platform.

Up to a point . . . .

The thought of blocking off native functionality and having to write parsers/formatters and manage data transport/encryption makes them stay with our platform. More than, say, three awkward internal interface issues, though, and they would be in the market for a new platform.

The ongoing big question for us at the vendor level is "if you build it, will they come?" and part of the solution involves understanding corporate culture, with another part being willingness to hone the UI so that it truly makes work easier for users to log in as opposed to not logging in.

Customers who have "no verbal orders" policies make sustainability easier. We try to promote "no verbal orders" to customers.

Here, the users get a user ID, and with a few simple policy statements in place, they quickly realize that the easy way for them to get work done and to gain access to work done by others is within the platform.

Users create instances of templates of core BPM processes, they deviate to a reasonable extent, but if they go out of their way to perform a sequence of steps NOT using an available BPM process template, they quickly get hit with a number of pre-processing alarms as they arrive at steps with missing data the process sequence would have ensured would not be missing.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Wow! A lot of good information to write an initial draft of a digital business platform which can be standardise!

Thanks,
AS
Comment
Alexander
Yes long overdue but needs independent body to research and seek out the challengers to old ways. Big vendors will resist but we must move on.....?
  1. David Chassels
  2. 2 months ago
Before having HTML5 widely used, a web-centric cross-browser application had to waste about 20 % of its cost to become browser-independent. Obviously, lack of standardisation imposes huge hidden cost on BPM-suite tools thus seriously limits BPM potentials. Sure, a business case is necessary. I think, some standardisation can break the iron triangle: "scope" (features and quality), "time", and "cost".
  1. Dr Alexander Samarin
  2. 2 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 10
There are two challengers, the stuck-in-time vendors/consultants and secondly, users.

A good starting point for standardization IMO is

"The Last UI You’ll Ever Need for BPM" (4 years ago)

http://wp.me/pzzpB-lz

It turned out for us that the same UI was very appropriate for ACM, which replaced what we used to call BPM.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Boris Zinchenko Accepted Answer
BPM industry exists for establishment and implementation of standards in the area of business processes. Standards are key instruments of BPM in implementation of its mission to formalize and improve business processes. BPM is dedicated to development and maintenance of standards. All history of BPM consists of evolution of standards. This is a continuous process.

Business Process Management (BPM) Standards is a collective term for the subset of open computing standards and specifications used to model and execute business processes. The goal of BPM standards has been typical of other standards efforts—to ensure skill reuse, definitional clarity, interoperability and portability—and has been focused specifically on process management efforts. Gartner

Originally, BPM standards were very complex and vendor specific. With time, different vendors discovered more and more coincidence in standards they develop. This is a positive sign indicating an objective uniformity of business rules behind these standards. If a field of knowledge is principally irrelevant to formalization, then every private understanding of it will be not feasible for generalization. The fact that business standards of different vendors and consultants gradually converge proves the existence of a solid common base comprising a rule set of real business operations in terms of strict logical definitions.

Convergence of standards does not go easy. Every vendor is objectively interested in keeping his own standard private as much as possible. A dream of a vendor is delivery of monolith system, which solves all client tasks and doesn’t need any other system. However, real enterprise environments are too complex to allow for this scenario. There always exist a diversity of client technologies, which vendors call legacy but clients cherish as an essence of their business operations. A dream of clients is an easy integration of existing technologies with minimal cost. In this way, there appears a fierce competition between vendors interested in private standards and clients interested in universal and inter-operable standards. Vendors are forced to follow client demands because support of standards becomes a key factor when making decisions on a purchase of BPM system.

In recent years, due to explosive growth of digital business platforms and general process automation we evidence rapid development and growing maturity on universal industry standards in various fields directly adjacent to BPM. It is only a matter of time when a “critical mass” of these standards will overweight isolationism of vendors and opens door to wider BPM standardization initiatives.

In our personal impression, this time is quite close because we see how more and more clients show interest in our universal approach to integrate versatile BPM systems existing today under umbrella of universal exchangeable meta-models and configurable process transformation rules ensuring transparent process standardization among different vendors. We believe that BPM industry is now really ready for the next round of standardization and, moreover, it has already begun.
References
  1. http://www.gartner.com/it-glossary/business-process-management-bpm-standards/
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
I find it difficult to get excited about "standards".

For those of us who promote ACM as the method of choice for managing workflow and workload, BPM “engines” that we embed or develop on our own for use in our platforms could, in theory, acquire points from a statement that the e-mapping approach adheres to a standard.

The main benefits would seem to be to give the customer the ability to switch vendors and, in such eventuality, experience a diminished learning curve and reduced cost of conversion.

Two problems . . . .

1) if e-mapping is simplified to the point where you basically do little more than drag and drop circles on a canvas and connect these with directional arrows (ignoring the minor complexity of putting in place branching decision boxes and a few other constructs), given a map (prepared in any environment) is it really that much of a chore to re-map in some other environment?

2) if the answer is no, then the learning curve for a vendor change is not going to be steep and the conversion cost will not be great.

Seems to me the two benefits go out the window and we need to look for other benefits.

I do understand “its [BPM] mission is to formalize and improve business process” – a good example is medical lab testing – you certainly don’t want a sample going to one lab with generation of test results that would be different had the hospital/clinic sent the sample to a different lab.

However, say we have a DBP where BPM is core, along with CRM, ECM, R.A.L.B. and F.O.M.M., possibly a few other methods.

My question is how, under this scenario, do BPM standards impact customer buying when, in one case the customer will be performing mostly structured work (+1 for BPM), but in another, the customer will be performing mostly unstructured work (+0 for BPM)?

My customers seem to be in the 80/20% zone of unstructured versus structured.

The reason for this perhaps is my methods are not impacted by shifts from 95/5% to 5/95% across silos within an organization. Customers who are in, and stay in, the 20/80% zone probably would view an e-mapping environment that adheres to a standard as having a selling point.

Imagine, however, an environment where the mix of unstructured work to structured is 95/5% - here, chances are there will be no end-to-end processes, just process fragments that users, software and robots thread together at run time.

In theory, you could find a customer with no processes, no process fragments, just ad hoc “processes” of one step each.

If you inspect a one-step-process in the e-mapping environment you find a) one step, b) no directional arcs (start-end reduces to start/end), just a step name, one or more attached forms, and a routing attribute.

Not very exciting, nothing worth standardizing, yet very useful because whereas most of the end users do not know when they pick a “process” from a menu of services whether they are picking an end-to-end process, a process fragment, or a process of one step - but whatever they pick allows them do perform the work they need to perform.

Where are the rules in a platform like this, you might ask? - the answer in our approach is at the attached form(s) or in a pre-processing virtual step.

Bottom line, what my customers value most is "their workflows", "their forms", except where government or b2b requires that they use standard processes.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
@Karl, Very valid points on a typical client situation. I bet most of BPM projects face this environment. Exactly here, standards are especially important for a positive client experience. Approaching a client with a suggestion to move all processes at once to another system, even in all respects superior to existing, is practically impossible without severe disruptions in existing processes.

However, having a number of structured and unstructured client processes, forms and workflows, it is always possible to run automatic or semi-automatic process discovery, which will collect data and metadata associated with these business artifacts. As a next step, you can run various process intelligence and process mining algorithms to reveal common patterns and most frequent relations in connected artifacts. Next, you can build a library of process fragments and entities, which comprise client’s business domain. This library will well illustrate, which of existing process modeling methodology is most close to what client really uses. Then, existing processes can be gradually reworked for compliance based on selected methodology and client vision.

I suppose it is a standard scenario working in any real BPM project for process integration and improvement. Standards serve here as a driver of structuring to crystallize existing experience in concise and compliant form.
  1. Boris Zinchenko
  2. 2 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 13
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.