THE ART OF
ADHERING TO GOALS
Regulation, Industrialization and Digitalization
as Drivers of Transformations
Christian Böhning
Dr. Mirko Schiefelbein
Christian Schneider
March 2013
White Paper
Copyright © COREtransform GmbH
1
Introduction
The developments in the banking market have confronted financial institutions with major challenges. Factors such as regulatory requirements,
the dynamic drive towards industrialization, the increasing significance of
international markets, and changing customer behavior and expectations
as a consequence of digitalization, all require a high degree of agility. At
the same time, the reduced equity base of financial institutions has led to a
greater focus on cost reduction which in turn narrows down scope for action
and design.
In this situation, it is crucial for banks to create the prerequisites facilitating
an effective and efficient positioning on the market. Aside from diversification of product portfolios and collaborations with partners, a key factor in
this context is the standardization of products, processes, and IT platforms.
This will allow financial institutions to stabilize their cost base and increase
their efficiency. Furthermore, standardization will give them access to
new levels of utility and benefits that cannot be achieved using systems
based on proprietary software (Fig. 1). For banks, this implicates a need for
modernization of structures that have grown steadily over the last decades
and transforming themselves to meet the latest as well as future requirements.
Standard software contracts for banks
Access to a new benefit level
S-Curve
current platform
Benefit of
IT platform
302
IT standardization as a key
requirement for agility
S-Curve
new platform
Step change
350
Individual
software
approach
390
Standard
software
approach
1.908
439
427
2007 2008 2009 2010 2011 Total
Source: IBS 2012; COREinstitute
Window of
opportunity
for platform
change
Incremental
investment
Figure 1: Transformation to standard software
Aside from economic and benefit-oriented considerations, two additional
factors are central to the decision-making process regarding a transformation. On the one hand, a bank must identify which of the systems available on the market for standard software provides the appropriate solution
with regard to its business focus. On the other hand, it is crucial that a
bank possesses the ability and the know-how necessary for managing the
challenges inherent to a transformation and to successfully carry out the
program.
Ability and know-how crucial
to transform
In the following paper, we will share our experiences with regard to transformation challenges and will address the migration of core banking systems
from proprietary to standard software in the context of the design and
management of highly complex large-scale programs. For this purpose, we
will first summarize the current situation on the banking market, followed by
an overview of providers for standard banking software solutions, and will
then sketch the main challenges of this kind of transformation. Next, we will
2
Adhering to Goals © CORE 2013
develop several solution patterns which, based on our experience, offer a
stable foundation to manage highly complex programs in an adequate and
targeted manner. We will first address the various phases of a transformation and will then focus on topics such as the decision management, the
methods and tools, the internal and external parties involved in the program
and their skills, and the Go-live management, in order to illustrate the main
instruments needed to manage program complexity. In the final section, we
will consolidate these aspects and discuss them with regard to the challenges of a transformation.
2Challenges of a technology-driven transformation
Transformations are a response to the current challenges in the banking
industry, but they simultaneously represent a challenge to the banks themselves. The challenges of the banking market lie, first, in the ever increasing
tightening of regulations as well as frequency of new regulations (Basel,
IFRS, SOX, SEPA, FATCA) which tie down dynamic forces and restrict
the banks’ scope of action. Further challenges lie in the necessary industrialization of financial institutions. The latter is characterized by higher
cost efficiency, standardized products and processes, scalability as well
as greater flexibility. In addition, banks must compete against new players
originating from partly unrelated industries who are penetrating the financial
services market. In the context of the current digitalization, Bank Attackers
are using innovative concepts to vie for the business of established banks,
break-up their integrated value chains, and thereby create added value for
customers, respectively divert revenue that previously went to banks.
In light of these challenges, there is a tremendous need for banks to
become more flexible in order to be able to react rapidly and comprehensively to changes. The industrialization of business models and value
chains of financial institutions has significantly increased their dependence
on technology. At the same time, it has become obvious that retail banks
cannot distinguish themselves from their competitors solely by their core
banking systems. Banks need to develop an understanding of IT systems
as enabler. Therefore, successful banking implicates distinguishing oneself
from competitors via products and services while simultaneously taking
advantage of ones’ positive brand reputation on the market.
Regulation, industrialization and
digitalization as drivers
Create the prerequisites for agility
Banks’ current technological foundations fulfill the requirement for flexibility
either only partially or not at all. The IT landscapes used to support the
processes of the banking business are for the most part individual developments that have grown in a piecemeal process over the last decades and
whose core systems are based on host technologies with programming
languages such as COBOL or PL/1. In accordance with changing business
demands, these core systems were successively upgraded by adding new
functions and technologies. Furthermore, banks rarely defined semantic
or technological standards for communication between systems. As a
result, banks now possess fragmented software landscapes consisting of
hundreds of IT applications reflecting the technology spectrum of the last
decades.
In light of this situation, many financial institutions are deciding to transform their IT systems by moving to standard software, drawing on comprehensive banking systems or specialized solutions for individual elements.
Reduce costs – tap potential
3
Adhering to Goals © CORE 2013
In spite of the escalating financial crisis, over 1,900 new contracts were
signed between banks and standard software providers in the last 5 years
(Fig. 1, left side). The objective of a transformation is to increase efficiency
as well as effectiveness with the resources and investments already in
place, and to reach greater benefits in comparison to the legacy systems.
Initially, reduced benefits have to be tolerated due to higher investments at
the beginning of a transformation (Fig. 1, right side).
Overview providers of standard software for banks
Europe
Asia
North- & South America
Oceania
Source: IBS 2012; COREinstitute. The logos are the property of the respective trademark owners.
Figure 2: Global overview of standard software providers
There are various data pools and analytical sources available in order to
help banks identify the best software solution or combination of solutions
on the diversified market for standard software systems, which currently
consists of more than 90 providers for more than 100 of such systems (Fig.
2 as well as overview in the appendix). Drawing on this information in relation to the specific banking segment, financial institutions can determine
the extent to which their individual business areas can be addressed by
individually developed software. This allows banks to identify customized
solutions for processes and functions.
Identify the optimal standard
software suitable for the needs
of both, IT and business
For banks, the challenges associated with the decision to proceed with a
transformation indicate the typical scale of a core banking system transformation: a duration of several years, in which hundreds of interfaces and
thousands of project milestones must be achieved, in which thousands of
workshops and tens of thousands of test cases are necessary, affecting
tens of thousands of employees and millions of customers as well as bank
accounts with billions of transactions consisting of hundreds of millions in
savings and billions in investments. The goal of such a transformation is to
reduce the time-to-market from several months to a few weeks, to increase
process security and implement state of the art standard software with
real-time banking capabilities as well as new front-ends for employees and
customers.
Banks are therefore confronted with tasks that demand much of the organization as such, that will require dedicated resources for a number of years,
and that have an impact on the core of the management and manageability of the program. Whereas in IT environments that have grown over
a number of years, the complexity has increased gradually and has only
Understand the transformation as
a challenge for the management
4
Adhering to Goals © CORE 2013
been manageable by applying appropriate management tools. Transformations break with this progressive development and are characterized by
the maximum degree of change within a limited timeframe. When carrying
out a transformation, organizations must take into consideration the legacy
system, the new system as well as the transition from the legacy to the new
system, while some aspects of the new system remain unknown during the
process. Consequently some information is unavailable during the transformation process; inherent uncertainties remain in planning, decisionmaking, and when actual measures taken.
This does not mean that banks can eliminate the complexity and intrinsic
uncertainties of the IT system when managing a transformation. Instead,
banks should define a dynamic and adaptable framework when developing
their new system, flanked by steering mechanisms in the form of clearly
defined and proven methods and processes. This provides orientation,
information, and control. Effective implementation of these mechanisms
requires experience in transformations in order to address these specific
challenges.
›› Provide orientation: The scope of the program and the size of the organization require the provision of orientation and consistency throughout
the duration of the project in order to make the context of the transformation phases transparent to all participants
Identify and individually address
challenges
›› Take decisions: The high degree of complexity and the restricted availability of information require fact-based decision management in order to
ensure factual expertise and comprehensible information.
›› Use tools: Single areas and factors in the project tend toward inefficiencies as long as they are not supported and managed by applying dedicated methods and tools appropriate for the specific problems.
›› Connect experts: The expertise and abilities required for the transformation cannot be provided exclusively by the bank. A project of this nature
therefore requires an adapted approach to create a network of internal
and external specialists.
›› Finalize projects: In order to act in a goal-oriented manner at the end of
the project, the operational processes must be results-driven while simultaneously ensuring the decision-making capability of all stakeholders.
Management teams of business and IT can address these challenges
by applying specific solution patterns in order to ensure the convergence
between the planned and the achieved goals. Within the definition and
management of this scope of action lies the art of adhering to goals and the
achievement of successful transformations.
5
Adhering to Goals © CORE 2013
3
Experiences and Solution Patterns in
Core Banking Transformations
3.1
Phases, or: the coordinate system
In the case of complex programs, it is necessary to provide a binding framework for the entire process from the blueprint of the statement of intent all
the way through to the Post-Go-live period. This framework functions as a
coordinate system which links various program phases with the definition of
tasks which span the various phases. Each phase focuses on pre-defined
tasks and results that are achieved by applying adequate approaches.
Ensure transparency and provide
orientation
3.1.1 The CORE Transformation Framework
The CORE Transformation Framework consolidates multifaceted experiences and solution patterns in a comprehensive frame of reference (Fig. 3).
Phases and disciplines of transformations
Modelling
Phases
Preparation
Target Concept
Disciplines
Strategy
Development
Execution
Transformation Setup
Sequence Definition
Guideline Determination
Product Specification
Architecture Specification
Masterplan Development
Model Definition
Masterplanning
Sourcing Strategy Definition
Enterprise Architecture Adoption
Business Case
Ramp-up and Mobilisation
Audits, Assessments and Reviews
Implementation
Go-live
Decomissioning
Benefit Collection
Compliance Management
Target Model Engineering
Requirements Engineering
Sourcing Management
Quality Management
Risk Management
Architecture Management
Project Management
Change Management
Transformation
Engineering
Task Force Management
Operational Controlling
Test Management
Rollout Management
Operational
Management
Transformation Tool Services
Source: COREtransform
Figure 3: The CORE Transformation Framework
The framework combines the three phases of modeling, preparation, and
execution along the time axis with a discipline axis on which the relevant
scopes determine the respective management and controlling focus.
Together, the two axes constitute a matrix which ensures
Focus: Preparation to ensure
the manageability of complex
execution
projects in every phase by
providing
function
based
In order to prevent implementation
scope definitions. The framesteps from having a premature impact
work integrates methods and
on planning, the phases of the detailed
tools that have been specifiproject plan and those of the implecally created for transformamentation are to be strictly divided.
tions and which are standTask-forces should be established to
ardized and harmonized, in
deal with any backlogs during impleorder to implement structured
mentation and thereby help to facilitate
procedures and to ensure the
project management.
holistic nature of the project.
Use of standardized methods to
ensure focus
6
Adhering to Goals © CORE 2013
This enables steering of neuralgic points in a targeted manner and to
concentrate on the transfer of results between phases in order to increase
transparency, address risks, increase efficiency, and guarantee the general
convergence between planned goals and actual results.
3.1.2 Goal definition through feasibility study and business case
The feasibility study and the business case analysis serve to ensure the
necessary alignment of internal and external participants and to outline the
essential parameters of the target state and the step by step approach.
They represent the central elements used to decide whether to go ahead
with a transformation.
Align strategic goals with internal
and external participants
The feasibility study evaluates the extent to which the standard software
and the provider fulfill the banks’ requirements, by using a functional gap
analysis, the definition and integration of the target architecture as well as
an infrastructure concept and a sizing and operating model. The results of
the study must be presented at a sufficient level of granularity to allow the
bank to take vital decisions regarding further details, such as collaborations
for standard extensions and validation of specific aspects of the architecture.
The business case analysis reflects the complementary tool for internal
coordination between IT and business departments. Based on cost reduction and quality factors, the IT determines the required synergy potential
resulting from decommissioning of legacy systems, improved functionality,
and reduced maintenance needs. The business side determines the functional decision making criteria and evaluates individual factors, such as a
reduction of operational risk or shorter time-to-market as well as revenue
potential. The business case analysis supports the decision regarding
which areas should be the first to undergo a transformation and which ones
require further planning, such as those related to the distinguishing characteristics of competitors with unique requirements.
The transformation projects initiated by major banks over the last few
years are designed to be implemented over several years and the amount
invested reaches up to 1b EUR. The goal of these projects is to reduce
the Run the Bank (RtB) and Change the Bank (CtB) costs and to increase
profits. However, as these effects can only be realized in the long-term,
at least one additional factor contributes to the need for a transformation.
This can be a merger & acquisition (M&A) situation, the discontinuation of
support or a major upgrade by an IT provider, or a fundamental change in
the bank’s business strategy. The feasibility study and business case analysis provide necessary but not sufficient arguments for a transformation. An
additional factor functions as the catalyst for the final decision and provides
the necessary pressure during a transformation process which forces the
bank to continue the transformation.
Integrate additional factors
for the transformation
3.1.3 Alignment of the program with the goal
The ramp-up plays a central role during the preparation phase of the transformation program. This planning stage, which can take up to nine months,
determines whether the foundation has been properly laid to ensure that the
implementation unfolds according to plan. During the ramp-up, particular
7
Adhering to Goals © CORE 2013
attention should be paid to defining the project sequence and the project
contents. At the same time, it is vital to create a roadmap for the execution
of the program, determine the IT-architecture and layout, fix the details of
the contract with the software provider, and define a customized strategy for
drawing on the knowledge of external specialists (Fig. 4).
Content and schedule for preparation phase
Month 1 Month 2 Month 3 Month 4 Month 5 Month 6 Month 7 Month 8
Program
setup
Target Model Engineering
Initialization methods, processes, tools
Setup core team
Business
analysis
Operative PMO
Pilotation methods,
processes, tools
Month 9
Roll out methods,
processes, tools
Onboarding project resources, training
project team for standard software
Ramp-up project teams for
execution phase
Major decisions concerning
business strategy
Prioritization processes and products
Roadmap/
Planning
Definition roadmap
on basis feasibility
study
Refinement roadmap
on basis strategic
decisions and process/
product prioritization
Spezification process and product
architecture
Consolidation plans
for subprograms
Finalization corebanking
roadmap for start of
implementation
Reconciliation corebanking roadmap with overarching masterplan
Architecture design
Conception solution architecture
Definition integration architecture
Innovation
topics
Contracts,
Sourcing
Refinement solution architecture
Refinement integration architecture
Execution PoC Frontend Phase 1
Execution PoC Frontend Phase 2
Definition PoC Big Data Architecture
Execution PoC Big Data Architecture
Contract negotiations corebanking software provider
Definition work packages
and shortlist vendors
Selection vendors and
closure contracts
Source: COREtransform
Figure 4: Topics for execution readiness
The governance structure of the project must be agreed on at senior
management level, including all necessary boards and committees. This
refers also to management and escalation processes for closing functional gaps. Besides, a detailed plan of execution is to be presented along
with a sourcing mix, while the
process model must be estabFocus: Revolving planning
lished in coordination with the
software provider regarding
In order to stick to the previously
methods,
processes
and
defined key milestones, on the one
tools. In order to determine
hand, and to take into account the
the contents of the project
dynamic nature of developments, on
during this step, the IT side
the other hand, revolving planning
must present the target archimust be applied under the supertecture and the roadmap
vision of the project management
along with a proof-of-concept
office. This requires participants to be
(PoC) for innovative technoloincluded in the projects early on, in
gies and including the piloting
order to enable detailed planning and
phase, while the business side
to provide fix dates for the targeted
must synchronize the banking
milestones. Later project phases
processes and products with
must be planned with adequate granthe processes and the strucularity and these plans must be gradture of the standard software.
ually refined.
Simultaneously, the bank
must come to an agreement with the software provider in terms of a long
term, viable licensing model for the software solution and also as regards
the required support during the implementation phase.
Compile a concerted and
comprehensive plan during
the ramp-up
8
Adhering to Goals © CORE 2013
3.1.4 Goal achievement through focused implementation
The execution phase stretches from the analysis, design and realization of
the project to the test management and all the way through to the Go-live.
During the implementation all parties deliver results into their sub-project.
Moreover, the business specifies the execution requirements with regard to
products, functions, and processes. The benchmark for these specifications
is the advised business processes which are continuously brought onto the
new platform and secured in the project results. The milestone plan set up
during the ramp-up phase serves as the foundation for the implementation
of the project (Fig. 5).
Involve the IT and business sides
in dedicated ways
Roadmap/Project plan for execution phase with critical path
Critical path
Month
Overarching
topics
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21
Overall concept/architecture
Architecture
blueprint
Migration/Transformation readiness
Process/
functional
analysis
Functional analysis
Replication/
Migration
Analysis data cleansing
Data cleansing
Process analysis
Go-live processes
Cleansing terminating
products
Frontend
design
Backend
design
and realization
Analysis
Design & development
0.1
0.2
0.3
0.4
0.5
0.6
Pilot
Integration test
Go-live
Rel. 1.0
0.6
0.5
0.4
0.3
0.2
0.1
Acceptance test
User acceptance test
Introduction
management
Preparation
Change
Change
assessment calendar
Theme
modules
Result
presentation
Training
Customer communication
Acceptance test
Change Governance Final structure
Roadmap
structure
and process
model
Sales: qualification, communication, etc.
Infrastructure
setup
Environment Environment
component integration
tests
tests
Environment
development
Environment Environment
acceptance production
tests
Environment
training
Source: COREtransform
Figure 5: Plan for the execution phase with key milestones
The milestone plan defines the project steps with delivery types and dates
and sets up the critical path for the transformation. According to the process
model, the targeted processes and products are analyzed, modeled and
executed along with the business side. The analysis and execution should
be conducted simultaneously to ensure the completion of sub-projects
Carry out activities simultaneously
and ensure precise coordination
9
Adhering to Goals © CORE 2013
and to avoid delays later on. The project should include sub-releases with
defined scopes and delivery dates that span the various sub-projects, to
enable the coordination of parallel activities, provide orientation for the
participants, and ensure the implementation of systematic checkpoints.
3.2
Decisions, or: forks in the road
Decisions constitute a central steering element in projects. They determine whether and to what extent certain options are realized, establish the
direction of a project, sharpen objectives, and create unity – sometimes by
overcoming major obstacles. Due to the high level of complexity and the
inherent uncertainty in transformations, those responsible are faced with
the need to take decisions on the basis of incomplete and sometimes insufficient information. The challenge lies in avoiding compensating for this lack
of information with intuition, and instead to find means for fact-based and
educated decisions and to consolidate these within the framework of decision management.
Take decisions based on facts
In the transformations supported by CORE, this management was successfully realized in different ways: through ad-hoc decisions, through the strict
timing of meetings as well as by an equally requirement- and managementoriented approach which is usually taken for critical decisions during transformations. In the following section, we will take into account both, the decisions of the bank management as well as those made jointly by the bank’s
senior management and that of the software provider. We will first focus on
the distribution of decisions and steering committee meetings, followed by a
discussion regarding their content and finally conclude with a consolidation
of the results of these analyses.
Define the organization for decision
management
3.2.1 Decisions: the core task of management
The frequency of decisions and meetings at the program management
level is unequally distributed across the individual project phases, greatly
increasing during the later phases. Less than 10% of decisions are made
during the modeling phase and less than 25% during the preparation
phase, which means that almost two-thirds of decisions are made during
the execution phase. The number of decisions in the execution versus
the modeling phase increases almost six fold, while at the same time, the
number of meetings increases fourfold. Whereas meetings take place quarterly during the early phases of the project, they are held every two weeks
during the later phase, prior to the Go-live. This corresponds to the fact that
in the beginning, relatively few principle, fundamental decisions are made,
while more specific individual points must be clarified in a timely manner
during the later implementation phases.
The higher frequency of meetings in light of the increasing number of decisions ensures that the number of decisions made per meeting remains
relatively constant. This prevents participants from “waiving through” decisions due to their large number and in view of the organization secures
a fact-based focus for the meetings. In addition, the higher frequency of
meetings in the later phases supports timely decision-making and thereby
strengthens the information base, as arising questions are addressed while
participants are still actively involved.
Ensure continuity and focus on
facts by increasing the frequency
of meetings
10
Adhering to Goals © CORE 2013
Beyond these insights, which are directly related to the project phases,
a more in-depth analysis demonstrates the development of a characteristic pattern for the distribution of decisions and meetings within the single
phases (Fig. 6). During the modeling phase a particularly high number of
decisions occurs in the middle whereas the frequency of decisions in the
preparation phase is highest towards the end of that phase, and during
the execution phase a peak occurs in the first third of the phase, with the
number of decisions remaining at a relatively high level during the rest of
the execution. These results are confirmed by a more differentiated analysis which examined decisions made by the bank together with the software provider, on the one hand, and those made by the bank alone, on the
other hand.
Number of decisions and steering committees across the project phases
Number Steering Committees
1
2
1
1
1
1
4
3
4
3
5
21
21
Number Decisions
2
3
6
39
35
16
14
12
2
9
2
2
Modelling
Q1
14
Q2
Q3
Year 1
Q4
5
2
Preparation
Execution
Q1
Q4
Q2
Q3
Year 2
Q1
Q2
Q3
Year 3
Q4
Q1
Q2
Year 4
Source: COREtransform
Figure 6: Distribution of decisions and meetings
The finding that there is not a successive increase but rather a characteristic distribution of decisions and meetings is of central importance to a
transformation project. This reflects the fact that decisions must be made
at very specific points in the project in order to drive it forward. A linear or
even exponential increase in decisions could lead to the assumption that
the decision-makers were surprised by the progress of the project instead
of steering and controlling the project with their decisions.
Take the distribution of decisions
into account
Two kinds of evaluations can be used in order to analyze the contents of
decisions.
›› The first analysis revolves around the project criteria of scope, budget,
and time.
›› The second analysis aims at distinguishing between decisions as
regards approach versus content.
The analysis of the project criteria (Fig. 7) shows the clear dominance of
scope decisions. It is noticeable that an agglomeration of all three dimensions, scope, budget and time, occurs at the end of the preparation phase,
and that they are almost equal in value, aside from the time dimension. In
the execution phase, decisions regarding scope outweigh the other dimensions, while budget and time are prominent only in the first third of the
phase and then again at the midway point of the execution phase.
Decide on scope, budget, and time
at the end of the preparation phase
11
Adhering to Goals © CORE 2013
Number of decisions concerning scope, budget, time
Scope
Time
Budget
28
21
16
16
14
14
12
12
9
9
9
12
2
2
2
2
2
Modelling
Q1
Q2
Q3
Year 1
Q4
2
2
2
Preparation
Execution
Q1
Q4
Q2
Q3
Year 2
5 5
2
Q1
Q2
Q3
Year 3
Q4
Q1
Q2
Year 4
Source: COREtransform
Figure 7: Decisions according to scope, budget, time
A similar pattern occurs in regard to the differentiation between project
procedure and project contents (Fig. 8). The decisions in the modeling
phase are related to the contents of the project, it is only at the end of the
phase that the procedure is established. This procedure remains a topic of
discussion throughout the first phase of preparation, while a clustering of
decisions again occurs at the end of this phase, this time related to both
dimensions. Decisions regarding the project procedure are not referred to
again until the beginning of the execution phase and again at the end of the
project, but decisions regarding content dominate throughout the project.
Take decisions on approach and
content jointly
Number of decisions concerning project content and approach
Project content
Project approach
35
25
21
14
12
2
2
Modelling
Q1
14
14
9
5
2
21
Q2
Q3
Year 1
Q4
7
5
2
2
Preparation
Execution
Q1
Q4
Q2
Q3
Year 2
Q1
Q2
Q3
Year 3
Q4
2
Q1
Q2
Year 4
Source: COREtransform
Figure 8: Decisions on content and approach
3.2.2 Comprehensive and consistent decision-making in crucial phases
This typology of decisions in regard to the distribution of decisions and
meetings as well as to differentiation among the content of decisions,
directs attention to the transition between the preparation and the execution phase. Decisions are concentrated at the end of the preparation and
the beginning of the execution phase. What is striking here is not only the
sudden increase in decisions, but the fact that decisions made during this
phase affect all of the factors and dimensions of the project in subsequent
phases. They are related to scope, budget, and time in equal measure, and
revolve around both, the content and the procedure of the project.
12
Adhering to Goals © CORE 2013
With regard to the differentiation between procedure and content, it is crucial
that the main dividing lines central to the implementation of the project
are drawn in relation to both
Focus: Establish subsidiary bodies
dimensions. Core decisions on
for decision-making
the content and procedure of
the project are dependent on
each other, and the establishIn order to embrace the manifold
ment of the space in which the
issues present in the decision-making
project is to develop at the end
processes, institutions undergoing
of the preparation phase and
transformations should establish indethe beginning of the execution
pendent, subsidiary decision-making
phase impacts both dimenbodies in addition to the steering
sions to the same extent.
committees involving the senior
management. These secondary entities function as reference bodies for
Within the context of differthe (sub-)projects and consolidate the
entiating according to scope,
projects’ requirements for information
budget and time, it becomes
and decisions. On the other hand, they
clear that budget and time
serve as contact points for the steering
decisions play a minor role in
committees and transmit their decithe later phase of execution,
sions to those involved in the projects.
but that they become relevant
With the help of such decision-making
one more time towards the
entities, it is possible to make factmiddle of the execution phase.
based and goal-oriented decisions that
Due to specific shifts in scope,
can be implemented accurately and
this phase is characterized by
effectively.
increased deliberation about
budget or schedule modification in order to reflect the new situation. Such suggestions should be
countered by a rigid focus on the scope. If budget and time become dominant factors during the execution phase, this is a signal that the project has
entered a critical stage of development.
3.3
Maintain budget and time,
focus on scope
Methods and tools, or: maps and signs
Methods and tools are essential for supporting the project and the project
management. With their help, relevant information is collected and
processed, partially through automated means. They serve to steer the
project and, by continually providing information, contribute in an essential way to the steering capability. Methods and tools are used in different
contexts during the project; some are used in specific project phases while
others are employed throughout the entire project. There are three typical
categories that describe the benefits of methods and tools.
Use methods and tools in a
specialized and context-specific
manner
›› Through access to methods and resources, processes and procedures
within the project are structured, standardized and coordinated, while
external requirements of the project are determined and decided upon.
›› Tools collect information from sub-projects and present it in a consolidated way, directly supporting the operational work of the sub-projects
and enabling self-monitoring and self-evaluation of the projects.
›› Tools are used to obtain data from sub-projects that these projects would
either not gather at all or only to a limited extent, since this data is not
13
Adhering to Goals © CORE 2013
directly linked to the operational work. This information is necessary for
the coordination of sub-projects, decisions by the management, and for
monitoring the project trajectory. The use of tools supports the continuous delivery of relevant data of the sub-projects.
3.3.1 Process Model
The task of the projects is to introduce the standard software and undertake
the necessary adjustments and additions, particularly concerning interfaces
and missing functions. In order to ensure the quality of the results, these are
produced according to a standardized process. The process model aims at
describing and defining the process beginning at the initial broad concept
followed by business details and IT design all the way to the final system
introduction and project end.
As there is nothing such as one single and overall valid process model for
transformations, project participants attempt to assert the tested models
from their own experiences: the bank, the software provider, and the
external consultants, the business and IT departments of the bank, and the
development team and those responsible for carrying out the test. Discussions about competing process models are not constructive and can escalate into “method wars”.
Lead discussions on methods in
a result-oriented manner
Process model detailing the requirements analysis
High-level requirements
analysis & design
Project
initiation
Requirements
analysis
Functional
solution
design
Design & Development
Technical
solution
design
Solution
build incl.
unit test
Process Analysis
Best
practice
identification
SIT incl.
E2E
test
Go-live/
Deployment
UAT
Project
closure
Final
test
Functional Analysis
Analysis conducted for all business processes that are
affected by project scope
Business
processes
selection
Test
Activities
and tasks
definition
Business
requirements
documentation
Analysis conducted according module structure of standard
software
Business
Partner
Account
Management
Payments
Services
Loans
Management
Cards
Management
Analytics
Source: COREtransform
Figure 9: Process model with focus on requirements analysis
Focus: One process model for
everybody
In order to direct discussions about the
“correct” procedure in an effective way,
the process model must be described
in sufficient detail and documented by
the bank in a comprehensible way. This
requires intensive discussions to be
conducted and finalized during the preparation phase as well as addressing the
possibility of a synthesis of competing
models.
In order to counter conflictprone
discussions
on
methods, a necessity for clarification is vital early on in the
project and in a comprehensive manner. Therefore, the
project management needs
to determine which tools will
be used for which steering
tasks, what type of information the (sub-)projects will
deliver via these tools, and
which information the tools will
process in what manner (see
chapter 3.3.2). With regard
Establish binding process model
prior to the execution
14
Adhering to Goals © CORE 2013
to process modeling and the functional analysis, the project management
must describe which perspectives will be depicted and the type of analysis
to be used, such as portraying the business perspective through a process
analysis or the perspective of solution components through a functional
analysis (Fig. 9). In view of the realization of the project, the process for
adjustments of the standard software and the implementation of proprietary
developments must be established (e.g. for modifying interfaces). In this
context, the project management must determine which types of results
are to be delivered and when. Regarding the testing of the system and the
test management, the parties involved must decide which test stages are
to be completed by the (sub-)projects for the single releases. The project
management must also describe in greater detail to what extent the projects
will submit their work packages to a system integration test (SIT) and to a
user acceptance test (UAT) (see chapter 3.3.4).
3.3.2 Project plan and dependencies
The project plan fulfills multiple functions: it supports the management of
the project, ensures that participants receive information quickly and expediently, and brings transparency to the dependencies within the project.
For this purpose, individual management tasks are summarized and subsequently supported by corresponding planning and management tools. The
projects and sub-projects are obligated to feed data into the tools from
which reports can be automatically generated, in order to inform participants about progress, risks, problems, and dependencies (Fig. 10).
Select tools according to specific
tasks
Project reporting based on the CORE Transformation Framework
Modelling
Phases
Preparation
Target Concept
Implementation
Go-live
Product Specification
Decomissioning
Architecture Specification
Guideline Determination
Disciplines
Strategy
Development
Execution
Transformation Setup
Sequence Definition
Masterplan Development
Model Definition
Masterplanning
Benefit Collection
Sourcing Strategy Definition
Enterprise Architecture Adoption
Compliance Management
Business Case
Ramp-up and Mobilisation
Audits, Assessments and Reviews
Target Model Engineering
Requirements Engineering
Tool-based reporting (selected views)
Sourcing Management
Transformation
Engineering
Quality Management
Risk Management
Architecture Management
Project Management
Change Management
Task Force Management
Operational Controlling
Operational
Management
Test Management
Rollout Management
Transformation Tool Services
Source: COREtransform
Figure 10: Reporting with the help of the program management tool
One central, server based tool for program planning, monitoring and
reporting should be created. Certain projects and sub-projects will be
attributed to this tool, in which their planning will be backed and executed,
starting with the baseline up to their respective updates based on a previ-
Enable project planning and
dependencies by using one
central tool
15
Adhering to Goals © CORE 2013
ously defined level of granularity. Of decisive importance to the granularity
are the milestones which are considered to be necessary for reporting
and for containing dependencies with other (sub-)projects. The dependencies contracts between the (sub-)projects are documented in the defined
milestones. By linking the various levels via milestones, the project plan
provides different planning levels reaching from the program as a whole
over the program roadmap to the project and sub-project plans. The project
planning tool can then be used to create reports for the individual planning
levels, which serve as the basis for management reporting.
Simpler solutions are available for financial and resource controlling, and
various tools can be used for information and special document management as well as for change request management and defect management.
The tasks and requirements in these fields can be narrowly defined in order
to provide customized information through a variety of tools.
3.3.3 Reporting
Reporting is one of the central means of communication during the execution phase. Data is processed and graphically depicted with the help of
standardized reports. The latter serves to inform participants about the
status, progress and management requirements of the projects and to
thereby create transparency for the (sub-)projects and management levels.
The use of granular presentations supports the analysis of potential aberrations and their roots.
Apply reporting corresponding to
phases and target groups
Postponement of deliverables to later phases (work packages per cw)
140
120
100
80
60
40
20
0
Plan as of cw 1
Is
Plan as of cw 8
Current
cw
-34
1
+2
-11
2
3
4
-24
5
-2
6
7
8
9
10
11
12
13
14
Wave of cumulated delays and top 3 projects according to non-completed work packages
New delays
100
80
59
60
40
20
0
-20
Cumulated delays
83
16
0
16
14
1
2
16
-2
25
11
14
3
34
24
59
85
2
85
0
83
85
6
7
Top 3
24
17
Integration
25
4
85
Total
Savings/Current Account
Development
14
Migration
5
Rest
30
Source: COREtransform
Figure 11: Work package statistics as an early warning system
Work package statistics provide an overview of the relationship between
the planned work packages to be completed within a reporting cycle and
those actually delivered (Fig. 11). This enables the implementation of an
early warning system that alerts the project management to the development of aberrations and shifts in scope, otherwise remaining non-noticeable. Contrasting juxtaposition of initially planned work packages and those
planned according to the latest update provides information about the
extent of a possible backlog created by shifts in delivery dates. The work
package statistics provide a graphic depiction of these shifts, allowing the
Implement an early warning
system to assist with steering
requirements
16
Adhering to Goals © CORE 2013
project management to counter such a backlog. Additional types of reports
such as the earned value analysis and the test case implementation also
alert to discrepancies between planned and achieved project results.
Integration readiness report
Applications
Cluster
Channels
Banking
Lending
Investments
Interfaces
Application
1 Branch Frontend
71
2 Online Banking
56
3 Call Center
42
4 Self-services
96
5 Operations Frontend
70
6 Foreign currency Frontend
47
7 Cashier Backend
8 Banking Terminal Backend
54
9 ATM
10 Statement printing
63
11 Domestic payments
76
90
69
14 Business partner
15 Cards management
63
16 Collaterals
35
17 Claims management
18 Ordering system
75
19 Depot management
20 Pricing
tbd
37
91
100%
53%
86%
17%
21 Workflow management
tbd
22 Document archive
78
Enterprise
systems
23 Authorization system
24 Data Warehouse
tbd
25 Tax
27 Group consolidation
28 Risk management
n/a
73
75–90%
50–74%
<50%
2
0
5
11
50–74%
<50%
7
15
50–74%
<50%
6
6
2
28
1
1
100%
100%
2
93%
7%
18%
4
n/a
>90%
75–90%
Defects closed/open
0
4
28
2
2
7
100%
Total
0
100%
2
2
1
3
N/A
100%
90%
10%
100%
61%
>90%
4
0
82%
0
n/a
28
0
3
3
95%
50
26 Finance/GL
n/a
Execution status
5
6
1
100%
11
Interface readiness
1
4
14%
83%
100%
5%
Total
6
17%
100%
10
8
10
1
47%
83%
3
8
4
8
4
24%
76%
2
23
9
42%
78%
55%
2
26
26
20%
58%
41
Support
services
2
1
80%
45%
28
2
14
60%
22%
Application readiness
3
5
38%
62%
40%
Open
9
32%
68%
61
13 CpD/Internal accounts
Closed
Defects
1%
99%
71
12 International payments
Executed
Execution
Readiness (%)
39%
0
26
N/A
2
4
Total
n/a
>90%
75–90%
Source: COREtransform
Figure 12: Focus on integration/interfaces
Other reports concentrate on the qualitative status of the (sub-)projects.
Status and integration/interface reports provide information about the
progress of the project with the help of key indicators. A traffic light system
indicates which fields require action (Fig. 12). Both, the dependency report,
created using the program management tool, as well as the early life report
(Fig. 13), which processes information separately for the IT and business
sides after the Go-live, are based on the traffic light scheme. Approval and
sign-off cascades (Fig. 18 below), drive the ultimate Go-live decision.
Access scope specific information
about status and progress
Early life report
G On track
IT
System
availability
G
Standard software solution
G
Frontend
G
ETL
G
Core data
Incidents
Emergency
activities
Quantity
framework
R Critical
Sales
Number customer
complaints
G
5
G
Waiting time
15 sec
G
Availability
96 %
G
0
G
Accounts
1.900
G
Savings
1.400
G
Call money
2.500
Availability hotline /
Ø Call duration
G
91% / 2:05 min
System relevant
calls
G
~350 (FC: 400)
G
Post-process.ing core data
30
G
Post-process.ing contracts
104
G
Open records dispo
G
Open records CpD
Number of calls
G
Maximum response times
1,52 sec
within 95% percentile
Complaints to
board
G
Amount of frontend calls
within scope of SLAs
Number of new
contracts
Frontend response
times
End of day
processing
A Under surveillance
Business
98,7%
A
Amount of achieved
SLAs (out of 10)
9
G
Stage 1
0
G
Stage 2
0
G
Reports ticket system
1
G
G
Emergency changes
Amount users in
dedicated environment
Services
0
Special cases
processing
~10.000
278
1.215
Source: COREtransform
Figure 13: Measuring the sustainability of success
17
Adhering to Goals © CORE 2013
Focus: Context and phase
dependent reporting
In order to cope with the changing
requirements in terms of information
and transparency over the course of a
project, reports for each specific project
phase need to be created. This ensures
that reports do not become simply a
routine, but that they are taken seriously
by the senders as well as the recipients
and that the current challenges of the
phases are being addressed.
its possible impact and probability of its
relation to the urgency of the event.
Test/defect reports (Fig. 15
below) illustrate data for individual and linked applications
according to time, categories,
and level of importance. The
reason for this multifaceted
presentation of data is that this
phase is exclusively focused
on defects and their resolution. Other reports depict the
magnitude of different factors
in relation to each other. The
risk/issue report in form of
a matrix describes the relevance of a risk as a product of
occurrence; it places the risk in
3.3.4 Testing and test management
Testing serves as continuous assurance for the quality of the results of
individual implementation steps. The complexity of the project, the successive development of the functionalities, and the process in the (sub-)release
steps, require a systematic test management in order to coordinate and
steer the typically thousands of test cases that must be carried out during
most of the execution phase.
The test management forms a central method within the execution phase
and is used as a means of steering and controlling to ensure proper integration and synthesis of the individual components into a complete system.
On the one hand, test management determines what will be tested. Within
this framework, specific tests are selected while the contents, scope and
timeline of the tests are planned and the test cases are defined. The IT
side and the software provider should be included in this process to avoid
testing standard functionalities whose quality has already been certified by
the provider. The development of individual components is directly followed
by the testing of the respective components (Fig. 14). These are the first
testing activities to take place and are initialized early on in the implementation phase. Additional testing steps are staggered throughout the process.
Typically, half of all test cases are component tests, followed by migration
and replication tests (20%), system integration and front-end tests (both
10%), non-functional (5%), end-to-end (3%), and finally acceptance tests
(2%). 90% of test cases therefore solely serve the checking of functions
and data migration capability.
Ensure quality through systematic
testing
18
Adhering to Goals © CORE 2013
Test activities according to shares and schedule
Test activity/test level
Share of test cases
Timetable
Test cases total
Go-live
Component tests
17 months
50%
10%
System integration tests
10 months
20%
Migration/replication tests
11 months
5%
Non-functional tests
10 months
10%
Frontend tests
8 months
3%
End-to-end tests
8 months
2%
User acceptance tests
6 months
Source: COREtransform
Figure 14: Overview of test activities
By establishing test environments, coordination, reporting, and defect
management requirements, the test management determines how tests will
be conducted and how the results will be handled. Test/defect reporting (Fig.
15) plays a particularly important role here, as the number
Focus: Early and structured testing
of test cases per test level
markedly increases along with
Testing should begin soon after develthe rising number of releases,
opment in order to ensure continuous
from a few hundred at the
quality control during the implementabeginning to several thousand
tion.
test cases in the last third of
the project. This is due to the increased functionalities that are implemented
with each release, which requires testing. Additionally, other regression
tests must be carried out since defects discovered in the previous release
must be examined in the current release to see if they truly have been
resolved and whether solving the aberration possibly led to the creation of
other defects.
Number of defects with severity critical and high
Defect history (cws)
Critical
478
2
2
144
48
High
49
20
29
3
2
1
96
72
434
100
168
-100
22
482
200
0
-102
234
498
593
Closed in cw
618
700
512
600
241
178 157
173 142 199 197 178 142
500
433
400
-154 -162 -112 -138 -183
-139
-135 -182
-225
300
-351
200
-300
Critical/ Test data/
Current Postponed New,
Not
defect accepted Retests
High
Open,
Accepted
Number of defects per application
22
463
Opened in cw
467
478
539
-200
50
Total
Open cumulated
300
19
6
13
Design detailed test reporting
-400
100
1
4
3
2
5
6
7
8
0
11
10
9
Drilldown: Defects application A1 on components
Critical
High
6
Critical
5
High
8
3
9
14
3
7
2
6
6
6
2
3
6
0
6
5
1
4
4
1
3
3
1
2
2
1
2
2
1
2 1
2
2
1 1 1
2 1 1 1
2
1
1
2
1
1
A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17
Source: COREtransform
K1
2
K2
2
5
K3
2
1
1
1
1
1
1
K4
K5
K6
2
K7
1
1
1
1
K8
K9
2
No
allocation
Figure 15: Test/defect reporting
19
Adhering to Goals © CORE 2013
3.4
Network, or: people and skills
A transformation requires a system to divide the entire project into phases,
nuanced decision management as well as specific and flexible methods
and tools. However, a transformation could not be implemented without the
banks’ employees and partners who draw on their knowledge to support
the project, who use their skills to shape it, and whose experience lead it to
the final success.
Exclusively drawing on its own
resources, the bank would
not be capable of providing
all of the diverse and specific
In order to cover the skill requirements
expertise and the related skills
that arise within the execution phase,
necessary for a transformaspecific skill areas for each phase
tion. The sourcing strategy
are to be identified using typical total
serves to determine which
load curves. From this, a skill sourcing
external support and skills
matrix (Fig. 16) is created to provide
the bank requires for a transspecific information about skill requireformation and to develop an
ments and their methodical integration.
approach for integrating these
skills adequately into the structures and processes of the transformation.
Focus: Phase oriented sourcing
Identify and integrate skill
requirements strategically
Distribution of skill requirements during execution phase
Load curve
skill type
Management
discipline
Type of skill scope
Project
management
1 Experience in major
projects to manage scope,
budget, time
Functional
management
2 Business consulting
Plan
Build
Integration
Test
Typical overall
load curve
Roll-out
Run
1
3 Requirement management/engineering
4 Quality and test
management
Technical
management
3
4
5 Architecture management
6 Solution know-how
standard software
7 Expertise system
integration
Organizational
management
2
8 Support communication
and decision
management
9 Expertise IT transformation
with focus on methods and
process
6
5
7
8
9
Source: COREtransform
Figure 16: Skill sourcing matrix
The skill sourcing matrix represents the basis to organize the integration
of the supporting consultants and to communicate the respective selection
processes transparently and comprehensibly for all participants. The depth
of detailed planning necessary to that end and the onboarding of experts
should be steered in a targeted manner starting in the preparation phase.
20
Adhering to Goals © CORE 2013
3.5
Go-live, or: the goal
All methods, processes, and tools as well as skills serve the goal of going live
with the new system and decommissioning the legacy system. The retention of the initially planned implementation will not be enough to achieve this
goal, as the corresponding processes have to be actively navigated. This
requires a complementary management designed from the perspective of
the Go-live. This Go-live management coordinates the individual projects
and sub-projects from the perspective of the end result and steers them
towards that goal.
Perceive dedicated Go-live
management as a requirement
for successful completion
The strategic planning of the roll-out starts about six months prior to the
Go-live. At this time, the management brings the operational focus onto the
elimination of defects and determines which business requirements must
be addressed to achieve Go-live readiness. Within this framework, the
management formulates specific acceptance criteria that will be successively measured and completed, on the one hand, and, on the other hand,
creates the decision-making capability for the Go-live. Finally, the Go-live
management plans the Post-Go-live situation.
Go-live criteria
Risk for Go-live
High
Medium
Low
To clarify
Ready for Go-live
Software
scope
ready
Software
quality
ready
Integration
ready
Infrastructure
ready
Drill-down criterion for software quality
SIT
completed
Data/
migration
ready
Processes/
trainings
ready
Organization ready
Communication
ready
Risks
addressed
Test case coverage sufficient
Bugfixing
completed
Production
readiness
Software
quality ready
T
Test
case cover- Current (% of
age sufficient
suKPI
f
fficient
Go-live criterion)
Detail assessment for bugfixing completed
UAT
A
AT
Cycle 1
completed
Test cases 1
Cycle 2
completed
Bugfixing
Test cases
completed
completed
Quality criteria
satisfied
Go-live criterion
(% of total)
1,871 (90%)
Total
Current
plan
2,079
2,079
Test cases
Production
completed
readiness
///////////////////// Test cycle not started /////////////////////
Test cases
completed
///////////////////// Test cycle not started /////////////////////
Lasttest
Cycle 3
…
bestanden
Showstopper
criteria satisfied
Bugfixing
completed
1,598 (85%)
Defects
fixed
44 (53%)
83 (100%)
83
n/a
Defects
fixed
30 (43%)
70 (95%)
74
n/a
Defects
fixed
Cosmetic defect Defects
criteria satisfied fixed
13 (52%)
25 (90%)
28
n/a
1
n/a
Major defect
criteria satisfied
Minor defect
criteria satisfied
1 (n/a)
0
(0%)
Source: COREtransform
Figure 17: Acceptance criteria for the Go-live
The consolidated preparation of the program process according to Go-live
criteria provides a fact-based view and links the status of the deliverables
within the projects to the overarching status of Go-live readiness. This
allows identification and evaluation of necessary actions in order to take
specific measures.
21
Adhering to Goals © CORE 2013
With regard to the acceptance criteria, requirements are formulated for
individual areas in a specific and multi-level way including risk evaluations, and the implementation
status of these requirements
Focus: Fact based and successive
is continuously reported (Fig.
approvals
17). The operative numbers
resulting from these reports
Decision cascades (Fig. 18) can
enable the project managebe used to ensure that the expectament to undertake precise
tions of all stakeholders as well as
and fact-based decisions
the IT and business sides are taken
regarding the acceptance of
into consideration in a coordinated
the project. At the same time,
manner, allowing the acceptance for
the project management must
the Go-live by the executive board.
ensure that all stakeholders
are informed about the progress of the project and that their expectations
are taken into account, whereby the acceptance criteria provide the necessary transparency.
Create decision-making capability
using detailed criteria
Approvals prior to Go-live
Sign-off program
Sign-off line
organization
Sub-programs
Business &
Operations
Banking
Investment
Sales
Lending
Product
management
Channels
Services
Sales
Bank controlling
Finance
Introduction
management
Sign-off
overall program
Program/ release
management
Go-live sign-off
IT
Program
steering
committee
Business
Finance
Business management
IT
Deposits
Overall program
management
Go/ No-Go
COO
CFO
Point
of no
return
CIO
IT
Business
Payments
Application
management
Production
management
Standard S/W
provider
Services
Organization
management
Finance
Business units
T-23 days
Source: COREtransform
T-16 days
T-13 days
T-12 days
T-9 days T
Figure 18: Approval and sign-off cascade
By means of release cascades, stakeholder decisions are brought into a
distinct structure; thereby, the dependency between the single competencies is respected and taken into account. In addition, it establishes transparency and addresses possible needs for preserving the responsibilities.
22
Adhering to Goals © CORE 2013
4Successful Transformations through
Goal-oriented Approaches
The manageability of the project and the management’s ability to steer the
project are crucial for the success of the transformation. The complexity and
uncertainty of the project should not be eliminated, but must be addressed
within the respective contexts. Transformations require complex management that draws on knowledge, skills, and experience and uses specialized
mechanisms and instruments to react flexibly and to steer the main challenges in a goal-oriented and successful manner.
Always keep focus on crucial
success factors
›› Provide orientation: An adequate framework that divides the program
into different phases with specific management and controlling scopes
ensures the provision of orientation throughout the duration of the
program and the continuity of the procedure for all involved parties.
›› Take decisions: The decision management ensures a balanced foundation for both the provision of necessary information as well as for the
essential scopes of the decisions, within the context of the individual
project phases, which allows for consistent decision-making.
›› Use tools: Specialized methods and tools secure the quality of results
and provide detailed information about the status and progress of crucial
areas, allowing participants to identify the steering requirements and to
adjust developments in a detailed way.
›› Connect experts: Identifying and connecting the employees and skills
necessary for the transformation ensures that the best candidates for the
respective task fulfill the identified requirements with respect to scope as
well as to the different project / program phases.
›› Finalize projects: The Go-live management consolidates the results of
the projects using specific Go-live criteria and simultaneously creates
the decision-making capability with the participation of all stakeholders
to ensure that the power required for the completion of the transformation is available.
With the help of these steering mechanisms, the management will be able
to adhere to the goal of transforming the core banking system throughout
all phases of the program and to lead the transformation in a goal-oriented
and efficient manner, thereby using the standardization of the IT system to
lay a strategically important building block for dealing with the challenges of
structural change in the banking market.
23
Adhering to Goals © CORE 2013
Appendix
Standard Software Providers for Banking
Europe
ABIT
G&H Bankensoftware
afb Application Services
iBS – Innovative Banking Solutions
Asseco South Eastern Europe
ICS Financial Systems
Avaloq
International Financial Systems
b+m Informatik
Intertech
B+S Banksysteme
Inversia
Banking Information Systems
Knowis
Bavaria Banken Software
Misys
BearingPoint
msg Gillardon
Bosch Software Innovations
Murex
Capital Banking Solutions
Neptune Software
Center of Financial Technologies
PASS Consulting Group
Colvir Software Solutions
Probanx
Commercial Banking Applications
Prof. Schumann
COR&FJA Alldata Systems
Profile
CPU Bankensoftware
R-Style Softlab
Delta Informatique
SAB Ingenierie Informatique
Diasoft
Sage
DIE SOFTWARE Peter Fitzon
SAP
e.stradis
SmartStream
EFDIS
SOPLEX Consult
ERI Bancaire
Sopra Banking Software
EVRY
Subito
Exictos
Temenos Group
FERNBACH Financial Software
Torstone Technology
Finnova
UNiQUARE Software Development
Forbis
zeb/rolfes.schierenbeck.associates
FORS-Banking Systems
North and South America
Accenture Software
Fundtech
ACI Worldwide
Harland Financial Solutions
Calypso Technology
International Private Banking Systems
Calyx Software
Kyriba
CLS Group
Mimics
Cobiscorp
Open Solutions
Computer Sciences Corporation
Openlink Financial
Datapro
Premium Technology
De Larrobla & Asociados (DL&A)
Provenir
Financial Software Systems
Sungard
FIS
Top Systems
FISA Systems
TwoFour Systems
Fiserv
Wall Street Systems
Asia
3i Infotech
International Turnkey Systems
Agile Financial Technologies
Nucleus Software
Autosoft Dynamics
Oracle Financial Services Software
BML Istisharat
Path Solutions
HCL Technologies
Polaris Financial Technology
Infopro
Silverlake Axis
Infosys
Tata Consultancy Services
InfrasoftTech
Oceania
CCK Financial Solutions
New Technology Business Solutions
A database with further information about the product portfolio of the
providers is available on http://www.coretechmonitor.com.
24
Adhering to Goals © CORE 2013
Authors
Christian Böhning is Managing Director of CORE.
He previously held leading positions in several international projects focusing on the transformation of core
banking systems. In his work, he concentrates on IT
transformation management, particularly with regard to
technology, processes, implementation planning and
steering in crucial business areas.
Dr. Mirko Schiefelbein is Knowledge Manager at CORE.
He obtained his PhD in philosophy and possesses
in-depth experience in the field of interdisciplinary
research. He has managed numerous research projects
and created a knowledge portal in the field of education.
He specializes in integrated knowledge transformation.
Christian Schneider is Transformation Associate at
CORE. He obtained a Master of Science in Financial Economics at the University of Maastricht and has
conducted research on the interplay of motivation and
behavior. At CORE, he brings his market and management expertise to the steering of complex IT transformation projects.
About the COREinstitute
The COREinstitute conducts research on the dynamics and systems
of complex transformations in various industries and sectors in order to
develop new solutions within transformation management for industry
experts, researchers, and engineers. The COREinstitute makes the results
of its interdisciplinary research available to the public across a variety of
media and through a range of publications.
Disclaimer
The logos depicted in this report are the property of the respective companies. COREtransform GmbH does not own the rights to the logos and is
using them exclusively for scientific purposes.
25
Adhering to Goals © CORE 2013
COREtransform GmbH
Am Sandwerder 21
14109 Berlin | Germany
Web: www.coretransform.com
Blog: www.coretechmonitor.com
Phone: +49 30 26344 020
Email: [email protected]
Copyright © COREtransform GmbH
March 2013