Enterprise Architecture Blog Posts
Need a little more room to share your thoughts with the community? Post a blog in the SAP Enterprise Architecture group to explain the more complex topics.
cancel
Showing results for 
Search instead for 
Did you mean: 
raulporras
Product and Topic Expert
Product and Topic Expert
266
This is part 2 of a 3-part series. For an introduction to the legacy innovator challenge in large multi-business corporations, see [Part 1]

How to Find the Potholes?


An approach that can help “find the potholes” and provide a framework to start creating a consolidation strategy is to think of four areas to classify capabilities in the spectrum of business-specific to enterprise-wide capabilities:

 



Figure 1. Capability Areas

 

  • Foundational capabilities
    These are the capabilities that are likely to be technical in nature but support a broad set of services on which the other capabilities are built. A lot of commonality can be found in this category, so they’re a good candidate for corporate consolidation. Examples include: master data governance, enterprise analytics, R&D support functions, etc. The difference between this layer and the next is that, as the name suggests, they’re prerequisites to allowing the other layers to work with each other at different levels of integration.


 

  • Shared services
    By definition, this is where most of the corporate synergies are found. These are capabilities that are not unique to any one business unit and for which corporate-wide standardization not only provides cost savings but also enhances the cross-BU benefits that can be achieved. The easiest examples in this category are the common shared-service functions like Finance and Human Resources but a lot of opportunity exists in many companies that haven’t built corporate-wide services around Global Procurement and, to some extent, Strategic Supply Chain Planning.


 

  • Core operations
    This is where we start to find some potholes to fill. Although core operations achieve the same purpose in each business unit (for example: manufacturing), it may or may not make sense to mandate standardization depending on the similarities that exist across the different business units. It is hard to justify why a plant that produces pencils should use the same manufacturing and scheduling practices than one that produces food-grade products. On the other hand, if two out of four business units have common customers, sharing order-to-cash capabilities among them will improve customer satisfaction (e.g. customer will receive only one invoice)


 

  • Business specific capabilities
    This is where the potholes live. This is where BU owners will fight (overtly or passively) to preserve their agility. Whether or not they are common to multiple business units, these capabilities are the ones that represent a competitive advantage for at least a portion of the business. These should be preserved, and artificial standardization shouldn’t be forced.
    Keep in mind that this doesn’t mean that a common platform for innovation can’t support business specific requirements (e.g.: individual pricing schemes can be supported by a common pricing process/engine) but the intention is to highlight the fact that individualization and agility for this layer should be a top priority of any consolidation project.


 

For an SAP point of view on how these different categories can be addressed, see [Part 3]