WIXLIB

4th IFIP TC2 Central and East European Conference onSoftware Engineering Techniques (CEE-SET 2009), Krakow, Poland, October 12-14, 2009Know-How Transfer in Core-Banking SystemImplementation Projects: A Case StudyKlaus Haller, Marcel HeubergerCOMIT AG, Pflanzschulstr. 7, CH-8004 Zürich, Switzerland{klaus.haller, marcel.heuberger}@comit.chAbstract. In the last years, many Swiss banks replaced their old core-bankingsystems with new ones. Implementing a core baking-system requires that thebank, the software vendor, and the implementation partner collaborate. Crucialfor the collaboration and the project success is planned and unplanned knowhow transfer. This case study examines the know-how transfer in a corebanking system implementation project for a retail bank with around 200project members. We describe the sourcing network and different roles peoplehave with respect to know-how transfer. We elaborate the methods used withinthe project for know-how transfer and present first results of a study looking ontheir effectiveness. Thus, this paper gives project managers a good insight intoknow-transfer within a project and points out how to stimulate themsuccessfully.Keywords: Standard Software, Core-Banking Systems Project Management,Project Organization, Know-How Transfer1MotivationDuring the last years, many Swiss banks modernized their IT application landscapeby implementing new core-banking systems [1,2]. Core-banking systemimplementation projects are a joint effort of the bank and an implementation partner.They customize the system to meet the bank's and its customers' needs. Whereas thefirst and most important (and widely investigated, see e.g. [3]) goal is to deliver theproject on time and on budget, this goal alone is not sufficient. The bank staff is onlyable to work with the new system and the application management is only able toensure the system's stability if know-how transfer takes place. Furthermore, there arealso know-how transfer issues in the project itself. The implementation partnertransfers customization know-how and process know-how gained in other projects.The bank contributes process know-how of their specific processes. In theory, theimportance of know-how management and know-how transfer in today's economy iswidely accepted [4]. Concrete efforts to improve the know-how transfer in a projector between projects like the one undertaken by Intel Solution Services [5] are seldom.One reason might be the inherent difficulty of measuring know-how transfer successand its benefits.

4th IFIP TC2 Central and East European Conference onSoftware Engineering Techniques (CEE-SET 2009), Krakow, Poland, October 12-14, 2009Nevertheless, COMIT decided to take a closer look on know-how management ingeneral and know-how transfer issues specifically in its implementation methodology,LeanStream [6]. LeanStream was initially developed for and used in two of the largestimplementation projects of the Avaloq core-banking system [7] with medium-sizedSwiss retail banks. Nowadays, it is applied in more and more core-banking systemimplementation projects.In this paper, we share our main findings with respect to know-how transfer gainedin one of the projects. The project size with around 200 makes this study especiallyinteresting, because the project size is far behind the limit where complexity explodesand becomes a major concern [3].Section 2 introduces the technical challenges of core-banking implementationprojects. Next, we presents the different organizations and groups forming the projectcontext, i.e. all groups interacting with the project and thereby forming a sourcingnetwork without directly belonging to the project (Section 3). We continue withquestions like who requires which know-how, and who can provide it (Section 4). InSection 5, we take a closer look on the main know-how transfer patterns in theproject, whereas Section 6 discusses the results of our study concentrating on theproject members’ experiences. We conclude our paper with a short summary andoutlook (Section 7)2Technical Aspects of Core-banking Implementation ProjectsTo ease the understanding of what and why know-how transfer takes place in corebanking system implementation projects, this section elaborates the technicalchallenges. Core-banking systems are standard software products. Buying standardsoftware (instead of developing new applications in-house) is appealing for manycompanies. It allows companies to concentrate on their core business. The corebusiness of a bank is providing financial services to customers: it is not developingsoftware. Next, companies with in-house software development require the righttechnical and project management skills in-house. Otherwise (or even then) there is ahigh risk that their projects fail or the costs are higher than expected. The staff aspectis especially challenging for smaller and medium banks. Finally, buying standardsoftware gives a bank access to state-of-the-art business processes. The softwarevendor implements the software at many banks and thereby gains access to differentprocesses. This know-how allows him to improve continuously the business processesimplemented in the standard software by choosing the “best-of-breed” processes.Buying standard software is the first step. The second step is to customize thesoftware to the specific needs of a bank. Customization means adopting andconfiguring the software such that the software supports the bank’s specific uniqueselling proposition optimally and such that it collaborates smoothly with the bank’sexisting application landscape.

4th IFIP TC2 Central and East European Conference onSoftware Engineering Techniques (CEE-SET 2009), Krakow, Poland, October 12-14, 2009The level of freedom for customization depends on the software product. Certaincomponents might be static whereas others are adjustable. We base our discussion onour generic standard software model (Figure 1). Standard software comes with a datamodel. The data model provides object types like account types, accounts, bookingsetc. The standard software might allow adding additional attributes to accounts (e.g.to support special discount models). Certain objects require a predefined set of objectinstantiations. An example is the object type accounts. The vendor might ship thesoftware, e.g. with “savings accounts.” Banks typically have different names forsavings accounts or special account types for certain customer types (e.g. “MidlandBank Student Saving Accounts”). We refer to such data as “domain values.”Workflows implement the bank’s business processes. They depend on the bank’sbusiness model. A retail bank requires a high level of automation. A wealthmanagement oriented bank relies on flexibility requiring manual interaction. A goodexample is also the loan approval workflow. The loan approval workflow of smallbanks has two main steps. Step one is the bank clerk who inputs the loan details intothe system. Step two is the credit officer who approves the loan. Larger banks mightalso give loan with an amount of more than five or ten millions. Then, the loanapproval workflow should be adopted, e.g. to a third person’s approval. Furthermore,standard software provides reports for internal or external purposes. The chief riskofficer needs an overview of the bank’s credit portfolio whereas other reports areproduced to meet regulatory demands. If a bank needs additional reports or wants tomodify existing ones, reports become part of the customization efforts.Finally, there are interfaces. Even a core-banking system does not provide allfunctionality needed to run a bank. Interfaces to other applications of the bank’sapplication landscape have to be customized, e.g. to trading systems or to externalservice providers like SWIFT ization,BusinessProcesses)Transformation nt InfrastructureAdjustablee StaticAdjustablee StaticBase Infrastructure (Hardware, Network, Database, Standard Software)Figure 1: Generic Standard Software blesStaticReportsMigratedOld DataAdjustableWorkflowsNew Operational DataData ModelDataStandard Softwaree Static

4th IFIP TC2 Central and East European Conference onSoftware Engineering Techniques (CEE-SET 2009), Krakow, Poland, October 12-14, 2009Obviously, a core-banking system has many components. All components might beadopted during the customization. The success of the customization depends highlyon the project team. The bank with its processes and organizations demands that thestandard software is configured to its needs. But implementing standard software alsorequires the bank to adopt its organizational structure and business processes.Therefore, implementing standard software is a transformation process for the bank.One crucial success factor for this transformation is the know-how transfer in theproject.3Project ContextThe core of each core-banking implementation project is the joint implementationproject team (short: joint team). It consists of consultants of an implementationpartner and bank staff customizing the system together. The joint team requirescertain know-how. It can get the know-how either by means of as-signing experts tothe joint team or based on know-how transfer from persons outside the joint team tojoint team project members. As a rule of thumb, the implementation partner providesconsultants with in-depth customization knowledge (technically and businessaspects). The bank sends persons with process know-how and with know-howregarding how the processes contribute to the bank's unique selling propositions.Figure 2 compiles the different know-how groups and their interactions with thejoint team in the middle. The bank has three main staff pools interacting with thejoint project. The first pool consists of future Avaloq users. They need know-howhow to execute (potentially adopted) business processes with the new system. There isthe logistically challenging task of training each bank employee and ensuring he orshe gets practical experience before the system is going live (e.g. by some trainingdays and a few days during which the bank simulates complete working days). Userswith in-depth knowledge of the processes, the business domain, and the old systemare key users. They must ensure that the customized system can be used efficientlyand provides mandatory functionality. Thus, as many key users as possible shouldjoin the project team. Secondly, the bank has an Avaloq team. Its size depends on thebank's sourcing strategy. In case the bank decides to outsource the applicationmanagement to an IT service provider (ITSP) as in our case study, a small team forthe management of the relationship to the ITSP might be sufficient. Thirdly, the bankhas their own help desk for supporting users with basic problems (e.g. forgottenpasswords) and forming the single point of contact for the users to the ITSP for severeproblems. The help desk requires know-how to be able to support the users in thefuture. For example, the help desk must know how to change passwords or how toopen new users in Avaloq.