IS480 Team wiki: 2012T1 Optimus/Project Overview
Home | The Team | Project Stakeholders | Project Overview | Project Management | Risk Analysis | Technical Application | Minutes Repository | Photos | Mid-Term Wiki | Final-Term Wiki |
Contents
- 1 Background / What is a Qualitative Scorecard
- 2 Functional Requirements Checklist
- 3 X-Factor
- 4 What our team will do?
- 5 The Collaboration and Motivation behind this initiative
- 6 Why then did we propose this project?
- 7 Functional Requirements
- 7.1 Use Cases and Specifications
- 7.2 Use Case Specifications
- 7.2.1 View Excel Files Status
- 7.2.2 Upload Excel Files
- 7.2.3 Publish and Revoke Scorecard
- 7.2.4 Reupload Scorecard with Comments
- 7.2.5 View Scorecard
- 7.2.6 Modify Scorecard Targets
- 7.2.7 Submit Scorecard
- 7.2.8 Manage Comments Trail
- 7.2.9 View Scorecard Workflow Status
- 7.2.10 Approve Scorecard
- 7.2.11 Scorecard Submission Workflow
- 7.2.12 Compensation Scorecard Submission Workflow
- 7.3 Data Points
- 7.4 Data Flow Diagram
- 7.5 ER Diagram
- 7.6 Requirements
- 8 Non-Functional Requirements
- 9 Prototype
- 10 Storyboard
- 11 Powerpoint Prototype
- 12 Testing
Background / What is a Qualitative Scorecard
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. It is a Tool that has been around since Q3 2009. It measures RMs’ qualitative performance (e.g. compliance, advisory excellence, etc.) on quarterly basis. There are currently 28 measures in the Qualitative Scorecard and this is used in conjunction with RMs’ financial scorecard to determine RMs’ overall performance and bonus. 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.
View Storyboard and Paper Prototype
In technical terms, our team will be building a Qualitative Scorecard dashboard that integrates with the bank's existing system which retrieves data from 20 different data points. Out of this 20 data points, automation of data collection from certain sources would be possible and for the rest, data would be retrieved by an excel upload. See Data-Flow Diagram
There will be Four different types of users utilizing this Scorecard. See Use Case Diagram and Use case Specifications
Functional Requirements Checklist
Moving forward, our objective is to first develop a format for data extraction through the various systems, thereafter presenting and synthesizing our findings through the use of text comments, tables, simple graphs via Liferay. Our first exciting challenge would be to communicate these statistics in a meaningful manner to Management and RMs.
The Scorecard dashboard will also feature workflow improvements and the automation of data collection from certain sources. 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 within Scorecard that allows RM Line managers to acknowledge and inputs comments. The comments are kept in an audit trail and ultimately the comments are one component that determines the bonus of the RM. Should the need ever arise to view the workflow of the scorecard, users are able to see the status of the scorecard, whether it is 'Pending or Approved'. In this way, this feature makes the process more transparent.
View Non-Functional Requirements
X-Factor
We will have a total of 240 RMs utilizing this Scorecard. 45 from Hong Kong, 72 from Singapore, 123 from the rest of the world (Zurich, London) etc. A survey will be conducted for RMs to quantify the satisfaction level of this Scorecard application.
Scorecard will be a front-end tool for RMs, middle and back office, that retrieves data from 20 data points, data will be processed in preparation for the expected output, and the findings will populated onto a single dashboard. Scorecard will also include a formal workflow process that allows for approval escalation.
What our team will do?
We will be developing a Qualitative Scorecard dashboard that performs data extraction from the systems, synthesize findings, automates the time-consuming manual process and provides a formal approval process as a replacement.
We will be responsible for the Initialization, Analysis, Design, Development , Test and Roll out of this Scorecard that will be integrated onto an existing system.
The Collaboration and Motivation behind this initiative
The opportunity to work directly with Technology heads in the bank, Lead Developers, Business / System Analyst, RMs, Business Development Managers and everyone else at Bank Julius Baer; allows us to develop a variety of professional skills. Alongside their supportive Swiss culture and excellent mentor-ship program, we are not treated as students nor a FYP team, we are treated as employees / project management team of the Bank.
In addition, this Scorecard that we are working on definitely has impact and adds business value, one that will be utilized by top management and 240 RMs worldwide.
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 reputation risks through enhanced RM competence and standard of conduct.
Functional Requirements
Use Cases and Specifications
Use Case Specifications
Use Case | Actor | Primary Function |
---|---|---|
View Excel Files Status | Admin | Administrators are able to check via the Admin console if the required excel files have been uploaded into the Scorecard system by the respective data owners. |
Upload Excel Files | Admin, Data Owner | Users are able to upload excel files to the Scorecard system, system will validate the uploaded files by performing a sanity check on the data within the excel file and prompt when errors are found. |
Publish Scorecard | Admin | Administrators will be given the option to publish the Quarterly Scorecard when the key excel files has been uploaded (IT Relationships.xls) into the system by the data owners. This Publishes that particular Quarter's Scorecard data for RM's verification.
Administrators are also given the option to revoke Scorecard (RM will then not be able to view the release of the Scorecard for that quarter should there be any changes until Admin Publishes Scorecard) |
Re-upload Scorecard with Comments | Data Owner, Admin | If RMs verify their Scorecard and finds that Data is wrong. 2 situations – (i) when data is truly wrong e.g. he attended a training but it is reflected wrongly as non- attendance and (ii) System inadequacy leading to issues eg AMLS alerts overdue as RM was overseas and system does not allow for delegation) |
View Scorecard | Admin, RM, RM Line Manager | Administrators are able to view Scorecards of everyone in the organization. RMs are able to view their own individual Scorecards for verification of data accuracy. |
Modify Scorecard Targets | Admin | Administrators are allowed to modify and set the targets for the RMs at the start of every the Year |
Submit Scorecard | RM Line Manager, RM | RMs and RM Line Managers are supposed to submit their Scorecards with their comments to their approving Managers after verification for approval. RMs and RM Line managers clicks onto Submit after agreeing to the entire SC for that quarter and has the option to add in some feedback on the comments portion (but which are not consequential to changing scoring; only for documentation purposes) |
Manage Comments Trail (add, view, submit, save, edit) | RM Line Manager, RM | RMs will submit their comments on their qualitative assessment for that quarter prior to submission of Scorecard. The are able to add, view, submit, save and edit the comments. |
View Scorecard workflow status | RM Line Manager, Admin | RM Line Managers, RMs and Admins are able to track the status of the excel files uploaded, they will be able to see the status of their Scorecard (Open, Pending Approval, Approved) |
Approve Scorecard | RM Line Manager | When the RM Line Managers logs into the Qualitative Scorecard system, he will be prompted for any outstanding / pending approvals through the Workbench Alert system RM Line Managers will be given the option to "Approve" or "Review" the Scorecard
|
View Excel Files Status
Upload Excel Files
Publish and Revoke Scorecard
Reupload Scorecard with Comments
View Scorecard
Modify Scorecard Targets
Submit Scorecard
Manage Comments Trail
View Scorecard Workflow Status
Approve Scorecard
Scorecard Submission Workflow
Compensation Scorecard Submission Workflow
Data Points
Data Points | |||||
No. | Data | Current Data Source | Data Uploader | Automation Possible? | Remarks |
---|---|---|---|---|---|
1. |
Document Deficiencies |
Access DB |
Operations - ACM |
TBD |
Source to be changed to CRM – to be analysed further, as this portion of CRM is not yet live |
2. |
Advisory Due Dilligence |
ADEX |
BRM |
Yes |
Can be sourced from AdEx (to be analysed further, as BRM performs data manipulation before uploading) |
3. |
AMLS Comments |
AMLS |
Compliance |
Yes |
Can be sourced from AMLS |
4. |
Acc Application Sent Back |
Excel |
Compliance |
No |
Manual data tracking by Compliance |
5. |
Operational Loss / Gain |
Excel |
BRM |
No |
Manual data tracking by BRM |
6. |
Call Report |
iCare |
iCare Support |
Yes |
Source will be changed to Call Report module of WB |
7. |
Client Reviews |
iCare |
Compliance |
TBD |
Source to be changed to CRM – to be analysed further, as this portion of CRM is not yet live |
8. |
Total AuM |
GMIS |
Finance |
No |
GMIS is hosted out of Zurich |
9. |
Training Attendance |
Excel |
HR |
No |
Manual data collection from HR |
10. |
Continuous Professional Development (CPD) |
Excel |
HR |
No |
Manual data collection from HR |
11. |
PARC Goal Setting |
Excel |
HR |
No |
Manual data collection from HR |
12. |
PARC Year End Review |
Excel |
HR |
No |
Manual data collection from HR |
13. |
Inactive Accounts List |
Olympic |
Account Management |
TBD |
To be analysed further if extract file can be automated |
14. |
Outstanding Written Confirmation |
Access DB |
Ops – Payments team |
TBD |
Source to be changed to CRM – to be analysed further, as this portion of CRM is not yet live |
15. |
% of accounts in SG / HK |
GMIS |
Finance |
No |
GMIS is hosted out of Zurich. |
16. |
Waivers and Refunds |
Excel |
Ops – CSS |
No |
Manual data tracking by CSS |
17. |
Credit Exposure without prior Credit Approval |
Excel |
Credit |
No |
Manual data tracking by Credit |
18. |
Team Hierarchy |
Excel |
IT |
Yes |
Can be sourced from IAFS |
19. |
RM Hierarchy |
Excel |
IT |
Yes |
Can be sourced from IAFS |
20. |
Account Mapping & Client Grouping |
Olympic, iCare |
IT |
TBD |
To be analysed further, if client grouping requirements will need to be change (in line with M4), and if Olympic extract can be automated |
Data Flow Diagram
ER Diagram
Data Cache
ER Diagram v6
ER Diagram v5
ER Diagram v4
ER Diagram v3
ER Diagram v2
ER Diagram v1
Requirements
1. View Qualitative Scorecard | ||
Functional Requirement | Description | |
---|---|---|
(a) View outstanding deficiencies |
• User should be able to view the respective tabs such as Mandatory Documents (MAS 626), Mandatory Documents (Non MAS), Outstanding Written Confirmations, Outstanding Investment Profiles, AMLS Comments Overdue and Risk-based Clients’ Reviews Overdue | |
(b) View call report |
• User should be able to see the respective components such as categories, previous two quarters, target, target trend and remarks | |
(c) View Quality |
• User should be able to see the respective components such as categories, previous two quarters, target, target trend and remarks | |
(d) View Advisory Framework page |
• User should be able to see the respective components such as categories , previous two quarters, target, target trend and remarks | |
(e) View Human Resource page |
• User should be able to see the respective components such as categories , previous two quarters, target, target trend and remarks |
2. Workflow Functions | ||
Functional Requirement | Sub-Functional Requirement | Description |
---|---|---|
(a) Approval Workflow |
(i) Submit Scorecard |
• User will be able to submit scorecard to respective RM Line Manager upon selecting “Submit” option |
(b) Report Issues Workflow |
(i) 'No edits allowed' |
• Regardless of the number of mistakes made for the various scorecard details, only the Administrative staff will be able to make changes |
3. Manage Comments | ||
Functional Requirement | Description | |
---|---|---|
(a) Create Comments |
• User will be able to create new comments on any scorecards | |
(b) View Comments |
• User will be able to view comments created by himself and other users | |
(c) Edit Comments |
• User will be able to edit his own comment |
4. Administrative Functions | ||
Functional Requirement | Description | |
---|---|---|
(a) Activate scorecard for Q |
• Administrative User will be able to facilitate the activation of scorecards | |
(b) Deactivate scorecard for Q |
• Administrative User will be able to facilitate the deactivation of scorecards; upon 30 days of creation, changes to the scorecards will no longer be allowed | |
(c) View status of scorecards in workflow |
• Users will be able to view the status of their scorecards along the workflow | |
(d) View status of data points |
• | |
(e) Change qualitative target |
• Users will be allowed to edit the qualitative targets as can be seen in their scorecards | |
(f) Create scorecard extract |
• Upon successful completion of their scorecards, users will be able to create a PDF extract which they can print out |
Non-Functional Requirements
5. Data Upload | ||
Functional Requirement | Description | |
---|---|---|
(a) Upload data (from excel file) |
• Users can upload data from excel files (or upload excel files?) for their scorecards | |
(b) Replace data |
• In the case that users wish to make amendments to their scorecards, they will have to resubmit the excel file and overwrite the original file |
Prototype
Storyboard
Powerpoint Prototype
- 1. As can be seen from below, upon successful log-in, the user will be able to see this page displaying 6 different portlets representing the 6 different aspects of the scorecard.
- 2. (a) Portlet - Without Sub-Tabs
- Upon clicking the first portlet, the system will display another page to the user showing a more detailed breakdown of component data for that particular aspect of the scorecard. The table shown will provide the user with a clearer idea as to the performance of a selected employee with his previous quarter's performance displayed in the first column.
- 2. (b) After the user defines the details of the Relationship Manager (RM) whom he/she wishes to monitor, a pop-up dialog box will appear over it. This dialog box displays a table of data with regards to the number or types of client accounts the RM has on hand.
- 3. As observed, a second pop-up dialog box will appear upon clicking on any of the grids under the columns displaying data from the different quarters.
- 4. Portlet - With Sub-Tabs
- Upon clicking the second portlet (as seen in the first diagram), the system will display a screen as seen in the second diagram, but with tabs (sub-components) which further define that particular aspect of the scorecard. Once one of these such tabs have been selected, a pop-up dialog box will appear over it, also displaying a table of data for that sub-component.
- 5. As for the below two figures, it shows the drop-down menus from which users can select and define the details of a certain RM whom they wish to view.
Testing
Test Plan
Purpose
The purpose of this document is to define the objectives, scope and deliverables for planning User Testing 1 (UT 1). It will serve as a tool for reference and guide us in the implementation of our UT, whose results would in turn provide us with results which will aid us in improving our project. UT 1 is scheduled to be implemented on 1st October 2012, Monday at the Bank Julius Baer Harbour Front office.
Upon conclusion of our UT 1, the test results will be consolidated and actions to be taken will be documented and reflected upon.
Background Information
We are Team Optimus, working on the Scorecard System meant for Relationship Managers, in collaboration with Bank Julius Baer. As of now, we have the front-end portal of the SS for all six portlets;
- 1. Human Resource
- 2. Client Base
- 3. Quality
- 4. Outstanding Deficiencies
- 5. Call Report
- 6. Advisory Framework Suitability Checks
User Testing
- 1. Objectives
- The main objective of our UT 1 is to ensure that the integration of our codes onto the bank’s system has been implemented successfully, preventing any delays in our future scheduled integrations. Also, the outcomes of our UT 1 will help ensure that our current GUI is performing at an acceptable level. The test results will serve by isolating problems related to the usability of our solution.
- Key Objectives includes;
- • Verify the usability and aesthetic appeals of the application
- • Isolate, define and document defects within the application
- Key Objectives includes;
- 2. Process
- Our UAT is to confirm that the system is suitable, and verify that the delivered application matches clients’ requirements. In addition, we also want to obtain valuable feedbacks on the usability and aesthetic of our application.
- We have made arrangements with the Bank to have at least 10 RMs to test our system, together with the different users such as the RM Leads and Admin staff.
- We have made arrangements with the Bank to have at least 10 RMs to test our system, together with the different users such as the RM Leads and Admin staff.
- 3. Scope
- The scope of our user acceptance test cases will be based on the following use cases:
- • Human resource
- • Call reports
- • Client base
- The scope of our user acceptance test cases will be based on the following use cases:
- 4. Test Types
- Our team will be focusing on the aspects of functional and usability testing in UAT 1 while covering a minimal amount of performance testing.
- The following types of tests will be performed:
- 1. Environment tests: Tests that validate the functioning of the system with the hardware, system software and networks.
- 2. Positive functional tests: Response to valid user actions and valid data.
- 3. Negative functional tests: Response to user actions or data that should generate error messages.
- 4. Invalid input tests: Response to inputs or user actions that may be unanticipated by the system design.
- 5. Usability tests: Verification of the ease of use of the system and its associated documentation and procedures (mainly to verify that the usage is similar to that of the current one so as to ensure familiarity and reduce the need for re-training)
- 5. Test environment
- Our team must set up the deployment environment with the following steps:
- • Ensure the system is fully integrated into bank’s server.
- • Ensure the system is fully integrated into bank’s server.
- Our team must set up the deployment environment with the following steps:
- 6. Test requirements
- • Testing will take place in the Bank Julius Baer – Harbour Front Office
- • UT 1 will take place on 1st October 2012, Monday
- • Our team must ensure that the test environment is ready before each test in UAT 1
- • Our team must run the SQL script to restore database to pre- testing mode prior to the start of each test
- • Testing participants will receive instructions prior to the start of UT
- • Test participants will conduct the test and our team will go around to document responses from them.
- 7. Test schedule
- All completed functionality and test data will be migrated to the test environment prior to the start of user acceptance testing.
Non-Functional Requirements | ||
Non-Function | Description | |
---|---|---|
Browser Compatibility |
| |
Performance |
| |
Performance – Online |
| |
Uploading of Documents |
| |
Access Control |
| |
Audit Trail |
| |
Archiving |
| |
Adopt functions that exist in current workbench |
| |
Assign Roles to Users |
|
Activity | Date Due | Completed Date |
---|---|---|
Identify and select testers for UAT |
14/09/2012 |
TBC |
Develop test scenarios and cases |
25/09/2012 |
27/09/2012 |
Confirm testers’ availability |
27/09/2012 |
27/09/2012 |
Implement testing |
28/09/2012 |
01/10/2012 |
Evaluate consolidated test results (user responses, reported bugs) |
05/10/2012 |
TBC |
- 8. Test assumptions
- • The UAT environment will be available and fully configured ahead of the UAT.
- • Testers will test the functionality documented by us
- 9. Text risks
- • Unable to get enough participants as RMs have very tight schedules
- • Unable to get enough participants as RMs have very tight schedules
- 10. Test scenarios