Serio Blog

Friday, 22 Jun 2007

When talking about Best Practice and ITIL (The IT Infrastructure Library), there are many key words and phrases that are thrown about. In this blog I have tried to identify just a few of the more common buzzwords and give a brief explanation of my understanding of them. (If you have limited knowledge of ITIL then the ‘Introduction to ITIL’ whitepaper is a must read).

1. Process Definition - Both Service Support and Service Delivery are split into processes. Each process should have a clear objective and is broken down into tasks, each with inputs and outputs.

2. RWO - ‘Real World Object’ is used to describe the inputs and outputs of each task. These can be physical objects such as a piece of paper, or electronic objects like information that is saved in a specified location. Even something intangible, such as a phone call, could be considered as an RWO.

3. Availability Management - This is a Service Delivery process put in place to identify the availability requirements of key IT systems and services, making sure these requirements are met. There is a very good whitepaper on this subject titled ‘Introducing ITIL Availability Management’. One of the key success factors for availability management has to be it’s reliance on having appropriate and meaningful Availability measurement and reporting. The previous blog post ‘Using Serio to obtain Availability Statistics’ also makes interesting reading.

4. Role - each task is performed or executed by a role. The role can be a human or a piece of automated software and should be governed by a set of rules, for example ‘The questions below MUST be answered before proceeding to the next stage’.

5. Process Owner - One person is responsible for the Process Definition, which should be treated the same as a Configuration Item and is subject to Change Control.

6. Service Desk - The Service Desk is a function, not a process and should be the first point of contact between the Customer and the Service, providing advice, guidance and rapid restoration of normal services. It has more functionality than the traditional Help Desk and should be focused on its main objectives, which are to improve and drive forward the service provided. Service Desk and Helpdesk have been discussed in this previous post.

7. Service Culture - Suggests that any organisation embraces the concept of service and customer care. The aim should be to exceed customer expectations, not in what you deliver but in the way you deliver it. Good Service Level Management (SLM) processes can help achieve goals and some good SLM KPI’s (Key Performance Indicators) have been posted here.

8. Call Logging Script - (and form based inputs). These are a series of questions that should be answered for every call and can increase the integrity of the data supplied whilst helping to reduce any duplication in work and ensuring a set uniformity for how data is recorded. Call logging scripts have been discussed previously and there is even a sample script here.

9. Incident Management - The goal of Incident Management is to restore the normal service operation as quickly as possible and minimise any negative impact. Many Incident Management topics have been posted over the course of the Serio blog, starting with an ‘Introduction to Incident Management’ here.

10. Incident Lifecycle - This is simply the steps that are taken when handling an Incident, from the initial reporting and recording (logging), then progressing through all the other required steps such as classification or assignment and ending in closure or resolution. A part of the Incident Lifecycle is its Workflow Position and Status. This has been blogged about previously and is explained in detail here.

11. Accountability - This is the responsibility of an agent, usually the logging agent or primary agent, to accept complete ownership of the Incident. This agent needs to remain in contact with the customer all through the Incident Lifecycle, explaining about any assignments, escalations, status changes and making sure the customer is kept informed right up to a resolution they are happy with.

12. Balanced Scorecard - This is an aid to managing performance by finding a balance between 4 perspectives of your organisations vision/mission and translating it into KPI’s. These perspectives are

1. Customers - What do your customers want and what do they need?
2. Internal Processes - How is value provided?
3. Learning and Growth - How will we provide future value and measure potential future performance.
4. Financial - What were our previous costs.

This is complementary to ITIL and provides information on Customer Perception, Internal Processes and Finances.

13. Configuration Baseline - This is the configuration of a product (Configuration Item) at a specific point in time. This serves as a reference for any further or future activities and should be recorded in the Configuration Management Database (CMDB) which has been covered in detailed posts starting here. []

14. CAB (Change Advisory Board) - A group or body that will assess, prioritise and approve any potential changes. Its members should be capable of ensuring changes are assessed from both business and technical perspectives. Membership and participation is flexible and should be composed to deal with the specific changes that are being dealt with. This board was discussed in a previous topic called ‘To a New Change Manager’.

15. Functional Escalation - This type of escalation takes place when agreed intervals of time are elapsed or because of the lack of expertise / knowledge. Transferring an Incident from 1st line to 2nd line support is a functional escalation.

16. Hierarchical Escalation - This escalation can take place at any time and is usually performed manually when it is likely a resolution will not be achieved satisfactorily or in time. This should allow enough time for any authorised line management to take action before agreed resolution times are breached. Escalations were discussed in the previous blog article ‘Escalation in Incident Management’.

I hope all readers will find this article useful but know the above list barely covers the multitude of keywords and phrases that seem to be thrown around. If anybody would like my understanding of any buzzwords not covered above, leave them as comments and I may use them in a future post.

Wednesday, 20 Jun 2007

This is a follow-on from my earlier posts about the open source report writer Datavision - the installation post is here and the getting started post is here. If you have not read the earlier post you need to do so before continuing.

In the getting started post last week I did some simple grouping, used some simple calculated fields, and added some variable report criteria.

This week I'm going to do something a little more complex, involving data evaluations and counting.

The Target Report

The report I'm going to create will take a start date and end date, and will list for each Serio Team resolving Incidents the number of Incidents resolved, and the percentage of Incidents resolved on time.

Creating the Report

Start by logging-in to Datavision and click Create a new report.

As previously, I'll use the views provided as part of the Serio SDK. Looking at the documentation for the views, I can see that I can get the resolving team from the view sv_issue_resolution.

So, from the Datavision menu, choose Insert...Database Field and from the list provided under All Database Fields, drag pending_team to the detail band, as I've done in Figure 1. P160 Pendiing Team

Figure 1 - Pending Team

Now we need to group by the Team. From the menu, choose Insert...Group and select the column sv_issue_resolution.pending_team. Having created a group, you can add a computed field to count the group. To do this, choose Insert...Special Field and drag a Group Record Count over to the Group #1 Footer band (do this by dragging and dropping).

This gives us a count of records by team. However, now we need to find out how many were resolved on time. I can see by consulting the Serio documentation there is another view called sv_issue_sla that contains SLA data - so I'll add this table to the detail band and perform a join between sv_issue_resolution and sv_issue_sla.

From the Datavision menu, choose Insert...Database field. Add sv_issue_sla.pending_mins_actual and sv_issue_sla.completion_mins_target to the detail band by drag and drop, as I've done in Figure 2. These two columns contain our SLA target and actual SLA achievement. P160 Add SLA fields

Figure 2 - Add SLA fields

To make the join between the two views sv_issue_resolution and sv_issue_sla, which we can do now we've placed database fields from both tables, select Database...Table Linker and link the two views as shown in Figure 3.P160 Linking Tables

Figure 3 - Linking Tables

Now it's time to look at a really cool feature of Datavision - formulas. The formula language is something called Ruby - google for 'ruby script' and you'll find lots of info about it. For me this makes Datavision a serious tool.

Here is how I'm going to use a formula. I've brought in our SLA target and actual SLA timing. If the target time we took is less than or equal to how long we actually took to resolve the Incident, I'm going to return a 1 - if not, I'll return a 0. Then in the footer I'll add-up all the 1's I have, and this will tell me how many Incidents were on time.

It sounds harder than it is. Here is the formula in Ruby:

if {dbo.sv_issue_sla.pending_mins_actual} <=

P160 FormulaTo add the formula, click 'Insert..Formula Field'. Then from the Fields window, choose 'Field...New Formula'. Give the formula name (such as 'On time') and then enter the formula above, as shown in Figure 4. 






Figure 4 - Formula


Having created your formula, drag it to the Detail band.

P160 Aggregate FieldNow we need to add-up all the 1's from our formula. Luckily this is easy in Datavision. First of all, click the 'On time' formula and then, while it's selected, click 'Insert...Aggregate Field' from the Datavision menu. Create a 'Sum' aggregate field as shown in Figure 5. 





Figure 5 - Aggregate Field


This will add-up all the 'on time' resolutions for each team, and give us a grand total at the bottom. I think that's really neat.

We are now almost finished. We need to tell Datavision to only count resolved Incidents, and from the Serio documentation on the views I can see this is what we need:

sv_issue_sla.issue_status in ('p', 'c') and
sv_issue_sla.type_code = 'i'

From within Datavision, select Report...Select Records and enter the SQL above.

Finally, We need to hide the Detail band - we are not interested in it's contents. Right-click on the 'Detail' label, and click 'Supress'. Do a little bit of tidying-up by removing unused headings, and your report definition should look like Figure 6. P160 Final Definition

Figure 6 - Final definition

And you can see the finished report attached (exported to PDF).

Tip: The default font seems to be Time New Roman, which I think is rather ugly. If you click Format...Default Format you can change this however to something more attractive.

Monday, 18 Jun 2007

My post today is all about Knowledge base content, and how you can make a start creating your own.

First of all, I’ll offer a definition in my own words. What is a Knowledge base?

It’s a special kind of database for storing a workgroup's or organisation’s knowledge and expertise. Typically a Knowledge base contains articles that relate to fault fixing, how-to documents, user guides, white papers and so on. There is also usually a retrieval system (often a search engine) and way of classifying and grading content.

Knowledge bases offer all sorts of possibilities. In Incident Management, they offer the possibility of a genuine lift in first time fix rate. They offer new staff a chance to make a bigger contribution more quickly, whilst reducing dependence on a few key engineers.

A knowledge base is bit like motherhood and apple pie – it’s almost impossible not to be in favour of it. So why is it then that so few companies seem to have effective Knowledgebase content in place? I was at a social networking event recently (a breakfast event, more lively and interesting than I expected it to be) and ‘reducing dependence on key technical staff’ was one of the things that came up for discussion.

Knowledge base content was one of the solutions proposed, but only a couple of us there had knowledge base content we were trying to develop. One guy claimed ‘we’ve got a really effective Knowledge base’ to which I asked ‘How do you know it’s effective?’.

I will go on to answer my own question – most likely in a future post. In the meantime, I’ll stick with why it seems so few companies have Knowledge base content of their own.

The answer lies in the content word. Where does the content come from? Who writes it? How can we make sure it is accurate? How can we ensure that, as technology changes and moves on, so does our content? Where does quality come into things? How can I create content when we are all so busy? How can I get any kind of objective measure of the usefulness (or otherwise) of the content?

The bottom line is it’s all about content.

In preparing this article, it became clear that there was almost a ‘hierarchy’ of content. I’ll try to define each (as I’ve seen it used in IT Service Management) and describe some of it’s relative strengths and weaknesses.

Trouble-ticket information

In ITSM, this might be the most commonly-found – because we create it as part of the task of resolving customer Incidents. An Incident might consist of a fault description and (eventually) a resolution, which offers us a knowledge base article as a 'free' by-product.


  • It’s free! (Well, almost).


  • Tends to be focus on problem resolution, but that isn’t the only thing we do – or the only thing we want. We want to things correctly in the first place.
  • Requires engineers to really take the time to explain what they did. The more time-consuming the write-up of resolution, the more likely the engineer is to gloss over something important.

I'll continue this thread in future posts.

[Update by blog admin: follow-up posts are here and here ]

Wednesday, 13 Jun 2007

Another day, another 'Web 2 not working' survey writes Tracey Caldwell.

Did you LinkIn then log out? Did you leave Second Life to get a life? Nothing to say on your blog or wouldn’t know a wiki if you met one in the street? You may not be alone.  Web research company Hitwise has found that the vast majority of people are lurkers, watching and not contributing to Web 2.0 sites.

Web 2.0 is not working, proclaimed news stories all over the web, based on a keynote speech  presented by Bill Tancer analyst at Hitwise on the "State of the Web 2.0: Measuring the Participatory Web”. Hands were thrown up in horror at the Hitwise figures showing only 0.2% of visitors to Flickr actually post pictures and a miserable 0.16% posted videos on YouTube.

Web 2.0 participation is certainly not widespread in business where hierarchical company structures and competitive career structures work against the Web 2.0 ideals of knowledge sharing and communal advances.

Web 2.0 for the business is unimaginatively dubbed Enterprise 2.0, a terminology that has the effect of making a global interactive networking phenomena sound like a rather dull CMS bundle. Given its uninspiring moniker it comes as no surprise that Enterprise 2.0 too seems to have stumbled at the starting gate.

BBC technology correspondent Rory Cellan Jones carried out an amusing personal study of the potential for Web 2.0 in his working life and concluded that at forty something he is too old to Twitter and too mature for Myspace.

A study that seems only slightly more scientific in that it included more than one respondent was conducted by NetBenefit. The hosting provider claimed its survey “Explodes the myth of poor take-up of web 2.0”. The write up of the poll breathlessly revealed that 60% of respondents are actively using web 2.0 technologies: “Despite recent criticism that Web 2.0 is all marketing spin people feel there is real substance to the new technologies being deployed such as blogs, Ajax and mash-ups with 69% of companies disagreeing that Web 2.0 is just hype”.

Turns out the survey was carried out amongst delegates at Internet World with an undisclosed number and type of respondent. The results also revealed the unastonishing revelation that Web 2.0 is seen as a natural progression in the usage of Internet technology “with 83% agreeing that it is an online 'evolution' rather than a radical step change in the way we use the World Wide Web”.

All this “Web 2.0 is not working” stuff does seem to be based on the slightly dodgy premise that minority participation is a problem though. In most sectors of society, a minority are the participants or the creators, from music, to software development, to R&D in industry. Tom Loosemore at the BBC is a Web 2.0 maven; tap into his blog for how Web 2. 0 can work in business.

Or Connected Internet has produced a nice, very short summary of what social Web 2.0 can contribute to business.

Monday, 11 Jun 2007

Customer Steve asks: ‘I know it’s a basic question, but could you write something about Incidents and Changes, this is now my responsibility and we have Changes logged as Incidents. Are there any advantages of doing it this way? Also, what about SLA target times with Changes?’ Time for a few definitions first. An Incident…

is something that is not part of the standard operation of a service we provide and that may cause disruption to that service, or cause it’s operation to be degraded.

Whilst a Change is…

something we (an amendment to a service we deliver to users) resulting from Incidents or Problems, or something we do simply to deliver business benefits or efficiency savings.

Steve asks if there are any benefits of logging Incidents as Changes? To be honest, I can’t think of any, and I’d probably go further and say it’s simply the wrong approach. If this were my Service Desk I’d want a clear division between the two – a list that was comprised solely of Incidents (as defined above) and a list solely of Changes (linked as appropriate to both Incidents and Problems). I’d then have a distinct management process to deal with both.

Applying SLA timings (for instance, target completion) to Changes in just the same way as Incidents seems to be an instinctive response by many people - just because it's an obvious and easily understood statistic. My advice is to stop and pause for a second and ask yourself why you’d want to do that. Do you have an agreement with customers that requires this, or is this something you want to impose yourself?

Whilst it could be OK to handle routine and predictable Changes this way, it might be that imposing fixed, rule-based resolution targets to Changes that can be both large in scale and ‘one-offs’ serves no useful purpose. If you are concerned that without targets the Changes will ‘sit’ and go nowhere, make sure progressing them is part of what your Change Management process is concerned with, and what your Change Manager reviews as part of his set of Key Performance Indicators.

Coming back to Incidents v Changes Steve gives an example. ‘We want to sell to a foreign country, but don’t have VAT data for that country in the sales system, so when someone wanted to process an order it raised an error (no VAT data). Is that an Incident?’

Here’s how I would handle this. Log the Incident and record the details carefully. Analysis reveals the system lacks some data it needs, and I would then raise a Change linking the two, giving the Change reference number to the customer. I’d then close the original Incident, but schedule a reasonably urgent delivery date for the Change, which presumably involves finding out about VAT in our target country.

An alternative approach would be to keep the original Incident open until the Change completes and resolves the Incident for us – I think either approach will work, it’s just a question of preferences.

Wednesday, 06 Jun 2007

This is the second post showing you how to create custom reports using Datavision, a simple open source database report writer. The earlier post is here.

Logging in to Datavision

If you've got this far, you've correctly installed Datavision. If it's not correctly installed go back to my earlier post.

Launch Datavision by running the file datavision.bat, and then at the first dialog click 'Start New Report'. You'll then be asked for login details. Here's what you need: 

Loggin1. Driver class name. Use this: net.sourceforge.jtds.jdbc.Driver

2. Connection info. This is a little bit complex. Take a look at this string:


Where it says server_name, replace this with the name or IP address of the machine that runs your SQL Server database.

Where it shows db_name, replace this with the name of your Serio database.

Your database administrator will know both of these items of information.

Figure 1 - Logging in

3. Database name. Re-enter the database name from 2 above.

4. Username. This is your database user that will be used to connect to the server. Remember you don't need to use 'sa' - just create a user with read-only access. It may be you need 'mixed' access on your SQL Server system.

5. Password. Your database password.

Now try to connect. If you fail, go back over the previous post and then this post and double-check everything. There is also a mailing list for support with Datavision. Posting to the list might be worth a shot if you get stuck, or post a comment on this blog.

Creating a report

If you've got this far you are ready to create a report.

I'm going to start with a very simple report definition. I want:

A report that lists Incidents logged broken down by logging team. The report will take a date range, which we will use with the date of logging to select our Incidents. At the end of the report should be a total.

I'm going to do this 2 ways - one using the views you get with the Serio Developer Kit (SDK) for Crystal, and I'm then going to repeat the exercise as if you didn't have the SDK using the tables that exist in every Serio system. The second example will come later.

fields list

I've described the report I want above. You can see the finished report attached. This is how it's done. You can save your work at any time using

1. From the Insert menu, select 'Insert Database Field'. You will then see the Fields browser, and from this expand all database fields (see Figure 2). Select sv_issue_assignment, expand this, and add the field 'logging_team'. You can find out what sv_issue_assignment contains in the SDK documentation. Add the field to the detail band (as shown in Figure 3).





Figure 2 - Database Fields Fields Logging Team Added


Figure 3 - Fields logging with team added


2. Now click 'Insert...Group' and add a new group. We need to do this because we want to have Incidents logged grouped by Team.

Select the field dbo.sv_issue_assignment.logging_team from the list and create a group. You can see how it looks in Figure 4.Group Added

Figure 4 - Group added

3. Now click 'Insert...Special Field'. Drag a 'Group record count' over to the section of the report marked 'Group #1 Footer'. Now add another Group record count to the bottom of the report, in the band labeled 'Report footer' as shown in Figure 5.With Footers

Figure 5 - With footers

4. Now we need to hide the 'detail' band. If you run the report now (select 'Report...Run' from the menu) then you'll see why - it lists the team many times. Hiding the detail is easy - right click where it says detail, select 'Suppress' and then click 'Always hide'. The detail band will be hidden, and displayed as grayed-out.

Type Code Selection5. Now we have to turn our attention to data. The view sv_issue_asignment contains both Incident, Problem and Change data. By examining the documentation in the SDK, I can see that Incident records are denoted in this view with an 'i' in the column called type_code. I need to add a filter, and to do that I select 'Report..Select records' and enter the following line, as shown in Figure 6.


type_code = 'i' 


Figure 6 - Type Code Selection 

6. Finally, we need to add our date range criteria. To do this, select 'Insert...Parameter field' from the main menu. You'll see a floating window called 'Fields' appear. From the menu on this window, choose 'New Parameter...'. Call the parameter 'start_date', and you'll be taken to the Parameter definition window. Complete the data.

7. Repeat step six, except creating an End Date parameter (ie, just change the word start to end) so you now have two parameters.

Final Criteria8. Finally, we need to use these parameters when we select Incidents. To do this, from the main menu, and click 'Report...Select Records'. 

Looking at the SDK documentation, I see that sv_issue_assignment has a column that stores the date logged, called 'issue_logging_date_time'. Therefore we can add an extra filter here, as follows:




Figure 7 - Final criteria

issue_logging_date_time >= {?start_date} and

issue_logging_date_time <= {?end_date}

so that our selection filter reads as follows

type_code = 'i' and

issue_logging_date_time >= {?start_date} and

issue_logging_date_time <= {?end_date}

as we can see in Figure 7. 

Just to recap, we have a filter for Incidents, and want to only count Incidents logged between two dates.

9. By right clicking on fields on the report, you'll find you can change fonts, alignment, styles and so on, and make the report quite tidy. Datavision also has some nice options for exporting reports - one of which is pdf. Again, you can find the report attached.

Now have fun creating your own reports!

[Edit by admin: A more advanced Datavision example is here ]


Monday, 04 Jun 2007

A customer asks for help in recruiting a Service Delivery Manager. Essentially what they seem to be looking for is someone to act as a catalyst for IT service management in their company – someone to get the process started, drive improvements, mould the team.

So how do you go about recruiting successfully? Our customer wonders what you’d write, how you define the job, how do you advertise?

Firstly, some credit must go to our customer for stopping and thinking about this – it’s pretty easy to run straight to the first recruitment agency you come across. Here are some things I’d do in a similar situation.

1. Ask around. In my time as a manager recruiting, some of the decisions I’ve made have worked out well, and others not so well – an experience I share with other managers. My conclusion is that some incompetent people are good at interviews, whilst some very able people are quite poor.

To relate a true story, someone I forged a good working relationship with (I’ll call him Peter), and whom I came to look upon as extremely able, was rejected by me at interview. Peter seemed overly nervous and out of ideas. A week or so later, my boss said with a shrug ‘I’m surprised you didn’t want Peter. Why was that? I worked with him at …. and he’s pretty good, I wouldn’t have given you tuppence for the rest of them. Your decision though’.

I brought Peter back for a second interview, eventually offered him a job, and never regretted the decision, as he brought a detailed and methodical approach to the role (teaching me a lot into the bargain as well).

To come back to the point, a personal recommendation counts for a lot – provided that you know and respect the person giving the recommendation.

2. In terms of describing the job, our customer suggests basing it on ITIL, as in ‘help us create a better service desk using ITIL best practices’.

I’d take a different approach. Our customer is looking for someone to act as a ‘catalyst in IT service management, to drive through improvements, and to bring practical experience which the Service Desk currently lacks’.

Why not ask for that? It sounds like a perfectly good description to me. If the people you interview mention ITIL without being prompted then great! If they don’t you still might find someone with the experience and drive that you need.

My advice is adopt an outward-looking description. Focus on what you want to deliver to the business – for example, understanding of costs, predictability of service, greater availability, reduced downtime costs – and ask for someone to help you achieve that.

3. Research your salary offering carefully. This is where your selection of recruitment firm is key – they should be able to help you in this regard. I’d avoid placing something like this with lots of agencies – pick a single, reliable firm.

4. Try to define the scope of the role. Will the person have responsibilities for just the Service Desk? What about the specialist Incident Management Teams? Who will the new manager report to? What will their peer group be?

Generally speaking, my take is that ideally your Service Delivery Manager will report to the board directly. Whatever you decide, I’d want it lead out clearly so potential candidates can read it, and be prepared for some people to request changes before they accept the post.

5. People lie on their CVs. Hard to believe I know, but it does happen – quite a lot in my experience.

There are a number of approaches you can take – checking references carefully is an obvious one. Most importantly though, read the CV carefully and discuss the things on it. For example, if someone says ‘reorganised the service delivery teams’ ask why, what problems was the candidate trying to solve, did it work as well as expected? Look for signs that the candidate is comfortable and able to discuss this with you. If they say that they ‘prepared management reports’, ask who the reports were for, try to find out how they guided decision making. There are also some more general questions you can use in this post.

6. Consider using a contractor to help you.

There are a few pitfalls with this approach, which I’ll describe in a moment. The basic idea is you hire a contractor with a proven track record in IT service management, give them a two month contract, and then ask them to help you with the recruitment. The advantage is you get some added expertise when you need it.

The disadvantage is that it can be tough to recruit a decent contractor, although references are usually easier to check and a decent contractor will often be working for the same companies over and over again. Another disadvantage is that your contractor may try to fill the vacant role, but this can usually be avoided with a decent brief.

In our customer’s case, they have a ‘sister’ company which would be a good resource to use for this exercise.

(Many thanks to AndyW for his input to this post) 

Thursday, 31 May 2007

'Perhaps you would like to spend as yet undisclosed wad of dollars on a device that allows you to finger paint?' asks Tracey Caldwell.

Collaborative working the old fashioned way involved getting people round a table to thrash out the latest strategy or issue. While Web 2.0 has attempted to take that online Microsoft has decided that the key factor in the collaborative mix is the table. Its Surface Computer does put the average coffee table to shame with a 30in touchscreen embedded but it is unclear what the benefits will be above and beyond the usual touchscreen kiosk.

It will be some time before Surface is widely available. In the meantime it is educational to look at the progress of alternative input devices. The Surface is deemed a natural user interface and is joined in that category by other technologies from voice recognition to more futuristic eye gaze tracking.

So how is the Surface more than just another touchscreen kiosk? A desk or a wall can be transformed with the 30in Surface computer; there is no need for a discrete kiosk, but current touchscreen technology can be embedded in various environments so no apparent change there. HP’s coffee table PC Misto would seem to tick this box. More groundbreakingly it responds to multiple touches on different parts of the screen, not just one input.

Users can draw directly on to the screen with their fingers, resize and interact with photos and videos, creating images together. Surface can recognise objects that have been barcoded and create on-screen versions or transfer digital content from them.

Just as you start to picture the benefits of the technology – a hotshot group of designers working on a new ad together perhaps, Microsoft is on hand to suggest a variety of potential application scenarios - but many of them seem less than compelling. Its press release proclaims, “Imagine creating and sending a personal postcard of vacation pictures instantly to friends and family, while still wearing flip-flops”. Or perhaps you would like to spend as yet undisclosed wad of dollars on a device that allows you to finger paint, another suggestion? Or perhaps order wine in a restaurant and, it is suggested, heaven help us, even splitting the bill.

The Surface contains a short range projector and five cameras to pick up touch movements. It has been five years in the making according to some reports and the technology has certainly been around for a while. User interface watchers would point to technology demoed by Jeff Han last August on Youtube.

Tuesday, 29 May 2007

We are going to be running a series of posts featuring how to write your own reports, in a' tutorial by instalments' form.

The good news we are trying to do this with free tools – so you can follow the posts even if you can’t stretch your budget to a report writer. If you want to follow this posts and create the reports as they are created in the blog, you will need to download the software from the links I’ve given below.

You will also need the Serio Development Kit for Crystal at some point. Don’t be put off by the name – it’s useful for any SQL-based report writer. This is also free, but you are required to sign a non-disclosure agreement. Before contacting your support representative to get a copy, please check you don’t already have it in your company.

The target audience for these posts is the more technically minded – getting some of the free tools working can be a bit tricky. I managed it in about 90 minutes (including the problems I had with about 5 different versions of Java on my machine), and I’ve tried to include a bit of troubleshooting below.

Important: Please don’t contact Serio support for problems with the open source reporting tools, as these are not Serio tools. I’ll try to anticipate any issues in the blog, but if something unexpected comes up use the blog comment features and I’ll try to help that way, where everyone can read the comments.

My advice is this: if you are going to follow these posts and create the reports at the same time, try to choose a machine that does not have Java installed yet – particularly the Microsoft Java Machine (JVM). For me, this was the biggest install problem I had (removing Microsoft JVM).

I’m going to be using Microsoft SQL Server as the target database platform, as it’s the most widely used DB platform. You can use Oracle, though you’ll need to use the Oracle JDBC drivers.

OK, here’s what you need. Remember these posts are for more technically-minded users.

1. Download Java and install it. The latest version link is below or google for ‘java runtime’.

2. Download the open-source report writer. We’ve chosen Datavision simply because it’s the easiest to install (you can download the software here). If you know of better ones let me know. It seems to be the simplest, but requires you to know something of SQL.

3. Install Datavision. There is no install as such, simply unpack the files. If you are not familiar with tar or gz google for it - there are lots of free tools.

4. Download the JDBC driver. Use the link below.

Unpack these files and put them somewhere safe.

5. Within the JDBC driver software, locate the file called ‘jtds-1.2.jar’. Copy it to the Datavision directory called /lib (which will have been created in step 3).

6. Datavision is started by running a BAT file on Windows platforms called Datavision.BAT. Locate this file, and edit it by adding the following on to the end of the first line – no spaces, no CR – just add it straight to the end.


Now try running Datavision (i.e., run ‘datavision.bat’).

Troubleshooting If you get an error message telling you that you’ve got the wrong Java version, you’ve got a bit of work to do. I had this problem as well, and resolved it by removing the Microsoft Java Virtual Machine (this link shows you how).

If you run a command shell (CMD) and type ‘java –version’ you can see the Java version you are running. You want that to say something like If you still get Java version errors, search your hard disc for ‘java.exe’. I had about 10 copies, and renaming each one except the one from Sun as Java.exe.old finally fixed the problem.

You know you are home and dry when you see the Datavision login page. I’ll describe how to log-in in the next post I write.

[Update by blog admin: the next post in the series is here]

Friday, 25 May 2007

I’m asked to write this blog post for someone who has recently stepped into a new Incident Manager role. In order to help someone get started, what kind of things do Incident Managers do?

Ideally of course you’ll have worked for an effective Incident Manager yourself, in an effectively-managed IT service management operation. If not, and particularly you are promoted unexpectedly, it can be a bit daunting.

First of all, go right back to the start. Incident Managers ultimately are responsible for the Incident Management process, the goals of which can be read here. If you then expand this to include the Incident Life Cycle, you get more clues.

My brief for this blog is to focus on detail and practicalities. So what I’d do is try to give a flavour of some of the things you’d expect to do with the emphasis on practicalities. It’s not exhaustive, but I hope it will give you an idea.

1. Ownership of the Incident Management Process.

If you are an Incident Manager, you will try to describe how your Incident-handling team work with Incidents, with each other, and what you expect of them. The best Incident Managers I’ve been lucky enough to work with have been clever enough to produce easily readable, useable documents. These documents describe such things as how to escalate an Incident, how to handle Major Incidents, who has responsibility for Incidents where in the cycle, it defines some roles and assigns specific people to roles... hopefully you get the idea.

What you are trying to define is ‘how can we guarantee that, when an Incident is logged, we’ll deal with it professionally and to the customer’s satisfaction?’.

But here’s where the effective Incident Managers are marked out from the also-rans. The effective ones take the time to explain the process to the Incident team – in effect to ‘sell’ it to them. They don’t just send an email saying ‘dear all, this is what I want you to do, I’m off for a round of golf’. Instead, they hold presentations, meetings – anything that will get the message across.

2. Making Sure the Incident Management Process is followed.

It’s something I see all to often. Someone has written some guidelines, or an Incident document, emailed it to staff, and that’s the last anyone sees of it. The document (ie, the Incident Management Process) is disregarded and ignored.

The effective Incident Managers act as policemen.

For example,

If they ask for resolution information for each Incident to be complete an accurate (so as to be of use later for Knowledgebase searching) then they try to ensure that that:

a: There is some checking of this in the Incident Management process itself.

b. From time to time they examine Incident records themselves. For instance, if they are a Serio user they might look at the Incidents resolved in the past week and examine the resolution information themselves, re-opening Incidents that don’t cut the mustard (and possibly tweaking the IM process itself).

Effective Incident Managers realise that alerts and information generated by an ITSM tool are all well and good, but that many staff may ignore these at first (in fact, you set-up your tool to generate lots of alerts and notifications this is absolutely going to happen), so they look for signs of people not using their tool effectively. There are lots of subtle ways this kind of thing can be addressed, starting with ‘a quiet word’ and a little extra training.

3. Asking ‘is the Incident Management process effective’.

This is not the same thing as point 2. For the most part, the Incident Manager will use a wide range of statistics for this, and will adjust the Incident process as required. Examples of KPIs can be found here for Incidents and here for Problems, and also see our white paper. Please note, as I’ve described countless times before this does not mean simply pulling a few metrics from your ITSM tool and giving them to your boss (if an Incident Manager had done that to me, I would have given them straight back). It means the Incident Manager sitting down and deciding what data they will examine, drawing conclusions, and making recommendations for improvement.

4. Managing the work and workloads of the Incident Management teams.

What this means is this: from time to time bottlenecks appear. For instance, you might get a situation where 100 Incidents are with your one-man networks team, and virtually no Incidents being handled by others.

Incident Managers keep abreast of these kinds of issues, and take corrective or remedial action as required. For example, by re-assigning work, hiring contract staff, re-scheduling non-urgent tasks. For Serio users, this is as simple as using the Assignment and Ownership performance charts effectively.

For many Serio users, the Incident Manager is actually the supervisor for the front-line Service Desk/Helpdesk team, an arrangement that usually works very well.

As a finish, I’d recommend that our new Incident Manager pick up a copy of ‘Best Practice for Service Support’. It’s a great source of information, and you can get it from