BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Thursday, February 02 2017, 09:50 AM
  4.  Subscribe via email
A question Tweeted by Emiel Kelly: with all the different types of business processes that exist in the business world, do you think one business platform can handle them all?
Bogdan Nafornita Accepted Answer
Yes. Processes natively talk to each other.
But such a platform needs to be deeply architected for modularity of UI, agility of process model and coherence of the data model.
And it absolutely needs a unifying vision beyond that: style, execution, patterns, seed models, standards etc - they all come into play.
It also requires a focused development model that is specific to process-driven architectures.
Managing Founder, profluo.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Vasileios Kospanos Accepted Answer
Great question, Emiel - my Tweep buddy!

Yes, ONE business platform can orchestrate your business completely. Connecting line-of-business applications with a process layer to utilize best all systems of record, ONE business platform - with solid integration capabilities - can handle ALL business processes. Depending on gathered requirements and agile delivery methodology, it can also do it rapidly and scale fast after the first processes by reusing centain artifacts and components.

The world is your oyster, Emiel!

Vasileios
AVP Marketing
PNMSOFT.COM
Comment
Agree (for a particular business).
  1. karl walter keirstead
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Walter Bril Accepted Answer
That typically depends on what you intent to do... If you want to map all your processes on a high enough business level (as in understandable), you could map all of them in (bias here) Elements.cloud say. However, if you want only to create executable BPMN flows in order to automate (parts) of your business processes you would need something else (e.g., Signavio). Bottomline, I suppose you need an umbrella type of "this gives us insight and oversight at a business level, to be used for Lean exercises)" solution and add more techie stuff that would sit in context of that umbrella solution. Most of the time, organisations lack the umbrella (or have a poor, hard to manage Sharepoint type solution... or even worse, a collection of outdated Visio's, Powerpoints or Word docs...).
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
David Chassels Accepted Answer
I know our DBPlatform can handle all required business processes. As I have explained before we established that relatively few task types can compose any operational business process. We even have proven build of an Intelligent process which can recognise past actions to bring forward the optimal outcome. It can readily build configurators with in built rules and automatically delivers the adaptive capability all achieved with a no/low code platform. We have been ridiculed and ignored as we were decades ahead of the game. But the technology which is well proven with early adopters has survived against the odds. As they say watch this space..
..just a question of time......and the "game" will change.....at great cost to some rather large vendors and their ecosystems.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
I consider this question as asking for requirements – what are essential capabilities of a business platform to handle all types of business processes.
Just a small addition to Bogdan’s list – such a business platform must be able to compete with blockchain-based smart contracts.

Thanks,
AS
Comment
Sure, MDM is needed - basically this means the future ability to show data, as it was, at the time it was collected on the form version that was in effect at the time the data was collected (someone may have in the meantime enriched the form to include a new field). Easy.

However, enter standards folks and now it becomes unfashionable for disparate systems to export their data in some reasonable format at a generic data exchanger for formatting and data transport.

Publishers can no longer can give names to objects the way they like, subscribers can no longer read objects using names that make sense to them

The healthcare industry in the USA has to an extent 'standardized' and ended up with a format that includes some 12,000 data elements.

Impact? You get transactions where 99 pct of the fields are null.

It's silly to presume that all subscribers to a publisher's data want/need all 12,000 data elements. Many only need part of some subset.

  1. karl walter keirstead
  2. 1 month ago
I do not see as competing with blockchain which is basically a "ledger system" for control of payments more working with....tracking all source and resulting information is the end to end process...blockchain just a function to be used within the bigger picture? So the platform must have Master Data Management capability to receive and send data as required to other systems/ledgers/legacy.
  1. David Chassels
  2. 1 month ago
Alexander. It was more the invention of healthcare industry bureaucracy. putting a focus on long term outcomes as opposed to focusing on improving the quality of healthcare services delivery to individual patients. The effect was to cause doctors to become data trolls.

Most "design by committee" ends up with a mess.
  1. karl walter keirstead
  2. 1 month ago
Karl, RE "a format that includes some 12,000 data elements" - sounds like the result of having about 1000 EHR products from about 600 software providers. Maybe we have to re-start this standardisation from a reference architecture?
  1. Dr Alexander Samarin
  2. 1 month ago
David, I would say that the most “generic” blockchain-enabled application is a Multi-Sourced (many owners of information) and Distributed (many owners of data-set copies) Record Storage (MSDRS). All other blockchain-based applications, including DLT, are extensions/variations of this MSDRS.
I am sure that a MSDRS is mandatory to execute multi-business-parties business processes such as contracts and transactions based on those contracts (banking, IoT, e-gov, healthcare, etc.). Being equipped by a MSDRS, a [common unified] business [execution] platform will be able to “sit” between those business-parties like an “escrow agent”.
Of course, some MDM capabilities are mandatory, primarily, as common dictionaries, e.g. http://www.edmcouncil.org/financialbusiness
  1. Dr Alexander Samarin
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 5
John Reynolds Accepted Answer
Wait... Weren't you going to save this question for April Fool's Day? ;-)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Gero Decker Accepted Answer
What does "handle" mean in this context?

Are we talking about documenting all processes?
Then sure, one platform can handle it all - and this is actually recommended because you want to have a single source of truth.

Are we talking about automating all processes?
Surprise, surprise - some vendors will claim that this is possible. In reality, I have never seen this happen. Application developers want to use a different platform than citizen developers. Some are fans of ticket tracking systems, others of RPA, yet others of IFTTT... So much to choose from - and each option with a different strength or weakness.
Co-founder & CEO of Signavio
Comment
+1 to Emiel, not all processes need to be automated, all processes need to be "handled".
  1. Bogdan Nafornita
  2. 1 month ago
Handling to me is "bring them to a good end" So executing processes for cases and everything needed to do that with a desired result.
  1. Emiel Kelly
  2. 1 month ago
I have a question re "handling" versus "automating".

Does "automated" mean that an RT engine automatically posts steps to an InTray as these become current along a process template instance AND that none of the steps along the template instance require manual input? i.e. all steps auto-execute/ auto-commit ?

If yes then the only required "handling" I presume is that of a person, software, or robot, streaming an insurance claim, a manufacturing order, or a patient needing healthcare services onto a template instance.

Clearly, if one or more steps along a process template instance is unable to auto-execute/auto-commit, then one would say that instances need to be 'handled'?
  1. karl walter keirstead
  2. 1 month ago
In healthcare (USA) there are billing message formats (837, 835, 270, 271 etc).. I suppose some vendors figured these would remain as is, so they coded them within the Case management systems. Well, the specifications changed a number of times forcing these vendors to put out new releases of their Case systems. Vendors who chose to encapsulate the billing formats in an external executable had a much easier time.

It makes no sense to me to do mapping in the same environment as run-time execution of process templates. - you map a process, roll it out, discover ways and means of improving it, make changes, and put out a new version After a while things settle down. The mapping environment gets used now and then, the run time environment processes thousands of template instances per day.

I don't altogether understand what is mean by "Application developers want to use a different platform than citizen developers" but, for sure, "Process mappers want (should, actually) use a different platform than run-time users of process templates"
  1. karl walter keirstead
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Ian Gotts Accepted Answer
Should we all just attach our marketing literature?

All the comments of "our platform can support all processes" are delusional. You platform COULD support all processes, but SHOULD it or DOES it.

Sure, you could build a CRM app using your platform, but SAP, MSDynamics, Salesforce, SugarCRM, Pega will all kick your butt. You could build HR but WorkDay, SAP, Fairsail, FinancialForce and others will kick you into the long grass.

The secret of success is focus. What are you REALLy, REALLY, REALLY good at? Make the proposition tightly focused and 100% complete. Hunker down and deliver that again and again and again, so the sales becomes easier and faster and therefore wildly profitable.
Comment
+1 Mission of BPM is linking and orchestrating processes, not implementing everything inside one engine.
  1. Boris Zinchenko
  2. 1 month ago
sorry, Ian, I don't really have any marketing literature, I prefer talking to customers and actually understanding their illness before I prescribe them my medicine.
I have responded separately to your challenge, so thanks for that.
  1. Bogdan Nafornita
  2. 1 month ago
Comments like "our platform can support all processes" probably are delusional.

"Case" (a cursor position in an rdbms) causes no raised eyebrows in healthcare or in law enforcement, but telling a job shop customer that you are "working on his case" (instead of "order") leads to confusion.

You won't find a diagnostic module, treatment module or medications module in CiverSupplier, but these are core to CiverMed.

Sure, we could build a standalone executable for coming up with a diagnosis but embedding the module in the medical Case management product and providing access via a menu item or icon on an icon bar, if done right, gives better performance than making the module a callable standalone executable.

The on-line help needs to change as you move from healthcare to aircraft MRO, to job shop manufacturing.

A really bad move, on the other hand would be to have four product development teams for our CiverMed, CiverPsych, CiverSupplier, & CiverIncident platforms.

Object-oriented programming lets you have one source code set.
  1. karl walter keirstead
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Christine Custis Accepted Answer
This is an interesting exploration and I hope to support my hypothesis that a single platform can handle all types of processes relevant to all industries, functional business areas and even specific activities/tasks in any organization. I'm thinking not just about a universal platform for handling the manipulation of processes, but one for the automated development of processes and workflows based on narrative inputs to the system by stakeholders.

To take a few steps back from the technical framework and the mechanisms that will need to be developed in order to make something like this work, I'd like to discuss the overarching premise. It is similar to that which is considered in GPS software such that, with an accurate and complete set of appropriate data, any algorithms and intelligence can be built to offer "directions" to anyplace from anyplace. Similarly, any self-driving/autonomous vehicle will work successfully in a real-world/production environment as long as the appropriate learning algorithms, business rules and other necessary inputs are included.

So what rules and algorithms do we include in a platform that can handle the process improvement activities for any process? I'd love to invite you to join me as I investigate this!
References
  1. http://pearlo.co
  2. https://www.linkedin.com/in/christine-custis-88b177b9
Comment
Dr. Custis, your proposition that there exists a single platform that can hand all types of processes is very motivating. (And you add to this that there can be a high fidelity mapping from processes implicit in human expressed narrative or language to executable automation artefacts!) I would like nothing so much as for these propositions to be true; they describe a universal process platform covering all types of work. (I like to emphasize the "work" part.)
All this said, it's true that I've argued the opposite case in answer to today's question, specifically that because of economic and technical reality, that the universal platform doesn't exist. Which puts me in a bind, seemingly holding one view and appreciating the other.
The resolution of the two positions may be found in the further development of platform technology, especially BPM engine technology. Many BPM engines impose modeling restrictions on business analysts, some less than others. But research and engineering on process engines are continuing here and there; to my knowledge there's no fundamental reason why state resolution in real time of the complex multi-dependent graph which is how BPM models reality, cannot be achieved.
And so we end up with your marvellous comparison to autonomous vehicles which are navigated successfully based on environmental data. (The comparison brings to mind a BPM token as it navigates an executable BPMN process graph.) To deliver on your vision would be to rapidly broaden the market for process technology. In this case the "universality" we seek starts at "work", continues with "language" and eventually is also realized in "notation" and "engine". Further up the stack, all bets are off, and we have application platforms, business economics -- and heterogeneity. But that's OK.
  1. John Morris
  2. 1 month ago
Christine
On rules simple think either yes or no and basic steps going thru the need. It is how business works and if complex rules just keep addressing using that same concept. This in a process can be implemented with flexible linking tasks with options flowing from source to target tasks. As for the algorithms use a calculation task and just apply...that's one area where good coders needed the rest just configure as required. Read my previous contributions thinking business not "IT" and you should "get it"....
  1. David Chassels
  2. 1 month ago
John you articulate well the huge implications of achieving that holy grail of that Platform which can do it all......and that has been our motivation to ensure what we built never is allowed to "be buried" facing up to the innovators dilemma.....!
  1. David Chassels
  2. 1 month ago
Well, we know that with competent knowledge workers it matters little in terms of outcome on simple processes whether you give them a process template or whether they invent a process simply by performing steps that appear , other than to the performer, to have no interlinking other than via time.

So, data mining could look at Cases and auto-construct a map (most the workers do this, and then they do that) and that when production of an assembly starts before a prototype has been build and tested, you see a lot more field re-calls.
  1. karl walter keirstead
  2. 1 month ago

Automated-development using technology is a natural progression from motion-time-study experts using clipboards and stopwatches.

A lower tech option involves sending in a facilitator who builds a process in front of a group of stakeholders, basically doing little more than asking "... and then what do you do next?"

"Handling" is more complex.

We have Cases where there is a mix of structured and unstructured interventions, more and more of which are the result of data imports from local and remote 3rd party systems, and devices, with performers typically focusing on 20-30 Case template instance steps per day.

So, here, we need RALB i.e. three-tier auto-scheduling, plus user micro-scheduling plus supervisor overrides to level and balance work and workload across Cases.

No picnic either periodically assessing in a non-subjective manner progress toward meeting Case goals\objectives despite the fact that FOMM (Figure of Merit Matrices) have been around since the mid 1960s and that we still find, on a daily basis, folks who have never heard of the term.
  1. karl walter keirstead
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 9
John Morris Accepted Answer
Tough question! Reminds me about the "one ring to rule them all" -- and we know how that worked out. (OK, it's a "Lord of the Rings reference... )

But why a tough question? Because the question concerns the definitions of "business platform" and "universe of processes" and "what are the business entities covered" -- and then the meaning of "handle them all". (For example does "handle them all" allow for coding when your notation is insufficient?)

1. SCIENCE VERSUS ENGINEERING VERSUS BUSINESS TODAY -- Do we believe that there process science exists (perhaps from TU/e) that is a sufficient foundation for the job of platform? And has that science been engineered into working platform software? And has that working software platform been packaged for real world use? (Note that as we have explored recently, a "platform that supports processes" also likely contains lots of other distinct technologies, such as decisioning.) POSSIBLITY: The train of development from science to engineering to business is still evolving; it is impossible to conceive of one platform existing in market space at this point in time that would usefully handle all process requirements. (As for the future? Maybe when it gets here .... accounting is more structured than business process management, and has been around for 100's of years. And accountants still have arguments about different ways of doing things...)

2. DIVERSITY OR MONO-CULTURE ALWAYS -- Do we believe that "a business platform" is a "real thing", and that it would have a "life-cycle"? Or is only a reification or imaginary? If a platform is a real thing, adopted by everyone, then like any mono-cultural ecosystem, systemic risk will be high for sub-optimization. Additionally, the world of business and government is increasingly fragmented at an operational level (the growth of Amazon and Walmart notwithstanding). Business services are very often now an emergent reality incorporating many business entities (field service is notable here). In this case, the meaning and application of "platform" is very different from its application only inside one corporation. (And we won't even address the difficult and complex issue of interoperability.) POSSIBILITY: Economic reality and risk avoidance demand an ever-evolving portfolio of distinct business platforms competing in the market.

So, technically, a common platform doesn't exist now and economically it shouldn't exist. This is good news for workers in the vineyards of process and nascent platform, because there's lots of work to be done and lots of business opportunity!
Comment
Good question Alex. I confess that my sales/biz dev orientation is biased towards "product". However you are absolutely correct to highlight the stack definition (this accords with lots of material that can be found on the web, including Wikipedia).
I note the original question says "business platform", i.e. implying a stack that extends into business semantic space. To argue the point now would require distinguishing between "product" and "platform", which is likely a hard thing to do.
Along these lines, I was recently speaking with a biologist and learned that the question of "species" -- something that a lay person would assume would be absolutely easy to define -- is in fact, according to this report anyway, apparently not so easy to define. Likewise I suspect the concepts of platform and product. In the end, as you suggest, economics will help sort things out. : )
  1. John Morris
  2. 1 month ago
RE "it is impossible to conceive of one platform existing in market space at a point in time that would usefully handle all process requirements." Is platform a product or a technology stack in according with the already discussed architectural pattern? It seems that you and many others consider the former while it may be the latter as well (thus very economically attractive for the customers).
  1. Dr Alexander Samarin
  2. 1 month ago
@John That's the best answer. Besides, even if the economical factor is excluded, I doubt if it's really ideal to handle all business processes in a "single business platform", considering the performance and sustainability factors.
  1. Anjana Ramesh
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Not a clear question - if processes convert inputs to outputs and are therefore all the same, then "With the number of different processes that exist" makes no sense.

Next, what does "one business platform" mean?

Is it a platform for inventorying processes plan side and hosting run-time template instances run-time side? - then we need two platforms.

If it is a platform for users that includes a UI, then we could have one but better, in my view, to have at least four, one for "back office/super users", one for access by back office/super users via a browser [we make them use remote desktop], one for casual users where they only get access to a menu of services at a portal (we don't want them to be able to establish a cursor position at the back-end RDBMS), then one for owners of back-end records.

It took us one year of negotiations with a large healthcare organization to get the security right for one class of portal users - all of this time was for outreach only to contractors providing home healthcare services to patients [they ended up not having access to any patient records].

"Patients at portals" will need a different setup [they will only be able to indirectly index to their EHR record].

The setup for contractors required two separate servers with a smart engine between the portal and the back end so that no portal user would be able to link to any record at the back end RDBMS.

I suppose healthcare is special because of (USA) huge fines for disclosure (inadvertent or otherwise) of PHI (Personal Health Information)
References
  1. http://www.kwkeirstead.wordpress.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Bogdan Nafornita Accepted Answer
Thanks for the challenge, @Ian, allow me to respond. Yes, a proper platform can handle all business processes. And yes, likely it shouldn't, and most likely it never will. So I guess, I'm both delusional and focused at the same time.

In your examples, you are purposefully ignoring one huge element that makes a market: pricing. A generalist business platform will never beat on features the hugely invested proprietary platforms that have dominated enterprise software for decades. But it will always beat them on price. And there's a huge market that does not need the best, but actually only the good enough.

And that's a type of focus that you seems to omit from your success recipe: cheap and good enough instead of expensive featuritis.

A good reference here is the Innovator's Dilemma which I'm sure you're familiar with.
Managing Founder, profluo.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Emiel Kelly Accepted Answer
Nice discussion. Actually I am not interested in platforms at all, but was more curious about how everybody sees process, process execution, process management.

Is it "a set of automated steps where some data in turned into other data" or is it more?

To me it's definitely more. Because there are so many industries where processes are executed. From taking care of kids, to building houses to fully automated gambling on the stock market.

Besides that, processes come in different management styles. From "good old taylor" till "I don't care what and how you do it, as long as it is ready tomorrow" and "I think I have a problem, can you solve it?"

So to me BPM starts with a good understanding of the above and then make clear what is needed to execute and manage the process. And maybe some platform might help.

But I don't think it will one for all.
Sharing my adventures in Process World via Procesje.nl
Comment
Is it "a set of automated steps where some data in turned into other data" or is it more? ---- of course it is more. There's no argument about BPM being about automated stuff.

When you look deeply, from an architectural point of view, on what is a difference between a business process and other groups of activities is that a process is a purposeful orchestration of activities towards a business goal. Purpose and orchestration are the key words here. As long as there is an explicit purpose and a desired style of orchestration (strong, weak etc), there could be a business platform ready to support that, even partially.
  1. Bogdan Nafornita
  2. 1 month ago
RE "To me it's definitely more." Sure - process is an explicitly defined coordination. (Although one of the coordination technique is "managerial" or tacit-knowledge-based - see https://improving-bpm-systems.blogspot.ch/2012/07/coordination-techniques-in-bpm-social.html). Thus it is feasible to have one platform for all.
  1. Dr Alexander Samarin
  2. 1 month ago
@John... I really like "BPM is the technology which is specifically about automating work." with a minor elaboration that this does not mean that all steps in a process need to be "automated" (i.e look ma, no hands).

So, yes for "the work" and then regarding individual steps in any process, it depends - some steps can be auto-execute/ auto-commit, others need a person to say "this time we want to go this way, last time we went that way."

Point. . . with this definition we can have remote sensors poking data or being polled, every mm minutes, 24/x7, taking in data, with processes running where auto-exec steps wait for posted data or, in the case of non-auto-commit steps, wait for human entry.
  1. karl walter keirstead
  2. 1 month ago
+1 "explicit purpose". And "orchestration" too. But what is the subject of the orchestration? I submit it is "work". Purpose shows up as well when we "say work" - which is the "purposive expenditure of effort". And which is what humans do. BPM is the technology which is specifically about automating work. We start with a purpose and then we are more productive first-of-all using BPM work orchestration technology, and as well using other complementary technologies. So for sure platforms or BPM are "about working with data" - but the whole justification is (as @Emiel is alluding to) is specific work, of which the contents of our systems are symbolic.
  1. John Morris
  2. 1 month ago
@Walter -- You are absolutely correct -- just because one has technology, doesn't mean one MUST or CAN use it . . . lots of very small businesses do books on spreadsheets -- even though QuickBooks is available to them -- there's also the hurdle of skill. Some people don't yet know accounting. And maybe spreadsheets are "good enough" in terms of cost/benefit.
  1. John Morris
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 13
David Chassels Accepted Answer
I detect some ridicule on the capability that there is a platform that can actually address all business processes. Understandable as sadly it has been hidden awaiting the market to be ready.....no way is a start up in the UK going to change a market dominated by very large self interests. I want to encourage likes of Christine to continue her research in knowledge there is an answer. This is about customers not suppliers and frankly such a move is long overdue. To aid thinking a couple of links to aid understanding. Let's move on from ridicule and being ignored and get ready for the fight.....and winning for the customer....
References
  1. https://www.leadingedgeonly.com/innovation-marketplace/InnovationDetails.aspx?id=114.
  2. http://data.parliament.uk/writtenevidence/committeeevidence.svc/evidencedocument/public-administration-and-constitutional-affairs-committee/inquiry-into-government-accounts/written/38055.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Bogdan Nafornita Accepted Answer
The only way to fight the "delusional" comment is to make that platform a reality. I'll take the challenge. Of course, on a small scale - I'm not rich and do not live in a rich country. But I'll build as many and as diverse solutions as I possibly can, within the same framework.
Managing Founder, profluo.com
Comment
My chime-in on "delusional", by the way, was mostly aimed at a user in custom manufacturing having a struggle to relate to a platform meant for healthcare (with examples relating to healthcare) and make much sense of it for their situation - I feel terminology is the likely hurdle, not the fact that you could build/run a particular mock up of linked process steps.

I would be pleased to join in a cake-bake if anyone wants to organize this. All participants would probably pick up some tips/tricks that would improve what we do/how we do it.,

Best format would be GoToMeeting with a 30-minute time limit, starting with a verbal description of what to build at the start of the session only, to disallow advance preparation.

I'm sure each vendor paints themselves in a corner in some area of their packaging.

Starting in healthcare, we are next to paranoid about disclosure so things like portal access were 10 times more complicated that what we would reasonably have needed to worry about in, say, job shop ops or even aircraft MRO.

Not easy to hide the healthcare baggage for other implementations needing less security.
  1. karl walter keirstead
  2. 1 month ago
You raise good point about number of lines of code. We have 3 core components in our platform with file sizes as follows; the process engine 500k, the graphical interface to design and build the applications 1.75mb and the presentation layer including the tak library for MDM 1.1mb. I have no idea how this compares with likes of IBM but it is this type of interrogation that analysts need to carry out to help buyers make informed decisions...and set targets for vendors to deliver optimal platform tools to build operational processes as discussed in this forum...?
  1. David Chassels
  2. 1 month ago
Good, because your system sounds interesting, well thought out, over a period of something like 20 years.

My problem is I came late to the party, having done what seems to have been BPM for a long time without knowing what BPM was so I figure I will for sure learn a few things.

I don't have great concerns about demoing my software with 1,500,000 lines of code. Our tech folks repeatedly say we could give it away on a street corner with no great loss of "secret sauce" because we have always had three designs running. (current release, the next release and the one we haven't yet quite figured out what it should/needs to do).
  1. karl walter keirstead
  2. 1 month ago
Karl
It's the cake off approach which analysts should be doing....constantly to seek out identify the emerging capabilities and working on behalf of end user customers...not their vendor customers? The financial sector anaysts had these conflicts and took some blame for 2008.....and now independence is required...even if still abused...! In my opinion just a question of time before a court action on this failure in the IT Industry...but I shall not hold my breath!
I would happily arrange participate in such an exercise using our DBP.
  1. David Chassels
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Eyal Katz Accepted Answer
The answer to this question is Yes. However, allow me to change this question up a little bit. If the question was "With all the different business processes that currently exist is there a platform that can handle them all equally well then the answer would be No.

I don't know of any platform that is built to handle all needs equally well. That would be very challenging. First you have platform for Enterprises like SAP NetWeaver, for ex (I used to work there). Then there are those meant for small business management. Since SMBs don't usually have a single person, let alone a team, managing these tools then a BPM suite will usually also include other facets like HR tools an other resource management solutions. Small business solutions will never be able to handle the needs of an enterprise and the complexity of enterprise BPM, like SAP NetWeaver is overkill for SMBs. Now,m this can further be broken down by industry vertical, etc.

I guess the bottom line of my argument is that it doesn't make sense to build an absolute all-in-one BPM platform to address every need possible. It will be too expensive, take too long to develop, and will be unsustainable in the long term.
Comment
RE "SAP NetWeaver is overkill for SMBs" - it is also overkill for SAP as they stopped developing further this tool.
  1. Dr Alexander Samarin
  2. 1 month ago
As I have said business is simple when you analyse just what is required to support people at work where all information is created. You also need to understand that in reality even in large organisations people work in relatively small teams to achieve their required process outcome which are linked for the end to end process to deliver such as CRM SCM HRM etc. This is the outside in thinking a complete contrast to SAP inside out where scale is prority and complexity created and thus indeed becomes unaffordable for SMBs.....? This approach can use legacy such as ERP or the accounting system but they are the slave to new adaptive people driven processes. Indeed many aspects of such systems will be retired over time as this new proven approach creates on version of the truth making double entry book keeping redundant......RIP ERP?
It is incredibly simple in concept yet it works anywhere simple or complex. Yes it took about a decade to research build and test with early adopters to prove. Those early adopters now running for over 15 years with constant change being supported..suggest you read my links available above... One with over 500 UIs and just recently switched from client server to web with over half UIs converted for less than £50,000 Total cost over all those years c£10m but the real challenge was and still is folk from IT do not believe ...or is it do not want to believe......? Large vendors certainly will not welcome...that innovators dilemma is real...but resistance can only last so long? We have proven and would encourage others to follow there is an answer...
  1. David Chassels
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 16
@David.. I am struggling with "over 500 UIs" in your system whereas we have 4, one of which is almost identical to one of the others
i.e. ordinary user UI, portal (3rd party) user and, back end record-owner user.

What do the other 496 UIs do?
Comment
Yes such to do list is required as users log on showing allocated work as individual or as part of authorised group. The click on item then takes the user to the UI to start, continue or finish a task presenting required data and requiring new data etc ready for next steps. Time can be incorporated to permit activity based costing and escalations if time is critical. A manager module allows overview of progress and reallocation of work as required. Full audit trail who did what when with real time reports. All basic stuff and readily built by the Platform as previously indicated.
  1. David Chassels
  2. 1 month ago
Got it, makes sense.

Our UI's are application shells, The default UI is ONE screen with a calendar on one side (for fixed time tasks), then a to-do list on the other side where process steps post..

If a user is handling 30 insurance claims and if each has a step that is "current", the user will see 30 to-do items for TODAY.

Very easy to have things the other way where a user is handling 30 claims but none of these has a step that is 'current' for TODAY, in which case the users sees no steps for TODAY.

Users can park one todo at 0900 hrs, another at 1000 (microscheduling). Normally they just 'pick away' at the list and when they have performed whatever is needed at a step, along one path\instance, they declare the step to be "Done" and step clears.

The idea is to clear out the to-dos (all of them) or push some to tomorrow. Supervisors periodically remove pending tasks and assign these to others. (leveling and balancing).

Why more than one UI?

Mostly, as explained, for security reasons, to accommodate CRM - here we want greatly reduced functionality so a portal user only sees a to-do list for TODAY with no option for going to tomorrow, next week, or yesterday. Posting at the portal the normal user back end UI, where most of the buttons have been de-activated would accomplish nothing.
  1. karl walter keirstead
  2. 1 month ago
Every UI is custom form for use by specific users at that task point in process and of course includes UIs as reports. Adaptive capability needs this individual customisation which is easily created with the "SOA in a box" data centric architecture. It is an end to end case management system with in built means testing with some 75 process maps with over 2400 associated tasks all seamlessly linked..at a click..!
  1. David Chassels
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 17
Boris Zinchenko Accepted Answer
Every real business landscape consists of many IT systems. This versatility is objective. It does not appear due to poor IT management and planning. It is predefined with objective evolution of business. Technologies evolve, departments and teams appear and disappear, companies split and merge. Even with best possible planning, only a minority of these events can be foreseen. This creates inevitable business agility. This tendency gets even stronger with growing complexity and deeper penetration of IT into all areas of modern business. It is not realistic to expect that any single business platform will be ever able to handle alone this versatility of technologies and business scenarios now or in foreseeable future.

It is hard to underestimate importance of BPM in this quest of IT and business integration. Good BPM system serves as a government by defining standards and rules, which ensure smooth and efficient functioning of entire business. In terms of this definition, a monopoly of a single business platform would mean a notoriously inefficient command economy run from a single center. On the contrary, versatile IT systems and components implement an agile competitive environment where individual IT systems compete and coexist to deliver top performance of the whole enterprise to make it robust, resilient and open to new technology challenges.

http://marketbusinessnews.com/wp-content/uploads/2016/07/Market-economy-versus-command-economy.jpg
References
  1. http://marketbusinessnews.com/financial-glossary/command-economy-definition-meaning/
Comment
@Boris, "deviations as essential to adaptability and survival", should be a poster in the BPM lounge! That reality is much richer than can be captured by even the most enthusiastic team is one reason why I hope for continued development and success of process mining.
As for adaptability itself, I'm reminded that evolution is a group process. Adaptation at the group level ensures group survival. For random individuals however it's the end of the process map.
  1. John Morris
  2. 1 month ago
@John, I admire your comment. I m forever confused on how so many large corporations have central planning monster dreams in their top management, as if they have learned on books of soviet economists. I suppose fuzzy logic is most demanded omission in today's BPM approach. Deviations from once established process are traditionally considered as violations, while, in fact, they are the most essential asset of business adaptability and survival. Ironically, a perfect process execution system is dead very same moment it has been built because reality is always one step ahead of every most well designed process. Agility, flexibility and modular design are cornerstones of every successful BPM initiative.

@Bogdan, I m not so optimistic. I m watching too often as people still try to build BPMS systems as monolith monsters! The obscure habit to make all own way instead of connecting good services is still prevailing even in big corporations.
  1. Boris Zinchenko
  2. 1 month ago
@Boris, of course "execute natively everything" is stupid. This would be a monolith - those times are hopefully gone forever.
Even today this is not the case - how many people write their own mailserver or SMS gateways in order to execute Send Tasks in their BPMS?
  1. Bogdan Nafornita
  2. 1 month ago
It's great that the question of command economy versus market economy comes up in a discussion of BPM. And also, @Boris, to highlight the power of BPM as not just technology, but specifically a technology of governance. There are good reasons (even 'scientific' ones) why a market economy should function better than a centrally planned economy (including the question of corruption); one of the best reasons is related to pricing and planning. It's just impossible for central planning (e.g. the Soviet Gosplan agency) to match the efficiency and effectiveness of the price mechanism for resource allocation. Which brings me to today's question on platforms and diversity. Many of the criticisms of central planning can apply quite well to the governance of very large corporations -- and corporations don't even have to pretend to serve "the people". Central planning in very large corporations is still central planning; successful organizations like GE thus break things up into smaller units. (I note that this discussion now has three topics: BPM-as-technology; BPM-In-A-Platform; Corporate-Entity-Using-Platform -- they are all distinct.)
  1. John Morris
  2. 1 month ago
@Bogdan, in your interpretation of platform, it can (and, ideally, should!) orchestrate the whole enterprise. Confusion point for me (and not for me alone, as shows above discussion) is word "handle". Many understood it as "handle" == "execute natively", which is, of course, nonsense. Orchestrate all with one BPM system - definitely YES. Execute all inside BPM system itself - definitely NOT.
  1. Boris Zinchenko
  2. 1 month ago
Then we have different views of what a "platform" means (which is fine). My idea of a platform is an open one, that can easily orchestrate external systems to do jobs. You don't have to write *every single task* in the process engine in order for the platform to *handle* those tasks.
  1. Bogdan Nafornita
  2. 1 month ago
@Bogdan, business change itself is where BPM is most important. But I cannot imagine business change being an independent action of business platform as such. It is always an effort of company management. So, one platform can very well hold and describe all processes in a company. One platform, which some luck, can direct many or even most of these processes. But one platform CANNOT implement (handle) all processes, which it directs and describes. Implementation and execution is normally delegated to external systems where these processes run. @Ian wrote excellent comment above about this.
  1. Boris Zinchenko
  2. 1 month ago
"It is not realistic to expect that any single business platform will be ever able to handle this versatility of technologies and business scenarios now or in foreseeable future."
Not even an architecture that, unlike previous systems (that are targeted towards solving for business problems, i.e. resultants of change), is targeted as solving for business change itself?
  1. Bogdan Nafornita
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 18
David Chassels Accepted Answer
Indeed some good points but let me put different perspective on what a Platform is in respect to solving the software problem that has created a bit of a mess for business. I think there is general consensus the BPM discipline should be driving next generation outside in applications. Despite disbelief fact is the core business logic never changes nor will; people and more and more machines create all new data. Just how this can be supported is the debate.

At the moment we have different coding languages which despite "agile" create unfriendly environment for business and so that gap persists in build and change. Many years ago someone described what we had built was effectively a 6GL closing that interpretation gap and opening a new door. As such there is no reason why such a business language platform could not be used to create efficiency but on a different model to distrbute globally and being used to build next generation solutions for enterprise operational needs. Sure current coding will address very clever specialist IoDs etc but for delivery of Digital Business Pocesses a 6 GL is long overdue and will dominate but not on a single centre as described by Boris. A global sharing model involving collaboration on continued evolution of such a 6GL Digital Business Platform will benefit all users. Once business "get this" vendors and ecosytems will have to change their model as the costs tumble and business knowledge rules...not IT....well that's my vision....!
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 19
I see that the discussion has reached the enterprise application architecture domain. As usual, we are not very exact with some concepts. For example, RE “people still try to build BPMS systems as monolith monsters”. Who are “people” – BPM-suite tool vendors or customers’ implementation teams or both?

As stated in “Typology of platforms” ( see http://improving-bpm-systems.blogspot.ch/2015/12/typology-of-platforms.html ), a typical characteristic of a business execution platform is “a coherent set of functionality sufficient to run business in a particular business domain as a set of solutions which are assembled from microservices”. Two words “microservices” and “assembled” are operative ones.

As we known, microservices may be in various programming languages and they may come from different sources: COTS, FOSS, in-house, B2B, and as commodities. Microservices-base architecture is not about monoliths.

Assembling on the base of explicit and machine-executable processes is, so far, the best way to achieve agility and flexibility of enterprise solutions.

Thus a business execution platform delivers solutions for different business processes as simple as an experienced chef – via a combination of good practices, proper tooling, perfect ingredients, knowledge how to prepare huge variety of meals, absence of fear for experimenting and ability to talk to people to understand their needs.

Thanks,
AS
Comment
RE "it's the vendors" - Not only. A lot of consultants use this trick to make them indispensable. Strongly agree about "be seriously architected for change".
  1. Dr Alexander Samarin
  2. 1 month ago
"Who are “people” – BPM-suite tool vendors or customers’ implementation teams or both?" - it's the vendors.
This holy-grail-ish business platform is not anymore a process super-engine with lots of functionalities deeply embedded and integrated (that is the current paradigm). It is an orchestrator of business functionalities - and those functionalities can come from anywhere. It is this orchestrator that must be seriously architected for change, as requirements, functionalities and their underlying technologies are changing a lot, and fast.
  1. Bogdan Nafornita
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 20
I very much like Alexander's "Assembling on the base of explicit and machine-executable processes is, so far, the best way to achieve agility and flexibility of enterprise solutions."

And there is a parallel between an experienced chef and a knowledgeworker. Both are hired with the understanding that they don't need to be told what to do and secondly, that their "secret sauces" are not easy to cast in concrete.

No problem making life easier (perhaps not for them, but for their assistants who may need to participate in the Case management process) but the fundamental role of what Walter Brill calls the "umbrella" is to accommodate one or the other or all of ad hoc interventions (microservices), process fragment best-practices (microservices) and end-to-end processes. Orchestration comes from the actors in the case of ad hoc interventions, it comes from BPM process fragment/processes for the balance.

The other very important contribution under the umbrella is background governance, which operates at the run-time Case level (read umbrella) and here, the purpose is to rein-in extreme, unwanted excursions away from overall policy and procedure/best practices.

Think of the example of a two-way highway where the centerline provides guidance or orchestration and the border lines on either side provide guardrails or governance.

Then, overriding all of the orchestration and governance, not without risk and peril, is the Case Manager who is the ultimate decision-maker re what gets done, when, where, by whom and why, with executive command over when Cases get closed "It ain't over till the fat lady sings".

So, the 'microservices" / "assembly" approach is the way to go and of course you cannot in a large organization have only one umbrella - different divisions will have a different range of methods, facilities, tools.

The final frontier/challenge is a) to provide interoperability by and between the umbrellas at the operational level and b) provide analysis\consolidation facilities at a free-form-search knowledgebase for those whose job it is to evolve strategy and build competitive advantage.

See "It ain't over till the fat lady sings" (2011)
References
  1. http://wp.me/pzzpB-eh
Comment
Karl, you are perfectly right about "happy scenario" - Another option in M&A is to start building a CUBE platform to migrate all existing merged business parties.

John, RE "rather a template and an enabler of the unique technology platform required by any specific organization" - Yes and, even, for industry domains such as healthcare, Smart Cities, Smart Home, E-gov.
  1. Dr Alexander Samarin
  2. 1 month ago
Re: "it's the vendors" -- this raises the issue of IP ("intellectual property") and legal boundaries of software "products". @Bogdan has emphasized the importance of "price" in defining a market. We can add to that the question of law -- which creates a new dimension of differentiation around platforms.
Re: "typology of platforms", the idea of "assembly" and CUBE (@Samarin), these are excellent and systematic guides to planning for business execution platforms. It's worth reviewing a previous BPM.com discussion on this topic:
http://bpm.com/component/easydiscuss/3823-is-the-business-platform-the-future-of-bpm
and here on Dr. Samarin's blog . . .
http://improving-bpm-systems.blogspot.ca/2015/10/enterprise-patterns-peas-example-cube.html
I believe the CUBE approach is the rational engineering approach that would well serve any organization that wants to transform for future endurance (either directly or indirectly) . This position is not in conflict with what I have argued above that as it stands now, for technical and economic reasons, there cannot be a common technical business platform.
As I noted in my response to @Custis above, "universality" depends on what level of abstraction we are looking at: "The 'universality' we seek starts at 'work', continues with 'language' and eventually is also realized in 'notation' and 'engine'. Further up the stack, all bets are off, and we have application platforms, business economics -- and heterogeneity. But that's OK."
I see CUBE as a "business language of architecture". And per Dr. Samarin's work, there may be specific CUBE software e.g. "microservices". But the platform itself supports heterogenous components appropriate for sector and organization. CUBE is not a lock-in "product", rather a template and an enabler of the unique technology platform required by any specific organization. And as of today, CUBE is still aspirational.
  1. John Morris
  2. 1 month ago
Sure, CUBE is the way to go, but taking mergers and acquisitions as an example, it is not easy for an organization being acquired to transition to another platform(s).

The acquired organization is under the microscope in the early days and understandably wants to start off of a good footing. Accordingly, the least initial disruption the better, is their usual reasoning.

Integration hurdles, I am convinced, are intentional in healthcare. Hospitals/doctors resist sharing (concerns regarding security, increased exposure to malpractice suits, etc).

Software vendors resist data sharing (they feel customers will stay with them longer).

The happy scenario is the one where the acquiring entity (any sector) has a good CUBE platform and newly acquired entities are given time to transition away from their methods/tools.
  1. karl walter keirstead
  2. 1 month ago
RE "cannot in a large organization have only one umbrella - different divisions will have a different range of methods, facilities, tools." - It is another reason for a corporate unified business execution (CUBE) platform to exist. Although different divisions like to pretend that they are very different and thus need different tools, my experience shows that they use the same practical process patterns and many similar services. (See an example - http://improving-bpm-systems.blogspot.ch/2013/02/enterprise-patterns-peas-example-and.html ).

So, instead of many tools with lack of integration, various quality, different life cycles and inadequate support, a CUBE platform allows to unite the efforts to deliver diverse solutions from a common set of microservices. Reuse, support, agility, automation and integration are achieved by design.
  1. Dr Alexander Samarin
  2. 1 month ago
  1. more than a month ago
  2. BPM Discussions
  3. # 21
  • Page :
  • 1


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