Overview
Background
UniDesk is an ITIL based shared service. It is available using Shibboleth over the web for Higher and Further Education. The service has at its aim to include:
- A Service Desk using TOPdesk software for managing incidents and problems
- Self-service incident logging and knowledge management
- High level Configuration Management and Service Level reporting
- Change and Release Management
UniDesk isn't just for IT. It supports over 50,000 staff and students in all areas of University and College business and academic work.
Our service community with over 1000 practitioners share knowledge through workshops, reviews and training. This has been a very successful vehicle to embed best practice and help provide service excellence.
UniDesk has been developed in partnership by Abertay, Dundee, Edinburgh and St Andrews Universities. St Andrews and Edinburgh have worked together on call management provision for over 10 years. The partnership shares the cost of the service and directs service strategy and development.
Sheffield Hallam has become a user of the service since 2012.
Following the service launch we continued with
- Problem Management ·
- Self Service Portal Deployment (date to be confirmed by Unidesk Board)
- System Upgrade from 4.2 to 5.1
- Change & Release
On completion of these modules the programme team believe that the current process need to be underpinned by an element of Configuration Management (CMDB).
Scope, Objectives and Deliverables
This project will have as its objective the creation of a common CMDB populated by a common data feed, interacting with existing UniDesk processes in the same way for each institution..
This delivers several strategic business objectives :-
- this is the next step towards an integrated service desk solution
- the provisioning of an asset management system which is an aim in itself
- the underpinning of our existing UniDesk processes
Project Deliverables are therefore
- Deliver to the partners and users of Unidesk a common CMDB (MUST)
- Deliver a common CMDB that can accommodate the varying configuration items desired(MUST)
- An agreed, common Configuration Management process (MUST)
- Agreed outputs (reports, views, selections) required by the Configuration Management process (MUST)
- Ensure that any interactions with existing processes will be common (MUST)
- Use only the pre-defined tables and fields with TOPdesk CMDB (SHOULD)
- If additional tables or fields are needed within TOPdesk CMDB, then these will be common to all partners and users although not necessarily used by them all (MUST)
- Create a common intermediate 'Holding Table' (as used for current data population of students and staff) (MUST)
- Create a common feed from the Holding Table to TOPdesk (MUST)
- Specific tables or fields only needed for one institution to be avoided if possible (SHOULD)
- The delivery of data from local systems to the Holding Table is outside the project (WON'T - this is local university responsibility)
- Any load testing or performance testing as/if required (SHOULD)
So ... The provision of data from local university systems to the Holding Table is to be funded locally. If any university wishes to have its own specific fields and tables, then this needs to be developed as a separate and subsequent project, and will need agreement with UniDesk CAB in the future.
Each University may declare the CMDB the golden copy of data, Each university will make the decision whether to import other golden-copy data into TOPdesk.
Also, individual institutions may want to do other work around this project, not funded by UniDesk partners.
Edinburgh, for example might wish to
- Replace or Integrate with the IS Alerts interface and process
- Replace the now aging ‘MIS Change Control System’
This means we keep in scope all common development and eschew any university-specific work and requirements.
Out of Scope
Each University or a division within may declare the CMDB the golden copy of data or elect to keep local systems as the golden copy of Configuration Items, supplying only (some of the) data to Unidesk, or they can have CMDB as the golden copy if they prefer.
The analysis of the configuration items to be held in TOPdesk is part of the project, and the construction of the 'Holding Tables' and import scripts also. However, the physical acquisition of the data from university systems into the Holding Tables is not part of the project (i.e. not funded by partners), and each institution will treat this as local development.
Benefits
CMDB will underpin the Incident, Problem and Change & Release processes.
It will establish UniDesk as a more comprehensive solution to any institutions looking for an integrated Service Management package.
Success Criteria
A CMDB process or set of processes agreed between the UniDesk partners, and within each institution.
| Deliverable | Success |
| Deliver to the partners and users of Unidesk a common CMDB (MUST) | A CMDB of tables and fields that is the same in each university. |
| A common CMDB that can accommodate the varying configuration items desired (MUST) | A CMDB that can be populated as desired by each university, allowing some items to be omitted without causing integrity problems. |
| Any interactions with existing processes will be common (MUST) | The incident, problem and C&R processes for each university interact with CMDB in the same way |
| Use only the pre-defined tables and fields with TOPDESK CMDB (SHOULD) | Ideally, we can satisfy our requirements using the existing tables and fields available in CMDB |
| If additional tables or fields are needed within TOPdesk CMDB, then these will be common to all partners and users although not necessarily used by them all (MUST) | If we identify other tables or fields that we need to hold important data then these will be created for all universities, even if not populated by all. |
| Create a common intermediate 'Holding Table' (as used for current data population of students and staff) (MUST) | All data to be fed into UniDesk must be stored in a temporary table from which data is extracted and pulled into UniDesk DB |
| Create a common feed from the Holding Table to TOPdesk (MUST) | Data is extracted and pulled into UniDesk DB regularly at a (daily) time(s) as required by each university using the same script (to be developed by TOPdesk) |
| Specific tables or fields only needed for one institution are outside the project (WON'T) | We will not consider tables and fields that are specific for one university to be within scope |
| The delivery of data from local systems to the Holding Table is outside the project (WON'T) | Each university will fund its own development for populating the holding tables that feeds CMDB |
Approach
As stated, the project aims to keep data items as close to those already set in the default tables and fields, this being a first phase of CMDB implementation.
We will have a core team that will work on this first iteration, comprised of - for Edinburgh - IS Applications and USD and Networks leading on software and networks - and St Andrews and Abertay.
We shall tackle each of the default configuration groups in turn - software, hardware, networks - working with the core team but bringing in additional business representatives as required for the individual analysis.
The five default objects (tables and fields) with TOpdesk which we hope to use as-is without additional fields or tables are
| Object (table) | typical configuration items | 'most interested' stakeholders |
| Hardware | desktops, laptops, servers, printers | Abertay Edinburgh OCS Group |
| Software | licenses, packages, bespoke apps | Edinburgh Apps Management |
| Networks | St Andrews Edinburgh Networks | |
| Telephones | Edinburgh Networks | |
| Inventory | furniture, stuff |
A sixth default table is Configurations, allowing the grouping of the above objects. However, the use of this is optional and may be superceded by the use of Father-Child relationships within CMDB.
The use of Location Field within UniDesk also needs to be assessed, as this may have to be redefined.
Timeline
These wil be used to set formal intermediate Milestones between now and Delivery once Project Brief is signed-off by partners and WIS give permission for project to proceed.
Project brief for 9th August
Analysis of data items by all partners through August.
Workshop with TOPdesk w/c 2nd September.
Follow Up workshop with TOPdesk first week of October.
Development on Holding Tables and Import scripts, and population of data, October and November.
Deliver first iteration of CMDB late November/early December.
Decision to continue onto a second iteration depending on need and budget by Unidesk Project Board in December.
The following draft timeline is provided by TOPdesk, and we take this as the starting point for the project plan.
Activity nr. | Activity | Details | Output | Planning | People involved |
1 – delivered by TOPdesk | Workshop CMDB | Presentation of TOPdesk
Group discussions | - Explanation of how TOPdesk works.
- Insight in differences between institutes
- Insight in data input | 27-06-2013 | TOPdesk Consultant, all institutes are invited |
2 | Preparation work | Redesign of locations in current TOPdesk installations to support CMDB
Defining report requirements based on the processes (Configuration and Asset Management, Service Catalogue Management, Service Level Management, Availability Management, Capacity Management, Change Management, Release Management, Incident Management)*
Defining the level of detail of each object type | - Insight in asset types to be registered (which hardware, software, telephone systems, network components and other items need to be registered
- Key metrics and properties of assets that are needed for the implementation
- Process KPI and report definitions |
| Process managers of all institutes |
3 – delivered by TOPdesk | Process design | Presentation of preparation work by the institutes
Top down process definition, zooming in to the required level of detail
Defining scope of CMDB registration, process integration
Define rights and authorisations
Define reports and KPI’s
| - Agreement on process design and procedures
- Scope of data registration, mandatory fields, events & actions and process integration
- Agreement on data integration and data import | Two days in September. | TOPdesk Consultant
Process managers of all institutes are invited |
4 – delivered by TOPdesk | Process implementation | Implement blueprint of CMDB process in TOPdesk databases on a high level |
| One day in September | TOPdesk Consultant
TOPdesk application manager(s) |
5 | Data gathering | Collect all data to be imported in TOPdesk and prepare database, CSV, Excel or XML files | - Data sheets |
| All institutes |
6 | Data check | Check CMDB data for consistency and accuracy
Prepare database view
Prepare business logic of data lifecycle | - Data view
- Import definitions
- Field mapping |
| TOPdesk application manager(s)
Database specialists of institutes |
6 – delivered by TOPdesk | Data import and key user training | Create import scripts
Implement scripts and import data
Half a day: Explanation to key user of data import, process application management, metrics and reports | - CMDB data imported (one-off or periodically)
- Key users and process managers are trained in the way TOPdesk is implemented and configured | Two days in October / November | TOPdesk Consultant
TOPdesk application manager(s)
Process managers of institutes |
Estimation
Estimation are for the funded work involved - the local pieces (analysis and any data gathering developments and user training) will need to be estimated and planned and budgeted for separately (around 25 days).
See https://www.projects.ed.ac.uk/project/smi003/estimation-0
Summary
| IS Apps Section | Team | Estimate (Days) |
| Project Services | Project Services | 18.4 |
| Development Services | Development Team | |
| Configuration Team | ||
| Development Technology | 34.8 | |
| Production Management | Applications Management | 14.2 |
| Technology Management | ||
| Service Management | Delivery and Integration | 40.6 |
| Multimedia | ||
| Directors Office | Directors Office | |
| Total Days | 108.0 |