To obtain high economies of scale, GBS models the entire process flow but handles only those processes that are not part of the company's core business. For example, procurement of green coffee beans is managed as part of snacks and beverages purchasing, while GBS assumes responsibility for the P2P system and the vendor accounting involved.As I interpret this, the process is decomposed into asset-specific tasks (those that are specific to green coffee beans) and generic tasks (those that are common across all purchased items).
The purpose of decomposing in this way is quite explicit. There is no stated intention of outsourcing the generic tasks, and there is no suggestion that they are not part of Proctor and Gamble's core competences. But there is a strong economic argument for managing these tasks as shared (reusable) services; and establishing these as shared services allows Proctor and Gamble to strengthen the underlying competences. The basis for this split (despite what it says in the article) is not core/noncore but asset-specific/generic.
To design services with significant levels of sharing (reuse), it is important to separate the asset-specific elements of the service from the generic elements. Asset specificity is a key determinant of service value. But here's the problem. The models that are commonly used within IT for designing component and services are type models. This means that they are already generic, they are at a level of abstraction at which asset specificity is not visible. (You don't see green coffee beans on a type model, you just see PRODUCT. You might happen to know that green coffee beans is a specific instance of PRODUCT. But you cannot use the type model to design a service that is specific to green coffee beans - or even to analyze a possible requirement for such a service.) This argument applies equally to process models or capability models, to the extent that they reference abstract types such as PRODUCT.
Thus although the Proctor and Gamble solution appears intuitively reasonable, it is not the solution that would be produced naturally and unforced by following any of the popular service-oriented design methods. (Of course, if you impose an arbitrary apriori separation of core/noncore on the problem space, you can produce pretty much any result you like, but that's not the point.)
The popular design methods (and tools) are geared for efficient solution of fixed problems, and do not provide a sufficient basis for reasoning about reuse, adaptability, complexity, and all the other things that service-orientation is supposed to bring. Asset-specificity is an important economic aspect of a service, and service engineers need ways of understand this aspect.
updated to remove the little symbol between "Proctor" and "Gamble" which caused problems with my XML feed earlier - sorry
No comments:
Post a Comment