BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 27 July 2017
  5.  Subscribe via email
From Kay Winkler: In the context of buying a BPM app (as in a premade on-boarding process), how does this compare with buying a BPMS and creating a tailor made process?
Accepted Answer Pending Moderation
Depends on the BPMs.

Does it support Adaptive Case Management?

The core requirement plan-side is to be able to evolve your own inventory of processes (otherwise you become an "also-ran" and your chances of pulling ahead/keeping ahead of the competition are greatly diminished).

The core requirement run-time side is to be able to dynamically allocate / re-allocate scarce resources to patients, orders, insurance claims, law enforcement Cases, where priorities can shift from one moment to the next.

Click on the link below to see my 11 "Basic Requirements for Success with BPM"
References
  1. https://kwkeirstead.wordpress.com/
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
There are already lots of commercial startups that use BPM behind the scenes to implement. you won't know it using their software, but they do. So let's set aside the "apps" that no one even knows are BPM under the hood.

How about cases where we do know it is BPM? Why would we know it is BPM? presumably because there was some advantage in us, as customers, knowing that it was built with BPM. What would that advantage be? would it be that the development team was faster building it, and i got my standard app (onboarding app?) faster? Or (spoiler alert) is the advantage that i know the vendor can customize the processes driving the app to my business?

If the advantage is that the customer can build it themselves, then I think that's fine too, so long as that's in the definition you're using of "app" (i.e., not just something i can buy off the shelf, but something i can build for myself).
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Let us start from an analogy: If somebody wants to cook a very good meal then this person looks for a good recipe and proper tools to execute it. After a few tries this person masters this recipe and adapts it for his/her taste. Also this implies that such a recipe is written in a commonly understandable language and a required tool set is rather standard (remember the "Anna Karenina Principle In Software Engineering" from the previous discussion).

With this analogy, the answer is: BPM-suite vendors and BPM consultants, please, make your tools and your methodologies standard enough thus, we, your humble clients, can easily combine the universality of your means and diversity of owns needs for the best of everyone.

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
"In the context of buying a BPM app (as in a premade on-boarding process), how does this compare with buying a BPMS and creating a tailor made process"

It depends on how the premade BPM app is constructed. If it's built using a BPMS and good design and implementation practices, then it's likely to be a better choice than starting from a blank page.

This was the premise of the Smart Process Applications that were in vogue a few years back - and I still believe in the concept. If the app is built properly, then you can use the underlying BPMS to modify and extend the functionality of the app to meet the needs of your business (as they change).
This is a great idea - but I haven't personally seen any packaged app vendor pull it off.

If the premade BPM app is "just code", then you are going to be limited to the configuration options that the vendor supports. This may still be a better choice than starting from a blank page, but you will be completely dependent on the vendor to provide the flexibility that your business needs to adapt to changing needs.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
First what does the "S" mean...Suite...no now in history? Solution...hmm any solution should be called what does as BPM is only the thinking to establish requirements. Software I go for this as logical the software delivering capability to implement any BPM tailor made requirement.

Now that no code capability exists in "BPMS" in a DBP to very quickly build custom adaptive solutions it is a no brainer as much quicker and better value to build and have control over build environment for inevitable change with no lock in?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
Completely not viable. BPMS is just the core that helps communicate the "how" to the customer and accelerate the joint app design process.

But next to that you need a great experience using the app, a great data model, an excellent open architecture, a great insight layer etc.
CEO, Co-founder, Profluo
Comment
@Bogden. I think you have just highlighted the confusion on what BPMS is...? I agree the software to support BPM needs to be transparent and with well structured architecture recognising the layers of connectivity to be orchestrated. This is what easily beats any inflexible pre made process application. [email protected]
Perhaps I'm misunderstanding Bogdan's point, which seems to me to be thoroughly wrong. A system that provides "just the core" functions mentioned wouldn't be a BPMS at all—it would be a model or simulation engine, at best.
Is the idea that the "experience", "data model", "insight layer", and "architecture" are delivered through some other mechanism? And would, perhaps, that mechanism be "programming the way our forefathers did"? Because, if so, it's not clear what I need that "core" for in the first place.
How about we improve the lives of programmers by allowing them to work at software companies, and improve the lives of everybody else by using that software to deliver custom end-to-end business applications without having to develop it themselves. Just a thought.
@E Scott: My point is that most BPMSs treat everything other than the core process engine (model+execution) as an afterthought or half-assed execution: interfaces (ask Scott why he is successfully selling Brazos UI on top of IBM BPM), data models, analytics etc. I cannot imagine a good, modern, enterprise process app with these as second-class citizens.
I know that my pov is contrary to that of most of my US friends (see Patrick's point below). You guys come mostly from a world of Fortune 500 CIOs, who are used to spending lots of money in getting the absolute most and best of a BPMS - in that case yes, you can get viable apps solely via BPMS. But then, given those amounts of money, you could build viable apps with *anything*.
I however come from the dark world of scarcity, applied to my target segment: no mid-sized enterprise in this world will ever spend on average half a million bucks per year (see Appian economics) for having "viable apps" built with an over-engineered BPMS solution.
As I said before - yes a BPMS is a good start for jointly developing the application logic together with the customer, but I cannot view it as a one-stop shop for developing apps - I don't believe in monoliths.
@Bogdan "I don't believe in monoliths." +1
  1. John Morris
  2. 1 year ago
  3. #4283
LOL "not believing in monoliths"
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Depends on the definition of "viable." If viable is functionality doing what's needed, required and built in a time frame and at a cost that was within the bounds defined for the project, 'yes.' Most current BPMSs are n-tier platforms with middleware, database, security integration to LDAP, APIs and a solid capability for presentation tier, including mobile. As such, "yeah," you can build something "viable" solely and singularly on your deployed BPMS of choice and its underlying infra. This has been going on for a while actually.

Now, as to comparisons about pre-made apps built on a given BPMS versus rolling your own, that again comes back to that pyramid of functionality, time and cost. That's a 64,000' level question with myriads of responses based upon the goals and objectives of a given business solution and its user base.

Just my tuppence.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
What an awesome question! ;) But even more importantly, great answers and different takes on it. Thanks to all for contributing with your inputs!

In our particular market environment (LATAM) we indeed have seen an important market shift, away from platforms (ECM, BPM etc.) towards end-to-end solutions, that typically are wrapped up as apps. Behind the scenes, these do, naturally, consist of BPMS, SOA and other components. In that sense, the points Alexander, Scott and John made, fit right in and are absolutely relevant to us as company as well. BPMS based, powered, driven or complemented applications have to be highly standardized in order to make sense to the customer in the long term. Also, the BPMS core pricing has to be aggressive enough in order to mitigate, or to at least lower, the effect of redundancy, investment wise.

So, from what I have experienced, "BPMS Apps" do not represent the magic bullet, have to abide to certain parameters (standards, pricing, process type) to be sensible for a customer, but they do seem to face both - increased demands and also supply in the market. In the short term, such apps maybe cheaper to have and entail a lower LoE than starting out from "scratch". Also interesting to notice is that it indeed is very common now, to see users with several BPM technologies and flavors in their environments, coexisting (more or less in harmony :D ) side by side.
NSI Soluciones - ABPMP PTY
Comment
Kay, similar environment in my part of the world: hybrid, aggressively priced, end-to-end solutions.
If I were to add to your comment, I'd say modern solutions shift away from being vendor/technology platforms (ERP, BPMS, ECM, DMS etc) to being customer platforms (a DBP connects and orchestrates *any* technologies as needed to solve customer problems).
  1. Kay Winkler
  2. 1 year ago
  3. #4303
Great input! Thanks.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
If I have an hangover, I just want an aspirin to solve it. Not a chemistry box to develop my own medicine.

So, this should always start with a proper understanding of the processes you'd like to support. Boring back office processes (hangovers) like Accounts Payable (why don't they call this "Pay Invoice" by the way); why not buy a solution? Maybe you have to modify some parameters like tax, currency, vendors and users but if the solution cannot cope with that, it's not that good.

As an idealistic process guy, I would like a Chemistry box for my real pains (primary processes). Build my own processes. And that is something different than building my own apps in a BPMS. Processes need many more enablers. But that's nothing new of course. But, building your own processes can also use pieces of standard equipment. Like my pizzeria didn't build his own oven. But we developed our own recipe!

Lot's of words to say that a performing process is more than the tooly things that support it. It needs good understanding of your processes. If you don't have time for that, it might be smart to buy some flexible stuff to support it.

And wanting to be more flexible and less dependent, that's a trend I see; an Anti-Enterprise-Software movement.

Organizations sometimes want an aspirin, sometimes a little part of the chemistry box with some basic medicines with some good help to adjust it to their own needs. And sometimes they want to develop their own medicine. But they want to be in charge. Not the vendor of the chemistry box.
Sharing my adventures in Process World via Procesje.nl
Comment
RE "Organizations sometimes want an aspirin, " - usually, they need a unique combination of commodity pils and in other words unique processes built from prefabricated fragments (which correspond to patterns).
@Emiel: funny to have brought the aspirin example - you may have heard of personalized (or precision) medicine? It is the prescription of personalized medical treatments based on individual risk of disease and individual predicted response to treatment. Hugely more effective than generic medicine, arguably the future answer to mis-medication (over- or under-).
Even before prescription medicine, you may have noticed that you respond differently to different pills for a hangover (or headache, or flu). That is because your body is unique and it responds better to some treatments than to others.
  1. Emiel Kelly
  2. 1 year ago
  3. #4282
I can see that, Bogdan. Tailored is always better, I think. But if a general thing just solves my problem quick and cheap (and I know there are not many risks), I'll take that option.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
@Bogdan Well said I see the future for enterprise software as that removal of such silos with DBPs reflecting how businesses really work putting people first orchestrating all layers e.g. people, tasks, data. legacy etc exactly as required. It will be at fraction of cost for customers...might be "costly" for big vendors...?

As for @EScott comment " ....programmers by allowing them to work at software companies, and improve the lives of everybody else by using that software to deliver custom end-to-end business applications without having to develop it themselves." Sounds like big vendor vision but no longer sustainable . Sure enterprise software companies will employ clever programmers but with objective to create software which allows their customers to have control including build over their business processes without need for programmers. It will be very "disruptive" but a move long overdue. It is effective commoditisation of enterprise software putting the customer in control. BPM is a door opener....?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
I think Emiel's analogy is a bit oversimplified, as there are plenty of business processes with the same name and general understanding (e.g. cost approval). However in each and every organization they function differently. So by buying a pre-made "medicine" I'm risking ending up with solution to someone else's (or some imaginary) "pains".

Additionally, when I buy a pre-made solution, I have 2 options:
1. To adjust my organization to how the application works, which doesn't make sense
2. To adjust the application to my individual needs which in many cases takes more time than building it from a scratch.

If you have a BPMS that is flexible and allows to deliver quickly, implementing app from a scratch will always be more beneficial.

If you have a monilithical monstrocity that takes months to deliver even small app, then maybe in such case pre-made solutions make more sense. But why invest in such solution in the first place?
http://ocrwdokumentach.pl/wp-content/uploads/2017/02/WEBCON-logo-mini1.png
Comment
Hard to follow all of these analogies and figure out what the underlying issues really are.

I don't get " ...If you have a BPMS that is flexible and allows to deliver quickly, implementing app from a scratch will always be more beneficial."

Sure, the customers want a "BPMS" that is flexible and allows quick delivery - but for apps ???

I figure a BPMS is a bit like MS Word.

Both are 'shells" that let you, in one scenario, stream Case records on to process templates to give private instances and, under the other scenario, let you type up a letter.

There will always be no end to the need for "apps" but if the BPMS accommodates basics relating to running processes, then any other engines surely don't need to be developed within the BPMS?

Why not just develop these anywhere and just message them to get the functionality you need. You message, the processing occurs, you get back processed results that flow into your BPMS?
One example of apps NOT to build within a BPMs. IMO, is a critical path algorithm that takes task durations and gives you back Early Start - Late Start - Early Finish - Late Finish values, and of course, your Critical Path.

Given that new BPM and a lesser number of ACM "apps" are able to assign durations to forward tasks, why add bloatware to the BPMs environment?

Seems to me a lot easier to export your template instances to a bona fide CPM app, have the app do the calcs and then come back with results you can use to adjust the timing of forward steps along your template instances.

Clearly the CPM app needs to be able to build a flowgraph from imported data, clearly it takes time to load the data, and time to export and upload results back to the BPMs but few users need/want real-time ES-EF-LS-LF calcs, so any "inefficiencies" in data export/transport/import/calcs/export/transport/import are insignificant.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
@Kay

It would probably be informative to hear from you what a "premade on-boarding process" is.

A second question is - Are there any BPMs' that wrap up process mapping i.e. "creating a tailor made process"? I don't get why would anyone would want/need this when 99% of the time users are running instances of templates compared to building templates?
Comment
@Karl I am confused..what exactly is " template"? Sounds like a pre built task already to configure and able to be linked to others ready to deploy?
The capability certainly exists to build custom tailor made process direct from the process map no need for programmers....
@David - Not sure how others describe "template" but our notion of a template is that it is the result of "compiling" a graphic flowgraph featuring tasks, interconnected by directional arrows, with some merge points, branching decision boxes, and a few loopbacks where re-iterations are anticipated.

Compiling \the plan-side graph gives you a run-time "template" of your process.

If 5 automobiles, part of a fleet of automobiles at a corporation come in for servicing at a service center, the service center would use the template five times to generate 5 private instances - each of the 5 autobiles will need different deviations from their instances, some will need less work, others more work.

I suppose you can think of cookie cutter as a " run time implementation" of a drawing of a cookie cutter. Each time need a cookie, you go to the template.
@Karl Thanks think now got it it is that graphical display of the required process. When you say "compiling" is that compiling code or compiling the required pre built tasks? We do the latter all business logic covered by less than 13 so we end up with a template..? Is template a widely accepted term for this.....makes sense to be agreed as a standard term for the display of the actual ready to deploy process?
The "template" (no idea if this is a widely accepted term), is not the graphical display.

"Compiling" the plan-side graphic display involves carving up the process map into discrete steps, and writing out database records for the steps and the logic connections between steps. (i.e. deploying the process).

A run-time side workload engine then goes to the database and posts steps, to the attention of the right users, based on plan side assigned "roles", as these become current.

The engine loads the right plan-side forms when a user clicks on a current task, the user performs any required work, fills in data attesting to the completion of the work. The engine then moves the processing along to the next-in-line template step(s).
Agree the power lies with the orchestration of people, their roles, data ( including legacy) and presented in UIs reflecting the specific instances as users sign in. This truly brings into use the power of a relational database! With us the graphical design is the build of that "template" ready for use.
  1. Kay Winkler
  2. 1 year ago
  3. #4304
Hey Karl! It was an example. So, in that case, imagine maybe a vertical specific onboarding process (example: Consumer Banking for a specific region) where all possible product variations a customer could chose from are covered (e.g. Credit Cards, Car Loans, Personal Loans, Mortgages) as well as all relevant evaluations and calculations (e.g. bureau integrations, credit scoring, spreads and payment projections). The customer then, instead of building the process, would rather use the "solution" and change the parameters to his liking (logical process flow sequences; e.g. 2 vs. n approvals, risk weighting formulas and so on).
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
A revealing question! Is a purely BPMS-based app viable . . . (considered possibly as technology, or as business model)?

And revealing answers! With lots of meat to chew on. Or vegetables, if you prefer.

How about the viability of the question itself? Why is it even sensible to ask if viable applications can be built around "technology 'x'"?

My answer is that the question can be asked specifically about a BPMS because BPM technology is THE technology of the work of business.

See the article on BPM.com on this topic:

Why BPM Is Unique & Important: Part 1 - One Technology of Work

So, from a technology perspective, a BPMS (which is the technical product instantiation of BPM technology) is at the core of almost anything that we want technology to help us with. A good place to start.

Is a BPMS-based application enough? Probably not.

There are other irreducible complementary technologies such as analytics, business rules, UX, database etc. that will need to be added to the application. You will still likely be able to say however that the BPMS is the core of the application.

There's an additional dimension that's been referenced in the discussion above, and that is domain knowledge. The idea is that there are common business processes and differentiating business processes. And the question arises, how does one have a viable application at different levels of deviance from standard processes.

This question has moved us from the world of technology to the world of business markets, technology markets, corporate governance and economics. It's about technology ecosystems and product packaging. A BPMS will enable core functionality in a given application, but the implementation of domain knowledge in the application is a separate task.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation
@John touches on the core issue of confusion on what is BPMS "So, from a technology perspective, a BPMS (which is the technical product instantiation of BPM technology) is at the core of almost anything that we want technology to help us with." BUT then goes on to say
"There are other irreducible complementary technologies such as analytics, business rules, UX, database etc. that will need to be added to the application. You will still likely be able to say however that the BPMS is the core of the application."

A platform that delivers the working application based upon BPM leadership MUST include rules UX database etc....so why does the BPMS term even exist if deficient in such key attributes. No wonder business folk get confused ...but of course that suits big vendors who really do not want customers to understand their technology....and the analysts who thrive on market confusion.....?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 14
  • Page :
  • 1


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