CHAPTER
1
Project Initiation and Scope
I n 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.