Having read recently about microprocesses, and with the development of process apps, is it still important that processes be end-to-end? If so, why?
At the highest level, your customers want your processes to hang together end-to-end: Quote2Cash, Inquiry2Resolution. But so do you employees Recruit2Retire
Just depends on your business needs and your imagination. Is end-to-end for an employee onboarding? Recruit-to-hire? Recruit-to-hire-to-onboarded? Recruit-to-hire-to-onboarded-to-exited-to-offboarded?
All a matter of choosing your scope and having sufficient imagination about how you can represent and improve things before the beginning and after the end of your initial process definition.
End to End. It's the most non saying consultant talk in BPM country. Like saying processes must be rdedjf to dejjdle.. Indeed; what?
Processes are a means. A means to deliver a result. So please be clear about that result and don't call it 'end'.
It’s about making the ends clear, because customers don't want an end'. They want a bicycle, a mortgage, a solved problem etc.
So in all my projects I start at the end (oh...what am I saying now), by making clear 'what are we doing here' .-> what are the desired process results. And then walk back to see where the desire for the result came from.
It's actually applying the process discovery method of Alec Sharp, where the 1:1 relationship aspect is very helpful.
And yes, in theory you could call this end to end. In practice it should be made more concrete.
Microservices are an interesting architectural style but it raises two tough challenges in a business process context:
1/ business processes need to be stateful in order to be useful. Microservices are basically stateless, otherwise it's difficult to make them reusable.
2/ business processes imply a lot of orchestration and choreography so they need to retain a lot of the underlying business logic, especially around cancellations and compensations, and this is a nightmare to implement with microservices.
So, I don't really get excited about the famous statement of Martin Fowler: "Smart endpoints and dumb pipes".
In our start-up, we are struggling to find the right balance between the productivity of reusing generic process bits and the high degree of modelling accuracy required for execution. We haven't cracked it yet. I feel I am missing some new overarching organizing principle and this keeps me up at night.
- Bogdan Nafornita
- 1 year ago
I never understood this end-to-end concept. It is irrelevant. Each business process goes from Start-to-End. So, how do they communicate with other processes? Simple; through shared data. It is the only way systems components communicate; be it BP-to-BP, procedure-to-procedure, program-to-program, or system-to-system. Data is the cement that holds it all together.
- John Morris
- 1 year ago
Application Logical (for a given system), Enterprise Logical (for the whole enterprise), Enterprise Physical (for the whole enterprise), and Application Physical (for a given system). In BPM, only Application Logical, and Application Physical are used. The Enterprise models are defined and implemented by the Data Management organization. For more info, see:
BTW, BPM is perfectly capable to avoid your “dirty” data problem – see http://www.slideshare.net/samarin/practical-process-pattern
Also, you may compare your dissertation with my book (sorry, my dissertation was not in the English language but is available on demand).
- Bogdan Nafornita
- 1 year ago
Besides all that other important stuff, a process should be firstmost
[i]clear for the[/i]
This could mean it should be end-to-end for a bigger picture, clear, simple and above all practical for the average business user and pretty darn detailed for the developer or implementor... My advice therefore is to define a scope at the highest possible and
[i]relevant[/i]level, and consistently stay within that scope. When you run into border issues, rethink the scope...
If you want to know how an input into your enterprise (which is a system of processes -- see ref1) influences some outputs from it then you must know "End-to-End (E2E) processes". But in the majority of situations, it is not possible to present an E2E process as an BPMN diagramme because there are various coordination techniques (see ref2) may be used to "construct" E2E processes from classic (presentable as an BPMN diagramme) processes.
This is a mystery of E2E processes - they do exist but in many situations they can't be made explicit and machine-executable with the majority of modern BPM-suite tools.
I believe there is a need for end to end processes in terms of Business Intelligence, strategic management and process governance in the organization.
However, in practice, it is way easier to deploy smaller processes that interact through shared data. Having smaller chunks of logic is clearly an approach that gives more agility compared to monolithic processes.
No not at all. Some processes are unpredicable thus designing them end to end is inappropriate. However within these unpredictable scenarios there is room for microprocesses or process fragments e.g. a credit background check as part of a loan application. In these scenarios the role of the BPMS or Case management suite is therefore to guide and support and not to prescribe.
There are different levels of Processes. An end to end ACM process will have many operational processes that address specific issues but all need to seamlessly work together. An example 75 smaller processes with say 500 UIs that may include selection, means testing, payment scheduling, invoice creation, etc all work together for the end to end business objective handling ACM. Each process which could include “micro processes and process apps” has its individual outcome working towards that big objective. All need to be “complete” or “end to end”; the big and small all delivering on the final end to end application such as ACM
Let's use Insurance as an example. Today customers desire to directly interact through multiple channels (e.g., direct, online, mobile, agency) to review, customize, purchase, and change products and services, as well as submit and track claims. In order to do this effectively, Insurers and their customers (e.g., partners, distributors, end customers) must communicate directly though all stages of acquisition (i.e., new business, underwriting, policy admin, billing, custgomer service, claims) and retain correspondence throughout to create an efficient and effective experience and ensure compliance. So when considering automation for end-to-end operations insurers are looking at 5-6 core areas, each one broken into 4-6 core activities, each broken into subactivities which have associated rules, data models, and integrations. And since they are intrinsicly linked, you really need to consider how they impact each other before automating one. But automation has to happen to be competitive. So we suggest identifing the more pressing needs and select those with the greatest benefit. Then break them into their individual inputs, end-to-end activities, outputs, and outcomes, innovate and reduce waste, build in reusability, implement, then rinse and repeat, all while keepint the big picture in mind.
If you want to "
[u]sell[/u]" a process project, the
[u]best business case[/u]is probably end-to-end (e.g. O2C, or "order to cash" etc.) -- even if most of the time the whole E2E process is not a continuous BPM process. Which leads to the topic alluded to multiple times here, which is the "mystery" of E2E processes (cf. @Samarin). The real world of E2E business processes, including the enormous amount of un-modeled and never-to-be-modeled tacit knowledge and tacit work,
[u]just is[/u]. And sometimes we can automate parts of it. It's likely microservices make it possible to get a little more granular on what can be incorporated into an automated process.
The implementation isn't really the issue. End to end is ideal, but isn't always easy to accomplish for any number of reasons.
So we break up problems into smaller problems, as humankind has been doing since the dawn of our existence. The smaller problems are solved by smaller processes that link up one way or another (yes, through data, but in other ways as well) to solve the whole problem.
But however we do it, whether or not the process is end-to-end, the
[b]experience [/b]must be, especially for customer-facing processes. The more you fracture your processes, interfaces, etc., into discrete units, the more work you may have to do to ensure a consistent start-to-finish user experience.
Although business processes have from the beginning always been thought of as starting at the customer and ending at the customer, in pratical BMP in companies, business processes have in most cases been defined as functional sub processes. So we frequently find in process maps "processes" like sales processes, procurement processes, production processes and so on. In many cases there is even a mix up with company functions, such as sales, procurement, materials management or accounting.
But all these functions or functionally defined processes are just part of a value chain to create a service or product for a customer, for which they need to fit together. The functional process approach for sure achieved quite some results in companies: process awareness has increased, functional subprocesses have been improved and process management is accpeted as a positive contribution to companies' performance. However, to achieve further value added and to develop process management to the next level, it is now required to make a step from this partial process view to a real end-to-end perspective.
To be a business process, is necessary to answer all the questions from the business request until the final result (product or service) to the requester, properly aligned with business strategy (we shouldn't offer products or services that are not in our scope). So, it means that a simple sequence of tasks is not a business process necessarily.
The vision of E2E process is determinant to get the best efficiency of business operations (the main reason of structure the business by processes), which allow to balance the times, costs, quality, risks, etc., along the activities of the process.
Other question is how can we structure the business processes, ensuring the vision of E2E processes aligned with operational tasks. To do it we need a processes architecture organized by levels, from the highest level of macroprocesses until the lowest level of tasks. Otherwise, if we do just the operational level, what we have are isles of sequences tasks, from where we never get the best efficiency of business operations.
I understand that many organizations can feel confortable with just the operational level, suported by business services (sequences of system transactions), because it's better than old state of isolated transactions or rigid workflows introduced by ERP's or CRM's. Anyway, these organizations just can get the best efficiency when structuring their business operations by E2E processes.
- Page :
However, you are not allowed to reply to this post.