Resolved
2 votes

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?

Thursday, October 08 2015, 09:47 AM
Share this post:
Responses (15)
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Thursday, October 08 2015, 09:56 AM - #Permalink
    Resolved
    5 votes

    At the highest level, your customers want your processes to hang together end-to-end: Quote2Cash, Inquiry2Resolution. But so do you employees Recruit2Retire

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 08 2015, 10:07 AM - #Permalink
    Resolved
    5 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 08 2015, 10:08 AM - #Permalink
    Resolved
    4 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 08 2015, 10:21 AM - #Permalink
    Resolved
    4 votes

    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.

    • Dr Alexander Samarin
      more than a month 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
    • Bogdan Nafornita
      more than a month ago
      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.
    The reply is currently minimized Show
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Thursday, October 08 2015, 10:21 AM - #Permalink
    Resolved
    4 votes

    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/
    • John Morris
      more than a month ago
      "Data is the cement that holds it all together" -- can't be said often enough.
    • Dr Alexander Samarin
      more than a month ago
      I would be very worried if something is cementing my system which must be agile.
    • Tim Bryce
      more than a month ago
      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.
    • Dr Alexander Samarin
      more than a month 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.
    • Bogdan Nafornita
      more than a month 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.
    • Tim Bryce
      more than a month 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.
    • Tim Bryce
      more than a month ago
      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.
    • Dr Alexander Samarin
      more than a month 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).
    • Tim Bryce
      more than a month 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
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 08 2015, 10:27 AM - #Permalink
    Resolved
    4 votes

    Besides all that other important stuff, a process should be firstmost clear for therelevant audience...

    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 relevant level, and consistently stay within that scope. When you run into border issues, rethink the scope...

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 08 2015, 11:01 AM - #Permalink
    Resolved
    3 votes

    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

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 08 2015, 11:39 AM - #Permalink
    Resolved
    3 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 08 2015, 12:01 PM - #Permalink
    Resolved
    3 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 08 2015, 12:18 PM - #Permalink
    Resolved
    3 votes

    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

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 08 2015, 12:33 PM - #Permalink
    Resolved
    4 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 08 2015, 12:51 PM - #Permalink
    Resolved
    4 votes

    If you want to "sell" a process project, the best business case 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, just is. 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 reply is currently minimized Show
  • Accepted Answer

    Thursday, October 08 2015, 03:54 PM - #Permalink
    Resolved
    3 votes

    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 experience 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.

     

    The reply is currently minimized Show
  • Accepted Answer

    Friday, October 09 2015, 05:43 AM - #Permalink
    Resolved
    2 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Saturday, October 10 2015, 11:43 AM - #Permalink
    Resolved
    4 votes
    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.
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
278 Replies
01/10/2016
David Chassels
271 Replies
30/09/2016
Emiel Kelly
223 Replies
30/09/2016
Bogdan Nafornita
210 Replies
30/09/2016
E Scott Menter
182 Replies
28/09/2016