HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2012T1 Optimus/Project Overview"

From IS480
Jump to navigation Jump to search
Line 22: Line 22:
 
| style="background: #50659B; font-size:90%; text-align:center; color:#ffffff" width="9%" | [[IS480_Team_wiki:_2012T1_Optimus/photos|<font color="#ffffff" size="1" face="Arial"><b>Photos</b></font>]]
 
| style="background: #50659B; font-size:90%; text-align:center; color:#ffffff" width="9%" | [[IS480_Team_wiki:_2012T1_Optimus/photos|<font color="#ffffff" size="1" face="Arial"><b>Photos</b></font>]]
  
| style="background: #50659B; font-size:90%; text-align:center; color:#ffffff" width="9%" | [[IS480_Team_wiki:_2012T1_Optimus/photos|<font color="#ffffff" size="1" face="Arial"><b>Mid-Term Wiki</b></font>]]
+
| style="background: #50659B; font-size:90%; text-align:center; color:#ffffff" width="10%" | [[IS480_Team_wiki:_2012T1_Optimus/midTermWiki|<font color="#ffffff" size="1" face="Arial"><b>Mid-Term Wiki</b></font>]]
  
| style="background: #50659B; font-size:90%; text-align:center; color:#ffffff" width="9%" | [[IS480_Team_wiki:_2012T1_Optimus/photos|<font color="#ffffff" size="1" face="Arial"><b>Final-Term Wiki</b></font>]]
+
| style="background: #50659B; font-size:90%; text-align:center; color:#ffffff" width="9%" | [[IS480_Team_wiki:_2012T1_Optimus/finalTermWiki|<font color="#ffffff" size="1" face="Arial"><b>Final-Term Wiki</b></font>]]
 
|}
 
|}
  

Revision as of 19:39, 11 October 2012

592px-Optimus logo smaller.jpg


Home The Team Project Stakeholders Project Overview Project Management Risk Analysis Technical Application Minutes Repository Photos Mid-Term Wiki Final-Term Wiki


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


Dashboard-overview.png


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

3 Layers Circle v2.jpg

There will be Four different types of users utilizing this Scorecard. See Use Case Diagram and Use case Specifications

Scorecard users.JPG


Functional Requirements Checklist

Screen-capture-9.png
View Use Case Diagram

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 Functional Requirements

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

RM ScoreCard System v1.3.jpg



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)
Users will fill up and submit a form that will be recorded in the system. If Data Owner has indeed made a mistake, he amends the data and re-uploads the excel file, A valid reason will keyed in by the Data Owner, it will be recorded and system will capture the user's UID, timestamp and reason. System will store these into an audit log.

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.
RM Line Managers are allowed to view Scorecards of the RMs within his/her team

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)
RMs get 1 month grace period in system to submit. System will record the date and time when he submits.

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

  • If the RM Line Manager disagrees with comments of RMs, he has option to “Review” with RM.
  • When RM clicks “Submit”, final pop-up page will appear: “Confirmation that your submission is final and no further amendments to data is required”.

View Excel Files Status

View Excel Files.jpg


Upload Excel Files

Upload Excel File.jpg


Publish and Revoke Scorecard

Publish-Revoke Scorecard.jpg


Reupload Scorecard with Comments

Re-upload Scorecard with Comments.jpg


View Scorecard

View Scorecard.jpg


Modify Scorecard Targets

Modify Scorecard Targets.jpg


Submit Scorecard

Submit Scorecard.jpg


Manage Comments Trail

Manage Comments Trail.jpg



View Scorecard Workflow Status

View Scorecard Workflow Status.jpg


Approve Scorecard

Approve Scorecard.jpg


Scorecard Submission Workflow

Workflow - normal scorecard submission workflow - v2.jpg


Compensation Scorecard Submission Workflow

Workflow - compensation Scorecard workflow - v2.jpg

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

[Data Flow model]

ER Diagram

Data Cache

view table structures here

ER Diagram v5

Scorecard ER Diagram v1.4.jpg

ER Diagram v4

Scorecard ER Diagram v1.3.jpg

ER Diagram v3

Scorecard ER Diagram v1.2.jpg

ER Diagram v2

Scorecard ER Diagram v1.1.jpg

ER Diagram v1

Scorecard ER Diagram v1.0.jpg

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

• Components such as categories, previous four quarters, target, target trend and remarks should be displayed for user to see the trend

• User should be able to view the account numbers when selecting values in the table

(b) View call report

• User should be able to see the respective components such as categories, previous two quarters, target, target trend and remarks

• User should be able to view the account numbers when selecting values in the table

(c) View Quality

• User should be able to see the respective components such as categories, previous two quarters, target, target trend and remarks

• User should be able to view the account numbers when selecting values in the table

(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

• User should be able to view the account numbers when selecting values in the table

• Statistics for types of overdue alerts should reflect in this portlet

(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

• User should be able to view the account numbers when selecting values in the table

2. Workflow Functions

Functional Requirement Sub-Functional Requirement Description
(a) Approval Workflow

(i) Submit Scorecard


(ii) Email

• User will be able to submit scorecard to respective RM Line Manager upon selecting “Submit” option


• Upon submission of scorecard, email alerts will be forwarded to the respective RM Line Manager; in the case of unavailability of the RM Line Manager, emails will be routed to the next highest level of authority

(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

• Other users will only be enabled to leave comments

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

OptimusStoryboard1.jpg OptimusStoryboard2.jpg OptimusStoryboard3.jpg OptimusStoryboard4.jpg OptimusStoryboard5.jpg OptimusStoryboard6.jpg OptimusStoryboard7.jpg OptimusStoryboard8.jpg OptimusStoryboard9.jpg OptimusStoryboard10.jpg OptimusStoryboard11.jpg OptimusStoryboard12.jpg OptimusStoryboard13.jpg OptimusStoryboard14.jpg OptimusStoryboard15.jpg OptimusStoryboard16.jpg OptimusStoryboard17.jpg OptimusStoryboard18.jpg OptimusStoryboard19.jpg OptimusStoryboard20.jpg


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.

PaperPrototype1Edited.JPG


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.

PaperPrototype2.JPG

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.

PaperPrototype3.JPG

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.

PaperPrototype4.JPG

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.

PaperPrototype5.JPG

PaperPrototype6.JPG PaperPrototype7.JPG

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.

PaperPrototype8.JPG PaperPrototype9.JPG

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

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.

3. Scope
The scope of our user acceptance test cases will be based on the following use cases:
• Human resource
• Call reports
• Client base

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.

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
• 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•
Uploading of Documents
All document uploads must be categorized as to whether they are either
• Client-Sensitive/Bank-Sensitive
• Call report
• Any other - May risk being stored on the file system of the application
Access Control
• Access restriction to client data based on roles, responsibilities and team structure
Audit Trail
• All comments in the Scorecard must be appropriately logged such that every change can be tracked as to what the change was and who performed the change, keeping an audit trail
Archiving
• All the requests and tasks and other workflow artifacts shall be accessible only via the intranet(through the workbench interface) for the current and previous quarters.
Adopt functions that exist in current workbench
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 procedure
Assign Roles to Users
• Default role should be assigned to all users
• User can be assigned with more than one role
• Initial Data set-up of assigning roles to users can be done through a script
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

10. Test scenarios




User Testing