At which point someone produces some consultancy's slide pack that include a formal defintion of levels 1-4 and everyone walks away thinking we all aggree; that is until you try and reconcile process artefacts from two seperate projects and you find you can drive a a truck through the ambiguities in most of these defintions.
So what's the solution? I don't claim to have anything definitive but I do think that by building models based on at least one well defined and understood idea, and defining further concepts based on that we can come up with something more useful.
In summary: Don't start with defining "Level 0" process is. Define the bottom level and let the concepts flow from there.
Elementary Business Processes
The only really firm defintional ground I can find in this domain are "Elementary Business Processes", these are defined as:
An elementary business process (EBP) is defined as a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state (C. Larman, Applying UML and Patterns)
This is happily a defintion that can be used for:
This is a well understood and generally aggreed piece of functionallity that can then be used as a building block for everything else. They provide the central tracing point between all your different views of the world. You can link them to:
EBPs provide yout the atmoic unit of functionallity while doing functional modelling in the same logical entities and screens do for data and unser interaction modelling.
This unit can then be used to integrate your functional requriements to the steakholder requirements, information arch, and application arch.