Introduction
This Request for Proposal (RFP) is to invite prospective vendors to submit a proposal to provide a Business Ticketing System to Glencore Group. The RFP provides vendors with the relevant operational, performance, application, and architectural requirements that the system must fulfil.
Company Background
Glencore is one of the world’s largest global diversified natural resource companies and a major producer and marketer of more than 60 responsibly-sourced commodities that advance everyday life. The Group's operations comprise around 150 mining and metallurgical sites and oil production assets.
With a strong footprint in over 35 countries in both established and emerging regions for natural resources, Glencore's industrial activities are supported by a global network of more than 30 marketing offices. Glencore's customers are industrial consumers, such as those in the automotive, steel, power generation, battery manufacturing and oil sectors. We also provide financing, logistics and other services to producers and consumers of commodities. Glencore's companies employ around 135,000 people, including contractors.
Need for a Business Ticketing Solution
As part of UK Corporate Reform, the marketing organisation at Glencore is executing an organisational change to improve the way in which business ticketing is managed in the organisation, to provide clear audit traceability of business requests and changes. The aim is to increase efficiency in ticketing operations and improve compliance through the use of an effective business ticketing solution. Further, external audits have shown that business ticketing is often currently managed through email with limited or no audit trail.
Project Objectives
Glencore intends to implement a Business Ticketing Solution to support the request and change management processes for business users at Glencore. This will enable Glencore to efficiently manage users’ requests and changes across the organisation by utilising a workflow tool that is fully auditable and reportable. The solution should also be able to support access requests by integrating with the Identity and Access Management solution that is being procured. The business ticketing tool will support existing ITSM Tools at Glencore including Cherwell and Jira.
Control Improvement Objectives:
-
User Experience - empower end users who will use the BT tool to submit tickets easily and self-serve where possible
-
Business Request Management – facilitate the ability to create, manage, track and close incoming service requests
-
Business Change Management – facilitate the ability to create, manage, track and close incoming change requests
-
Process / Workflow Automation - manage a series of automated actions to carry out business procedures, including the ability to maintain an audit trail
-
Access Management - handle access requests for an IT instance and be integrated with a solution that identifies, tracks, controls and manages authorised users’ access to an IT instance
-
Knowledge Management - utilise knowledge to support the needs to fulfil requests, changes and workflows optimally
-
Reporting and Dashboards - capture detailed information from the BT solution such as request history, compliance dashboards etc.
Project Scope
In the first phase of the project, Glencore intends to grant up to XXX[AZ1] licences for the Business Ticketing solution. This will cover uses in Business Areas including HR, Finance, Accounting and Change Management.
The initial scope of the project will focus on ensuring that requests and changes can be fully auditable in a workflow tool. The solution should be able to be integrated with chosen Identity and Access Management (IAM) tool, email service and document management solutions outlined in Architecture section. There may be the need to integrate with existing ITSM tools including Cherwell and Jira, but this will be on discussion with vendors to see if optimal/feasible.
Capabilities, Requirements and Use Cases
The full list of Functional and Non-Functional requirements needed for the Business Ticketing solution can be found in the ‘Glencore BT Requirements’ attachment. Each requirement is tied to a high-level Macro requirement (see Glencore Macro Requirements tab) and has been prioritised as according to the MoSCoW matrix (see Prioritisation Categorisation Guide tab).
The Operating Model below outlines the functional capabilities required for the Business Ticketing solution. This has been worked through with Glencore as a business and IT.
Whilst it is necessary for the Business Ticketing solution to facilitate the provision of the two capabilities outlined in red (Access Management and Knowledge Management) through integration (see Architecture Section in this document), it is assumed that the Business Ticketing solution will not be required to provide the functionality for these two capabilities directly.
Jira Service - HR POC.pptxGlencore BT Requirements v3.xlsx
Business Ticketing Operating Model - Functional Capabilities
Figure 1 – Business Ticketing Operating Tool Functional Capabilities
Business Ticketing Functional Requirements
Below outlines the high-level Macro Requirements required for the Business Ticketing Solution. These have been worked through with Glencore as a business and IT. These can also be found in the Glencore Macro Requirements tab in the ‘Glencore BT requirements’ attachment. Each of the functional requirements in the Functional Requirements tab in the Excel are tied to one of the Macro requirements outlined below.
|
Functional High level requirements |
Description |
|
Simple and efficient way to create, modify and delete tickets |
|
|
Multi Channel Access |
|
|
Multi-ticket type support |
|
|
Self-service portal |
|
|
Knowledge Management |
|
|
Distribute tickets between ticket owners / ticket routing |
|
|
Maintain audit trail |
|
|
Simple approval workflow |
|
|
Workflow automation capabilities |
|
|
Business Rules Management |
|
|
User centric information / simple CRM capabilities |
|
|
Maintain access rights and permissions |
|
|
Dashboard and analytics |
|
|
Integration Support |
|
|
SLA Policy functionality |
|
Figure 2 – Business Ticketing Functional Macro Requirements
Business Ticketing Non-Functional Requirements
Below outlines the high-level Non-Functional Requirements required for the Business Ticketing Solution. These have been worked through with Glencore IT and Security. Each of the Non-Functional requirements in the Non-Functional Requirements tab in the Excel are tied to one of the high-level Non-Functional requirements outlined below.
|
Non Functional High Level Requirements |
|
|
Security & Privacy |
Compliance with data regulation laws and InfoSec requirements |
|
Scalability & Availability |
A highly available solution with option to scale as per organization needs |
|
Monitoring |
Maintain a full and comprehensive audit trail of all requests. Ensure that records are kept for purpose of auditability |
|
Integration |
Ability to integrate with IAM and PAM tools |
|
Data Retention |
Capability for data retention of audit records and transactions |
|
Performance |
Industry standard performance including support for high volume of concurrent users |
|
Extensibility |
Option to scale and customise the Business Ticketing solution |
Figure 3 – Business Ticketing High-Level Non-Functional Requirements
Business Ticketing Use Cases
When engaging Glencore as a business, we have identified Business Use cases for the Business Ticketing Tool (see ‘Use Cases’ tab in the ‘Glencore BT Requirements’ attachment). Below lists a selection of use cases for business areas we engaged to formulate the use cases as well as the capability area of the ticketing tool that the use case would require.
|
Business Area |
Capability Area |
Use Case Description |
|
HFM |
Access Management |
Ability to gain access to HFM as an application, taking into consideration application security |
|
HFM |
Change Management |
Ability to request and change parent / child relationship of entities within a given scenario/structure |
|
HFM |
Request Management |
HFM Journal Management creation including supplemental data justifying the journal entries, submission, approval, through posting |
|
HFM |
Sox Requirements |
All changes listed to be tracked through a workflow tool: metadata, entry screens, rules, ownership, security |
|
Finance (Metals and Coal – CFPT) |
Change Management |
Ability to make changes to Finance related systems like: Treasury, TF and Finance Operations Center |
|
Finance (Metals and Coal – CFPT) |
Request Management |
Ability to add new bank accounts |
|
Finance (Metals and Coal – CFPT) |
Request Management |
Ability to add new instrument types |
|
Finance (Metals and Coal – CFPT) |
Access Management |
Ability to set up new users/accounts on finance systems |
|
Accounting (Oil) |
Request Management |
Ability to manage data requests and account requests used for audit planning |
|
Accounting (Oil) |
Request Management |
Ability to receive and process requests from other areas of the business for approvals, accounting turnarounds |
|
Accounting (Oil) |
Access Management / Request Management |
Ability to review access requests / formally review a memo |
|
Accounting (Oil) |
Workflow Management |
Ability to manage journal reviews and signing off on financial statements |
|
Accounting (Oil) |
Request Management |
Ability to manage requests for new profit centres managed by the centre of excellence |
|
Accounting (Oil) |
Reporting and Dashboards |
Ability for reporting to be in line with month-end / cycle-end review (investigate what is currently being showcased within Blackline) |
|
Change Management (Oil) |
Request Management |
Ability to receive requests for new business proposals, including having the ability for approvals |
|
Change Management (Oil) |
Request management |
Ability to receive requests for new project proposals, including having the ability for approvals |
|
Change Management (Oil) |
Workflow Automation |
Capability for Workflow Management in process reviews, in particular useful for audit tracking |
|
HR |
Request Management |
Ability to manage requests that come through to HR, over and above what is available through WorkDay on self-service currently. An example would be to manage requests for tax documentation |
|
HR |
Segregation of Duties |
Ability to manage different agent groups/teams and the security segregation of duties associated |
|
HR |
Knowledge Management |
Ability to guide users through knowledge articles/knowledge base to fulfil their HR requests |
|
HR |
Workflow Management |
Ability to track workflow on requests that come through for compliance purposes |
|
Accounting (Metals and Coal – CoE) |
Request Management |
Ability to set up and manage new companies |
|
Accounting (Metals and Coal – CoE) |
Request Management |
Ability to set up and manage new accounts |
|
Accounting (Metals and Coal – CoE) |
Workflow Management |
Ability to track system error messages that come through to Accounting |
Figure 4 – Business Ticketing Use Cases
Demo Specification
The BT Solution Provider should provide a demonstration of the BT solution, delivering upon the use cases and requirements mentioned above in their own environment which will be used to enable Glencore to view the candidate BT technology as part of the RFP process.
The timeline for the presentations and demonstrations is mentioned in the RFP Schedule section of the document. The solution will be evaluated on its ability to fulfil the use cases and the ease of use for the end user.
Target Architecture
Below is the draft proposed Target Architecture for the Business Ticketing (BT) Service. This may be updated along the process upon discussion with vendor to optimally handle tickets at Glencore.
Figure 5 – Business Ticketing Target Architecture
Integrations Proposed for the Business Ticketing Solution:
-
Email Service Integration – Glencore will still continue to keep the ability to raise tickets through email and have the ability to pass information from emails to the Ticketing Tool would aid the logging of tickets. Also, using emails to communicate to users on the status of the ticket would be beneficial i.e. once it’s been logged / fulfilled / cancelled
-
Document Management Integration – Glencore will look to self-serve where possible and point users to knowledge articles where possible to fulfil requests and aid the ticketing process. Document Management tools used at Glencore include Confluence, Microsoft Teams, OpenText and Sharepoint
-
Identity and Access Management (IAM) Service – the Business Ticketing solution is likely to receive requests from users for access to applications and it is necessary to integrate with the Identity and Access Management service to grant the right roles and level of access for the requestor
RFP Schedule
The schedule for this RFP is shown below:
|
Date |
Milestone |
25 April 2022
|
Glencore publish Request for Proposal
|
26 April 2022
|
Bidders acknowledge receipt and confirm participation
|
29 April 2022
|
Final date for questions
|
3 May 2022
|
Glencore to respond back to vendor questions
|
6 May 2022
|
Replies to this RFP to be submitted
|
10-11 May 2022
|
Demonstrations by vendors to meet requirements and use cases
|
13 May 2022
|
Presentations from selected bidders arranged
|
27 May 2022
|
Selection of preferred partner
|
Figure 6 – Business Ticketing RFP Schedule
Glencore RFP Contact:
Gregor Wicki is our designated contact to manage all correspondence relating to this RFP. Contact details are below:
|
Email: |
|
|
Telephone: |
Guidance to Respond
Respondents must address all information specified by this RFP. All questions must be answered completely. Glencore reserves the right to verify any information contained in the service provider's RFP response and to request additional information after the RFP response has been received. Marketing brochures included as part of the main body of the bid response shall not be considered. Such material must be submitted only as attachments and must not be used as a substitute for written responses. In case of any conflict between the content in the attachments and a service provider's answers in the body of the proposal, the latter will prevail.
Response Format
Respondents must follow a structured format for the proposal as defined in the next section and complete the mandatory response document files provided with this RFP. In addition, respondents may provide further response information — this must be in Microsoft Office format (e.g., Word, Excel, PowerPoint, Project, Visio). Glencore requires service providers to respond in English. The proposal must be accompanied by a covering letter, signed by an individual authorized to bind the proposed entity.
Proposal Document Structure
Bidders should follow a mandatory structured format for their proposal. This section describes the content and format for the bids tendered. The information to be included is described below.
|
Section |
Description |
Executive summary
|
Present a synopsis of the response to the RFP. This should summarise the objectives, approach and benefits of the work, validating the partner’s understanding of our needs. |
Approach and timelines
|
This section should describe the partner’s approach and it should include sub-sections for each service area being requested with supporting timelines and activities. |
Scope and deliverables
|
This section should list all required deliverables with an overview of the proposed services and solutions based on our service requirements. |
Methodology and plan
|
This section will include the method which will be used to manage the overall programme / projects and the client communications. It should include a high level project plan with phases. |
Detailed and itemized Pricing
|
Include a fee breakdown for software components and associated deliverables. |
Glencore BT Requirements Excel: Functional Requirements
|
Provide a response whether the proposed BT solution can support Glencore’s functional BT requirements. A list of functional requirements is listed in ‘Functional Requirements’ Tab in the Glencore BT Requirements attachment and is based on Glencore’s Business Ticketing objectives and best practices. Each requirement is prioritised using a MoSCoW approach (explained in Priority Categorisation Guide tab). Provide a response in column J against each requirement to indicate whether the proposed solution can support the requirement. |
Glencore BT Requirements Excel: Non-Functional Requirements
|
Provide a response whether the proposed BT solution can support Glencore’s non-functional BT requirements. A list of functional requirements is listed in ‘Non-Functional Requirements’ Tab in the Glencore BT Requirements attachment. Each requirement is prioritised using a MoSCoW approach (explained in Priority Categorisation Guide tab). Provide a response in column J against each requirement to indicate whether the proposed solution can support the requirement. |
Glencore BT Requirements Excel: Questions to Vendors
|
Provide brief responses to questions mentioned in column D in the ‘Questions to vendors’ tab in the Glencore BT Requirements attachment |
Appendix - company overview
|
Official registered company name, address, main telephone number. Key contact name, title, address, direct telephone and e-mail. Person authorized to contractually bind the company against this RFP. Brief service history, including year established and number of years the company has been offering IT security services. |
Appendix - team resourcing model
|
Describe the qualifications and relevant experience of the types of staff that would be assigned by providing biographies for those staff members. Overviews of supporting teams / departments and their locations should also be included. |
Appendix - references
|
Provide 2-3 current references where you have completed similar projects. |
Appendix - internal security model
|
Provide an overview / summary of your internal security framework, including key security policies, client data related controls and any associated third party controls. |
Appendix – commercial terms (see Commercial Requirements section)
|
Commercial terms and conditions of their offering in the response to this RFP. |
Appendix – supporting information
|
Additional supporting information, such as example reports etc. |
Figure 7 – Proposal Document Structure
Commercial Requirements
In addition to the functional requirements Glencore require that a number of commercial requirements are considered in the RFP response.
|
REQ |
Requirement |
Description |
|
REQ 1 |
Commercial terms and language
|
Bidders are requested to incorporate the commercial terms and conditions of their offering in the response to this RFP. All responses and contractual agreements are requested to be returned in English. |
|
REQ 2 |
Duration of service
|
The commercial terms of any responses should be based on a 1 year commitment with option to extend the contract incrementally by 2 years (1 year +1 +1). |
|
REQ 3 |
Currency
|
The associated costs for proposals should be priced in United States Dollars[AZ3] (USD). |
|
REQ 4 |
Resourcing
|
Responses should specify named parties for all team members who will be directly assigned to the account along with their professional biography. The proposed use of any third parties should be divulged. Also see section below. |
|
REQ 5 |
Service location
|
Responses should include where services are provided from (e.g. Security Operations Centers) as well as where any data (e.g. client data) will be stored. |
|
REQ 6 |
Service review
|
Glencore will require a quarterly service review to discuss findings and trends. |
|
REQ 7 |
Management reporting
|
Glencore require a monthly management report from the service provider. Please provide an example of the management report as part of the RFP submission. |
Figure 8 – Business Ticketing Commercial Requirements
Appendix 1 – Key IT Metrics
Bidders should base their proposal on the following metrics:
|
Metric |
Count |
Description |
Number of sites
|
200 |
Sites, in this context, being defined as a network connected site |
Number of users
|
40,000 |
This is the number of user across the Glencore estate |
Number of PCs
|
37,000 |
Count of domain joined PCs (desktops and laptops). |
Figure 9 – Key IT Metrics
Appendix 2 – Disclaimer
Glencore International AG will not be liable in any way for any costs incurred by vendors in the preparation and delivery of their responses to this RFP nor for any subsequent discussions and/or product demonstrations.
Receipt of the RFP or submission of an RFP response confers no rights upon the vendor nor obligates Glencore International AG in any manner.
Appendix 3 – Functional Requirements
Below outlines the full functional requirements for the Functional Requirements, which can also be found in the Glencore BT Requirements attachment.
|
Requirement ID |
Requirement Title |
Requirement Description |
||
|
Simple and efficient way to create, modify and delete tickets |
|
|||
|
1 |
Create Ticket |
The BT solution shall provide the ability to raise a ticket through a support portal |
||
|
2 |
Modify Ticket |
The BT solution shall provide the ability to process and close tickets once raised |
||
|
3 |
Delete Ticket |
The BT solution shall cancel request workflow completely and request status shall be updated accordingly, if requester choose to cancel request |
||
|
4 |
Request Edit / Cancel Stage |
The BT solution shall provide configurable option at workflow level to mention at what stage request can be cancelled or edited |
||
|
5 |
Catalog Schema |
The BT solution shall provide a request/change catalogue with default and custom metadata such as category, sub-category, descriptions |
||
|
6 |
On-behalf of request option |
The BT solution shall support on-behalf of request option |
||
|
7 |
Add comments / justification |
The BT solution shall provide ability to add/update comments for requester and approver in request |
||
|
8 |
Copy/clone request |
The BT solution shall provide option to copy/clone request based on another request |
||
|
9 |
Ticket priority |
The BT solution shall provide the ability to define priority based on ticket parameters |
||
|
Multi Channel Access |
|
|||
|
10 |
Multi Channel Access to raise ticket |
The BT solution shall provide the ability to raise tickets through preferred channel: email, mobile app (tbc) |
||
|
11 |
Email notifications customisation |
The BT solution shall provide the ability to customise email templates and content for emails automatically sent to end users |
||
|
12 |
24/7 Email-based actions |
The BT solution shall provide the ability to perform email response based actions. For example, user can respond over email to update approval decision using standard keywords (APPROVE, REJECT). |
||
|
13 |
Custom Mailbox |
The BT solution shall provide the ability to use your mail servers to manage incoming and outgoing email tickets and respond to emails as a team rather than individuals |
||
|
14 |
Mobile-optimised interface |
The BT solution shall provide the ability ability to provide a mobile-optimized interface for users to access features such as the request catalogue, approval work items, and access certification items |
||
|
Multi-ticket type support |
|
|||
|
15 |
Multi-ticket type support |
The BT solution shall provide the ability to support different types of tickets, depending on the nature of the request e.g. request management, change management, incident management, problem management |
||
|
Self-service portal |
|
|||
|
16 |
Self-service portal |
The BT solution shall provide the ability for all employees to raise requests directly via a support portal and track status |
||
|
17 |
Personalisation of UI |
The BT solution shall provide the ability to support different UI views based on roles, permissions, policies applicable, preferred language, time zone of the logged in user |
||
|
18 |
Accessibility support |
The BT solution shall provide the ability to provide accessibility features such as text-to-speech, alternative colour palettes, screen magnifier. The vendor to describe which accessibility features are provided and if there is any industry standard that the solution is compliant to. |
||
|
19 |
Portal / Home page customisation |
The BT solution shall provide the ability for every end-user to customise their portal / home page and select the widgets, dashboards, and data views they see when visiting the home page |
||
|
20 |
Branding |
The BT solution shall provide the ability to brand the user interface with Glencore colours, fonts, and logos |
||
|
21 |
Language Support |
The BT solution shall provide the ability to provide support for the following languages and character sets in the user interface: English, (other languages tbc) |
||
|
Knowledge Management |
|
|||
|
22 |
Knowledge Management |
The BT solution shall provide the ability for users to look up solutions from the knowledge base and create documentation for recurrent questions |
||
|
23 |
Canned Responses |
The BT solution shall provide the ability to create pre-formatted reply templates to common questions so that agents can save time |
||
|
24 |
Article Suggestor |
The BT solution shall provide the ability for agents to get KBase articles suggestions to respond to email tickets |
||
|
Distribute tickets between ticket owners / ticket routing |
|
|||
|
25 |
Distribute tickets between ticket owners / ticket routing |
The BT solution shall provide the ability for tickets to be allocated between users and teams (team coordination functionality) |
||
|
26 |
Public and Private Notes in Tickets |
The BT solution shall provide the ability to allow agents to add notes for the rest of the team not visible for the requested/end-user |
||
|
27 |
Tags |
The BT solution shall provide the ability to categorize and bucket the tickets by putting tags on it |
||
|
28 |
Agent Collision Detection |
The BT solution shall provide the ability to detect and avoid multiple replies from different agents to the same ticket |
||
|
Maintain audit trail |
|
|||
|
29 |
Maintain audit trail |
Maintain a full and comprehensive audit trail of all requests. Ensure that records are kept for purpose of auditability. |
||
|
Simple approval workflow |
|
|||
|
30 |
Approval workflow |
The BT solution shall provide the ability to create simple workflows to facilitate ticket routing, approvals and process and automation |
||
|
31 |
Approvals delegate and reassignment |
The BT solution shall support delegation of approval authority by approver to someone within the organization and reassign work items in case the approver is not the right person |
||
|
32 |
Email notifications, reminders and escalation |
The BT solution shall provide send email notifications to notify users of a change in status or if an action is required, send out reminders to request approvers based on configured time and set escalation if a work item is not completed based on configured time defined in workflow |
||
|
33 |
Priority approval queue display |
The BT solution shall set approval queue in approver's dashboard/inbox based on priority of model derived from request item's priority |
||
|
Workflow automation capabilities |
|
|||
|
34 |
Workflow automation capabilities |
The BT solution shall provide the ability for process automation based on meta data and predefined rules; e.g. auto-assign tickets to specific support groups |
||
|
35 |
Employee Onboarding |
The BT solution shall provide the ability to onboard new employees efficiently by facilitating easy collaboration with other teams responsible for onboarding an employee |
||
|
36 |
Workflow Automator |
The BT solution shall provide the ability to automate processes and mundane tasks by setting the desired conditions with a simple drag and drop option |
||
|
37 |
Scheduler |
The BT solution shall provide the ability to schedule tickets automatically for recurring tasks |
||
|
38 |
Sandbox |
The BT solution shall provide the ability to create an out-of-the-box environment to test out workflows and configurations before syncing them to your account |
||
|
Business Rules management |
|
|||
|
39 |
Business Rules Management |
The BT solution shall provide the ability for low code business rules implementation |
||
|
User centric information / simple CRM capabilities |
|
|||
|
40 |
User centric information / simple CRM capabilities |
The BT solution shall provide the ability to provide overview of a user’s recent tickets and requests |
||
|
Maintain access rights and permissions |
|
|||
|
41 |
Role Management |
The BT solution shall provide the ability to manage role (access) management per user/application/role |
||
|
42 |
System Access Requests |
The BT solution shall provide the ability to log system access requests (new user, change user, leave user processes) |
||
|
43 |
Inventory Access |
The BT solution shall provide the ability to access inventory: per user, per role, per application |
||
|
44 |
Access Management |
The BT solution shall provide the ability to help the occasional visitors like managers to login to the BT solution using day passes |
||
|
Dashboard and analytics |
|
|||
|
45 |
Analytics and Reporting |
The BT solution shall provide the ability to review number of tickets logged, in progress, closed and cancelled |
||
|
46 |
Analytics and Reporting |
The BT solution shall provide the ability to review list of outstanding ticket assignments |
||
|
47 |
Analytics and Reporting |
The BT solution shall provide the ability to run analytics on ticket duration |
||
|
48 |
CSAT Surveys |
The BT solution shall provide the ability to measure service desk efficiency and customer satisfaction with every support ticket coming into the service desk |
||
|
49 |
Custom Agent Dashboard |
The BT solution shall provide the ability to consolidate data in real-time and show it on a single screen. This will help agents prioritize and manage work better |
||
|
50 |
Comprehensive library of default reports |
The BT solution shall provide a comprehensive library of default reports including request related reports |
||
|
51 |
Customizable reports |
The BT solution shall create customized reports as required for requests, changes. |
||
|
52 |
Request reports |
The BT solution shall create detailed report for requests including application details, approver details, decision and comments. |
||
|
53 |
Export report to CSV, PDF or HTML format |
The BT solution shall support to export report results in CSV, PDF or HTML format as required |
||
|
54 |
Report scheduling |
The BT solution shall support scheduling of reports |
||
|
55 |
Report data volume |
The BT solution shall support 300k+ records, 1200+ applications (TBC) |
||
|
56 |
Reporting APIs |
The BT solution shall provide analytics and report specific APIs to integrate with other third party solutions (i.e: power BI) |
||
|
57 |
Email report |
The BT solution shall share report results over email with beneficiaries |
||
|
58 |
Compliance dashboard |
The BT solution shall provide a comprehensive compliance dashboard to display violation, remediation data |
||
|
59 |
KPI dashboard |
The BT solution shall provide a KPI dashboard |
||
|
60 |
System operations dashboard |
The BT solution shall provide a user friendly dashboard that reports on the monitor system health |
||
|
61 |
Report data retention |
The BT solution shall provide configurable option to store report results for specific duration as required |
||
|
62 |
Fine grained access to report |
The BT solution shall provide framework to support fine grained access to report module |
||
|
63 |
Cap limit on report result |
The BT solution shall provide configuration option to cap limit for reports based on how many records can be extracted. The BT solution shall create alert on such violation and stop report generation process all together. |
||
|
64 |
Statistics on usage report |
The BT solution shall flag inactive reports based on usage statistics and shall create alert for the same |
||
|
SLA Policy Functionality |
|
|||
|
65 |
SLA Policy functionality |
The BT solution shall provide the ability for Multi SLA policy support depending on criteria such as user group, ticket type etc in order to determines the duedate/time for a new ticket |
||
|
66 |
SLA Policy functionality |
The BT solution shall provide the ability to set up different business hours for your various remote service desk teams to accurately define SLAs and manage expectations |
||
|
Other |
||||
|
67 |
Community forums |
The BT solution shall provide the ability to utilise community forums to gague user feedback and collaborate on tooling |
||
Figure 10 – Business Ticketing Functional Requirements