The distinction between services, functions, capabilities and processes is borrowed into ALMA from other service management frameworks, but with an agile and lean twist. The insight that capabilities of the different collaborations in the organization are central are borrowed from the emergent practices of capability mapping and agile enterprise architecture.
A Service is something that a person would happily use if we were to offer it on its own. "Fork Delivery" could be a Service on its own, but in the context of a lunch restaurant people wouldn't be happy if they didn't also get the plate, the food, spoons and knives and chop sticks when needed, and so on. "Fork Delivery" is therefore more likely a part of the Service "Lunch Delivery", and not something valuable on its own. A Service meets a human need all the way from the notion of the need to delivery.
A Process is the actual way of providing the part of a Service. When we perform our Processes and measure them and design improvements for them, it is important that we consider the whole Service and the human need it is supposed to meet. Else we run into a huge risk for sub-optimization which breaks the principle of flow.
A Capability is what a part of an organization needs to have in order to provide their part of the Service. It is distinct from Processes in that a Process defines exactly how a part of a Service should be done. But defining a Service in terms of exactly how it is delivered will be against the root principle of improvement. We need to be able to investigate different ways of providing a Service, and as long as we provide the needed Capability, we should be free to experiment how to do it.
"Fork Delivery" would be a Capability needed to provide the Service "Lunch Delivery", and we can experiment how to optimize the fork delivery in numerous ways. The larger investigation whether we actually need forks at all must also be possible to do in the name of improvement, but that would require that many more people would be involved in the experiment. In the small, within the limits of a Capability, people should be free to experiment without having to ask.
A Function is an organizational entity: a group of people who work together performing one or more Processes. An individual can be a part of several Functions but be aware that this can lead to priority conflicts within the individual, unevenness in their work, and overburden. People need to have a home. It is better for one person to belong to a single Function.
A Function can be represented in another Function. People from one Function then participates in the other Function's work. This is great for Sponsorship Functions (management and governance) where limited resources have to be distributed and priorities be made. By forming the governance Function by asking the Functions that are closer to the gemba for representatives, we ensure that the decisions made by the Sponsorship function is more in line with reality (the principle of empiricism at work).
By handling governance in this way we also combat the misconception of the organization as a hierarchy and lower the risk that it will be misused as an arena for persons to play games of political power. There is a power structure in place that should be recognized and designed in an effective way, but the presence of a power structure doesn't mean that forming hierarchies is a good way of governing it.
A Function may handle one or many Processes. A Service may be delivered by using only one Capacity, performing only one Process. But it is more common that the Service will require many Capablities, and therefore potentially many Functions in collaboration. They really must cooperate well in both designing and operating the Service, defining the Capabilities and their interaction.
It is often efficient when a Service is delivered by Capabilities and Processes that all can be performed within one Function. The Function can then experiment with improving the whole Service. It is resilient if many Functions can deliver the same Service in parallel so that more needs can be met faster. It is seldom efficient but brittle if a Function consists of only one person. Dependency on single individuals make the organization vulnerable. People need to have peers.