Solution Documentation: Libraries & Process Model

When laying out the Business Processes area, is there a 'correct' choice between end-to-end and modular process flows, and what should actually drive it?

End-to-end processes are the highest-value scenarios to document, so why not document all of them down to process-step level — and what's the trade-off that stops you?

Why must you build Business Process Monitoring alert objects in the Business Process area and assigned to a flow element, rather than authoring them in the Alerting Library?

A custom Z-program and a standard t-code are both 'callable' — which goes in the Executable Library, and what is the deciding property?

What single feature tells you a flow should be modelled as a modular process rather than an end-to-end one, and how do you handle scenario differences within it?

If an analyst expects to see evaluated KPIs in the Analytics Library, what's the misconception — what does the library actually hold and where does analysis happen?

When the same process step is reused in several flows, what documentation must NOT be duplicated onto each reference, and where does it belong instead?

You have a standard SAP function module and a custom Z function module — which one belongs in the Development Library, and what is the dividing line?

In SOLDOC, name the two top-level folders and the five libraries that make up the reusable side.

When does the FI/MM/SD module-based folder structure for the Configuration Library break down, and what do you do instead?

If you rename the step 'Sales Order' to 'Order Entry' in one flow, does the library now hold two steps — and what is the original vs reference relationship?

A colleague treats interfaces in 7.2 as just named endpoints differentiated by description — what does 7.2 actually give you to distinguish and refine them, and is it fixed?

Where does Solution Documentation 7.2 get its system-landscape data from, and what are the three views it exposes?