Model Banks One Route to Lean IT
Transcript of Model Banks One Route to Lean IT
Model BanksOne Route to Lean IT
Stefan Humburg, Jan P. Heck
April 2014
2
Model Banks: One Route to Lean IT, April 2014
© Platinion GmbH 2014. Copyright reserved.
For further information please contact:
E-Mail: [email protected] Phone: +49 (0)221 5895 8332 Fax: +49 (0)221 589 2051
Platinion GmbH Im Mediapark 5c 50670 Cologne
3
Model Banks: One Route to Lean IT, April 2014
Model BanksOne Route to Lean IT
About the authors
Stefan Humburg is Associate Director in the Cologne office of PlatinionHis focus areas are core banking systems and IT transformations in financial institutions. Stefan Humburg is member of the Platinion Banking Practice Group and member of the Leadership Group and Steering Group within Platinion. He is also core group member of the BCG IT Practice Area and the BCG Practice Area Financial Institutions Middle East
Jan P. Heck is Project Leader in the Cologne office of PlatinionHe is specialized in the financial service industry with focus on IT strategy and IT transformation. Jan is member of the Platinion Banking Practice Group
4
Model Banks: One Route to Lean IT, April 2014
nadequate application landscapes hamper efficient operations of many small and
mid-sized banks. They suffer from IT complexity, in part as a result of being sourced
from a wide range of vendors. Even core applications are often built up from different
customized vendor products or self-developed solutions. Therefore, application and vendor
maintenance is often either ineffective or very expensive. Demands for highly specific
internal development skills even worsen the situation. This complexity can slow essential
system enhancements, creating an implementation backlog of business requirements.
Banks are further hampered by having limited IT resources which leads to resource
monopolies, with an overreliance on key individuals and deficient system knowledge.
Even worse, most IT resources are committed to day-to-day operations and no capacities
are left to address innovative solutions. Two strategies exist for addressing these issues
1. Step-by-step: Partial IT simplification by reducing IT landscape complexity
2. Comprehensive: Replacing the wide areas of the application landscape including
core systems with a simplified package solution while adjusting the vertical
integration of IT by employing a single-sourcing strategy
Transforming or replacing significant parts of bank’s application landscape is one of the
most challenging technology and business transformation projects for any company. It
involves strategic and structural changes encompassing all banking operations and
their entire IT underpinning. Whatever strategy is chosen, it will require a significant
transformation process involving the whole bank. Our understanding of transformation
management covers steering of three parties: application vendor, third party providers
as well as the implementing bank. Only with this multidirectional steering, in time delivery
from all parties and an accelerated, smooth go-live can be ensured.
In such an extraordinary situation for the bank, Platinion as a professional and
experienced orchestrator can add significant value. Just one reference from our track
record: „… fastest core banking systems replacement seen during last 18 years–
leveraged by a highly efficient business requirements specification and stringent
transformation management.“ (Global core banking systems vendor after go-live)
I
5
Model Banks: One Route to Lean IT, April 2014
This article draws on best practice showing that small and medium-sized banks can implement
the comprehensive approach of replacing wide areas of their application landscape within a
limited timeframe. There are several reasons why a bank may choose to take on this challenge
� Business strategy change
� Competitive pressure from other banks or M&A situations
� Need for increasing business and IT efficiency by creating a streamlined IT operations
� Legacy systems unable to handle product expansion or requirements from regulator
� Revenue growth opportunities through offering innovative products across multiple
channels and reaching more clients
� Infrastructure renewal to enhance efficiency and decrease associated costs
Banks aim to achieve the benefits of a renewed application landscape while minimizing cost
and complexity of this transformation.
The above mentioned successful Platinion project shows that this is applicable. Our client is a
small regional bank, specialized in corporate and selective premium banking. The replacement
of its tier one state-of-the-art banking solution and additional applications following the best
practices processes and preconfigured modules provided by an application vendor (typically
labeled as model bank).
The former application landscape was made up of the core applications and more than
20 additional satellite systems. A lack of integration has led to high IT costs and almost
unmanageable complexities. Platinion supported the entire project from strategy development,
vendor selection until the successful go-live.
Strategic drivers for adopting a model bank approach were
� Simplified IT landscape: Highly integrated, standardized solution with limited customi-
zation, developed by an external service provider
� Resolved operational risks: Diminished dependency on niche IT resources, achieved
by simplified and standardized core applications with fewer third party interfaces
� Tighter business/IT alignment: Decrease internal IT complexity through purchasing of
standard software instead of in-house development, allowing the IT department to focus
more on client and requirement management
� Shorter time-to-market: Standardization reduces the need for additional customization
when launching new products or services
6
Model Banks: One Route to Lean IT, April 2014
Model bank as an answerThe Core Banking System (CBS) is the heart of a bank‘s IT. It is the central system or
a tightly integrated set of applications which processes daily banking transactions and
posts updates to accounts and other financial records. It underpins nearly every business
process in a bank by enabling basic functions such as gathering deposits, making loans,
handling customer data, payments, and managing corporate cash.
IT environment of a typical bank
Figure 1: Core Banking System in the context of the overall IT landscape
The CBS is integrated into the IT landscape through numerous interfaces with various
other (enterprise) systems including the bank‘s general ledger and external systems such
as card handling and check processing. During the last decade, the bank‘s demand for
multichannel solutions such as online or telephone banking and various payment channels,
has increased. This makes vastly intensified demands on the usually matured CBS, creating
needs for functions, flexibility, and scalability which most existing systems cannot handle.
Model bank, a concept offered by different IT/CBS vendors, simplifies CBS solutions by offering
comprehensive, standardized out-of-the box solutions adaptable to a bank‘s needs following the
best practices processes and preconfigured modules. Most offer a broad variety of functionality,
reducing the complexities created where numerous heterogeneous solutions are integrated in
satellite systems. This can make the introduction of new CBS solutions both simpler and quicker.
7
Model Banks: One Route to Lean IT, April 2014
Model bank solutions have several key characteristics
� Industry-leading bank processes set up in the system and adaptable to an individual
bank‘s needs
� Pre-configured bank products and simplified launching of customized products
� Community net effect—collateral benefits from employing an innovative CBS vendor
which also delivers similar services to other clients
� Majority of key banking functionality covered by the out-of-the-box solution, with
no need for configuration or development specification. The „plain vanilla“ model bank
covered already 85% of the project bank‘s requirements
� Highly integrated system limits the number of third party interfaces while interface
adapters for standard systems make integration easier
� External partners accelerate future developments due to a standardized solution
In our recent project, the initial release of a model bank-driven CBS was delivered within
four months of the vendor contract being signed. All products and processes included in the
release were completely configured, covering the majority of the bank‘s requirements without
any need for customized development. The information needed for configuration and all future
customized development was gathered, aligned, and signed off within two months.
The majority of best practices known from other large scale IT transformation projects also
apply for CBS replacements with model bank solutions. Beyond that, the following four key
topics should be kept in mind
� Adapting the RfI/RfP paradigm by placing the burden of proof on the bank rather than
the vendor (i.e., the bank tries to prove why a standardized best in class solution is not
able to meet its requirements)
� Contractually anchoring key milestones to facilitate the bank in steering the project
� Manage the bank to efficiently set requirements and provide metric-based progress
monitoring–requires steering of all key stakeholders including implementing the bank
and goes significantly beyond usual vendor steering approaches
� Meticulous preparation for smooth go-live–only achievable at any point in time
throughout the transformation if the items critical to the mission are identified and their
status is transparent as well as reliable
Obtaining an initial configured system release requires preparation. This starts with a
comprehensive vendor selection process adapted to the model bank approach.
8
Model Banks: One Route to Lean IT, April 2014
Adapting RfI/RfP paradigm to model bankMulti-phased RFI/RFP processes for vendor filtering/selection are well known by most
banks-but how to achieve target-centric requirements definition and commitments from both
parties?
Once a bank has opted for CBS transformation, the next step is streamlining vendor selection.
In our project, an RfI/RfP-driven vendor selection process, including negotiation with the
chosen vendor, was conducted in 12 weeks. This timeframe was made possible by adapting
key paradigms of the selection process to an efficient and lean approach.
Shortlisted vendors were chosen using market know-how, emphasizing their experience and
regional footprint. Two preferred vendors were chosen via a Request for Information (RfI)-driven
preselection using previously defined knockout criteria and focused on the potential vendor‘s
adherence to a model bank-driven approach.
During most vendor selection processes, the vendor gathers the bank‘s requirements for the
new system. This almost invariably leads to the bank specifying a copy of its former system. We
inverted this paradigm so that the vendors presented their best practice solution (processes,
products, etc.), and the bank was required to show where and why these capabilities did not fit
its setup, reversing the usual burden of proof.
Functional range was evaluated during the initial RfI phase. Vendor information provided in the
Request for Proposal (RfP) was enriched through workshops on business-critical specifics.
Several reversals of normal vendor selection paradigms are essential when choosing a model
bank solution
� Focus on model bank functionality, assessing which requirements can be met
without individual configuration/customization
� No rebuild/copy of the current system-bank should adapt to the vendor‘s standard
operating model
� Adapt to vendor‘s standard operating model for standard services, with customi-
zation for business-critical bank specifics only
� Ensure business buy-in for a streamlined selection and decision process
� Any functional gaps which cannot be covered by the configured model bank are
documented, with the bank needing to sign off on their extent as input for the
contract negotiation
9
Model Banks: One Route to Lean IT, April 2014
During our project, we held six weeks of dialog-driven, functional vendor workshops with
two potential vendors, evaluating their capabilities in detail. Each workshop focused on
specific topics and started with a brief functional overview by the vendor. Multiple options
were compared through parallel workshops with both vendors. Each session ended with
both sides signing off. Topics addressed during the workshops were in line with the overall
evaluation model, including banking topics like customer data, treasury, trade finance,
wealth management, cards, channels, compliance, and reporting. IT-driven topics such as
interfaces, post-implementation activities, data migration, and infrastructure requirements
were also discussed during this phase.
10
Model Banks: One Route to Lean IT, April 2014
Contractual anchoring of key milestonesMilestone-driven planning usually forms the basis of a transformation - but when was the
last time you negotiated a vendor contract that has financial penalties in place in case of
late delivery?
Large transformation projects such as CBS replacements and renewal of significant
applications and architectural designs often lack of two issues in the contracting and
planning phase
� Typically, vendor and third parties are not willing to accept penalties on milestones
and banks are not using their negotiation power to implement success fees on
in time and in quality delivery (in budget delivery typically healed by fixed price
contracts)
� Planning mostly done by assuming best progress along the entire project timeline-
contingency not accepted by the bank. If accepted and put into the project plan
transparently, the consumption is taken into any activity by the first day of the
project
Between the selection of a vendor and the beginning of the transformation project to the
new CBS solution, two tasks are essential
� Vendor contract signed: Detailed service contract negotiated and signed with the
preferred vendor
� Transformation planned: Detailed plan devised including key topics like specifi-
cation, test, data migration, and training
These two activities should be executed in parallel. This creates the robust contractual
basis essential to success, enabling the bank to embed key milestones (e.g., delivery of
major releases) into the vendor contract and to consider contractual dependencies in
planning.
Vendor contract negotiation should incorporate the following
� Standard requirements/scoping: Detailed scope definition including processes
and products to be covered by the model bank
� Non-standard functionality: Functional gaps requiring customized developments
must be defined in detail, including description, priority, and pricing
11
Model Banks: One Route to Lean IT, April 2014
� Integration: All systems requiring integration/interfaces with the model bank need
to be outlined and prioritized in the contract
� Responsibility for activities: Ownership (bank or vendor) has to be agreed for all
activities, especially data migration, training, test preparation, test execution, and
troubleshooting
� Penalties for non- or late-delivery: All key milestones (including transformation
start, functional gap specifications deadlines, release delivery, go-live) have to
be specified. Key milestones should be directly linked to payments, incentivizing
on-time delivery of components
� Transparency regarding transparency: If contingency is considered as part of
the plan, this needs to be explicit in the contract and use of this contingency needs
to be addressed
Depending on the bank‘s situation, size, and budget, transformation to a model bank-driven
CBS can be achieved within 18 months. The following chart provides an overview of the
key phases
Figure 2: Key phases of model bank-driven CBS implementation
12
Model Banks: One Route to Lean IT, April 2014
During the implementation and test phase, the vendor must provide at least three major
CBS releases, what offers the bank early, tangible deliverables, what also helps to get
familiar with the architecture:
� Configured model bank: Standard out-of-the box solution configured according
to bank needs outlined during configuration workshops (performed in the specifi-
cation phase)
� Functional release: Configured model bank solution including development for
closing functional gaps
� Final release: This release includes all components (model bank, closed functional
gaps, interfaces, and migrated data) and is used to test the CBS solution in an
end-to-end fashion
Milestones for these key releases should be incorporated in the vendor contract alongside
other key milestones and timelines such as provision of gap/interface specifications, in
order to ease vendor steering and ensure on-time delivery. Consideration of contingency
has to be avoided and if not needed to be explicit and associated with respective
measures, e.g., in case contingency is needed this needs to be started from day 1 without
any delays. The key for us is to steer the entire transformation process-not only the CBS
vendor but also third party providers as well as the implementing bank. This enables
access to bank-internal resources and accelerates the delivery of critical items on time
and in the right quality, including the need to establish C-level responsibility for work
packages critical to the mission.
13
Model Banks: One Route to Lean IT, April 2014
Manage the bank to efficient requirement setting and provide metric-based progress monitoringStatus/progress reporting is usually applied in every major IT program - but managing all parties
involved, including the implementing bank itself, already during requirements specification and
testing often does not get the attention needed.
Most key bank deliverables should be provided during the specification phase. This reduces
the risk of delays being caused by missing or misleading bank deliverables. Close tracking
and stringent progress monitoring across the entire project is essential to ensure success.
This should not be a one-way street. Transformation management has to consider multi-stake-
holder steering - not only vendor steering - covering application vendor, integration partner, and
implementing bank.
At the beginning of this phase, bank representatives receive introductory training providing a
functional overview of the new CBS solution. These sessions are focused on in-scope business
processes selected during evaluation. During our project, about 500 business processes were
selected from the vendor‘s standard reference process model.
Two major topics, configuration of the model bank and functional gap specification, predominate
during the specification and test preparation phase.
Configuration of the model bank
Configuring processes, products, reports, and other CBS functionalities is necessary to adapt
standard out-of-the-box functionality to the needs of the bank. CBS vendors using a model
bank generally use proven approaches to collect information. The bank provides the input as
well as reviewing and signing off the configuration.
The CBS vendor is responsible for gathering all the information required to configure the model
bank. Standardized input formats are usually leveraged to enable the vendor to use this input
in an automated fashion. Progress should be tracked on a daily basis by project management
(the following charts illustrate a streamlined process). Creation, review, and approval times for
these inputs should be specified in the vendor contract.
14
Model Banks: One Route to Lean IT, April 2014
Figure 3: Model bank configuration process and monitoring
Close tracking of project deliverables and related milestones is essential for all topics. Their absence
can create significant difficulties, particularly if bank deliveries are binding in the CBS contract.
During project planning, many CBS vendors assume that the bank will delay or miss significant
deliverables. This leads them to propose challenging, often unachievable, transformation timelines.
In cases where the bank can deliver, driven by realistic planning and properexecution, CBS vendors
are sometimes incapable of adhering to their own plans.
Whenever possible, processes for alignment, review, and approval of the bank’s deliverables should
be incorporated into the contract. The CBS vendor acts in a monopoly setup-vendor lock-in with
insufficient solutions need to be avoided. Vendor commitments made during selection/negotiation
phase are usually not reliable and need in-depth challenging by leveraging former project/vendor
solution experience.
Functional gap specification
Precise specification of mandatory functionality not covered by the standard solution is required
(e.g., bank-specific products or individual functionality). The bank must specify all such requirements
during the initial phase of the transformation. These include
� Objectives and scope of the functionality, which causes the functional gap
� Functional requirements including key players and roles, workflow/functions, business rules,
user interface/automation, accounting entries, and outputs
� Non-functional requirements including volume details, security, performance, and migration
15
Model Banks: One Route to Lean IT, April 2014
A description of each of these functional gaps has to be provided, reviewed, and signed off
by business. In response, the CBS vendor should provide details of functional specifications
required to resolve the gap in preparation for the gap closure implementation. Even though
model bank-based solutions offer flexible and easily modifiable solutions, adapting it to
non-standard bank specifics could prove challenging if extensive development is required.
Early alignment and detailed specification of required non-standard functions is critical.
Model bank-adapted testing
Usual testing procedure needs to be adapted in order to fit with a model bank-driven approach.
Model bank release is usually delivered by providing a pre-configured model bank, implemen-
tation of bank‘s specifics, and an integrated solution. Testing needs to go along with three
phases taking into account the respective focal points (configured model bank, bank-specific
functionality, integration with other systems) of each implementation build. This enables testing
to be facilitated through key success criteria
� Consistent testing skills across all testing phases - same people testing all key functionalities,
prepared with respective trainings
� Model bank-focused mindset - standard functionality in focus - raising numerous additional
requirements does not support the model bank approach
� Early identification and validation of model bank configuration by defining key
configuration elements
Incremental model bank testing has to be conducted as early as possible during testing. Test
execution needs to be integrated as soon as all components (configuration, bank specifics, and
integration) are available. Testing can then commence in a consolidated approach also taking
into account migrated data.
In parallel to testing, it needs to be ensured that the bank is performing the following
transformation tasks
� Data migration including data mapping, cleansing, loading, and dress rehearsals
� Training for all users to gain system knowledge and experience
� Infrastructure to set up environments for development, test production, and training
After testing has been completed, proper preparation of the go-live phase including detailed
planning of dress rehearsals and the go-live weekend has to be conducted.
16
Model Banks: One Route to Lean IT, April 2014
Top management accountability and meticulous preparation for smooth go-liveMost would agree that go-live planning is the key success factor, but did you ever have all
members of Clevel responsible for go-live preparation and execution?
Last phase prior and during go-live is the most intense and critical phase of the entire
transformation. Nevertheless, successful go-live can never be achieved in isolation during
this phase. Only early step-by-step preparation of critical topics throughout the entire
transformation leads to a successful and smooth go-live. Multiple user acceptance tests
and dress rehearsal iterations with defined quality gates form the basis.
To realize a successful go-live, Platinion leverages clear C-level ownership of go-live
topics critical to the mission and well-informed escalation. This covers ensuring staff
readiness through trainings, operational readiness health checks by all business lines, and
definition / implementation of standard operating procedure for most critical business
processes. It is not required to achieve full documentation coverage of all system
functionality at go-live, but it is very important to have at least all manual workaround
documented at that point in time. An initiative to close the documentation gaps should be
initiated in parallel to the final go-live preparation activities.
This accelerates the resolution and puts the spot on the critical items that are jeopardizing
the go-live. Simple but reliable transparent status reports with measurable results are key
levers for escalation and progress.
Go-live planning is the key element and mechanism to steer the preparation and execution
of this phase. This consists of the go-live plan itself which, on a detailed level, usually
contains thousands of items and determines the execution of the plan. Detailed fallback
planning is, however, mandatory, in case the go-live cannot be executed as planned and
needs to be rolled back. The most important element for executing a go-live successfully
is planning and executing a continuous review process and walkthrough session with all
go-live participants with at least three dress rehearsals (real simulation) of the cut-over
procedure.
17
Model Banks: One Route to Lean IT, April 2014
The model bank is a viable solutionOur currently conducted go-live proofs that the model bank approach is well suited
to provide a core banking solution for small and mid-sized banks. It offers an effective
means of running lean IT setups with a small IT organization. Testing is to be conducted
staggered along provisioning of different system builds (model bank, bank specifics, and
integration). The bank needs to approach change with the right mindset, willing to use the
vendor standard functionality. It should stick to the vendor’s standard and only insist upon
individual development if absolutely necessary. It also needs to define functional gaps in
the vendor contract and avoid rebuilding the existing application landscape. Stringent and
contract-centric management of all key stakeholders is essential.
This report offers guidance, illustrated by real-life examples, as to how small and mid-sized
banks with limited IT capacity should go about this process
� Assessing whether a model bank is a feasible option for simplifying CBS replacement
and operations
� Strategic rationalization and prerequisites for introducing a model bank
� Best practice, in contrast to general CBS replacement/IT transformation projects,
for selection and introduction of a model bank
CBS replacement also causes major changes to the IT organization and governance,
especially if the approach is shifted to a model bank. IT organization, target governance
and operations processes, and business IT alignment need to be adjusted accordingly.
* * *
18
Model Banks: One Route to Lean IT, April 2014
Fastest core banking system replacement ever seenOne main challenge many small and mid-sized banks are facing is the limited integration
of their mature and widely customized key applications and satellite systems. Manual
workarounds to overcome the resulting limitations aggravated by the involvement of
numerous external vendors is a main driver for highly increased complexity, slowing
necessary developments and leading to an implementation backlog of business
requirements.
A radical modernization approach can be a viable option - replacing the CBS with a model
bank-driven solution. To make this approach work, knowledgeable guidance is a key
success factor. Platinion’s real-life expertise shows that the fulfillment of four conditions
is essential
� Adapting the RfI/RfP paradigm by placing the burden of proof on the bank rather
than the vendor instead of requesting requirements which result in a rebuild of the
existing applications or an extensive functionality wish list
� Contractually anchoring key milestones with penalties to set incentives for the
vendor to stick to the transformation schedule instead of facing the situation that
emerging delays are only causing financial impacts for the bank
� Early finalization of the functional specification and close progress monitoring to
ensure timely and streamlined delivery by vendor, third party, and bank instead of
having new requirements coming up throughout the entire project
� Meticulously prepared go-live phase to ensure smooth go-live and reliable,
metric-based status reporting instead of an ad hoc-driven go-live execution
� Establish accountability on all C-levels instead of steering an IT project with business
involvement
All these measures depend on a very experienced project lead to drive the full transfor-
mation process. Steering the CBS provider, potentially involved third parties (e.g., for
integration) as well as the implementing bank allow us accelerated delivery of critical project
results like business requirements and enable us to leverage these benefits step-by-step
throughout the entire project until go-live.
Stefan Humburg & Jan P. Heck
19
Model Banks: One Route to Lean IT, April 2014
About PlatinionPlatinion was founded in 2000 with two offices-Cologne and Munich. More than 125
consultants support clients in Germany, Europe, and increasingly beyond. Our clients are
mostly large companies and groups, but also prominent, medium-sized businesses.
Platinion projects are typically characterized by special challenges. These may originate
from the exceptional strategic or operational significance of the assignment. Other factors
may include the extent or the complexity of the project content-or quite simply its tight
deadline.
Our work at Platinion is always aligned with the client’s strategic economic objectives.
We judge solutions by their contribution to business success and long-term effect on the
company-wide IT architecture.
The interactions between technology, organization, and strategy lead to a variety of
different project types, as demonstrated by the following excerpt from our project portfolio
� Restructuring of IT processes and organization
� Functional and technical support of mergers and acquisitions
� Analysis of IT and software architecture weaknesses
� Specification and implementation of IT architectures
� Product evaluation, e.g., core systems
� Technical concept development and design of software solutions
� Quality assurance for IT implementation
� Design and implementation of feasibility studies
� Conduction of load and performance tests
� Management of large-scale projects
Cologne
Stefan Humburg
Im Mediapark 5c
50670 Cologne
Phone: +49 (0)221 5895 8332
Fax: +49 (0)221 589 2051
E-Mail: [email protected] or [email protected]