1. Peter Schooff
  2. BPM Discussions
  3. Thursday, 09 November 2017
  4.  Subscribe via email
From Karl Walter Keirstead: Any platform you put in place has to be able to seamlessly manage 'work' and 'workflow' relating to various entities or modules (inventory building, orders, manufacturing, shipment, customer service). So do you think it's time for most businesses to replace their ERP systems with a BPM/Case management system?
Patrick Lujan Accepted Answer Pending Moderation
Blog Writer
Apples and oranges. ERP, particularly SAP, is entrenched some thirty years now. The problem with ERP was that orgs tried to use it for more than it was designed, still do. There was some very bad bleeding edge years for a while there with Siebel, J.D. Edwards, et al.

Correspondingly, a BPM/ACM system would be further down the stack in terms of customization capabilities. Depends upon what they want, need to do. This isn't a "one size fits all" question and either approach can entail a lot of Benjamins if the problem domain isn't well defined or the implementer doesn't know they're doing which, of course, the vendors, SI and big consultants usually fit the bill on both accounts. Hammer, nail, proper tools and all that.

Just my tuppence.
  1. one week ago
  2. BPM Discussions
  3. # 1
Emiel Kelly Accepted Answer Pending Moderation
No, they should all move to an AI powered Digital business platform that can be fully controled in virtual reality.

Jokes aside; first understand your customers, your processes and their needed characteristics. Then decide what tooly things migh support them.

A ferrari solves a lot of problems, has great characteristics, but is useless on a dirt road.
Sharing my adventures in Process World via Procesje.nl
  1. one week ago
  2. BPM Discussions
  3. # 2
Dr Alexander Samarin Accepted Answer Pending Moderation
Each ERP is a monolith thus it must be turned into microservices. Obviously, an BPM-suite / Case-suite tool is mandatory but not sufficient. A good Corporate Unified Business Execution (CUBE) platform is the right choice.

Thus ERPs must morph into sets of ready-to-use good-practices business processes which can be easily adapted by an organisation. Such an adaptation can cover functions, integration, tools, etc. Thus, organisations may mix components from competing ERP vendors and startups.

@Alexamder - fits well with my notion of what would be needed

i.e. CUBE hosting highly automated processes phone call -> launch of order -> get from stock or make -> ship -> track -> receipt of payment with good predictive analytics on customer needs/patterns etc..

Huge programming exercises would be avoided by linking to existing ERP vendor apps/services (providing they can import and providing they can export).

Entry into this market space would be difficult accordingly "same as" approach would not work. However, consolidation of data to a real-time graphic Kbase where you see customers, orders, stock, suppliers, work in progress, shipments in progress might cause companies with legacy ERP systems to switch.
@Karl, sure, I remember that at one client we had a process-based shell around their monster ERP. But, we didn't manage to externalise all the events from that ERP thus it was not possible to completely hide it.
@Alexamder - same experience as you report - most monster softare suites presume users logging in with keyboard entry.

The huge problem is we are all moving to IoT where the desired option is to look at apps as peripheral services to some CUBE. Advanced liaison is via auto-export of requests, push to remote devices/have remote devices pull, processing is engaged automatically, results of processing are posted to the data exchanger with data pulled/pushed by the CUBE.

For software where data exchange is possible, we have seen HUGE problems in healthcare systems with vendors who have tried to embed their data exchange needs within their apps (creating, in effect, mini-monster apps that require a new version of the core app each time a minor revision is made to the data exchange facilities).

Developers of cloud apps seem not to have learned anythign from siloed server processing - many times there is no option other than logging in and keying in requests.

Better, in my opionion to park a generic data exchanger on the outbound side of the app so that automated postings can be made from withn the CUBE and so that automated pickups can be made by the CUBE.

Exceptions are direct push, wait, receive back when instant responses are needed.

Software developers need to understand there are two classes of "users" i.e. 1. humans 2. software apps, robots, machines
  1. one week ago
  2. BPM Discussions
  3. # 3
David Chassels Accepted Answer Pending Moderation
As a Chartered Accountant I never believed in ERP as the answer to running a business and certainly not for Governments.....it has been the biggest "con" in selling to businesses just look at the mess and that gap between such systems and people. If you have not got ERP great start that new journey with BPM supporting software building intelligent Adaptive Case Management systems empowering people and use legacy where useful.

Where ERP exists there will exist useful processing and functional systems which should be used and orchestrated by the process need. The New ACM must be the driver and importantly deliver that Adaptive UI / form recognising the task state supplying required data, the role of the user reacting to new data inserted. Over time ERP can be "retired" in controlled manner...replacement yes BUT plan very carefully over years!
  1. one week ago
  2. BPM Discussions
  3. # 4
Juan J Moreno Accepted Answer Pending Moderation
In our country, we say "Zapatero a tus zapatos" (Shoemaker take care of your shoes), meaning that each one should focus on its core capabilities.
In my experience, eight-heads monster software is born when trying to cover typical ERP capabilities from a BPM Suite package.
Of course, we all see processes everywhere, but it does NOT mean that a BPM Suite can solve every transactional, vertical, or business specific need.

Said that, I must point out that of course we are seeing, a great convergence between BPM Suites, ERP's, CRM's, etc, because at the end, all tools try to improve business processes. And maybe ERP's ends up eating BPM Suites, providing a set of process management features that make unnecessary to buy a separate BPM Suite. But this is just futurology...;)
CEO at Flokzu Cloud BPM Suite
Hmm I see DBPs eating up ERP!
  1. David Chassels
  2. 1 week ago
RE " maybe ERP's ends up eating BPM Suites" - SAP tried and failed with Netweaver.
@David, maybe but all 100%. For example, to implement all the "supply-chain" complexity at my current humanitarian client, I need just some some basic functionality from logistics, asset management and transport modules of an ERP, but all the clients processes are unique and not available in any ERP.
  1. one week ago
  2. BPM Discussions
  3. # 5
E Scott Menter Accepted Answer Pending Moderation
Blog Writer
Sometimes I look around at this industry I've been part of for decades and wonder how it is that the technology has changed so much, while the culture has changed so little. Two-hundred-page RFPs, multi-million dollar purchases, and giant monolithic software suites remain the norm, forty years after the introduction of distributed computing. The IBMs, Oracles, and SAPs of the world sell software the same way they did decades before the Internet, smart phones, and GPS, all the while touting endorsements of their innovation issued by analysts largely funded by those same companies.

Should you replace your expensive, clunky, high-maintenance enterprise software suites? Yeah.
http://www.bplogix.com/images/icon-x-medium.png Scott
@Scott . . .Perplexing indeed.

In healthcare, some of the "top" EMRs/EHRs still promote MUMPs (1966) as a "solution".

No incentive to change, it seems, so long as offshore programming services can be contracted for at $20 per hour.
  1. one week ago
  2. BPM Discussions
  3. # 6
John Morris Accepted Answer Pending Moderation
Should BPM/Case replace ERP? Let me add to the set of "multi-headed monster references" in this forum question (+1 @Juan): Today's question is a multi-headed monster: (1) Is replacement technically possible? (2) Is there a good use case? (3) And what about the business case? All these questions are necessary however much ERP is considered a monstrosity.

Technically one cannot replace ERP with just BPM/Case. This is because ERP is a set of modularized software providing business functions based on irreduceable foundational technologies of database, rules, process, analytics, UX etc., plus code and technical architectural/functional software artefacts such as APIs, identity management and security. And then there are specific business functions layered on top of this, especially the idea of transactioning (accounts, orders etc.) And then we get to first-class business functions (cash flow, inventory etc. etc.) (The systematic attempt to model enterprise eventually gets labelled as an "enterprise ontology", a nice term but not yet productized for popular adoption.)

BPM/Case defined as technology ( as opposed to a definition as "everything but the kitchen sink development platforms" ) is a necessary but completely insufficient basis on which to build the business functionality currently supported by ERP.

As readers of BPM.com know, I advocate for the centrality of the idea of business process management technology as the technology of business. But just because BPM is the technology of business, does not mean that it is sufficient on its own for the construction of full business modules. What Churchhill said concerning democracy could be said about ERP: "It's the worst of technologies; the problem is we have nothing better."

Positive Postscript: Insofar as the original question comes from a place of ERP pain, one can ask about the way forward from ERP costs and inflexibility. There are both technology and vendor/market answers to this question. The words "disaggregation" and "ontology" come up. Suffice to say that #BPM process technology will be at the core of "ERP II".
TWEET: #ERP: The worst of #technology. Except we have nothing better. Or do we? What about #BPM #process & #case technologies? Can we free ourselves from ERP and #getAgile with process? - http://bit.ly/2hYYXQS - @BPMdotcom @PSchooff #Transformation #BusinessAnalysis
  1. John Morris
  2. 1 week ago
  1. one week ago
  2. BPM Discussions
  3. # 7
David Chassels Accepted Answer Pending Moderation
I think Scott raises really interesting point one that may well result in some rather large casualties as next generation enterprise digital software moves in. There is much talk about how "Automation" could reduce jobs but to my mind this needs focus as to "where"? Those at the front line are in good position where tangible empowerment will enhance their jobs. It's looks like those in the "middle" are now under threat. Looking at the enterprise software industry which has seen little change selling monolithic systems as Scott articulates; so who are the "middle men"...? Sure big vendors will take a hit but is it not the "Systems Integrators" and large consultants whose days are numbered? They have been the beneficiaries of the monolithic systems such as ERP over selling of their benefits. Other industries are facing such challenges ....this is the one now facing the IT business software one? No wonder SIs resist cost savings for end customers....certainly been our experience! Time for businesses and Governments to wake up and become the "Intelligent buyer" and understanding the BPM principles is easy and now readily supported in delivery...too easy for those vested interests....?
When a customer is attracted to "customizable" software there typically are five scenarios a) customizable by customer "power user" b) customizable by customer "tech staff" or c) customizable by your friendly neighborhood independent consultant or VAR d) customizable by an army of vendor "experts" - the cost escalates as you move through a-b-c-d.

It's not unrealistic to see a 100 times differential between a) and d).

And, of course, not all scenarios are possible for a particular software suite.

The "customizing" also varies from easy, to difficult, to very difficult, to too difficult.

It's hard to sympathize with buyers who have no clue what their needs are and put out RFPs with checklists consolidating all of the "features" that all of the vendors list in their bafflegab.

Then we have buyers who put out RFPs when they have already decided which vendor they want to work with.
  1. one week ago
  2. BPM Discussions
  3. # 8
Bogdan Nafornita Accepted Answer Pending Moderation
In today's world, a monolithic approach to any problem will not get you too far, that is - if it gets you anywhere.
Yes, as Scott mentioned, the mentality of vendors is still entrenched in the "one-stop-shop" phase, just because it's easier to cross-sell to existing customers.
Also, the hypocrisy of this approach (on both sides, the vendor and the buyer) is staggering.
That's why operations say ERP stands for "Excel Runs Production" and SAP stands for "Scheiss, Angst und Panik" (do your own translation :-) )
Managing Founder, profluo.com
@Bogdan, What a marvelous re-phrase of ERP and SAP! I agree that translation will kill the spirit. Hope colleagues with some German will appreciate it same as i do.
  1. Boris Zinchenko
  2. 5 days ago
LOL! ERP stands for "Excel Runs Production"
Boris Zinchenko Accepted Answer Pending Moderation
BPM is a command center of the digital enterprise. In this capacity, BPM in no case should replace or duplicate process execution systems, such as ERP, CRM, ETL, QAS etc. Such duplication cannot bring anything except for down-standard replicas of true ERP and other specialized systems, which took decades to establish and mature. On another hand, BPM command interface must become an integral part of ERP management, which is already a reality e.g. in SAP and nearly all other leading ERP systems. It neither means that ERP replaces BPM, nor that BPM acquires ERP. Rather, it reveals valid and important projections of BPM into existing process execution environments.

The next logical step should be unification of these versatile BPM interfaces of various execution system, which will allow transparent execution of business processes across system boundaries. We already watch significant progress in this direction through continuous proliferation of uniform standards for business processes, such as BPMN, DMN and other notations. When these integration tendencies will accumulate sufficient support among vendors of enterprise software we will be a step closer to BPM governed world with individual services and systems orchestrated and run through centralized and vendor agnostic business management facilities. Judging by the speed of penetration of BPM techniques into specialized business applications, such as ERP, in recent years, we may see this reality of business integration on BPM foundation sooner than expected by many experts in the field.

Please tell us how you get graphics to post !
@ Boris ... "allow transparent execution of business processes across system boundaries." seems to be the way to go.

"BPM" (CUBE?) is capable of providing the orchestration (workflow), RALB (resource allocation, leveling, and balancing) can take care of workload.

The out-arrows in your diagram, to me, represent "task requests". i.e. you message a processor called ERP, for example, it returns value-added data and that data joins other data at the hub for possible use at next-in-line process steps.

Two things we do not have to worry about or should not have to worry about are:

1. Silos - the hub with RALB/BPM where the BPM steps have assigned roles, re-defines silos as resource pools. If a step calls for "electrician" then the pool either has such a resource or you wait.

2. Standardized message formats - sure, it would be nice, but why not allow each set of trading partners to agree upon a format and let each write out and read data elements using their own preferred data element names? Most will pick a standard (why invent new if you can find one that suits?) but just as we allow deviations away from rigid processes, it is not difficult to accommodate custom formats per pair of trading partners if you have a generic data exchanger.

The big hurdle is that many systems do not accommodate other than direct data entry (they cannot read/parse/import and they cannot write/format/export).

Exceptions, of course, are banking industry messaging, customs transactions, some b2b, etc.
Never ever put a technology in the centre of business universe - any architect will veto it.
@Karl, @Scott, thank you for valuable clarifications to my diagram, which i did not care or had a patience to highlight. Silos is an alarming word for me. I precept a silos as potentially important data, which were not paid enough attention to be structured and interpreted properly. For messaging i suppose that various sorts of enterprise message hubs are taking a spin in nearly all industries and JOSN packaging becomes de facto a standard for micro services. In most ancient cases, automatic filling of fields in a web browser or even desktop forms is always an option.
  1. Boris Zinchenko
  2. 4 days ago
@Alexander, thank you. The picture was intended to depict technical universe,rather than business universe. On another hand, BPM is not entirely a technology but a vision. As a vision, it inadvertently tends to a center of architecture, even if not explicitly intended or endorsed to appear there.
  1. Boris Zinchenko
  2. 4 days ago
@Boris, RE "As a vision, it inadvertently tends to a center of architecture" - what system are you talking about? Business System (i.e. an organisation) or technology system? BPM can't be the vision for the former. Knowing that the latter is derived from the former then BPM is only one, although essential, component. Thus BPM can't be in the centre again.
Scott Francis Accepted Answer Pending Moderation
Blog Writer
I'm just impressed someone got a graphic posted in here :) BPM at the center of everything! :)
  • Page :
  • 1

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