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 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


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


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 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 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


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


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


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


� 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


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


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


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


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


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


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


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


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]

Model Banks One Route to Lean IT

Documents

Transcript of Model Banks One Route to Lean IT