CHAPTER
1
Project Initiation and Scope
In this book, we will be implementing Oracle Fusion Financials for a fictitious bank named ACME Bank. This bank does not reflect any real bank in any country.
ACME Bank profits have been decreasing for the past two years even though the name is a very strong and well-known brand. Operating margins are low. Investors are concerned about the opaqueness in their reporting. Auditors are concerned about the lack of control and governance in the bank. The Chief Operating Officer is struggling to pinpoint the areas where there are cost inefficiencies. The Chief Financial Officer is concerned that he does not know the true picture about which lines of businesses within the bank are performing poorly. The operational business users are frustrated that too many of their daily tasks involve manual work. There are too many Microsoft Excel spreadsheets floating around in the shared drives and in the emails, resulting in total lack of governance and controls on the financial data within the organization.
The Chief Executive Officer creates a small team to do an operational analysis of the bank operations and processes. The deliverable from this team is to make recommendations to make the bank more efficient for operations and compliant with regulatory requirements.
Listing the Bank’s Pain Points
The operational efficiency analysis team performs a detailed analysis for a month after interviewing several people within the organization. The people interviewed are primarily in the Information Technology (IT), Finance, and Investment Banking departments. The key finding of the team is that the bank’s IT architecture is fragmented, with each division making its own decisions for implementing the software solutions. The bank lacks a centralized finance platform. There is no centralized IT control of the architecture, and this has resulted in highly fragmented systems and processes, thus increasing operational costs and reducing efficiencies. This has been further aggravated by the different technical teams working in their silos.
In the past, the bank has grown organically and also by acquisitions. With the economic crisis of 2008, regulatory authorities have cranked up pressure for compliance to their reporting needs. However, the bank is struggling to understand its capital adequacy situation given the lack of a central accounting and reporting platform.
Business Process Pain Points
The team discovers various shortcomings in the operational processes that make the organization inefficient overall. These are listed in Table 1-1.
TABLE 1-1. Business Process Pain Points at ACME Bank
Technical Pain Points
The analysis team discovers the various system architecture–related pains suffered by the business and their Information Technology department. The root causes of these pain points are due to the way ACME Bank’s legacy systems have evolved over a period of time. Most of the time, the new systems were implemented without proper due diligence and were implemented in a rapid response to a requirement with a narrow and tactical viewpoint. The development processes for these systems lacked any centralized governance. Table 1-2 lists the various technical and architectural pain points identified by the analysis team.
TABLE 1-2. Technical Pain Points
Post-Analysis Decisions
After the analysis work was done, the following action points were captured:
Implement a new architecture for finance that is superior to the technology stack in legacy systems.
Implement industry-standard best practices for operational processes.
Reduce end-user applications and centralize key business applications, starting with finance systems.
Standardize the technologies that are supported by the business as usual support team.
Reduce the number of technology vendors.
Reduce and standardize the number of development tools.
Implement a platform for centralized security of key applications to ensure segregation of duties.
Implement best practices for data integration into financial systems.
Implement a governed release management process.
There has been an increasing amount of pressure from regulatory bodies, and both internal and external auditors, to improve the systems and processes within the bank. As a result of these findings, it was then decided to initiate a new project for financial transformation by introducing an architecture that will help the bank improve processes, technologies, and time to market, and thus become more efficient. In order to meet this objective, industry-standard tools will be considered and decisions will be made to deploy a tool that addresses most of the bank’s needs. Given the problems with the bank’s past experiences, the possibility of building a home-grown system was left out of the discussions.
Finance System Selection for Finance Transformation
After investigating various products in the market, Oracle Fusion Financials was selected for implementation. This product addresses various business and technical pain points faced by the bank.
Addressing the Business Process Pain Points
Oracle Fusion Financials addresses the business process pain points listed in Table 1-3.
TABLE 1-3. Addressing the Business Process Pain Points
Addressing the Technical Pain Points
Implementing the Oracle Fusion Financials system addresses the various technical pain points listed in Table 1-4.
TABLE 1-4. Addressing the Technical Pain Points
Scope of Financial Transformation
The CFO has directed that the scope of the initiated project should address most of the pain points. The operational efficiency analysis team prepares a business case for the Financial Transformation project that is presented to the CFO and senior executives in the bank. A consensus is reached, and a budget is allocated for the commencement of this project. Given the large size of the bank, it is decided to restrict the scope of the initial project to deliver major benefits, with measurable success. The project will be done in two phases. In Phase 1, the Financial Systems platform will be implemented, followed by Phase 2, during which other Oracle Fusion Applications subledgers will be implemented.
It was mandated that the standard Oracle Fusion product will not be modified in any way that makes the system unsupportable by Oracle. However, as part of the implementation, there will be a need to extend the system by using the Standard API (Application Programming Interfaces) & Web Services, which Oracle Fusion provides out of the box to design extensions, and interfaces; for example, for importing data into Oracle using File Based Data Import (FBDI) and outbound extracts using BI Publisher. The system will also be configured to implement the various data security rules, approval management rules, and segregation of duties in a manner that meets the acceptable governance requirements on the system.
The ACME Bank is headquartered in the United States with additional operations in the United Kingdom, Japan, and Latin America. The bank’s business is divided into four key pillars that are also referenced as a Line of Business (LOB). Some of the key LOBs in ACME Bank are Investment Banking, Commercial Finance, Insurance, and Mortgage, as shown in Figure 1-1. Each of these Lines of Business has various cost centers. Some of the cost centers are shared across these LOBs, whereas some of the cost centers are dedicated to each LOB. Some of the key cost centers in the bank are Human Resources, Tax, Compliance, Training, Customer Services, IT Support, IT Service Delivery, and Finance. The various activities performed in the bank are grouped into projects. One of the examples of these projects is the Financial Transformation project itself, which is the underlying basis of this book. It is expected that the Financial Transformation project will allow the bank to track the revenue, expenses, assets, and liabilities for the U.S., U.K., Japan, and Latin America operations across all lines of business and cost centers.
FIGURE 1-1. ACME Bank’s high-level operational structure
In order to achieve the objectives of this project, the following goals are defined as the high-level scope of this project.
Introduction of Common Global Chart of Accounts
It was decided that even though the U.S., U.K., and Latin American operations will operate with their own separate ledgers, to ease consolidation and procedural consistency across the globe, the same Chart of Accounts (CoA) design will be used in all ledgers. The CoA should allow room for growth and future reporting requirements. Equally, it will be necessary to provide new bases of reporting, that is, US GAAP, UK GAAP, IFRS, and other future requirements, and these should be capable of incorporation with minimal redesign or workarounds. The following principles must be adhered to for the global Chart of Accounts.
Keep the Structure Short and Simple
The Chart of Accounts structure should be kept as simple as possible. In cases where a reporting attribute could be held either as an element in the GL Chart of Accounts or as a reporting attribute in the Fusion Financial Account Hub (FFAH), the intention is that it should be held in the FFAH unless there is a proven and identifiable need to keep the element in the Fusion GL Chart of Accounts.
Keep the Structure Logical
Each element should have a clear and single purpose. We have avoided allowing element values that mix concepts (for example, nominal account codes for Sales Western Region and Sales Eastern Region). These should be dissociated into two separate elements (Account and Region).
Keep the Usage of Each Element Unambiguous
Elements such as Location are open to misinterpretation. For example, having the location segment in Chart of Accounts can raise several questions, such as, is this the location of the investing unit in ACME Bank or the location of the trading counterparty? Or is it the location of the shared service center settling the trade or the location of the trading broker? The aim of the design should be to provide clear and unambiguous definition of the intended usage of each of the proposed segments in the Fusion General Ledger Chart of Accounts.
Introduction of Ledger Strategy
It was decided that all the countries in the ACME Bank would operate with their own ledgers. Even though accounting will be carried out on multiple reporting bases, it was noted that most of the accounting events have the same treatment in GAAPs and IFRS, and therefore, to avoid data duplication, a delta ledger strategy will be implemented. For example, the difference between US GAAP representation and the IFRS regulatory requirements only affects a small section of the ledger, and therefore it would be particularly cumbersome to maintain a full parallel ledger for IFRS reporting.
Introduce Centralized Audits, Governance, and Security
It was decided that the bank must improve and simplify access management of financial systems by consolidating and replacing a number of components that make up ACME Bank’s existing Identity Governance framework, including management of access rights (Rules), Entitlements, Reporting, Provisioning, and Role Catalog, as well as the user access to execute various financial processes. The new finance system should provide a number of features, including a number of recertification options (roles, role assignments, rules, movers, non-personal accounts, and data container ownership), reconciliation of financial systems, and provisioning of access rights for finance users. Thus, it should be possible to capture the audit trail of access and to provide the ability to report on audit trails, compliance checking, and violation management to allow faster response to external regulations.
Budgeting, Intercompany, and Consolidation
It was mandated by the CFO that budgets must be defined in the finance systems and enforced during operational activities to control costs and expense. It was also decided that manual processes of consolidation among group companies must be automated, with intercompany entries to be eliminated automatically during consolidation. The system should be able to easily adapt as the organizational structure becomes significantly more complex for consolidations. If new businesses are acquired, those acquired entities should be consolidated quickly without having to be immediately operationally integrated. Consolidated reporting should be possible under multiple accounting bases (that is, US GAAP, UK GAAP, IFRS, and so on). Further, consolidated reporting must be possible under multiple reporting currencies as required.
Fast Close of GL Periods
The system should allow a faster close process while adding more control and automation to the various GAAP submissions and consolidation for group reporting. The system should provide integrity, transparency, auditability, and reduced risk of errors during the period close processes. It should be possible to easily investigate numbers, review and compare results across periods, and reconcile back to source systems as applicable.
Financial Reporting and Dashboards
The bank has been deprived of a centralized financial system that provides reporting dashboards and analytic capabilities. Therefore, the new finance system must have state-of-the-art reporting with dashboards and analytics. Not only must the reports available to the users be secured for access, but the data presented within those reports must be secured by roles as well. The users should also be able to build a dashboard by themselves using the catalog of data sources available to them.
Summary
In this chapter we provided a high-level overview of why a Financial Transformation project has been initiated in ACME Bank. We have also explained why Oracle Fusion Financials was the chosen product to address the problems faced by the bank in financial reporting and governance. Finally, we explained the high-level scope of the Financial Transformation project initiated by the bank while explaining how it addresses the key pain points of the bank for finance operations.
Subsequent chapters will detail the features in Oracle Fusion Financials and how they are implemented in Phase 1 of the project, which is highlighted in this chapter.