1600 PMP mock questions 1400 CAPM mock questions 800 SCJP 6 mock questions 600 OCAJP 7 mock questions 590 OCPJP 7 mock questions 556 SCWCD 5 mock questions 500 OCEJWCD 6 mock questions pdfDownload (java,struts, hibernet etc)

ITIL Basics for selecting a new service management tool

Some generic functionality and requirements you may be interested in when selecting a new service management tool:

■What Services are we trying to get under control and how will technology enable us to do this more efficient and more effective?
■What IT Service Management processes must be supported?
■Do we need to be able to partition the data?
■Who will provide training and what type of training are we looking for?
■How much customisation do we allow for (think customisation of your business processes and of the new technology)?
■Who will provide support and where will the support come from?
■What languages must be supported?
■How many different SLAs must be supported (one customer or multiple customers)?
■What?s the budget you?re thinking of (short, medium and long-term to implement and support the tool)?
■How will the tool deal with escalation (over various) timezones?
■Do you require web-based technology or are you happy to run with client-server based technology?
■What type of technology will the product run on (SQL, Oracle, MySQL)?
■Who will be using the tool and what type of platforms do they currently use?
■Will you require local support or are you happy with support that comes from overseas?
■How many concurrent users will the tool have?
■Do you require integration with knowledge-base technologies?
■Do you require any specific reports/outputs from the data?
■Do you require integration with PABX, monitoring and/or alerting tools?
■Is there any legislation that may impact your selection?
■What's the viability and credibility of the tool vendor?
■What references are provided to you, so you can check out how the tool really works (are they independent)?
■Do you have a (test-)script that shows the flow of data within your organization and the flow of data with external entities?
■Does the tool have any technical limitations?
■How's the tool's flexibility (is it easy to customise or does the vendor own all IP and are you forced to use their developers to do all your customisation?
■How easy (read expensive) is it to export and import data between your current datasets and the new one?
■Do we have any requirements for response times (especially think of searching the knowledge base)?
■Do we need integration with other reporting or project management tools?
■What confidentiality requirements of the data do we have and does the tool support our requirements (e.g. user and group based access)?
■What integrity requirements of the data do we have and does the tool support our requirements (e.g. automatic integrity checks)?
■What availability requirements of the data do we have and does the tool support our requirements (e.g. can we restore one record)?
Service DeskScroll down please.

Incident ManagementSome Incident Management supporting functionality you may be interested in when selecting a new service management tool:

■Proper online documentation for the various roles that will be using the tool (e.g. user, administrator, supervisor, process owner).
■Provide context sensitive help (using online and offline options)
■Ability to create Incident templates for dealing with the various Incident models (e.g. ?standard? Incidents and Critical Incidents).
■Ability to auto populate, auto-calculate fields, and auto verify fields.
■Ability to perform advanced boolean and logic-based searches, with the capability of narrowing down and filtering search results.
■Ability to audit-track, monitor and report against any specified Incident attributes (e.g. change in category or priority).
■Ability to keep a history of the number of times an Incident has been (re-)assigned to another group/person with the ability to automatically escalate the Incident when exceeding a preset threshold.
■Ability for logging and recording Incidents (client/server based) using various input media (e.g. screen, email, etc.)
■Ability for logging and recording Incidents (web based) using various webbrowing platforms (e.g. Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, Google Chrome, etc.)
■Ability to use personalised or group access to create, modify, delete, and verify records.
■Classification of Incidents, and the ability to link independent workflows to them. (e.g. into Incident, Query, and Service Request).
■Classification of Incidents based on reporting source CI (e.g. Server, Printer, Desktop, etc.)
■Prioritisation of Incidents based on Impact, Urgency, with an option for including more dimensions like Effort.
■Ability to create an (v1) x (v2) x (v3)...(vn) priority matrix with assigned service targets (response, resolve, escalate, feedback) to each of the identified priorities.
■Ability to use a context sensitive n-tiered categorisation model (a mimimum of at least 3-tiers is recommended)
■Ability to assign (escalate) Incidents to other service groups and business units.
■Ability to assign (escalate) Incidents to other individuals.
■Ability to assign service targets and service levels to Incidents (e.g. response times, solution times, feedback times, and escalation times).
■Incident Matching functionality that allows the Incident Owner to search for similar Incidents that may or may not have a workaround or solution attached to it.
■Ability to link the Incident to a CI and retrieve information on other ITSM records related to the same CI (e.g. Configuration Items, Problems, Known Errors, Changes, SLAs, OLAs, and UCs)
■Ability to link the Incident to a CI and retrieve information on other CI records related to the CI on which the Incident occurred.
■Ability to change the status of the Incident (Incident Status) into a required state (e.g. pending for Problem resolution).
■Ability to time-stamp work (resources spent) on Incidents (e.g. on phone, analysing, after work).
■Automatic functional escalation when certain service target triggers are met. Automatic hierarchical escalation when certain service target triggers are met.
■Ability to create workflow rules in the Incident Management process flow (e.g. can?t close an Incident without feedback from customer).
■Automatic feedback request functionality, based on a rule based system (e.g. priority 1 must have feedback before it can be closed, priority 5 can be closed automatically after a certain amount of time has elapsed).
■Dashboard functionality to visualise and monitor the current workload.
■Reporting functionality that supports monitoring and reporting against any set of key performance indicators.
■Ability to select orphaned records to archive.
■Ability to orphan records so they can be archived.
■Ability to perform integrity checks on the Incident Management database.
■Ability to flag Incident records for Problem Management.
■Use of diagnostic scripts to support the Incident Management troubleshooting process.
Problem ManagementSome Problem Management supporting functionality you may be interested in when selecting a new service management tool:

■Proper online documentation for the various roles that will be using the tool (e.g. user, administrator, supervisor, process owner).
■Provide context sensitive help (using online and offline options)
■Ability to create Problem templates dealing with the various systems in use (e.g. hardware Problem, software Problem, major Problem, etc.).
■Ability to create Known Error templates dealing with the various systems in use (e.g. hardware Known Error, software Known Error, etc.).
■Ability to auto populate, and auto-calculate fields.
■Ability to perform Boolean and logic-based searches, with the capability of narrowing down search results.
■Ability to audit-track and monitor/report against any specified Problem attributes (e.g. change in category or priority).
■Ability to audit-track and monitor/report against any specified Known Error attributes (e.g. change in solution category).
■Ability to keep a history of the number of times a Problem has been (re-)assigned to another group/person.
■Ability to keep a history of the number of times a Known Error has been (re-)assigned to another group/person.
■Logging/recording Problems (client/server based).
■Logging/recording Known Error Records (client/server based).
■Logging/recording Problems (web based).
■Logging/recording Known Error Records (web based).
■Logging/recording of Problems based upon set the exceeding of preset ?pain-factors?.
■Personalised or group access to create, modify and delete records.
■Classification of Problems. (E.g. Problem with workaround available, Problem with no workaround available, etc.).
■Classification of Known Error Records (E.g. Known Error with solution available, Known Error with no solution available, etc.).
■Prioritisation of Problems based on Impact and Urgency.
■Prioritisation of Known Error Records based on Impact and Urgency.
■Ability to create an (i) x (j) priority matrix with assigned service targets to each of the identified priorities.
■Tiered categorisation model (3-tier approach)
■Assigning Problems to other Service Groups.
■Assigning Known Error Records to other Service Groups.
■Assigning Problems to other Individuals (e.g. for root cause identification)
■Assigning Known Error Records to other Individuals (e.g. for identification of a solution).
■Assigning individual tasks that (may) lead to root cause identification, workaround identification, or solution identification to groups and/or individuals.
■Assigning Service Levels to Problems (e.g. response times, solution times, feedback times, and escalation times). These levels should support any SLAs as set by the organisations and will be aligned with OLAs and UCs.
■Assigning Service Levels to Known Errors (e.g. response times, solution times, feedback times, and escalation times). These levels should support any SLAs as set by the organisations and will be aligned with OLAs and UCs.
■Incident Matching functionality that allows the Problem owner to search for similar Incidents that may need to be linked to the identified Problem.
■Problem Matching functionality that allows the Problem Owner to search in various, typically external knowledge bases for workarounds and solutions to the identified Problem/s.
■Ability to link the Problem to the Incident/s related to it.
■Ability to link the Problem to a CI (the identified root cause) and retrieve information on other IT Service Management records related to the same CI (multiple problems may be linked to the same identified root cause!)
■Ability to link the Problem to a CI and retrieve information on other CI records related to the CI against which the Problem has been recorded.
■Ability to change the status of the Problem (Problem Status) into a required state (e.g. pending for Solution).
■Ability to change the status of the Known Error (Known Error sStatus) into a required state (e.g. Rectified, pending for Change implementation).
■Ability to time-stamp work (resources spent) on Problems (e.g. on phone, analysing, after work).
■Ability to time-stamp work (resources spent) on Known Error Records (e.g. on phone, analysing, after work).
■Automatic functional escalation when certain service target triggers are met. Automatic hierarchical escalation when certain service target triggers are met.
■Ability to create workflow rules in the Problem Management process flow (e.g. can?t close a Problem without an identified root cause, workaround, or solution and feedback from customer or Change Management).
■Automatic feedback request functionality, based on a rule based system (e.g. priority 1 must have feedback before it can be closed, priority 5 can be closed automatically after a certain amount of time has elapsed).
■Dashboard functionality to visualise and monitor the current workload.
■Reporting functionality that supports monitoring and reporting against any set of key performance indicators.
■Ability to select orphaned Problem records to archive.
■Ability to orphan Problem records so they can be archived.
■Ability to select orphaned Known Error records to archive.
■Ability to orphan Known Error records so they can be archived.
■Ability to perform integrity checks on the Problem Management database.
■Ability to perform integrity checks on the Known Error (Records) database.
■Ability to flag Problem records for Change Management (to create awareness on current issues for which RFCs may well be submitted).
■Ability to import Known Error Records from external databases.
■Ability to plug-in Known Error Records from external databases (rather than importing them).
■Ability to perform trend-analysis on Incidents, Problems, and Known Error Recods.
■Ability to create a Problem log that contains all associated documentation used in the analysis and identification of a workaround/solution.
■Ability to create a Known Error log that contains all associated documentation used in the analysis and identification of a workaround/solution.
■Data-mining and statistical analysis that leads to (automatic) identification of Problems (e.g. a sudden increase of Incidents in a particular area should be picked up automatically as a potential Problem).
■Reviewing capability of Problem Records (information captured with record) against efficiency and effectiveness.
■Reviewing capability of Known Error Records (solutions) against efficiency and effectiveness.
■Use of diagnostic scripts to support the Problem Management troubleshooting process.
■Online Kepner-Tregoe guidance to support the Problem Management process.
■Online Ishikawa guidance to support the Problem Management process.
■Online Brainstorming guidance to support the Problem Management process.
■Online Fault Tree Analysis guidance to support the Problem Management process.
■Ability to plug-in internal and external "help" systems.
■The ability to ?release? Known Error Records for use to Incident Management and the Service Desk.
Change ManagementSome Change Management supporting functionality you may be interested in when selecting a new service management tool:

■Online documentation (User, Admin, Supervisor, Process owner).
■Context sensitive help.
■Ability to create Change templates dealing with the various systems in use and covering the various identified Change categories/models.
■Ability to auto populate, and auto-calculate fields.
■Ability to perform Boolean and logic-based searches, with the capability of narrowing down search results.
■Ability to audit-track and monitor/report against any specified Change attributes (e.g. change in category or priority).
■Ability to keep a history of the number of times a Change has been (re-)assigned to another group/person.
■Logging/recording Changes (client/server based).
■Logging/recording Changes (web based).
■Personalised or group access to create, modify and delete Change records.
■Classification of Changes (Based on priority and category).
■Prioritisation of Changes based on urgency.
■Ability to create an (i) x (j) priority matrix with assigned service targets to each of the identified priorities.
■Tiered categorisation model (3-tier approach)
■Assigning Changes to other Service Groups.
■Assigning Changes to other Individuals (e.g. for assessment or scheduling)
■Assigning individual tasks and authorisation levels that (may) lead to approval/rejection of the Change, to groups and/or individuals.
■Assigning Service Levels to Changes (e.g. throughput times, response times, approval times, feedback times, and escalation times). These levels should support any SLAs as set by the organisations and will be aligned with OLAs and UCs.
■Ability to link the Change/s to the Known Error/s related to it.
■Ability to link the Change to one or more Releases and/or assigned Release tasks. Multiple changes may all be linked to one Release.
■Ability to link the Change to a CI or a number of CIs and retrieve information on other CI records related to the CI against which the Change (or related Problem) has been recorded. This helps to assess the impact of the Change on other parts of the Infrastructure.
■Ability to change the status of the Change (Change Status) into a required state (e.g. pending for Approval, scheduled, in test, in build, in roll-out, reviewed).
■Ability to time-stamp work (resources spent) on Changes (e.g. assessing, building, testing, etc.)
■Automatic functional escalation when certain service target triggers are met.
■Automatic hierarchical escalation when certain service target triggers are met.
■Ability to create workflow rules in the Change Management process flow (e.g. from build, to test, to roll-out approval, to implementation, to post implementation review).
■Automatic feedback request functionality, based on a rule based system. This ensures the Change is seen as successful by the customer before the Change records is closed.
■Dashboard functionality to visualise and monitor the current workload.
■Reporting functionality that supports monitoring and reporting against any set KPIs.
■Ability to select orphaned records to archive.
■Ability to orphan records so they can be archived.
■Ability to perform integrity checks on the Change Management database.
■Ability to flag Change records for Release Management (to create awareness on current RFCs that may well become work for Release Management).
■Integration with Programme and Project Management tools.
■Integration with scheduling tools (e.g. Exchange/Outlook/Notes).
■Integration with electronic sign-off technology and encryption to support a secure approval process.
■Ability to perform trend-analysis on Changes.
■Ability to create a Change log that contains all associated Change related documentation.
■Ability to schedule Change related meetings.
■Ability to invite members to Change related meetings.
■Ability to store minutes of Change related meetings.
■Ability to store various review check-lists against the various Change categories.
■Reviewing capability of Change/s against efficiency and effectiveness.
■Use of diagnostic scripts to support the Change Management workflow process (e.g. some visual workflow capability that makes it clear where the Change is in its own specific lifecycle).
■Online discussion forms to assess the various Changes with the ability to track and store all communication.
■The ability to ?release? Changes to Release and Deployment Management for development.
■The ability to ?release? Changes to Release Management for building.
■The ability to ?release? Changes to Release and Deployment Management for testing.
■The ability to ?release? Changes to Release Management for roll-out.
■Ability to store test plans with the Change record.
■Ability to store back out plans with the Change record.
■Ability to store test results with the Change record.
■Ability to store back out results with the Change record.
■Ability to store Change success criteria with the Change record.
■Ability to store the Change success criteria results with the Change record.
■Ability to automatically create an internal Forward Schedule of Changes (iFSC) that integrates with Project Management tools (such as Microsoft Project). Data should be drawn from tasks and resources assigned by Change Management. The iFSC will contain data on developing, building, testing, implementation, and reviewing. It will be used predominantly by IT.
■Ability to automatically create an external Forward Schedule of Changes (eFSC) that integrates with Project Management tools (such as Microsoft Project). Data should be drawn from tasks and resources assigned by Change Management. The eFSC will contain data on changes that have been approved for implementation. It will be used predominantly as a means to communicate with the customers.
■Ability to import data from Availability Management and Service Level Management concerning scheduled maintenance outages and maintenance windows as agreed with the customers. This part should integrate with the iFSC. It merges the data from the Projected Services Availability (PSA) / Projected Services Outages (PSO) document with the current change schedule.
■Ability to import data from Availability Management and Service Level Management concerning scheduled maintenance outages and maintenance windows as agreed with the customers. This part should integrate with the eFSC. It merges the data from the Project Services Availability (PSA) document with the current schedule.
Release (and Deployment) Management■Online documentation (User, Admin, Supervisor, Process owner).
■Context sensitive help.
■Ability to create Release templates dealing with the various systems in use and covering the various identified Release types
■Ability to auto populate, and auto-calculate fields.
■Ability to perform Boolean and logic-based searches, with the capability of narrowing down search results.
■Ability to audit-track and monitor/report against any specified Release attributes (e.g. change in category or type).
■Ability to keep a history of the number of times a Release (or Release task) has been (re-)assigned to another group/person.
■Ability to store Release policy documents into the Release Management system.
■Logging/recording Releases (client/server based).
■Logging/recording Releases (web based).
■Personalised or group access to create, modify and delete Release records.
■Classification of Releases (Based on effort and resources required for implementation).
■Prioritisation of Releases based on urgency.
■Tiered categorisation model (3-tier approach).
■Assigning Releases or Release tasks to other Service Groups.
■Assigning Releases or Release tasks to other Individuals.
■Assigning individual tasks and authorisation levels that (may) lead to build, test, and/or implementation of a Release or part of a Release.
■Assigning Service Levels to Releases (e.g. development times, build times, test times, roll-out times, feedback times, and escalation times). These levels should support any SLAs as set by the organisations and will be aligned with OLAs and UCs.
■Ability to link the Release/s to the Change/s related to it.
■Ability to link multiple approved Changes into one Release.
■Ability to link the Release to a CI or a number of CIs and retrieve information on other CI records related to the CI against which the Release (or related Change/s) has been recorded. This supports efficiency and effectiveness of the Release Management process.
■Ability to change the status of the Release (Release Status) into a required state (e.g. development, build, test, training and communication, roll-out, etc).
■Ability to time-stamp work (resources spent) on Releases (e.g. assessing, building, testing, etc.).
■Automatic functional escalation when certain service target triggers are met.
■Automatic hierarchical escalation when certain service target triggers are met.
■Ability to create workflow rules in the Release Management process flow (e.g. from build, to test, to roll-out approval, to implementation, to post implementation review).
■Automatic feedback request functionality, based on a rule based system. This ensures the Release is seen as successful by the customer before the Release results are transferred back to Change Management.
■Dashboard functionality to visualise and monitor the current workload.
■Reporting functionality that supports monitoring and reporting against any set KPIs.
■Ability to select orphaned records to archive.
■Ability to orphan records so they can be archived.
■Ability to perform integrity checks on the Release Management database.
■Ability to flag Release records for Configuration Management (to create awareness on current Releases for which the CIs may well have to be updated by Configuration Management.
■Integration with Programme and Project Management tools.
■Integration with scheduling tools (e.g. Exchange/Outlook).
■Integration with electronic sign-off technology and encryption to support a secure approval process (within the boundaries of Release Management).
■Ability to perform trend-analysis on Releases.
■Ability to create a Release log that contains all associated Release related documentation.
■Ability for automatic version control of Releases, baselines, and variants.
■Ability to schedule Release related implementation tasks.
■Ability to schedule Release related training.
■Ability to schedule Release related communication and marketing/public relations activities.
■Ability to store various review check-lists against the various Release types.
■Reviewing capability of Release/s against efficiency and effectiveness.
■Use of diagnostic scripts to support the Release Management workflow process (e.g. some visual workflow capability that makes it clear where (how far progressed) the Release is in its own specific lifecycle).
■Online discussion forms to coordinate various Release/s and Release related activities with the ability to track and store all communication.
■The ability to ?release? Releases back to Change Management for further approval or review.
■The ability to ?confirm? Releases as developed.
■The ability to ?confirm? Releases as built.
■The ability to ?confirm? Releases as tested.
■The ability to ?confirm? Changes to Release Releases as implemented.
■Ability to store Release test plans with the Release record.
■Ability to store back out plans with the Release record.
■Ability to store test results with the Release record.
■Ability to store back out results with the Release record.
■Ability to store Release success criteria with the Release record.
■Ability to store the Release success criteria results with the Release record.
■Ability to automatically sign-in and sign-out resources from the DSL (DML).
■Ability to automatically sign-in and sign-out resources from the DHS (definitive spares area).
■Integration with existing procurement policies and systems.
■Integration with existing HR policies and systems.
■Integration with existing OH&S policies and systems.
■Integration with existing Information Security policies and systems.
■Integration with existing Event Management policies and systems.
■Integration with existing Access Management policies and systems.
■Ability to create, modify, and archive/delete delta Release/s.
■Ability to create, modify, and archive/delete full Release/s.
■Ability to create, modify, and archive/delete package Release/s.
■Ability to create, modify, and archive/delete high level roll-out plans.
■Ability to create, modify, and archive/delete detailed roll-out plans.
■Ability to visualise Releases in software- and hardware entity relationships models.
(Service Asset and) Configuration Management■Online documentation (User, Admin, Supervisor, Process owner).
■Context sensitive help.
■Ability to create CI templates dealing with the various systems in use and covering the various CI types (e.g. system, application, module, documentation, etc.).
■Ability to create Baseline templates dealing with the various systems in use and covering the various Baselines in use (e.g. workstation v1, workstation v2, server v1, server v2, etc.).
■Ability to describe information on both a logical and physical level (e.g. workstation, mouse, documentation, etc.).
■Ability to auto populate, and auto-calculate fields.
■Ability to perform Boolean and logic-based searches, with the capability of narrowing down search results (nested searches).
■Ability to audit-track and monitor/report against any specified CI attributes (e.g. change in location or owner).
■Ability to keep a full history of a CI?s status.
■Ability to store Configuration Management related documents into the Configuration Management system.
■Logging/recording CIs (client/server based).
■Logging/recording CIs (web based).
■Personalised or group access to create, modify and delete CI records.
■Classification of CIs (E.g. CI, baseline, variant, etc.).
■Tiered categorisation model (3-tier approach).
■Assigning various levels of ownership to CIs, baselines, and variants using a group based authorisation model.
■Assigning various levels of ownership to CIs, baselines, and variants using an individual based authorisation model.
■Assigning individual tasks and authorisation levels that (may) lead to the addition of, modification of, and deletion of CIs, baselines, and variants.
■Assigning individual tasks and authorisation levels that (may) lead to the addition of, modification of, and deletion of relationships between CIs, baselines, and variants.
■Assigning Service Levels to CIs, baselines, and variants (e.g. when do leases, contracts, or warranty expire). These levels should support any SLAs as set by the organisations and will be aligned with OLAs and UCs.
■Ability to store Service targets in the CMDB.
■Ability to link Service targets to CIs, baselines, and variants.
■Ability to link the CIs to other CIs.
■Ability to link the CIs to Incidents.
■Ability to link the CIs to Problems.
■Ability to link the CIs to Known Errors.
■Ability to link the CIs to Changes.
■Ability to link the CIs to Releases.
■Ability to change the status of the CI (CI Status) into a required state (e.g. ordered, in test, disposed of, etc).
■Ability to date/time-stamp any CIs that require action at a specific date/time (e.g. when maintenance is required, lease needs to be extended, etc.).
■Automatic functional escalation when certain service target triggers are met.
■Automatic hierarchical escalation when certain service target triggers are met.
■Ability to create workflow rules in the Configuration Management process flow (especially when the status of a CI changes).
■Automatic feedback request functionality, based on a rule based system. This ensures the CI is properly updated as requested (typically by Change Management).
■Dashboard functionality to visualise and monitor the current utilisation of the CMDB.
■Reporting functionality that supports monitoring and reporting against any set KPIs.
■Ability to select orphaned records to archive.
■Ability to orphan records so they can be archived.
■Ability to perform integrity checks on the Configuration Management database (CMDB).
■Ability to flag CIs as suspicious ? this should trigger Change Management to take action.
■Integration with Programme and Project Management tools (loosely integrated).
■Integration with scheduling tools (e.g. Exchange/Outlook) (loosely integrated).
■Ability to perform trend-analysis on CIs (the CMDB).
■Ability to automatically populate the CMDB with new CI records.
■Ability to automatically verify the integrity of CIs kept in the CMDB against the ?real? world.
■Ability to schedule verification checks.
■Ability to schedule auditing checks.
■Ability to define CI lifecycles that a CI must go though.
■Online discussion forms to coordinate various Configuration Management related activities with the ability to track and store all communication.
■The ability to ?flag? CIs as ?last verified on date/time?.
■The ability to ?flag? CIs as ?updated based on RFC on date/time?.
■Ability to create unique labels for new CIs.
■Integration with existing procurement policies and systems.
■Integration with existing HR policies and systems.
■Integration with existing OH&S policies and systems.
■Integration with existing information security policies and systems.
■Integration with existing Event Management policies and systems.
■Integration with existing Access Management policis and systems.
■Ability to visualise any relationship models on any type of CIs.

Reviews and Comments


PMP, CAPM, PMI is a registered certification mark of the Project Management Institute, Inc

Copyright © www.techfaq360.com 2016


About US | Contact US | Privacy Policy | Terms and Conditions  | Website disclaimer  | Cancellation and Refund Policy  | Shipping & Delivery Policy