Shared Service (SS) is not a new concept and we have a lot of publications about this subject. I hope that many would agree that a SS appears differently from the business and technology perspectives. Since every service is valuable to its consumers by the service functionality and outcomes, this is all that is needed to make a decision on whether to use this SS, or that one, or at all. Data, in this case, should only meet data quality requirements and fit the meta-data – both defined by the service. This is really simple while the risk comes from the technical implementation of the service. We will discuss this risk in detail.
In the “brown field”, the major problem and risk of the business aspect of the SS is business ownership. The functionality, now provided by the SS, together with the resources delivering this functionality, had belonged to several personas* before the SS was introduced. Thus, the SS, when acquires functionality and related resources, reduces the scope of the ownership of related personas. This can seriously impact the persona’s remuneration and managerial/influential power. As a result, there is a risk of operational resistance of the former functionality owners.
The technology aspect of creating SS in the “brown field” encounters the risks of:
- data redundancy elimination in several systems that before provided now-shared functionality
- inter-dependency and integrity of data in the systems that have lost now-shared functionality.
Particularly, if systems A and B provided the same functionality for some of the data, a delegation of this data to the SS (redundancy elimination), has a risk of errors: when the SS is created related data is not supposed to be delivered to A and B any more. However, without a meticulous investigation, we cannot say that no other internal processes in A and B used this data. That is, these processes can fail without the data.
Another challenge in technology is the need for an update of the mentioned systems A and B allowing them to use the SS. This challenge is frequently missed in planning, funding, development and testing. This is an additional (operational/management) risk.
Here are a couple of examples. Assume a Pension Asset Management company invests in different funds that are quite distinctive in investment to industries and geography. Each fund has a Fund Manager and a supporting team. They operate on different Exchanges in different jurisdictions. Each team has to identify the price of the fund shares. There are similar sets of rules that teams use for the pricing in spite of different jurisdictions, i.e. the pricing work is duplicated (though uses different data). This work is the candidate for a shared Fund Pricing Service. Another example may be found in the advertisement brokering companies. The media advertising campaigns usually require the involvement of different media channels, e.g. web portals, TV, radio, messengers, street ads, etc. The processes of allocating advertisement time-slots and places in the brokering company are so similar across different media channels that, instead of having multiple teams per media channel, it may be just one team with a few specialists and automated support working as a business shared service.
Apparently, we have to distinguish between the creation of SS and wrapping several existing systems with a single interface, e.g. UI, and a task dispatcher. Yes, such a solution replaces an explicit dependency of the “consumer” on those systems with an implicit one, which is good already. Yes, it makes a replacement of one or several wrapped systems with the better ones transparently to the “consumer”, which is also good. Nonetheless, such a wrapper is not a SS – it provides no unification of functionality or reduction of functional redundancy. It depends on the wrapped functionality and cannot be easily customised for the new consumer needs without an impact on the existing consumer base.
When a SS is created and adopted in the company, several aforementioned risks disappear. The new risks raise due to continuously changing regulations (compliance risks) and technology evolution (risk of becoming outdated). Here is an example of the latter. A merchant has a function responsible for money transactions to the banks and uses related technology, connectivity, protocols and teams. One of the major goals of a merchant is to increase money circulation. What would be more feasible for the merchant – improve its own technology (systems and processes) or discard it and outsource money “transition” with, e.g., Fast Payment service provided by an external professional vendor? In other words, a company’s SS should continuously check up on its competency and competitiveness against the external market; not doing this results in market risk.
_______________
*Persona is a managing owner accountable and responsible for certain functionality.
HOW to ARCHITECT for DEVELOPERS 