Name of Best Practice / Selection Criteria for Business Information Management tool
File Name / BiSL_BP040
Date modified / dd-mm-yyyy
Description of contents / This document describes the selection cirteria from the perspective of the Business InformationManager and does not address any associated requirements/desires for the ICT organization.The requirements detailed are generic and serve as a point of departure for the tool selected. It omits discussion of specific tools.
Type of document / Example
BiSL Processes / Use management cluster
Comments

ASL Foundation

P.O. Box 9769

3506 GT Utrecht

The Netherlands

T +31(0)30753 1424

F +31(0)30755 1502

I

Selection Criteria for Business Information Management tool
Example
Place / Place
Date / dd/mm/yyyy
Author / Author
Status / Status

Contents

1Introduction

2Definitions

3Functional requirements for incident management

4Functional requirements for change management and
transition management

Reports

Handling incidents

4.1.1For customer organization/client

4.1.2For management

4.1.3Own department/business unit

Change management and transition management

4.1.4Budgeting

4.1.5Lists

General

4.1.6Counts

4.1.7Export/email

5Additional general requirements

Version Management

Version / Date / Author / Description

Distribution List

Version / Date / To

1Introduction

The change & release management field within business information management (BIM) has arisen from the demand to improve interaction between the user organization and the ICT support department.Within BISL, these activities are carried out in the connecting processes (change management and transition management) and the processes within the functionality management cluster.
A typical BI manager can translate user desires and requirements in such a way that the ICT staff can better understand them, and vice versa.

The basic premise is that the BI Manager represents the user organization.They filter the information from the users to ICT, monitor progress, and report back to the users.Preferably, a BI Manager is also someone with experience in the user organization itself.

To ensure that the BI Manager can deliver optimal service to both the user organization and the ICT departments, s/he should have access to a flexible tool to keep track of everything.

This document describes the demand from the perspective of the BI manager and does not address any associated requirements/desires for the ICT organization.

It also omits discussion of specific tools.The requirements detailed are generic and serve as a point of departure for the tool selected.

2Definitions

Change

An incident: regardless of whether it pertains to a modification or a bug and regardless of its origin or nature (functional/technical).

Release

A new delivery of the softwareA release consists of a collection of changes.Therefore, this use of the term ‘release’ differs from how it is used in the distinction between a patch and a release.For the purposes of this document, a release shall mean any delivery, regardless of the conventions agreed to between Business Information Management, Application Management, IT Infrastructure Management, and the software supplier.

3Functional requirements for incident management

Within BISL, incident management is part of End User Support.

The minimum required data to be logged are indicated below:

  • Incident registration
  • Record
  • Contents
  • Priority
  • Key data, such as:
  • Caller
  • Times (call, completion, referral, etc.)
  • Department, system, etc.
  • Action owner
  • Possible cause/solution
  • Status
  • Assign
  • Update history
  • Follow status
  • Report service agreement violations
  • Record and display history (experience database for similar past incidents)

4Functional requirements for change management and transition management

For each entity, a description is provided below of the minimum required data to be registered for a new release, which is managed using the change management process and put into production via the transition management process:

Project
  • Project name
Application
  • Application name
  • Project name
Release
  • Release name
  • Application name
  • Status
  • Scheduled physical delivery date
  • Actual physical delivery date
  • Difference in days between actual and scheduled physical delivery
  • Scheduled date of installation into test environment
  • Actual date of installation into test environment
  • Difference in days between actual and scheduled installation into test environment
  • Scheduled date of installation into production environment
  • Actual date of installation into production environment
  • Difference in days between actual and scheduled installation into production environment
  • Year of scheduled transition into production (in connection with annual
    work-hour budgeting)
  • Available work-hours(programming time made available by supplier)
  • Reserve work-hours (reserve work-hours that are not booked, to be used for quick fixes for bugs)
  • Effective work-hours = available work-hours – reserve work-hours
  • (Optional) checkbox to indicate that all disputes pertaining to work-hours have been resolved
  • Optional attachments, such as:
  • Release Notes
  • Installation Notes
  • Test plan
  • Release recommendation
  • …..
  • A free format field to enter comments
Budget
  • Year of the budget
  • Budget in work-hours
Change Request
  • Unique ID number
  • Caller (the person who debriefed BIM, including department/company)
  • Creator (the BI Manager)
  • Origin (Did the call originate from the production environment, the acceptance environment, or is this not applicable?)
  • Release of origin- the release it pertains to
  • Solution release- the release in which the request will be delivered
  • Reference- Software supplier’s reference
  • Date reported
  • Action by (the person responsible for the next action, including department/company) (This can also be multiple persons/departments.
    So, if applicable, the sequence can be indicated, with comments.)
  • Brief description of the request
  • Detailed description of the request
  • Progress (date, who, description of action)
  • Status
  • Reason (necessity) (Must have, Nice to have, Luxury)
  • Priority (Urgent (for bugs), High, Medium, Low)
  • Type(Modification, Bug)
  • Category (e.g. Reports, Interfaces, Instruments, Static Data, etc.)
  • Work-hours budgeted (cost estimation of the work-hours to be used)
  • Work-hours used (subsequent calculation of the work-hours actually used)
  • Date cancelled/closed
  • Date on which the request was last modified and by whom
  • Options to define hyperlinks (for documents and internet/intranet addresses)

Wherever possible, the fields from the items above should be selected from popup lists when entering a release, incident, etc.The BI Managers are responsible for maintaining these lists.

Reports

In order to provide proper analysis, it must be possible to compose a report flexibly on the basis of the data logged.It must be possible to perform calculations, make selections, and defining sorting sequences.In short, reports must be fully customizable.

Thus, it must be possible to put a specific reporting tool (e.g. Business Objects) on the database of the selected tool.In this case, the BI Manager will in fact expect to have insight into the table structure.But BI Managers do not need to be “IT specialists”, so they are not expected to do any programming (e.g. SQL) themselves.

A number of sample reports that are needed within the framework of Business Information Management are provided below.It should be stated that this is only a sample selection.The BI Manager should be able to compose his/her own reports dynamically, including counts, calculations, grouping, and sorting sequences at multiple levels.

Handling incidents

4.1.1For customer organization/client

  • Lists of unsettled incidents by department/system/system owner
  • Summary of status/content of individual incident
  • Summary with quantitative/qualitative analysis by dept./system/owner (see under heading “reporting function/management”)

4.1.2For management

quantitative/qualitative analysis on the basis of a set format:

  • By system/department
  • number of incidents reported
  • number of incidents handled
  • number of unsettled incidents
  • number of service level violations
  • Total
  • By urgency/category:
  • number reported
  • number handled + average completion time
  • number unsettled + average time unsettled
  • service level agreement violation
  • trends in:
  • amounts/types reported
  • handling time
  • amount of time unsettled
  • violation
  • Where applicable/possible:by type (question/desire/failure/password)
  • number reported
  • number handled
  • number unsettled

4.1.3Own department/business unit

A flexible subcollection of the items indicated above

Change management and transition management

4.1.4Budgeting

Per year

Per year:the budget made available minus estimated costs of unsettled change requests minus actual hours spent on closed change requests = rest of budget for that year.

Per unsettled release

The number of hours available minus the reserve hours minus the total estimate for all hours scheduled for all unsettled incidents for this release = capacity to be allocated.

Per closed release

Each incident with at least the estimated costs, subsequent calculation, and results, both by incident and the totals.

4.1.5Lists

Workload

All incidents for the next release.

Unsettled list

All unsettled incidents for the release selected.

Modification

A summary of all modifications completed for each release, with the following required data: estimated costs, subsequent calculation, results, number, brief description.

General

4.1.6Counts

Age matrix

All unsettled incidents grouped into age ranges (< 30 days, 30-60 days, etc.) based on their date reported.

Older than x days

A list of all incidents older than x days

Updated since x date

A list of all unsettled incidents that have been updated since <fill in date>

4.1.7Export/email

It must be possible to export individual reports to at least XLS and RTF format so that cross-table analyses can be conducted and quality reports can be stored.

There should also be a link with the various mail tools (Lotus Notes, MS Outlook) so that reports can be emailed to people and/or groups immediately.

5Additional general requirements

  • Good search function (by key word)
  • Configurable as desired
  • Wherever possible, entry fields should be selection lists.
  • Multi-user
  • Externally accessible via Internet or dial-up server
  • If applicable, accessible to users as well
  • Cost-effective
  • User-friendly

1/13