Application Portfolio Rationalization

OADP for IT Optimization
Stage I: Portfolio Rationalization

IT Optimization
An Applied OADP Methodology
IT Optimization is Oracle's applied OADP methodology for aligning primarily the
Application and Technology layers with the Business Architecture

3 Stages of IT Optimization
1. Portfolio Rationalization
 Platform and Application Standardization
2. Data Center and Systems Optimization
 Clustering
 Virtualization
 Consolidation
 Security
 Management Automation
3. Shared Services / Cloud Computing
 IT as a ‘Business’ - ITaaB
Business

Copyright ©2009 Oracle Corporation. All rights reserved. 2

IT Optimization (ITO)
Applying a standard process methodology

ITO
Architecture
A hit t
Vision

Stage II: Data Center &
System Optimization
Strategic Business &
ment
ITO Alignm

Stage III: Shared
Services/
Cloud Computing
Cl d C ti


Common Drivers for IT Optimization
> Discover Business Challenges
g
IT Optimization Area Issues and Challenges
Portfolio Rationalization Multiple applications providing the same functions

Recent merger or acquisition
Complex and inefficiencies associated with maintaining stove-piped
systems
Data Center d
D t C t and Under tili d
U d utilized servers and storage
d t
Architecture Optimization
HW refresh cycle or move to commodity HW platforms
Management Automation
g
Data Center consolidation
Security challenges due to complexity
Shared Services / Cloud Increasing transactions and data volumes
g

Financial Chargeback

Just in time scalability
y


Prerequisites and Inputs

Prerequisites • CxO Sponsorship for Larger Efforts, LOB sponsorship for smaller efforts.
• Overall IT Optimization Architecture Vision Completed

• Catalog of Business Capabilities, including (for each capability)
• Value to the Business Strategy/Goals (Hi or Low)
• QoS requirements (Availability and performance)

Inputs • Scalability requirements (xx growth within yy years)
• Matrix of Business Capabilities / Organizational units


How do you Rationalize a Portfolio?

Step 1 - Build inventory of
existing applications /
technology Inventory

Step 2 - Map inventory to
business / IT capabilities
Map
Step 3 – Analyze the portfolio
against evaluation criteria
(Portfolio Scoring) Analyze

Step 4 – Propose the
appropriate actions to transform
the “Current State” into the Transform
desired “Future State”

Copyright ©2009 Oracle Corporation. All rights reserved.

Important Factors to Consider
1. What are the driving factors for the Portfolio Rationalization process ?
• Reduce Application Support Costs – Think about application consolidation
• R d
Reduce HW costs – Thi k about hardware consolidation when consolidating
t Think b t h d lid ti h lid ti
applications
• Reduce Environmental Costs – Think about next generation hardware refresh to
lower power consumption
• Reduce IT Complexity (including ongoing support costs) – Reduce overall
number of applications and integrations that are supported
2. Is the Organization ready to move to a more centralized structure that may occur as
a result of application consolidation ?
3. Does the organization have the required PMO structure to support the rationalization
efforts (there may be numerous overlapping projects proposed to effect the end state
architecture) ?
4. What is the organizations budget for the project (will affect roll out schedules and
may necessitate cost saving quick hit projects over others to generate funds for the
overall effort) ?


Architecture Vision Phase


Portfolio Rationalization
Architecture Maturity
IT as a Service
• Standardize
• Eliminate Redundancy
y
• Modernize
Optimized IT Core
• Migrate Integration Layer

Service Group A Service Group B Service Group C Shared Services
Application Grid Application Grid Application Grid /
Data Grid Data Grid Data Grid
Cloud
Transitional Security Layer

Computing
Architecture Virtualized and
Pt. to Pt. Integrations
Consolidated
SFAProduct
SFA-Product
product ERP SCM
ERP-
productMES- DB
product Dev
DB-
Stage
Inv
LMS MGMT
B2B
B2B-
Infrastructure
IT Silos SFA Stage
SFA-
Test
Product ERP-
Prod
Stage
MES- MES-
Stage Prod
B2B- Stage
Dev
and Services
SFAProduct product ERP SCM productMES- DB LMSInv
DB-
Product ERP- product Dev Stage
MGMT
1
Client
Stage
FBT PAY G
NTS Security Security Security Security
TRDS
Customs NTS A/c

RRE
IPS
Penalty

Refunds
Data…….

RBA
Def
Rationalized
Integrate d A/C
1

Excise Payments

IT
CCD Compliance
Staff
CR EC I ADD AW A ELS
Staff
Business Phone
DDDR TASS
PKI CDCC
CWMS GC I Bus. Intel

IVR WOC
Ref aterial
m

Portfolio
BOA
Remote TAX
Client BANK Staff Staff AG ENTS Call Centres
B EP

Architectural
Complexity


Portfolio Rationalization
According to industry analysts such as Gartner, a focused applications
rationalization effort will typically result in a 20% cost savings while improving
support for the lines of business.

Reduce Complexity and Cost
• Fewer, more strategic vendors
• Standardize processes
• Eli i
Eliminate i f
information “ il ” i
i “silos”, improve ddata
quality & enable seamless sharing of information
across the organization through integration
• Support strategies; Global Single Instance,
Shared Services
• Eliminate redundant and niche applications
• Reduce risk
• M d i l
Modernize legacy applications
li ti
• Simplify / standardize technology infrastructure
Shift IT spending from Infrastructure • Improve security and regulatory compliance
to Strategic Investment • Delivery models; Buy vs Build ASP SaaS
vs. Build, ASP,


Architecture Vision
Scope Considerations
• Avoid “boil the ocean” approach. Attempt to define a scope that either
1. Reflects a “horizontal / vertical slice” of functionality, aligned with a
business goal or objective. For example:
– Rationalize all applications that support Financial Control & Reporting,
with the goal of improving the quality and timeliness of information
– Rationalize all applications that support Month End Close, with the
goal of reducing Month End Close from xx days to x days
– Rationalize all applications that support a Business Process in need of
streamlining
2. Reflects a manageable set of layers of the enterprise technology
capabilities, e.g.
• Servers – consolidate or upgrade to reduce “sprawl”
• Database – standardize/consolidate onto fewer instances
• Integration middleware – standardize onto a single platform –
leverage technologies like AIA to reduce integration complexity


Architecture Vision
Considerations
• Confirm with Customer, their existing applications inventory will be mapped to
Capabilities Model to identify redundancy/gaps
• Common portfolio scoring criteria include strategic value, functional fit,
conformance to IT standards, risk and TCO
• For Application Portfolio Rationalization
– Business Capabilities approach is commonly employed with customers who
have low level of maturity in applications portfolio management and business
process management
– Oracle Business Capabilities Model enables teams to accomplish the first
iteration of Application Portfolio Rationalization in less time, with fewer resources
– The BCM can be used either in spreadsheet form or with a tool such as
Primavera Prosight or Troux.

– For Technology Capabilities Rationalization
– Use the Oracle Technical Reference Model(TRM) to categorize Assets
– The TRM can be used either in spreadsheet form or with a tool such as
Primavera Prosight or Troux.


Architecture Vision
Considerations
• Make it clear that Portfolio Rationalization may effect a loss in functionality in
order to enable greater agility.
• Apply the 80/20 rule to Application Functionality. If the target application
supports 80% of the required functionality then the remaining 20% should
not preclude its adoption as the standard. When implementing the
remaining 20% make sure that they are done in such a way as not to
impede upgrades to the application.
• Composite applications can be set up to handle ‘missing’ functionality
until such a time that the business processes change or the target
application can support the given requirements.
• It is better to use the extensibility features of applications rather than
customizing the application itself. This will enable easier application
upgrades and result far less complexity.


Guiding Principles
Sample Principles for Future State Architecture
Business Architecture
Simplified / Enable agility to
Improve Operational
standardized / deploy new
Efficiency / Reduce
managed business products &
Costs
processes capabilities

Application Architecture

Maintain Shared Reduce / Acquire COTS
Standardize products &
Common Application Application customize only as
Platform Footprint necessary

Information Architecture
Real-time
Common Enterprise Out of the Box
information updates
Object Models analytics / schemas
/ monitoring

Technology Architecture

24x7 platform Open standards & Optimized , scalable,
availability systems agile environment


Architecture Vision
Sample Principles
Business Architecture Principles

• Cost Optimization – Low cost across the lifecycle of a product or service is a compelling value
proposition for targeted customer segments.
• Corporate Environment Responsibility – Going green is not only crucial from a social
responsible and moral standpoint, it also has economic benefits. Eco-efficiency, eco-
transparency and eco-innovation are critical for a greener future.
• Enterprise Balance – This principle embodies “service above self” and decisions made from
an enterprise wide perspective h
t i id ti have greater l
t long t term b
benefit th t ti l d i i
fit than tactical decisions made f
d from
a particular organizational perspective.

Application Architecture Principles

•CCommon U A li ti
Use Applications – D li ti capability i expensive and proliferates conflicting
Duplicative bilit is i d lif t fli ti
data.
• Technology Independence – Independence of applications from the underlying technology
allows applications to be developed, upgraded, and operated in the most cost-effective and
timely way.
• Adherence to Open Standards - promote business / IT agility, reduce risk and achieve a lower
agility
overall TCO than proprietary applications.
• Common Development Methodology and Tools - Standard development methodologies
increase the likelihood of high quality results and promote reusable components.
• Replace Obsolete Applications – Every application has a limited useful life span. Beyond this
life span, the application becomes functionally deficient and costly to operate and maintain.
p pp y y p


Architecture Vision
Sample Principles
Information Architecture Principles

•Data Quality – Systems that consistently carry stale and incomplete data pose risk and inefficiency to the
business and should be streamlined to only carry the information that it can realistically ensure quality for.
•Master D t M
M t Data Management - M lti l sources of data cause data quality/integrity i
t Multiple fd t d t lit /i t it issues th t greatly i
that tl increase
system complexity and overall cost, while reducing agility.
•Standard Data Exchange Format – Exchanging data in standardized representations lowers integration cost of
supporting new and changing data model requirements.

Technology Architecture Principles

•Adherence to Open Standards - Standards compliance enhances flexibility.
•Platform Standardization – simplifies maintenance and lowers support costs.
•Availability - Loss of business service can be very costly and can often be underestimated.
•Performance and Scalability - Responsive systems, with sufficient capacity, enable business success.
•Service Level Objectives - If the Technology does not allow the business to meet its Quality of Service (QoS)
objectives, then the business will suffer.
bj ti th th b i ill ff

Governance Principles

•Strategic Focus - Aligning the Enterprise Architecture with the business strategy increases the value of IT to the
business.
•Accountability - Accountability structures encourage compliance with the Enterprise Architecture.
•Compliance to Enterprise Architecture - An effective Enterprise Architecture needs to be a guide for all IT
projects
•Wide Participation - Wide participation by stakeholders throughout the enterprise ensures that the Enterprise
Architecture will meet the optimal requirements of the enterprise, not just a select group of LOB requirements.
•Quantitative Decision Making - Utilizing quantitative processes and metrics provides a consistent and equitable
means of evaluating decisions and i
f l ti d i i d increases th effectiveness of E t
the ff ti f Enterprise A hit t
i Architecture GGovernance.


Business Case Development
Performed Architecture Vision Phase
e o ed c tectu e s o ase

Architecture Current Future Strategic EA Business
Vision State State Roadmap Governance Case

• Strategy Map • Understand the • Agree to • Business Value • Identify • Define Future
- Customer existing Business Architecture alignment with State Costs/Risks
• Identify
Perspective Case culture Future State: existing auditing
timelines and • Estimate EA
- Financial - Quantifiable and other
• Identify existing: milestones for Roadmap
Perspective Measures financial
- Goals / Drivers measurement Investments
- Metrics for structures and
Business Case
• Business Model - Priorities
calculation processes • Perform
Development - Measures used
- Value Proposition - Non-tangible or Cost/Benefit
Activities - Metrics preferred
- Cost Structure Soft criteria analysis
and - Monetization
Artifacts - Revenue Stream numbers • Build the actual
Business Case
• Business • Assess against
document
Capability Model benchmarks
• Operating Model
- Level of Business
Process Integration
and Standardization

Work
Effort


Current State Architecture Phase


Step 1 - Inventory
Inventory Current Portfolio
• The process of rationalizing your portfolio begins with capturing an inventory of
all applications and th underlying t h l
ll li ti d the d l i technology platform, currently i use.
l tf tl in
• Capture information pertaining to an application’s underlying technology (e.g.,
hardware, operating system, database, etc.) as well. Standardization and lower
TCO can be realized through migration of applications to run on a common
technology platform.
• Automated tools can quickly identify servers and software applications installed
on your network, but there may be no substitute for human intervention when it
comes t determining b i i f
to d t i i basic information f application portfolio scoring such as
ti for li ti tf li i h
business capabilities mapping, strategic value, functional fit, conformance to IT
standards, risk and TCO.
• Completing such an inventory will usually reveal many overlapping and duplicate
applications that are candidates for consolidation.
• Spreadsheets or a tool like Treux can be used to capture the inventory list.


Current State Architecture
Inventory of Existing Applications


Deliverable Details – Applications Inventory


Step 2 - MAP
Map Current Portfolio to business functions
• Once you have captured the pieces of the portfolio, they must be mapped to the
business f
b i functions th t th support.
ti that they t
• The mapping does not necessarily need to be at a very granular level. Level 1 or
2 business process flows can be used for this effort. You could also use a simple
matrix showing the applications and which business functions they support.
• It is especially important to capture where a particular business process is
duplicated. Through an iterative process, when new business processes are
discovered relative to a given portion of the portfolio, the remainder of the
portfolio should b analyzed ( t l
tf li h ld be l d (at least at a summary l
t t level) t d t
l) to determine if th
i those
pieces are also supporting this process. Think in terms of a company that has
more than 1 ERP system. While the multiple system may each support unique
business processes, it it more likely that there is overlap among them.
• Spreadsheets or a tool like Treux can be used to capture the inventory list to
business process mapping.


Current State Applications Matrix
Current State Applications Layer Perspective

Customer Internet Accounts Service &
Billing Reimbursement
Relations Mgt.
Mgt Marketing Payable Repair

AMIS Recipient QuickBooks MCC CREM BigTree
MCC
MCC
AMER Web Store

ACT CREM Navision ISCALA CREM EVA 3
EMEA

Business MCC EBS Filemaker CREM
APAC Works Pro

SAP EBS
Australia


Deliverables
• Applications Inventory
• Owners
• Business Users
• Costs (* to be used in generating the business case)
• Etc
Etc…
• High Level (Just Enough Just in Time)
• Current Applications Architecture
• Current Data Architecture
• Current Technology Architecture
• Current Integration Architecture
• Current IT Organization Chart (* tto b used in establishing governance)
be di t bli hi

• Current PMO Structure (* to be used in establishing governance)


Performed During Current State Architecture Phase
e o ed u g Cu e t c tectu e ase

Architecture Current Future Strategic EA Business
Vision State State Roadmap Governance Case

• Identify
Business Case
and - Monetization
Business Case
document
• Operating Model
- Level of Business
Process Integration
and Standardization

Work
Effort


Step 3 – Analyze
Analyze the Portfolio information gathered in Phases 1 and 2 applying
objective criteria
• The analysis should be done in the context of what the portfolio should look like
in the future, not where is it now.
,
• Portfolio evaluation can be simple or elaborate, depending on organizational
maturity. For some organizations, just reviewing support for mission objectives
and capturing an estimate of application costs will be a substantial
accomplishment,
accomplishment and is often enough to identify “low hanging fruit .
low-hanging fruit”
• When a recommendation for an application isn’t obvious, a more detailed
analysis is required. While this could involve a wide array of criteria, some
obvious considerations would include: strategic value, functional fit, conformance
g
to IT standards, risk and TCO.
• Whatever level of analysis is applied, when the process is completed, you are
able to recommend actions to take for each application including replacement,
retirement, consolidation upgrade, modernize etc.
retirement consolidation, upgrade modernize, etc
• Make sure to take integration and information architecture changes into account
when developing the future state architecture. Portfolio Rationalization almost
always involves changes to interfaces (
y g (integrations) and the underlying data for
g ) y g
the applications.


Future State Architecture Phase


IT Portfolio Scorecard
Prioritize Future State Capabilities (Specific Criteria)

Likelihood of Success X- Y-
Criteria Axis Weight Score Business Value Criteria Axis Weight Score
Out of the Box X1: 15% Financial Return Y1: 30%
Functionality

Number of Interfaces X2: 15% Risk Y2: 20%

Development Effort X3: 20% New Business Benefits Y3: 15%

Support X4: 10% Technology Efficiency Y4: 10%

Business Critical X5: 25% Impacts Revenue Stream Y5: 15%
Functionality

Standards Based X6: 15% Implementation Time Y6: 10%

X 100% Dimension Total Y 100%

Source: Kraft Foods, 2002


Weighting Criteria Examples
Hardware Characteristics
• % utilization – currently at peak would suggest a need for upgrade upgrade.
• Energy Efficiency – older machines will have higher power requirements, need
more cooling and generally have a larger physical footprint in the datacenter
• Scalability – can the machine be scaled internally (add processors or memory)
or is it at full capacity?
p y
• Purpose – what applications are currently running on the particular machine and
are they supporting business critical functionality?
• Standards – it the machine in the currently recommended architectural
standards?
• S
Support – h
t how many people are th
l there in the organization that can support the
i th i ti th t t th
hardware?
• Lease Term – is the machine leased or owned, and is the lease term due to
expire?
• Manageability – is the machine easy to manage (does it have built in sensorssensors,
can it to predictive self healing or it limited to failure notifications)?
• Interfaces – does the machine support all the interfaces required for maximum
availability and performance (does it support Infiniband, does it meet HA
redundancy requirements)?
y q )


Application Characteristics
• Number of Customizations - will the customizations need to go into the target
application – or will the business change to deal with less customizations?
• Number of Interfaces - they will need to be re-written if the application is
being removed
• Number of Developers - how many are currently supporting an application
that is being removed? They will need to be re-trained which will eat into short
g y
term cost savings.
• Number of Support Personnel – the more that are re-purposed the lower the
overall cost
• Number of Versions Back - is it still supported by the manufacturer or will it
needed t b upgraded?
d d to be d d?
• Adheres to Target Standards - helps achieve a simplified infrastructure –
which will lower costs and improve agility in later stages of maturity
• Has functionality to differentiate company in the marketplace – this would
be a reason not choose a COTS application as a replacement
• Number Users - how many people will need to be trained/re-trained on the
target application?


Business Value

• Eliminates HW/Support/Licensing – will reduce TCO
• Reduces Risk – systems that are easy to implement have reduce risk and can
generate faster ROI.
• Lowers HVAC/Electric/support – more energy efficient systems are more
efficient and will reduce costs
• Directly Impacts Revenue Stream - talks to risk – back office rationalization
may be lower risk than a CRM or Customer Facing system directly tied to
revenue.
• Provides needed functionality to g
y grow the business - may rationalize an
y
application with an upgrade that the business currently needs
• Enables quicker response to market factors – agility is a key differentiator for
businesses. Those that can react quickly to market demands and opportunities
will have a competitive edge.
• Meets/Increases Compliance Requirements – as regulations increase,
increase
businesses need to ensure their stakeholders that they are compliant to maintain
shareholder confidence.


IT Portfolio Matrix
> Prioritize Future State Capabilities

100

Difficult to execute but high value to the business Some low hanging fruit
Valu to the Business

50
ue

Do not fund these projects Fund Selectively

0

0 50 100
Ability to Succeed
Source: Kraft Foods, 2002


Future State Architecture
Application Portfolio Analysis


Artifact Details – Application Diagram


Applications Technology Footprint


Artifact Details – Information Architecture


Artifact Details – Applications Integration Diagram
ICC EAI Architecture
BUNZL THAI IDS
E WMS

PO ASN
INTF361 INTF362
Nistevo
Ni t
INTF357 INTF360 Order
INTF358 Transportation
USSTCMN0 INTF359 INTF363
FTP
Server
RMF
WBIC

PO ASN
Bill of Material INTF340
INTF361 INTF362
Invoice INTF338 COMCARE

PO INTF306 Order INTF357
MAPICS PO INTF358
Invoice INTF307
ASN INTF359
Goods
Order INTF112 Receipt INTF360
TRACKX PO INTF116
Order
WMS Item Basic INTF104 Transportation
Vendor INTF127 INTF363

Gen Inventory
JD Movement INTF339
Edwards SAP
Item Basic INTF334 SATTSTORE
Goods Receipt INTF337 WMS
ASN INTF332/335
Order PO INTF333

Order
INTF 324/325/326
BPCS Customer INTF327 WCMt
Dual Inventory INTF121/122
Price List INTF330

e
Catalogue

e
Catalogue
INTF3288

INTF331
Product

Item
Inventory Catalogue Item INTF329
Inventory Report INTF298/300
Report INTF299/301

OPTIVA Bill of Material INTF304 WERCS Product DB

A2A

B2B


Reference Models
Architecture Component Framework
Collectively, the Architecture Component Framework assets map onto the
Technology, Information and Application Architecture layers of an enterprise
architecture framework.
OFRA - The OFRA best practices framework maps directly onto the technology
architecture layer of an enterprise architecture framework. OFRA is based on a
number of architectural design perspectives that address specific architecture
patterns for designing solutions – SOA E2.0 and so on. E h perspective
tt f d i i l ti SOA, E2 0 d Each ti
embodies the sum knowledge and experience of Oracle, its partners and
customers gained from implementing Oracle-based solutions. Each perspective is
defined to maximize the benefits of the Oracle technologies that are exploited in
the design.
th d i
ORA – is a high level classification of software capabilities spanning technology,
information and application architecture layers .
Technology Capability Blueprint – an alternative viewpoint of the software
capabilities required to meet logical architectural requirements


Reference Models
Industry Reference / Solution Design
An Industry Reference Architecture is an industry specific rendering of
ORA. It maps against the technology, information and application
architecture layers of an EA framework An IRA provides a definition of
framework.
Oracle’s technology stack and industry footprint capabilities that are
relevant for meeting the needs of a specific industry or industry domain.

Solution Designs include industry solutions & technology patterns.

Industry Solutions - Technology focused solution architectures defining high
level functions and process flows, and with Oracle Technology and industry
footprint mapping
Technology Patterns - Technology focused solution architectures defining
functions and process flows, and with Oracle Technology stack mappings


Reference Architecture Taxonomy
Design Oracle Enterprise Architecture
Offer
Best Practices Framework
Architecture
Framework Business Architecture Component

ethodology

Governan
Framework
Application Architecture
Oracle
Information Architecture Reference

nce
Architecture

Me
OFRA Technology Architecture

Perspectives
Technical
SOA O ac e product app gs
Oracle p oduct mappings Reference
Reference Model
Architecture (3rd party mappings)

E2.0 Reference
Architecture
Solution Designs
Security
S it
Reference
Architecture Technology Industry Industry
Patterns Solutions Reference
Grid Architectures
Reference
Architecture

BI/DW
Reference
Architecture
Technology
(Capability)
Maximum Blueprint
Availability
Architecture


Oracle Technology Reference Model
June 2010
Development Middleware Security Management

User Interaction
Authentication Incident
Content Mgmt BI Collaboration Mgmt
g

SOA & BPM
Authorization
Programming
Application Grid Service Level
Languages
Mgmt
Directory
Di t

Database
Info Mgmt Storage Grid Configuration
IDE Analytics Auditing
Mgmt Mgmt Mgmt

Disaster Data Backup Embedded
Recovery Replication In-Memory Encryption
Security Recovery
Performance
S/W Mgmt
Configuration
Mgmt Provisioning
Infrastructure
I f t t

Security
OS VM Server Storage Network IRM Mgmt


Oracle Applications
Capability Reference Model– Financial Industry
Model
Access the IBU Portal Here

31

Future State Applications Footprint

Analytics OM, SCM,
OM, SCM,
OM, SCM, CRM Loyalty iStore Sales Field Service
Field Service
Field Service
Financials
Financials
Financials iStore Marketing Order Mgmt Pricing CTO

Business Operations
Supply Chain Demand Order Procurement Services
Planning Planning Management
Demantra Configurator
Replenishment
ASCP Demantra
PIM Forecasting Configurator
Configurator Procurement
Trade Management
Procurement Point-of-Sale
Service Contracts
Service Contracts
ASCP
Optimization Forecasting
lanning Store Inventory Mgmt
Advance Scheduling Demantra
Supplier Inventory Demantra Order Management InvoiceQuality
Quality
Match
Planning Scheduling
Supplier Advance Forecasting
Advance Forecasting Order Management
Item Planning
g Returns Management
Supply Network Collaborative
Collaborative
Warehouse Merchandise
Planning
Planning Category Mgmt
Advanced Pricing
Advanced Pricing Workforce Scheduling
Optimization Management Management
Price Optimization Learning Mgmt
Value Chain Transportation Global
Global Price Management
Collaboration Management Order Promising
Order Promising
Promotion Planning
& Optimization Store Helpdesk
Value Chain
Allocation
Home Delivery
Demand Forecasting
“AS IS”
Sales Audit
Workforce Comms
“TO BE”
Corporate Administration
EPM Financials Financials Human Resources Real Estate
Financials
Indirect Procurement Projects Compensation Helpdesk HR IT

FIN
Master Data Management
Integration and CollaborationCustomer
Customer
Customer Online
Customer Online TCA
TCA
Data Hub
Data Hub
Enterprise Infrastructure

Apps you own
Apps you own Proposed New Apps
Proposed New Apps

HCM


Deliverable Details – Apps/HW Footprint


Deliverable Details – Integration Diagram


Deliverable Details – MDM Diagram


Performed During Future State Architecture Phase
e o ed u g utu e c tectu e ase
Strategic EA
Architect Current Future Business
Roadma Governa
ure State State Case
p nce
Vision

• Identify
Business Case
and - Monetization
Business Case
document
• Operating Model
- Level of Business
Process Integration
and Standardization

Work
Effort


Strategic Roadmap Phase


Step 4 - Transform
Propose the appropriate actions to transform the “Current State” to the
desired “Future State” using Transitional Architecture(s)
• Once you have completed the Application Portfolio Analysis and developed a Future
State Architecture, you are able to recommend actions to take for each application.
• The recommended actions may include:
– Replacing existing applications with Oracle Applications and retiring existing
applications, resulting in Global Single Instance or Shared Services model
– Upgrading existing Oracle applications
– Modernizing legacy mainframe applications, leveraging Oracle SOA / AIA
Foundation Pack – see Appendix or Modernization site
– Migrating existing applications to run on a common platform (Oracle DB / RAC /
Linux)
– Enterprise SOA: Integrating existing applications leveraging Oracle SOA / AIA
and optimizing Business Processes leveraging Oracle BPA


Step 4 - Transform
• The recommended actions may include (continued):
– Introducing a single User Interface layer, leveraging Oracle WebCenter,
across all applications to establish a common user e perience and
ser experience
collaborative work environment for End Users
– Enterprise BI / DW / Reporting solution, leveraging Oracle Business
Intelligence EE
g
– Enterprise Content Management solution, leveraging Oracle Universal
Content Management
– Enterprise Security solution, leveraging Oracle Identity Management
p y , g g y g
– OnDemand vs. OnPremise, Buy vs. Build, SaaS, etc…
• A Single Global Instance of Oracle Applications may be the desired
goal,
goal however a “big bang” approach may not be practical An
big bang practical.
Implementation Roadmap reflecting a phased-rollout approach
(employing one or more of the recommended actions on the previous
slides) is a means of achieving a GSI incrementally, thus mitigating risk
and i
d impact of change on an organization.
f h i i


Strategic Roadmap
Deliverable Details – Prioritized Candidate Projects
Primary Targe ts Secondary Targets
ntiating

Build & Future State
1 Cu stomize a s
Differen

necessa ry to
diffe rentia te
usiness Value

4 Buy &
Future State
Medium

3 cu stomize a s
2 ne ce ssary
Bu

The Oracle Insight identified 5 major
recommendation categories that were
7
A C D B evaluated for prioritization
Tablestake

E

High
5 Buy be st
Future State
pra ctice
A Core Applications
6 Unstructured Data
B Management

Impact
Business Process
C Optimization
Marginal Stable Best Practice Advantage
D Single, Common UI
Current Operating Performance
E Protected Enterprise

Medium

Low Medium High

Effort


Strategic Roadmap
Functionality Driven Transitional Architecture
Current State (CS) Establish Common Migrate to Common Single Payroll Application
Payroll Application Application
• MA& Growth resulted • Define Standards for common • Establish common business • Execute common business
in 4 payroll systems
p y y p y
payroll application.
pp p
processes for p y
payroll data p
processes for Payroll
y
Business

• Set up PeopleSoft rules to capture and processing
support entire employee
population

• Multiple payroll • Set up PeopleSoft instance • Consolidate Payroll apps • All new employees set up in
applications – 1 • Build migrations from existing • Train payroll users on new PeopleSoft Payroll.
PeopleSoft Payroll payroll applications into application • Retire obsolete payroll
Apps

instance PeopleSoft • Execute Migration plans to applications.
• Establish interfaces to Payroll move employee data into new
Data (i.e. budgeting apps) instance

• Payroll data stored in • Establish single view of the • Formalize data governance • Data Governance Processes in
multiple applications employee for Payroll data procedures. Place
• Establish Data Governance • Validate migrated employee • Product metrics for business
info

Processes data. process
• Establish metrics for business
processes

• No standard • Set up infrastructure to support • Run instance on new platform. • Tune application as required to
hardware or software Enterprise PeopleSoft Instance support Payroll functions
for payroll
Tech

applications


Strategic Roadmap
Business Process Driven Transitional Architecture
Current State Rationalize Sales Rationalize Financial Rationalize HCM Ready for
(CS) Process Processes Applications Optimization
• Define Current • Establish common • Establish common • Establish common • Common use business
Business

State Here business processes for business processes for business processes for processes can be
sales Finance people related functions optimized on a new
infrastructure platform for
grown

• Define Current • Consolidate disparate • Consolidate Financial • Consolidate ERP • Consolidate Applications
State Here sales applications onto a applications onto a applications onto a single can be optimized on a
common platform common platform platform shared platform
Apps

• Standardized Application • Standardized Application • Standardized Application
Interfaces in Place Interfaces in Place Interfaces in Place

• D fi C
Define Current
t • Si l view of sales d t
Single i f l data • Si l view of fi
Single i f financial
i l • Si l view of
Single i f • C
Common/Shared d t i
/Sh d data is
State Here for the organization data for the organization employee/partner/etc… ready to be consolidated
• Data Governance • Data Governance data for the organization into a single database
info

Processes in Place Processes in Place • Data Governance instance or common
Processes in Place database platform

• Define Current • Apps and process • Apps and process • Apps and process • Standard Infrastructure
State Here standardized on standardized on standardized on platform optimized for HA
Tech

architecture standards architecture standards architecture standards and scalability – enabling
growth


Oracle@Oracle Architecture Roadmap
Current S
C State: <Transitional Future SState:
Business Silos States> Operational Excellence
(1998) (2003)
Business • 40 Data Centers • Multiple Transition • Centralize and Globalize IT
Phases
Architecture • 2300+ S ff
Staff • C
Centralize IT GGovernance
• 1998 65 ERP inst. • Gain IT efficiencies via IT standardization
• 2001 20 ERP inst. & optimization
• 2002 10 ERP inst. • Reduce Data Centers (2)/Staff (1600)
• Save on expenses (
p ($1B/year)
y )
• 2003 1 ERP inst
inst.
Application • Few standard business • Standardize core business processes and
• For BPs, started with
Architecture processes rationalize apps
RevRec/Financials
• 40 Education registration • Education Sys Rationalization (1)
systems • Phase I Capabilities
• IT Support Rationalization (1)
• 27 IT Support apps • Acct • E-Bus SSuite S /
Std/Rationalization
• >1000 applications Reconciliation (< 100 applications)
• Corporate
Information • 63 Financial databases • Financial Data Rationalization
Submissions
Architecture • 60 IT Support databases (1 single global instance)
• Process • IT Support Data Rationalization
pp
Efficiency (1 single global instance)
• 97 Email servers on 120 • Phase II Capabilities • Email Consolidation
Technology
Architecture databases • Full Balance (2 server cluster/4 DBs)
• 501 Education servers Sheet & P&L • Education Server Consolidation (296)
• 600 t t servers
test • E
Exceptions
ti • T t Server Consolidation (30)
Test S C lid ti
• Analysis/Review
…

Application Portfolio Rationalization

Application Portfolio Rationalization

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Application Portfolio Rationalization

Ähnlich wie Application Portfolio Rationalization (20)

Mehr von Bob Rhubart

Mehr von Bob Rhubart (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Application Portfolio Rationalization