BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Thursday, October 08 2015, 09:47 AM
  4.  Subscribe via email

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?
Ian Gotts Accepted Answer

At the highest level, your customers want your processes to hang together end-to-end: Quote2Cash, Inquiry2Resolution. But so do you employees Recruit2Retire
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Scott Francis Accepted Answer
Blog Writer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Emiel Kelly Accepted Answer

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.
Common Sensei at Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Bogdan Nafornita Accepted Answer

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.
Managing Founder, profluo.com
Comment
thanks Doc for the great reference, I will for sure take some time to read it. There is a plethora of valuable advice there, I have no excuse for missing it so far.
  1. Bogdan Nafornita
  2. 1 year ago
Stateful Service Orchestration may be a way to practical microservice architecture by constructing more-responsible microservices from less-responsible ones thus reducing the potential complexity. Microprocesses as explicit and machine-executable assembling of microservices is a potential match with microservice architecture. See http://improving-bpm-systems.blogspot.ch/search/label/%23microservices
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Tim Bryce Accepted Answer

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.
References
  1. http://timbryce.com/
Comment
Agility has nothing to do with it. I can change business processes on a dime, but the fact remains the only way processes communicate is through shared data. That is an inescapable fact.
  1. Tim Bryce
  2. 1 year ago
I would be very worried if something is cementing my system which must be agile.
"Data is the cement that holds it all together" -- can't be said often enough.
  1. John Morris
  2. 1 year ago
The logical data base contains only primary values (since generated values can be calculated from them). In the physical world, the data may be stored many different ways, including generated values, if there is an access problem. In my world, there are four data base models:
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:
http://www.amazon.com/PRIDE-Methodologies-IRM-Tim-Bryce/dp/097861822X
  1. Tim Bryce
  2. 1 year ago
@Tim, maybe you meant common/standard data types not shared data? Sure the former are useful if being used within services.

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).
Failure to recognize data as a reusable resource is inviting redundant data; what we call "dirty" data, meaning how it is defined in one system is inconsistent with how it is defined in other systems, which could very well lead to erroneous information.
  1. Tim Bryce
  2. 1 year ago
Nonsense. Don't make me go into a dissertation on the virtue of Data Management. Data transcends system boundaries and should be shared in all systems of an enterprise. Data is to systems what parts are to assembly lines. This is why the concept of Information Resource Management (IRM) is akin to MRP.
  1. Tim Bryce
  2. 1 year ago
I agree with Alexander, although it may be just a questionable wording from Tim. Communicating through shared data is a very painful coordination scenario (as Alexander said, "tight coupling") in process-driven applications design.
  1. Bogdan Nafornita
  2. 1 year ago
I think, “your” processes are only components in “my” system. Use of shared data between components creates the tight coupling between those components thus reduces agility of the system. For example, microservices use only API to communicate between them.
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Walter Bril Accepted Answer

Besides all that other important stuff, a process should be firstmost 
[i]clear for the[/i]
[i]relevant audience[/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...
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6

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.


Thanks,


AS
References
  1. http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html
  2. http://improving-bpm-systems.blogspot.ch/2014/03/coordination-techniques-in-bpm.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Philippe Ozil Accepted Answer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Peter Whibley Accepted Answer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
David Chassels Accepted Answer










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



Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Garth Knudson Accepted Answer
Blog Writer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
John Morris Accepted Answer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
E Scott Menter Accepted Answer
Blog Writer

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.


 
http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Alisa Addison Accepted Answer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Jose Camacho Accepted Answer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 15
  • Page :
  • 1


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