埃森哲-apparc韩国银行咨询报告

Title: 5.3 Application ArchitectureSummary (English only) Describes Bank Xs future application architectureDoc ID :abd7a787ecbeec5a67b3e12dcf17b61e.pdfVer.: 1.1Prepared by :M.SDate :16-8月-19Reviewed by :Date :Application ArchitectureDecember 7, 1995Page 26Proprietary and Confidential 5.3 Application Architecture5.3.1 Section Overview5.3.2 Application Architecture Model5.3.3 Current Application Architecture5.3.4 Application Architecture Guidelines5.3.5 Proposed Application Architecture Strategy5.3 Application ArchitectureThis section describes Bank Xs current and future application architectures-the systems and applications used by customers, branch personnel, business users, executives, and external agency to support Bank Xs business environment. The application architecture is built based on user requirements, new technical solutions, and banking best practices. Where possible, we have identified potential technical and business supported changes that could help Bank Xs systems. The Application and Data plan describes the actual planned improvements or new applications to be built over the next five years.Key featuresThe focus of the new application architecture is to enhance market-driven processes-processes that improve Bank Xs position in the Korean banking environment by providing better customer service, products, increased market coverage, and competitive prices. Many of the new applications focus on improving management information to help Bank X manage a larger bank and to more precisely evaluate customer needs. Highlights of the new application architecture include: New sales and marketing systems Needs analysis (customer, product, and market) Campaign planning (new channels, sales, promotion activities) Branch opening support (global information system) Sales support (sales schedule, customer consulting activities) Enhanced customer management systems Corporate data information management (financial, personnel, news) Retail customer information management (name, address, family relationships) Advanced credit systems Corporate credit analysis Customer credit scoring New management information systems Business unit profitability (customer, product, branch) Regulatory and Compliance Treasury management Market risk Product managementPotential risksTo achieve the application architecture, Bank X will need to carefully coordinate technical infrastructure improvement, database development, and EDP resources. This requires managing the following risks: Customer applications (e.g., ATM, credit card, phone banking, electronic banking) are not competitive with other Korean banks or non-Korean banks (e.g., Citibank) Changing customer preferences may require changed application focus, new products, or new services Bank X EDP department lack the resources to both support existing applications and build new technical infrastructure Bank X tries to build to many new applications Existing applications are do not meet future needs or can not integrate well with new applications Technical infrastructure and databases can not support new applicationsBenefits of Application ArchitectureAs application architecture is a high level model shared by both business and EDP personnel to identify the types of systems Bank X requires. It is a tool similar to a building architecture that provides a model to be used to plan projects, design new systems and databases, and prioritize EDP activities.Business and Technology department cooperation The application architecture should be shared document between business units and technology areas. Business units, operations personnel, branch personnel, and executives should be able to identify the applications that support their areas. Changes to those applications should be clearly distinguished as should new applications Increased Usability The architecture should provide users with the applications they need to support their tasks and to meet their type of work. Flexibility and Isolation By separating applications based on business functions, the application should be allowed to grow in sophistication with the business. Secondly a change to one business areas applications should not impact other business areas.Identification of Packaged Solutions The application architecture and the application plans should describe applications to a detailed enough to identify whether packaged solutions can meet business requirements.Standardization The architecture should identify opportunities to share program components and data across applications. It should also help indicate the proper platforms for applications.5.3.1 Section OverviewThe application architecture section is comprised of the following sections:5.3.2Application Architecture Model - presents a conceptual model used to categorize and visualize the architecture components.5.3.3Architectural Transformation - Describes the process of building Bank Xs new application architecture5.3.4Application Architecture Guidelines - presents guidelines that should be followed in order to implement a successful architecture.5.3.5Proposed Technical Architecture Strategy - this section illustrates the likely features of the new architecture. It contains the following sub-sections:-Service Delivery-Central Processing-Relationship Management- Management and Control- Information Delivery5.3.2 Application Architecture ModelThe goal of the architecture strategy is to define an application architecture that will support Bank Xs future business requirements. To assist in the development process, Andersen Consultings Vision Application Architecture Model was chosen as a design tool. This section shows how the proposed application architecture was designed using the Vision Application Architecture Model as a starting point. The components of the Vision Application architecture are:1. Service Delivery2. Central Processing3. Relationship Management4. Management and Control5. Information Delivery6. Gateways.Figure 5.3.1 - Components of the Vision Architecture1. Service DeliveryService Delivery supports all banking functions provided to benefit Bank Xs customers. These include the branch network, internal departments, customers, correspondent banks and clearing and funds transfer service providers. They may use a variety of techniques to access the organizations information, such as terminals in branches, executive workstations, telemarketing workstations, ATMs, home and telephone banking and corporate workstations. The objective for Service Delivery is to provide an integrated and seamless interface to all users. Traditionally, screens and menus were developed as part of a specific system such as branch sales, credit scoring or account processing. However, to reduce costs and improve customer service organizations are trying to streamline their business processes. For instance, they might want not only to sell a loan to a customer, but also get credit authorization and set up an account on the spot.The range of functions provided by the system must match the range of activities the user performs. If front office staff in a branch are supposed to provide customer service and to sell, then they need a platform which will allow them to do both, irrespective of whether they are accessing a product processing system or a sales support system.2. Central ProcessingCentral processing includes the transaction processing traditionally supported by central systems. This processing ensures that the banks transactions are properly executed and that the banks various accounts are properly managed. Central processing consists of four components:Operations ProcessingIn order to process transactions a number of common functions need to be performed before they are applied to a particular system. The users authority to carry out the transaction needs to be authenticated - for instance, ATM PIN validation. The source and nature of the transaction need to be recorded for use in activity measurement and for productivity monitoring. Security requires that transactions are properly audited and in some instances business rules dictate that a second person must authorize the transaction. Journal entries must be generated. If transactions are not applied to the underlying product processing system, these exceptions must be captured and reprocessed efficiently.Closing and SettlementClosing and settlement functions ensure that all accounts are properly updated, reconciled, and accurate. It requires transferring information between various entities including other banks, clearing agencies, and across branches. The system should process business transactions rather than a series of more physical transactions dictated by the limitations of product administration systems. For instance, transferring money from one account to another is a single business transaction. This remains true even when the accounts are in different currencies, processed on different systems, and require several journal entries.Product AdministrationProduct administration functions perform all product specific processing for deposits, loans, foreign exchange, credit cards, bill payment, trade finance, and other types of products.Product FactoryA product factory is a system that supports common product functions such as interest calculation and payment, pricing, product reporting, product accounting, and other product calculations. Many banking institutions are using object-oriented techniques to manage their many product types.3. Relationship ManagementRelationship Management supports sales and marketing, customer management and credit control. These are business functions which relate principally to customers and households as opposed to individual accounts. Marketing campaigns are managed across the various distribution channels available. Then, by drawing on information about individual customers, other members of their households, their products, product usage patterns, demographics and behavioral psychographics, needs are identified. Campaign execution can be in the form of direct mail, telemarketing or the passing of leads to branches. Sales support provides facilities for demonstrating product benefits to customers, managing leads in progress and closing the sale.Customer service histories are maintained recording the quality of the individual relationship. For business customers and high net worth individuals, information on customer profitability and the relationship as a whole may be used to determine how to structure and price product offerings. Institutions also need to report on the individual customer relationship for regulatory purposes such as to the Bank of Korea.Credit management includes not only the initial scoring of applications but the subsequent monitoring and resetting of limits. By understanding a customers complete relationship different decisions can be made. For instance, a customer with an unauthorized overdraft on a checking account but a large balance on deposit should be treated differently from a customer with a similar unauthorized overdraft who has also exceeded the limit on his credit card. Part of the process is likely to involve credit scoring and using third party information for credit decisions.4. Management and ControlThe Management and Control component of our architecture is divided between management information functions and administrative functions. Administrative functions, which are generally not specific to the financial services industry, form the basis of effective organization and office management.The Management Information component supports the activities of planning, analysis, monitoring and reporting. It is divided into three broad categories: Financial: Information on costs, profits and positions for use in producing financial position and regulatory reports (including BIS reports), budgeting and forecasting, and assessing risk. Operations: Information on productivity and service quality. Sales: Information on current sales performance and that required to assess the actual profit and potential for profit from different products and sectors of the market.Executive information is provided from all three categories in a more summarized form.5. Information DeliveryInformation Delivery manages the external delivery of information whether on paper or by electronic means. Information Delivery may involve additional processing such as that required for Electronic Data Interchange (EDI). It allows financial institutions to be a service provider for information exchange between clients and third parties. Indeed the financial institution may choose to position itself as the provider of the value-added EDI network itself. The physical printing of reports, statements and mailings are also Information Delivery activities. It can often be more cost effective to subcontract some of these activities to third parties. Through Information Delivery it is also possible to consolidate orders for physical media such as checkbooks and plastic cards, realizing greater bulk discounts. 6. GatewaysThe gateways are the components generally systems software or middleware that enable information to be distributed between applications as well as shield the applications from changes in the underlying technical or data architectures. The four main gateways are: Driver: Manages the process of getting valid business transactions to the appropriate application, including translating single business transactions into one or many systems transactions. For example, when a central customer master file is updated, the driver process will ensure that this transaction is passed to the relevant applications. Integrator: These processes will be responsible for integrating information from the various applications. An example would be the summarization of data from the customer or product information to evaluate branch profitability. Navigator: Establishes and maintains the banks view of its relationships and systems. It maintains information about clients, intermediaries, other third parties and their interrelationships. Distributor: These processes consolidate information for use both within Bank X and also for external organizations such as clearing and settlement organizations or for SWIFT.Gateway functionality is further discussed in the technology plan.5.3.3 Architectural TransformationTransforming from a centralized mainframe architecture to a new distributed architecture is a difficult task, and one that many organizations have failed in. Nevertheless the realities of todays banking and technology environments have made architectural transformation a necessity. More and more the banks with best technologies and information systems have a competitive edge. Banks with advanced technology can: Deliver advanced services to customers Spot market trends quicker Bring products quickly to market that truly meet customer needs Capture new market segments Discriminate between profitable and unprofitable customers Discriminate between high risk and low risk products and customers Mitigate their risks through diversification or hedgingTo develop Bank Xs new application architecture we have taken the following steps which we hope will lead to successful architectural transformation.Step 1 - Recognize the changing environmentBefore the project started Bank X had recognized that both technology and Korean banking were evolving at increasingly rapid rates. It is no longer possible to plan technology on a one year basis, nor can one use the technology developed for banks 10 years ago. In the first step, we reviewed the current Transaction System - Reporting system architecture which is based on IBM Japans model for banks 10-15 years ago. With the changing technology, this model has become outdated and for the most part, Japanese banks are searching for new methods. Unfortunately for the larger banks, changing is difficult after 15 years of investment in mainframe systems. Sometimes being the largest bank in the world can be a liability.Step 2 - Identify new methods for grouping applicationsThe second step was to find new methods of grouping Bank Xs applications (rather than simply grouping by on-line or reporting). Our method was to choose six data and processing characteristics (see section 5.1) and classify the applications by these characteristics.Step 3 - Regroup system supported functions into new applicationsIn step 3, we regrouped the business functions based primarily on the user type, processing type, and data summarization level. This lead to a preliminary application architectureStep 4 - Validate against other application architecturesStep 4 was the process of validating Bank Xs architecture against Andersen Consulting Vision architecture (described in Section 5.3.2) as well as against other banks architectures. This validation lead to a few adjustments. This architecture is shown in figure 5.4.Figure - Current ApplicationsStep 5 - Map in new business requirementsThe fifth step was to map in new business requirements by identify potential applications based on the user requirements developed by the management assessment team. Step 6- Revalidate against the vision architectureThe final step was to revalidate the future architecture against th