HeaderSIS.jpg

IS480 Team wiki: 2012T1 Optimus/Optimus Team/Project Overview

From IS480
Jump to navigation Jump to search

Project Overview


Project Description

The Qualitative Scorecard is a tool that can be utilized by Relationship Managers (RMs) to manage and prioritize their oversight on the administrative matters of the business. While client asset gathering and retention are vital indicators of a RM's success, realizing a high standard of conduct is equally important for continued business sustainability.

In technical terms, our team will be building an integrated Qualitative Scorecard dashboard that integrates with the bank's existing system; "Workbench" which retrieves data from several systems in the bank hosted on different platforms and programming languages.

Our objective is to first develop a format for data extraction through the various systems, thereafter presenting and synthesising our findings through the use of text, tables, graphs, charts. Our first exciting challenge would be to communicate these statistics in a meaningful manner to Management, Bankers, RMs and Analysts with their own data requirements.

The Qualitative Scorecard dashboard will also feature process and workflow improvements. The existing paper based approval approach is time-consuming very manual. Our dashboard automates the process by eliminating the need to print out stacks of scorecards for approval, reducing paper waste and paper consumption.

We intend to also develop a formal approval process which allows the dashboard to assign tasks, send reminders, track scorecards and at the same time create a record of the entire process. Should the need ever arise to view the workflow of the scorecard, users are able to see who approved or rejected the scorecard, or flagging out RMs who have failed to complete their workflow task. In this way, this feature of approval workflow makes the approval process more transparent.

The Collaboration / Project Motivation

The opportunity to work directly with technology heads in the bank, alongside developers, business analysts and everyone else at Bank Julius Baer; allows us to develop a variety of professional skills. Alongside their supportive swiss culture and excellent mentorship program, we are not treated as students nor a FYP team, we are treated as employees / project managment team of the Bank.

In addition, this "real" project that we are working on would definitely have "real" impact that adds "real" business value, one that will be utilized by top management in the Bank.

What we really love about our sponsor is that we are given autonomy, we are given loose directions and then sent free, being able to have the freedom to figure out the best way to approach the project and propose. In addition, we are allocated tech leads who will be present to answer questions related to the project. We are also tasked with idea generation. Being thrown a problem, we are challenged to think strategically and contribute to the solution rather than just standing there being part of the problem.

Why then did we propose this project?

We identified an existing pain point in the bank. Whereby, every Relationship Manager (RM) is handed a hard copy overview of his/her key qualitative indicators; this would include the number of outstanding documents and number of Anti Money Laundering System (AMLS) comments overdue etc. RMs will be able to view at a glance whether their document deficiency list is growing tremendously and hence need looking into, or whether their increasing unfunded and inactive relationship numbers signal possible sales opportunities by re-engaging "long-lost" clients. In summary, RMs will have a tool to see if they meet the qualitative targets of the Bank, in addition to having Global MIS for the tracking of financial KPIs. We believe that this scorecard that is produced quarterly will facilitate the bank’s administrative responsibilities.

A robust Advisory framework is at the heart of every successful private bank. This scorecard would be aligned with the Advisory Framework. This Advisory Excellence process is a key value proposition for Julius Baer and aims to provide a more structured approach on servicing their clients. By building this application, the bank can leverage off this to ensure suitable and consistently high quality advice to clients, it aims to also create value for the Bank by achieving better acquisition and retention results, increased identification of additional sales opportunities and reduced legal, financial and reputational risks through enhanced RM competence and standard of conduct.

Learning Outcomes

IT Architecture, design and technicality

• Deliverables (practicality, sustainability)
- Client's Requirements
Optimus will be required to automate the existing paper-based Relationship Managers' Scoreboard Dashboard system, with our focus on a few selected functionalities. The real-time integrated Qualitative Scorecard dashboard should be able to retrieve and synthesize data from several systems in the bank; the challenge comes in as these systems are hosted on different platforms and programming languages.
Our project should be implemented in a way which is meaningful to the Management, Bankers, RMs and Analysts, with their respective data requirements. On top of these, Optimus aims to value-add to the project by developing additional functionalities which would be able to assist the users further in managing the information.
Upon completion of the project, the BJB should be able to leverage upon it in order to develop and maintain functionalities.

Technologies

• ASP
- Active Server Pages (ASP) is a server-side script engine which can be employed to develop interactive Web pages. The scorecard system currently being used by BJB, was coded in ASP. As the team intends to embark on our project using Java, it will be practical for us to pick up skills on utilizing this tool as it will aid us greatly in our development progress.
• Workbench
- Workbench is a Banking application which facilitates the management of databases, be it in terms of design, modeling or generating. It will be of great assistance in our project, since the project involves the addition, modification and extraction of information. We have all had prior experience with this application in Data Modelling (IS202 DM), and thus, it is believed that our skills will compliment what is required of us for the development of the project.
• Webkit 2.0
- Webkit 2.0 is the most updated version of Webkit, an API layer consisting of WKContextRef, WKPageNamespaceRef, and many more. It practices the bottom up approach, to support a split process model so as to allow other clients of Webkit to utilize it. Being something new to the team, we have reached a consensus with regards to setting aside time to learn and understand the workings of this piece of technology.


Client Requirements

Application Overview

The Qualitative Scorecard will be a tool utilized by the Relationship Managers (RMs) to manage and prioritize their administrative matters of the business. As an RM, client asset gathering and retention are important indicators of an RM’s success. However, maintaining a high standard of conduct is equally important for their business sustainability.

Every Quarter, data relating to the performance of the RMs is uploaded into the system. This system will provide a simple way for RMs to access and view their “Report Card”, that will then be approved by their team leads.


Feature List
Feature List

1. Compiles and synthesizes information uploaded from various sources:

• Anti-Money-Laundering Solution
• Reporting Portal
• Client Outout
• Doxter
• FX Automation
• iCare
• IPO Suite
• JBSChat
• Loans and Deposits Portal
• Name Check
• SpiraTest
• Transaction Reversal

2. Files are uploaded as an .xls/csv file and is automatically processed when an up-loader sends the file to a specific email address.

3. Covers all RM data across 2 accounts:

• Singapore office
• Hong Kong office

4. Notifies the RM of his performance, taking to account trend and whether he/she meets the targets set by the bank. Each category being broken down to more specific information.

• Client Base (total number of relationships/number of accounts)
• Outstanding Documents/Deficiencies/Responses
• Mandatory MAS/Non-MAS Documents
• Total Outstanding
• 0-60 Days
• 61-120 Days
• >120 Days
• Outstanding Written Confirmations
• Total Outstanding
• 0-60 Days
• 61-120 Days
• >120 Days
• Pending Documents
• 0-60 Days
• 61-120 Days
• >120 Days
• Total Outstanding
• 0-60 Days
• 61-120 Days
• >120 Days
• Training Attendance
• Call Reports
• Quality
• Account Applications
• Operational loss
• Profit
• Goodwill
• Acquisition Cost
• Waivers and Refunds
• Due Diligence
• Number of Accounts
• Number of Violations

5. Flags RMs who have failed to complete their workflow task (or are below their targets)

6. Viewed on a hierarchical basis (CEO > Team Lead > RM)

• Allows Team Leads/CEOs to approve their team’s report cards via the system
• Human Resources and Administrators can edit entries in the system

7. Relationship Managers can:

• Be sent reminders
• Track their performance over a quarterly basis
• Comment to the administrator regarding problems in their report card
• Print the report card for personal records

Functional & Non-Functional Requirement, Prototypes

Functional Requirements
Use Case Description

Email to Update System

Actor(s): Data Uploader

Primary Function: User able to activate system upload by sending an email with Excel file attach.


Manage Excel File

Actor(s): Data Uploader, Admin, Workbench System, ADEX System, AMLS System, IFS System

Primary Function: User able to perform add/delete/read of Excel file to the system.


Release ScoreCard Result to RM

Actor(s): Admin

Primary Function: System Admin release scorecard results for the particular quarter to RMs whenever it is ready.


Release Training Result to RM

Actor(s): Admin

Primary Function: System Admin release training results for the particular quarter to RMs whenever it is ready.


View ScoreCard

Actor(s): Admin, Top Management, RM, RM Leader

Primary Function: User able to view the ScoreCard, with different access level.


Reporting Issue

Actor(s): Admin, Top Management, RM, RM Leader

Primary Function: Users able report any issue to admin whenever facing any difficulties in using the system.


Approve ScoreCard

Actor(s): RM Leader, (Top Management is not listed because of team structure, need to confirm with BJB)

Primary Function: RM Leader need to approve the RMs' ScoreCard in his/her team.


Generate RM ScoreCard

Actor(s): Workbench System, ADEX System, AMLS System, IFS System

Primary Function: System will pull data from other systems, together with the excel file uploaded, RM ScoreCard System will able to generate RM Performanace ScoreCard.

Use Case

RM ScoreCard System Use Case v1.1.png

Image : RM ScoreCard System v1.1


For a clearer reference: File:RM ScoreCard System v1.1.pdf

Business Scenario Diagram

BJB AS-IS Business Diagram.png


Non-Functional Requirements

Usability

• The graphical user interface should comply with the standards / guidelines laid out by Bank Julius Baer
• The menus should be self-explanatory
• Navigation should be easy and user-friendly

Browser Compatibility

• The solution must be browser-based and compatible with the Microsoft Internet Explorer version 7.0 and higher.

Performance

• Response Time: The response time on any page across the application should be less than 2 seconds.
• Session Timeout: The session timeout should comply with the standards / guidelines set by Bank Julius Baer (currently defined as 20 minutes). However this must be a configurable parameter which is preferred to be able to be adjusted.

Performance Online?

• Each standard page load with standard data volumes must be less than 2 seconds Larger data volumes may take longer, but not longer than 10 seconds?
• Heavy back-end processes may take up to 10 seconds to deliver and render the page
• For heavy back-end processes, consider pre-calculating the data and storing it at rest.
- Near-time on event of data change. For intraday, with an 'as of' date/time stamp consider twice a day / 4 times and at most hourly

Sending of E-mail Notifications (Approval escalation process from RM up to CEO)

• The preference is not to send emails directly to end users from individual systems?
• Consider a central notification solution?
• Consider opening a workflow task in a central system for tracking and follow-up purposes
• Only important events are to be emailed to the users?
• No sensitive data is allowed in the email (Names, Addresses, Transaction details)
• Links to underlying applications with a non-identifying querystring is the preferred content

Exporting Data Directly From UI

• All tables and screens need to have the ability to export the data via Excel and pdf

Scalability

• The product engine should be scalable for addition of new processes for the user base mentioned above, without impacting performance
• The product should have the capability to roll-out to other booking centers in future (in addition to Singapore and Hong Kong)

Configurability / Portability / Maintainability

• All the configurable parameters (identified in the Functional requirements section of this document) shall be designed for providing the flexibility in functionality with zero implementation effort. Intalio shall build configuration admin screens or if the configuration is achieved through database entries, share the details with BJB on where and how future configuration can be achieved

Uploading of Documents

All document uploads must be categorized as to whether they are either

• Sensitive/Autitable - must be stored in System D
• Relative to client's wealth / call report - must be stored in System D
• Any other - may be stored on the filesystem of the application

Access Control

• Access restriction to client data based on roles, responsibilities, team structure and physical location

Encryption

• All data in transport must be encrypted end to end either in the protocol (https, sftp, jdbc over ssl etc) or through a tunnel (stunnel, ssh tunnel, ipsec, vpn)?
• Sensitive data should be encrypted at rest where possible (names and addresses). This may be done through the application layer and is to prevent casual viewing of the sensitive data by a DBA

Audit

• All inserts, modifications and deletes to data must be appropriately audited such that every change can be tracked as to what the change was and who performed the change.?
• All trails of workflow must be simply audited so the full trail from start to end of the process and be viewed.?
• Access control to which roles can view the audit trail need to be considered

Availability / Reliability

1. Target maximum availability during operational hours, defined as 8:00 AM to 1:00 AM (past midnight) SST (Singapore Standard Time)
2. Desired System Recovery: In case of an emergency, the system should be recovered within specific boundary limitations:
a. Maximum time the business can live without the application is 8 hours
b. Maximum amount of data loss the business can live with is 8 hours
3. The system downtime or outage of surrounding systems shall not have any impact on the solution availability, except in cases of online data extraction from source systems. However, the system may have reduced updates or functionality if surrounding systems are unavailable.
4. Desired Mean Time between Failures (MTBF): 90 days
5. Desired Mean Time to Repair (MTTR): 4 hours (during operational hours) for critical issues
6. Target End of Day Processes/Data Refresh period: Maximum of 20 minutes to run any batch jobs / scheduled programs only during non-operational hours

Retention / Archiving

The data retention requirements should comply with the shelf-life defined by Bank Julius Baer. The following shall be applied for TRA:
Online: All the requests and tasks and other workflow artifacts shall be accessible online (through the user interface) for the current and previous financial years (eg: 01 Jan 2010 to YTD 2011).
Offline: Legal access (offline) to data shall be retained for 10 financial years. (A financial year means the period from 1 January to 31 December)

Deployment

The following has to be ensured prior to deployment:

1. Data setup is completed and verified. (eg: user-team details in IAFS)
2. The master list of values for drop-down menus are setup
3. The default values are setup
4. The parameter tables are setup
5. The user access rights have been setup in IAFS
6. The code base is appropriately versioned, sealed and a portable format is available for deployment
7. All installation guides have been provide and training conducted on the deployment procedures

Note: The above mentioned deployment activities are suggestive only and not exhaustive. The list of pre-implementation activities shall be elaborated during the later stages of the project.

Other Requirements

As an enterprise, BJB uses SoA with re-usable services. Hence, the services provided by BJB will be as generic as possible to cater to other applications as well; any additional filtering / manipulation of data specific to TRA will be done by Intalio.
Existing equipment for Development and Test environments is expected to be utilized. It is anticipated that the solution can share application hosts with other applications. Clear indication of minimum hardware and software requirements (to meet the expected utilization) and system diagrams are to be provided for all environments (Development, Test, Production and Disaster Recovery). If resource conflicts are known between other applications then these must be highlighted.
Paper Prototype

SC Adex workbench Overview.png

SC MainpageDashboardv2.jpg Enlarge image

SC Dataupload.jpg


SC Mainpagepg1v2.jpg Enlarge Image