In some sense, most important business processes can be considered end-to-end, in that they are cross-functional and inter/intra-organizational as they execute operational behaviors that transform input(s) into output(s) and realize some kind of value(s) along the way. However, in practice, end-to-end processes are often understood as value streams or operational perspectives of capabilities, which, in my opinion, cloud the thinking of what to address in the process space and of how to go about fixing things. Or, the end-to-end are overly large expressions of such behaviors, which become wall-sized diagrams that have little explanatory power even if they are correct.
I would rather see the process, and its abstraction of the process model, be understood as expressions of operational behaviors that are not too big nor too small (i.e., they are in the Goldilocks zone). These can be mapped to other architectural concepts, such as value streams and capabilities, without having to force fit these things into a process form (with many of the semantics of the process modeling language being ignored or broken just so that it can be shown as a process model). Better heat maps can be constructed from such an approach, providing more targeted points of attack and more realizable but meaningful goals to achieve.
In the end, the "big project" should be thought of as a table top puzzle exercise. If success is defined as the picture on the box cover, then good luck with that approach and sustaining interest in such an outcome. On the other hand, if success is defined as finding the corner pieces, similarly shaped pieces, same-colored pieces, etc., then local progress accumulates to being global process pretty cleanly.