Hi there, welcome back to the 4th episode of the new season of the Process Extraordinaire Weekly newsletter and the main topic last week has, without a doubt, been the question: what actually is an end-to-end process and why are some people/parties (at least in my opinion) not getting it. Obviously, this is just my perspective on this topic and I could be completely wrong, but nevertheless I feel obliged to share my perspective with you all in this week’s newsletter.
Let’s get into it, shall we?
First and foremost, let’s start with a definition of a process: the dictionary defines a process as a series or actions or steps taken in order to achieve a particular end. Sounds logical and I think most people would agree with that. As we are living in the age of AI I have also asked this question to chatgpt and according to AI: “In the context of an organisation, a process is a structured set of activities or tasks that take inputs, transform them, and produce outputs to achieve a specific business objective.”
If we take an example in the procurement space (everybody knows this, so easy example) the process called “Create Purchase Order” describes a specific series of activities that transform input (usually an approved purchase requisition) into a Purchase Order than can be either sent for approval or sent to the designated supplier. In this process, you might find activities like assessing the purchase requisition, performing source determination, checking sourcing agreements and aligning delivery dates and incoterms. Usually (but not always) a single business process has one main responsible role.
So far, so good.
Let’s make things a bit more complicated and introduce the end-to-end process (I’ll call it E2E from now on, saves me a few keyboard strokes) and figure out where I stand on this. First the definition of an E2E basically is (again according to the internet, via chatgpt, and I agree with it): An end-to-end (E2E) process is a complete value chain that spans across multiple functions, departments, or systems, starting from an initial trigger (such as a customer request) and continuing through all necessary activities until the final outcome (such as product delivery or service completion). It ensures a seamless flow of work across organisational boundaries to achieve a business objective.
One of the most important words in this definition is of course “cross-functional”. An E2E process, by definition crosses the boundaries between various functional domains. Simple example again: the procure to pay E2E starts typically in the business (they are the ones procuring something), it then moves to procurement, back to business for the goods receipt and into finance (or procurement) for the invoice verification and finally into finance for payment of the supplier. I still believe that 99% of the readers of this article will agree to this definition and its importance.
Where things go south sometimes is when organisations or software vendors tend to inflate the scope of an E2E process. The most famous example is, again, in procurement where procure to pay is now commonly referred to as source to pay or even make to pay and I generally have two problems with this:
(1) In many cases they don’t even refer to an actual E2E, but rather to a functional domain. I came across the best practice framework of one of the largest ERP vendors in the world and their L1’s were called things like Manage HR, Manage IT, Manage Finance (so far so good), Source to Pay, Order to Cash (????) and even stranger, their L2’s were normal functionally decomposed sub-domains. Just call it Purchasing instead of Source to Pay and leave the E2E terminology to the actual E2E processes. It’s just wrong and confusing.
(2) I might be a bit of purist on this, but if you inflate the scope of an E2E process, at a certain point it not really is one E2E anymore. You’re basically just combining 2 or more E2E’s and calling it 1 E2E and I don’t understand why. Let’s take Source to Pay as an example.
Source to Pay starts with the sourcing activities such as Spend Analysis, Category Management, Supplier Management and Contract Management. Of course there is more, but those are the major parts of it. It then transfers into the procurement cycle that starts with Requisitioning, Purchase Ordering, Goods or service receipt and finally the whole invoicing misery (sorry, have no other word for it). From a data flow perspective this is indeed a logical sequence (see picture below).
However, the frequency of both major parts (source to contract and procure to pay) are so vastly different that this cannot be regarded anymore as one process. They are simply two processes that run at very different speeds. Like two cogwheels, where one runs at 5 RPM and the other one at 5000 RPM. You can connect them directly, there needs to be an intermediate gearbox or reducer. In the case of source to pay, the contracts (or outline agreements or other records for source information) play this very role.
Also, not every instance of the source to pay process starts at the beginning of the Source to Pay E2E process. You run the sourcing activities annually (for the purpose of establishing outline agreements I mean) but you run the procurement cycle maybe hundred times a day and this discrepancy between the two E2E’s is exactly why you should not regard them as one E2E. You can run the procure to pay process without any sourcing activities (I’m not saying that this is a wise thing to do, but it is possible) but having sourcing without procure to pay simply makes no sense at all (it becomes a paper tiger). Without this mutual dependancy it cannot be regarded as one E2E.
So, ending my rant against inflated E2Es, if you are referring to a functional domain, please use the proper functional name (I don’t care how you have structured your ERP software tbh), and if you are referring to an E2E process, please take into consideration the ‘speeds’ at which these E2Es run and make sure that within one E2E the speed of the processes are similar.
Does that make sense, or I am as high on mushrooms as I typically is?
See you next time…