Computer Account Management Module Enhancement Requirement for
BMC Remedy Service Management System
ICTO has purchased the BMC Remedy IT service Management Suite for managing ICTO service
calls, and it is now requested to purchase an extension module in the area of Computer Account
Management. The objective of module extension is to streamline the process for applying of
staff accounts in various IT systems and platforms provided in our current campus environment.
The new Computer Account Management Module shall be developed based on UM’s existing
Remedy system to provide a tightly integrated one stop service for all the academic and
administrative staff.
The requested module should include functions for web-based application submission, account
manipulation workflow management, user notification upon completion, and also provide an IP
Phone Number inventory management sub-system. It should be able to keep track of lifecycles
from account creation, transfer to deletion for all staff on all the existing computer systems and
platform.
1. System User Roles & Workflow
The account management module must support the following user roles:
1.1. Departmental Applicant – the authorized departmental users to initiate the request;
1.2. Departmental Approver – the supervisor to review and approve the request in
department level;
1.3. IMS Helpdesk – the first group of people to review and revise a request after it has
been approved by Department Approver
1.4. Platform Administrator – the people who will perform actual operation for creating,
deleting and modifying a computer account in a particular platform;
1.5. IUS Helpdesk – the people responsible to notify account owners and request applicants
upon job completion.
Departmental
Approver
Departmental Applicant
The following diagram shows the overall workflow process in general account management:
Cancel request
Fill-in request form.
Check all platforms
to be enabled for a
unique ID, i.e. uid
Revise request form
Review the request
form
Reject
Platform
Administrator 1
Platform
Administrator 2
Platform
Administrator n
IUS Helpdesk
Enable Platforms Request
IMS Helpdesk
Approve
Review & Revise the
request form
Cancel request
Complete the
required
administrative tasks
on the responsible
platform
Mark Complete with
one of the
resolution: Enabled,
Disabled, Not-InSystem
Complete the
required
administrative tasks
on the responsible
platform
Mark Complete with
one of the
resolution: Enabled,
Disabled, Not-InSystem
Complete the
required
administrative tasks
on the responsible
platform
Mark Complete with
one of the
resolution: Enabled,
Disabled, Not-InSystem
Check if New
Account
Application?
New Account
Print Password Slip
and deliver to the
account user
Notify IMS Help
Desk and Applicant
2. Application Creation and Submission
2.1. The system should be able to configure Applicants and Approvers for different
departments/faculties;
2.2. Authorized applicants can submit application form for
2.2.1. To create a new user ID/password for a staff with associated platform enabled
2.2.2. To transfer a staff to another department
2.2.3. To enable/disable/extend additional/existing platform for an existing user ID
2.2.4. To delete an existing user ID and all its associated platform
2.3. Four types of forms must be implemented for 2.2.1 (applications for new Academic &
Administrative Staff, temporary account for Academic and Administration). Each of
them have different layout and required information to be filled in;
2.4. Applicant can select different computer platforms to be enabled for the new account
creation application;
2.5. More than one approvers can be set up in a particular department, and applicant can
select the designated Approver for reviewing and approving the application request;
2.6. After an applicant submitting a request, email notification will be sent to the
designated approver, other approvers in the same department will also receive a copy
of the notification;
2.7. Either the designate approver or other approvers in the same department can approve
or reject an application, or directly modify the application detailed information.
2.8. If an application is approved, email notification will be sent to IMS Helpdesk and the
applicant will be notified
2.9. If an application is rejected, email notification will only be sent to the applicant
2.10.
IMS Helpdesk can directly submit all types of application-form to initiate the
process, without the needs of departmental approval.
3. Application Request Handling
3.1. After a request is submitted and approved, email notification will be sent to IMS
Helpdesk;
3.2. IMS Helpdesk colleagues will review and revise application form (if necessary), before
confirm to notify individual platform administrators for action.
3.3. The system must support applications for 16 platforms (Lotus Notes, PC LAN, Unix
System, Oracle Application, Email Alias, CA, Web Course, Wireless, SSL VPN, IP Phone
Number, MS Exchange, Emeritus SSL VPN, Emeritus Wireless, Emeritus Email, Retired
Email, New Computer Preparation);
3.4. More than one administrators can be set up for each platform, which can be modified
at a later stage.
3.5. When a request involves a particular platform, all the platform administrators will
receive email notifications after the request is confirmed by IMS Helpdesk
3.6. For application stated in 2.2.1, system will generate a random password (8 digits of
alpha-numeric, excluding some special characters) and send to platform administrators
3.7. Upon receiving the notification for account manipulation, any one of the platform
administrator can mark the job completion with one of the resolutions (Enabled,
Disabled or Not-In-System)
3.8. The system will record the “Completed By” and “Completion Date” for all the involved
platforms for each request
3.9. In addition to email notification, system will provide interface to platform
administrators for enquiry on Completed and Outstanding requests;
3.10.
Recursive reminders will be sent to platform administrators, if a request has not
been marked for completion within the pre-defined period;
3.11.
Reminders can also be triggered by IMS Helpdesk;
3.12.
During the request handling process, IMS Helpdesk can monitor and keep track
the progress for all applications, while applicant can only keep track the progress for
their departmental applications.
4. Application Completion
4.1. When all the involved platforms has been marked completed for a request, email
notification will be sent to the applicant, IMS Helpdesk and IUS Helpdesk;
4.2. For account creation request (2.2.1), IUS Helpdesk can print out the password slip and
deliver to the account user.
4.3. The password slip should contain system generated random password, the IP Phone
Number assigned and its Initial PIN (if the IP Phone Number platform is requested for
enabling)
4.4. The system should generate statistical reports for overall applications completion rate
and request handling elapsed time, by Year/Month, by platform and by requesting
departments.
5. IP Phone Number Inventory
5.1. The system should include a Phone Number Inventory Management sub-module for
the IP Phone number platform;
5.2. For each Phone Number, the system should keep track its Status (Available, In Used,
Reserved or Frozen), Initial PIN, Allocated to User, Allocated to Department, Allocation
Date, Allocation Remarks and the Assignment History;
5.3. The Phone Number records should be able to imported and/or updated from external
file in batch (Excel or XML);
5.4. The IP Phone Number platform administrators should also be able to update individual
phone number record in the inventory;
5.5. For platform enabling request, administrators can assign a phone number from the
available list, together with its initial PIN.
5.6. The Phone Number Status, Allocation details and Assignment History should be
updated in inventory when it is assigned in a platform enabling request.
5.7. For platform disable request, the status of the Phone Number will be updated to
“Frozen”, and it will become available again after three months;
5.8. The IP Phone Number platform administrators should be able to enquiry the latest
inventory records, and export the inventory to external file (Excel or XML) in both adhoc mode and periodic batch mode.
6. Implementation Requirements:
6.1. The proposed Computer Account Management Module must be developed in and
tightly integrated the with the existing Service Desk System of the BMC Remedy IT
Service Management Suite
6.2. The proposed module must present a consistent user interface, layouts, formats, looks
& feels, menu structure, documentation, and help facilities.
6.3. The proposed module must be run natively in a web browser without the installation or
assistant of browser add-ons or plug-ins. It must be certified to run properly at least on
the IE 7+ and Firefox 3+.
6.4. The proposed module should work with common software such as Microsoft Excel,
Word and PDF reader/writer for data exchange.
6.5. The proposed solution must be designed as open and modular system. Additional
functionalities to other business areas can be easily integrated and extended with
additional modules.
6.6. Integration with 3rd party software and/or customization should be supported with
configuration, web services API, Java programming API and/or automated xml/text
based data exchange.
6.7. The proposed system must support Unicode (up to extension B) character set with
private use area for user defined characters.
6.8. The proposed system must support at least 50 concurrent users.
6.9. The proposed system should provide fast response, e.g. less than 3 seconds for each
click over a fast 100Mb Ethernet.
6.10.
Vendors should provide means to simplify steps involved in using each function
and provide a design to reduce the page to page navigation.
6.11.
The proposed system must support role-based security privileges granting and
revoking to enable fine-gained access control.
6.12.
Vendors shall provide trainings on using the new Account Management Module.
6.13.
Vendors shall provide implementation documents including functional
specifications; user acceptance plan; documentation of workflow; design; configuration
and operation guides.
7. Warranty and Maintenance
7.1. First-year warranty including post-implementation technical support, debugging, minor
enhancement and modification must be bundled with all proposed items.
7.2. Annual maintenance service charge for the next five consecutive years must be listed.
7.3. The terms and conditions of both the warranty and maintenance services indicating
their coverage and level of services must be clearly indicated.
8. Tender Information Needed
The following information should be provided:
8.1. Delivery and Installation schedules
Vendors are expected to provide a ready-to-use modularized packaged solution with
any necessary customization to fulfill all requirements specified in this document.
Vendors should provide detailed implementation methodology and plan. The plan
should cover the time line, processes involved, scheduling of each process, fees
incurred, staffing requirements, and software and hardware requirements. They should
state the company's policy toward knowledge transfer after implementation. The
Proposed System will start the implementation in one month after order placed and be
fully operational in not more than three months.
8.2. Price
All prices quoted for each type of service and software items (including optional items)
should be itemized in unit cost with quantity and discount clearly indicated. They should
also list any bundled training and optional paid courses along with their schedules.
Ongoing support and annual maintenance cost if applicable (optional).
8.3. Roadmap
Vendors should provide roadmaps showing the future product development of the
Proposed System and the schedule for delivery of major upgrades to the software.
8.4. Requirements Fulfillments
For each requirement, vendors should demonstrate how it can be satisfied with the
proposed system. If necessary, please also attach the relative screen shots and flow
charts (if any) to justify the statements. Vendors should list out all requirements which
does not support out of the box, the minimum customization that have to be done, and
the limitation of the solution for any specific requirements. Vendors could make use of
the section numbers to cross reference the requirements which are being addressed in
the proposal. Please make sure all requirements from section 1 to 6 had been addressed
before submitting the proposal.