Over the years, organizations have maintained and developed multiple systems providing similar business capabilities across many different geographies. This scenario can be seen in many business areas within the organisation and it becomes increasingly difficult to figure out how to rationalize this fragmented and complex application landscape. By developing a ‘Unified Product Model’, one can develop a capability blueprint for all the applications serving similar functions and then use this blueprint to streamline the application landscape, thereby reducing the complexity and bringing agility. This paper is based on the work carried out for a major Financial Service client to simplify their complex landscape.

1. UNIFIED PRODUCT MODEL
A Capability Modeling Technique
Abstract
Over the years, organizations have maintained and developed multiple
systems providing similar business capabilities across many different
geographies. This scenario can be seen in many business areas within the
organisation and it becomes increasingly difficult to figure out how to
rationalize this fragmented and complex application landscape. By
developing a ‘Unified Product Model’, one can develop a capability
blueprint for all the applications serving similar functions and then use this
blueprint to streamline the application landscape, thereby reducing the
complexity and bringing agility. This paper is based on the work carried
out for a major Financial Service client to simplify their complex landscape.

2. The Problem
Over the years, organizations have
maintained and developed multiple
systems providing similar business
capabilities across many different
geographies. This scenario has arisen
because organizations have either
expanded their business through
acquisitions or have grown organically
over the years and expanded in another
market where their existing system could
not be directly used due to functional or
non-functional limitations.
Due to this, many organizations end up
owning and maintaining multiple systems
across different geographies serving
similar functions. Though serving similar
functions, these multiple systems end up,
owned and managed in different ways,
have different technology architectures
and contain different levels of
customization (depending upon the
localization requirement for the
geography they serve) making the
landscape complex and difficult to
comprehend.
This scenario can be seen in many
business areas across different industries
but the challenge everywhere remains the
same.
– How do we rationalize the complex
world consisting of multiple systems
with similar capabilities providing
similar function across different
geographies and organization units?
The Solution
Rationalizing a complex, fragmented
legacy landscape is a challenging task.
The rationalization involves identifying
common capabilities across multiple
systems, globalizing them, migrating
the non-core capabilities to other
platforms outside the system. There
are two main challenges that make
rationalization difficult.
1. Complexity of Individual Systems
– Organizations have multiple
systems serving similar functions.
These systems are bespoke
and/or COTS based with varied
technology base. Further, each of
the system in most cases, have
further grown organically over the
years to address their own market
specific needs. Due to this, the
system level complexity in
organizations is too difficult to
comprehend and rationalize.
2. Articulation of Business Benefits-
3. Articulation of Business B
Another challenge that prevents
rationalization is the inability to make
evident the benefits of rationalization
to the senior management. Most of the
time, it becomes very difficult to put a
business case, forward to seek
investment in terms of time and money
for rationalization as there is no clear
understanding and consensus on
capability rantionalization.
However, rationalization and consensus can
be achieved, if organizations are able to
collate, compare and contrast all the
business capabilities and related features
available across all the individual systems.
By doing this, organisation would be able to
figure out
 which capabilities are common and
overlapping among the systems
 which capabilities are unique to
individual system
 and which capabilities are non-core and
redundant and can be discarded
The comparison of capabilities can be
achieved, if a structured process is followed
to produce a unified business capability map
termed as ‘Unified Product Model’ which
can be referenced and used for capability
rationalization. The following key strategic
steps are recommended to create a ‘Unified
Product Model’.
Figure 1 – Recommended process to develop a Unified Product Model

3. The Process
Let’s explore each step, by taking into
account the above rationalization process
followed in real time, for a Financial Service
Client. This organization had a fragmented
and complex landscape for their Account
Receivable business function. The Account
Receivable business unit was positioned as
one of the capabilities under ‘Financial
Account Management’ Sector, which
further was part of high level ‘Enterprise
Business Capabilty Model’ of the
organisation.
The organisations Account Receivable
business area was served by three complex
legacy based systems serving Germany,
Canada and Taiwan markets individually.
Though serving similar functions, these
systems ended up owned and managed in
different ways - they had different
technology architectures, contained
different level of customizations
(depending upon the localization
requirement for the geography they serve)
thereby making the landscape complex
and difficult to comprehend. For
convenience, lets name these system as
System Canada, System Germany and
System Taiwan.
Step 1 – Establish Individual Baseline
Capability Maps
The first step towards creating a product
model is understaning the basic business
capabilities for each system individually
and establishing an abstract individual
system capability map. Here, one would
understand and formulate what
capabilities each system provides from
the highest level and later expand the
higher level capabilities to more granular
capabilities levels. The highest level
capability group is most abstract and is
termed as Level 1. The level numbers
increase with increase in granularity.
To achieve this, the existing
documentation for the systems should
be explored to discover any past work
related to business capabilities. Later,
indirect sources (such as business
process models, value graphs, SWOTs
or high level system component
models) should also be explored to
infer more details on capabilities for
each application module of the
system. This collated information
should then be distilled and mapped
to capabilities and categorised in
logical hierarchical buckets to create a
basic baseline capability map for each
system.
For the Financial Service client, by
following above approach, it was
possible to document Level 1 and
some of Level 2 capabilities. Since
each of the systems were at different
maturity levels and serving a different
geography, three different capability
maps were created. Further, for the
Germany System a lot of relevant
documentation was available, while
for Canada System documentation
was available at moderate level while
for Taiwan System not much
information was available. Hence the
baseline capability map for each
system was different with respect to
maturity. The Figures 2, 3 and 4
represent the capability maps created
for the three systems. The capabilities
in blue represent Level 1 capabilities
while capabilities in Green bucketed
under Level 1 form Level 2 capabilities.
Step 2 – Perform Competitor Analysis
As a next step, industry scan should be
performed to find key competitors for the
business unit. Compare the key products the
organisation offers to the market with the
products of the competitors with respect to
their business capabilities and features.
Figure 2 Germany System Capability map
Figure 3 Canada System Capability map
Figure 4 Taiwan System Capability map

4. Also perform research on the start- ups in the competitive
landscape to ascertain key new industry trends and disruptive
capabilities they are offering. Shortlist these capabilities and add
them to the baseline capability maps.
Step 3- Conduct SME Level Interviews
Next step in the process involves going through all the collated
capabilities listed in individual capability maps with the Subject
Matter Experts (SME’s) of the individual systems. Assess each
capability with respect to name, scope and provide a definition.
It is also critical to ensure that there are no overlaps of scope of
a capability with other available capabilities. For the Financial
Service organization, two half day long, 1to1 meetings with
Subject Matter Experts of each of the system were organized to
gain their feedback.
Most likely, after gaining feedback from the SME’s, some
capabilities will need to be shifted from one group to another
or from one level to another level depending upon the relevance
and granularity. It is also possible that new capabilities are
discovered which would need to be defined appropriately not
only with respect to name and scope but also with respect to
the position in the capability map. During the discussion with
SMEs, ensure that following directives are kept in mind for the
capability definitions.
Capability Directives
Ensure that, with SMEs, the Level 1 capabilities are discussed first
and agreed. The Level 1 capabilities represents Capability
Groups that can be further expanded to sub groups and
capabilities. For Financial Service client’s Germany System – one
of the Level 1 capabilities was ‘Receivable Management’ which
represented ‘Receivable Management’ group and grouped set of
capabilities related to Receivable Management function like
‘Billing’ and ‘Payments and Posting’.
After finalizing all the Level 1 capabilities, move on to discussing
and defining Level 2 capabilities (sub-capabilities under each
capability groups). Ensure that you discuss the business process
flows for the specific systems with SMEs to discover, align and
define Level 2 capabilities. For example for the Financial Service
client, Germany System, ‘Receivable Management’ (Level 1
Capability Group) consisted of Level 2 Billing and Payments which
aligned to payments and transactions process flow.
During the Level 2 capability discussion, ensure that the business
features under that particular Level 2 capability are also discussed
and agreed. For example for Level 2 capability – ‘Payment’ all the
features that system can offer to manage the payment are noted
down as level 3 capabilities. One of the features that can be noted
is ‘Defer payment’ which allows the system to defer the payments
of the customer. This process should be repeated for all the Level
2 capabilities. Once all the capabilities are discussed, we get an
expanded capability map.
Step 4 – Create a Unified Capability Map
DIRECTIVES
Capability should describe WHAT and not HOW
Capability should have an OUTCOME
Capability should not be described as a process or value stream.
Capability should be define clearly (i.e. the scope)
Capability must be unique.
Capabilities can be framed from their parent.
Capability can be framed by roles of people / users performing.
It does not matter if capability is automated or not for definition.
Automation is more related to maturity assessment.
Figure 5 Capability Map with Disruptive Capability

5. Once all the capabilities are known for different systems, create
a single unified capability map. Collate all the unique
capabilities found across all of the individual system capability
maps. For the Financial Service client, a new capability map was
created taking into account individual capability maps produced
for Germany, Canada and Taiwan systems.
To create unified map, start by collating and unifying Level 1
capability groups. It is highly likely that Level 1 capability groups
for all the individual systems would be same. Hence it should
be a case of using same capability groups existing in individual
maps in the new unified capability map.
Next, taking each Level one capability group, combine all the
Level two capabilities from individual capability maps and create
a single Level two capability list. Go through each capability in
level two capability list and remove any duplicates. For the
Financial Service client, there were number of duplicates that
were found. For example, for capability group ‘Receivable
Management’, duplicates for ‘Billing’ (Level 2 capability) were
found. Once all the Level two capabilities are covered, move to
Level three capabilities under each Level two capability
following a similar procedure as followed for unifying Level 2
capabilities. Below is a diagram that depicts the state of
capabilities at Level two, three and four. The concept of creating
a unified list at each level is shown below in the Venn diagram.
The region to all the three systems depicts unique capabilities.
Now, layout all unique Level two, three and four capabilities on
the unified capability map. On this capability map, mark each
capability with the availability status as shown in the diagram
below. This diagram provides a blueprint to business owners to
understand which capability is available geographically and take
decisions. Below is a diagram showing the unified product model
that will get created.
Figure 6 –Unified Product Model for Financial Services Account Receivable Function

6. Step 5 – Conduct Business Owner Interviews
Once a Unified Product Model is available, validate the model
with business / product owners who are responsible for
creating and managing products and their capability features.
For the Financial Services client, the Unfied Capability Map
was discussed with business products managers who were
responsible for managing and developing new products and
features, for all the three systems capabilities.
Discuss each capability again with respect to name, scope,
definition and categorization and tailor the capability map
based on their feedback.
Step 6 – Publish Unified Capability Map
The final step is to circulate and publish the map to both
business and technical stakeholders across various teams. It
will be useful to create an introduction deck based on the
work carried out for UCM and train selected individuals so
that they can start using the capability map for their own
work.
The Benefits
Unified Product Model will provide benefit to both technical
as well as business stakeholders.
Common Taxonomy
One of the key benefits of Unified Product Model is that it
establishes a common language / taxonomy for all the
capabilities of the system. This is extremely useful for
scenarios where organization has multiple systems
performing similar function across multiple geographies.
W
With Unified Product model, there is no ambiguity with respect
to names, scope and definition of capability. This allows both
business and technical staff to use the terms confidently in their
day to day work.
Perform Capability Assessment
Unified Product Model helps compare the availability of
capabilities across several systems. This further helps the business
understand which capabilities are common (i.e. available) across
all the systems. The capabilities that are common always serve as
good candidates for rationalization into set of shared capabilities.
From Unified Capability Model, one can easily find out which
capabilities are available in all the systems and consider them for
externalization if strategically important.
Unified Product Model also helps the business promote reuse of
capability features across the systems. For example if a strategic
capability is available in one system but is not available in the
other systems, then the capability know how, implementation,
logic and related process flows can be understood and reused
while developing a similar capability in other systems.
Optimize Investments
Each project in flight can be inspected to understand which
capability it is impacting. Later the investments of the project can
be split across the capabilities. Once a split of project investments
is available for the capabilities, one can find out the total
investments going into particular set of capabilities for the
financial year.
The investment view of capabilities can be overlaid by strategic
view (view showing strategic important capabilities) to
understand if the investment is going in the right proportion and
amount for strategic capabilities. This exercise can allow the
business to stop the leakage of funds going into non important
capabilities and divert the investments to the capabilities that are
strategically important to business.

7. About the Author
Jaspreet Puri
Principal |
Strategy Practice |
Infosys Consulting
Jaspreet is an IT Strategist and
Enterprise Architect with over 19 years of experience in
anchoring and leading complex business transformation
programmes. He specializes in IT Operating Models,
Optimization, CIO Advisory, Enterprise Architecture, Post
Merger Integration and Divestments.
Currently Jaspreet is acting as an IT Strategist providing
business architecture guidance for Global Account Receivable
business unit for a Financial Service Client. He is responsible
for developing IT Strategy, blueprints for investments and
projects, business capabilities, alignment and rationalization.
Jaspreet holds an MBA from London Business School and
Masters in Engineering from IIT Delhi
.