Serio Blog

Friday, 29 Jun 2007

Tracey Caldwell asks if the time has finally come for videoconferencing in business, at least in Australia and New Zealand.

Now that we are all Green and just as importantly have to be seen to be Green, the days of executives making long journeys in fuel hungry cars or worse still aeroplanes to attend meetings should be disappearing, replaced by virtual meetings.

Videoconferencing suffered from a bad press for years. It was complex to set up and use and rarely replicated a true meeting experience with jerky images and delayed voice. The video conferencing vendors would have us believe that with today’s software and broadband speeds, all that is a thing of the past. So why is it not used very much?

Or should that be why is it not used much in business? Anyone under 16 videoconferences routinely. Of course the videoconferencing offered by MSN and Bebo is one on one. Desktop and boardroom videoconferencing are two different animals and the real challenge is replicating a meeting among several people, being able to view all or one of them, handling interruptions, being able to kick Maria from accounts under the table before she falls asleep.

In South East Asia, Australia and New Zealand, where distances between business centres dwarf those in the UK or Europe, analysts found the uptake of videoconferencing increased significantly in the last year, partly due to the falling costs of equipment. Lots of new vendors especially telephony vendors and software vendors augur well for the growth of this market, they say.

The buzz for this year Down Under is around telepresence, expensive systems which aim to give workers that in the room meeting experience, all bar the biscuits. Unified communication, linking video and audio conferencing with web conferencing and instant messaging are also high on the agenda.

China is leading the market, according to Raidah and Frost & Sullivan, accounting for 44.5 per cent of total Asia-Pacific videoconferencing revenues. The ability to link several provinces across the country has taken this market by storm according to the analysts with players like Huawei and ZTE aiming to move into other Asian countries.

Vodafone, along with other comms companies, knows it should be taking a lead on greener meetings. It has announced it now requires that the alternative of using videoconferencing is considered before travel is approved. There were “air hostesses” at the recent launch of its videoconferencing initiative and a number of posters suggesting “Spend more time with your family”, presumably what cabin crew will be doing once the corporate muscle of Vodafone is flexed.

Google has caught the wave, buying up the flagship software product of video-conferencing start-up Marratech, leading people to believe that conferencing software may become the next addition to Google's office suite.

Google says it is excited about acquiring Marratech’s video conferencing software, which it says “will enable from-the-desktop participation for Googlers in video conference meetings wherever there’s an Internet connection”. I am loving the calendar, not so keen on the spreadsheet. It will be interesting to see what Google makes of videoconferencing as a desktop app.

A report from Cisco, vendor of the £150,000 plus per site Telepresence videoconferencing kit points out that the uptake of videoconferencing is not all about the technology.

Cisco-commissioned report “The Psychology of Effective Business Communications in Geographically Dispersed Teams”, points out that although richer media such as video conferencing helps build teams, it still takes two weeks longer building relationships through videoconferencing than through F2F (face to face, great acronym).

The report recommends using videoconferencing at the beginning of a project, reverting to instant messaging when everyone knows each other. With videoconferencing sounding a bit like a very expensive curry night it is hard to believe that the time is very ripe for this technology. Please see the attached Cisco-comissioned report.

Thursday, 28 Jun 2007

In this post, I’m going to continue talking about Knowledge base content – I started this thread here, and added a diversion thread here.

I’m going to write about content you write or create yourself, which is about many of the specific things you have to do, and some of the issues that arise when trying to create content of this kind. I’ll refer to this as enterprise content – as it’s (usually) unique to a given company or organisation.

Getting Started

The first thing you need to do is decide who the consumers of your enterprise content are, because this will influence the nature of the content, it’s presentation, and it’s availability. I usually ask clients I’m working with to write down a single paragraph about each type of consumer, covering the expected level of expertise, and examples of the information they may be looking for. This then goes on to become part of the editor’s brief (more of which in later posts).

Grouping the content

Next what you should do is to stream or classify the content you wish to create. Unless you plan on having just a handful of documents, it is worth avoiding a ‘skip’ or ‘dumpster’ mentality where lots of unrelated content is thrown in together. Organising your content correctly at the start means your knowledge base can ‘scale’ correctly over time.

There are lots of ways to do this.

By document type. Examples might be:

  • Fault resolution: Documents that tell people how to resolve common faults.
  • How-to documents: These tell people how to perform common tasks that are not faults per-se, such as how to apply a service pack, deploy a ghosted workstation, order a new computer.
  • Bugs: A place where bugs or known errors and workarounds are listed

By subject matter. Examples might be:

  • Documents relating to operating system software
  • Documents relating to desktop software
  • Documents relating to hardware configuration

Which works best for you will depend on what type of company you are. If you make and sell specific hardware or software product, it might make sense to organise your content by product. If you are involved is more general IT support, it might make more sense to group by content type. Make sure the grouping will be understood easily by your consumers.

Serio refers to groupings of content like this as a Catalog. Unless you plan to have many thousands of documents, keep the number of Catalogs to as small a number as possible, particularly at the start. Too many does not help consumers, it confuses them.

Design Some Example Content

So far, we’ve got a picture of our consumer, and we’ve applied a simple organisation to our content. Now you need to write some example documents – not many, 3 or 4 in each Catalog should be fine. Here you’ll define the layout and, by example, the tone and style of the documents you’d like to see.

I’ll post next week on how to design a ‘good’ document (a totally subjective opinion I know) and how to create a quality system. I’ll also post some info on how you can ‘optimise’ documents for the indexing service that Serio uses.

Monday, 25 Jun 2007

This is a follow-up and continuation of last weeks Knowledge base Content post. In writing this post it veered some way from my chosen topic, hence it’s posted under Technology, but it’s something I think it’s worth writing about – combining both local and specific internet search results in a single relevance-based list.

Third-party content

Third-party content is often taken directly from, or derived from, trouble-ticket data (I discussed trouble-ticket [Incident] data last week). I’m describing it here because it’s a type of content you don’t control. Typically hardware and software vendors publish this kind of content for the benefit of their customers. Sometimes the content is free, other times it's restricted and paid for (The Serio knowledge base is found here).

Third-party content presents some interesting challenges, the most important of which is integration when the content exists on an Internet website. I’m going to discuss these challenges here, as this is something I’ve been asked about before.

In an ideal world you’d set-up your own knowledge base, and simply ‘add-in’ third-party knowledge base sources – so that when you do a search, you can search at the same time:

your local content (your own trouble-ticket data and documents),
the knowledge base directory at vendor A,
the knowledge base directory at vendor B and so on.. 

and have a single, consolidated results list based on relevance.

It sounds great, but is very difficult (impossible?) to implement at this time. In a nutshell, if the content exists on another site you can either:

  • Spider the content yourself, like a search engine does. However, webmasters have a habit of banning spiders they don’t recognise or which operate without permission on their websites, so as to conserve bandwidth for real users
  • Ask the remote website to query it’s own content for you – but this presents problems when constructing a single results list based on relevance because your own knowledge base software cannot see the actual document (ie, does a remote document rank above or below a local, private document).

So, like I said, it’s technically demanding – even leaving aside the ‘terms of service’ issues that arise when using the content of another ogranisation.

Tip: If you are a Serio user, there is something you can do – add your best external knowledge base sources to your ‘Useful Links’ chapter (see ‘Useful Links’ in the HowTo guide for more information).

Probably the best hope for solving the problem I’m describing lies with major search engines such as Yahoo! and Google. What they need to do is allow searchers to set-up customised pages that restrict the searching to particular points within sites (where the KB content is specifically, not just a particular URL) and let the search engine perform consolidated search for you based on your choices.

However, for this to solve the problem search engines would need to see your own local (trouble ticket) content, and would need to understand this is private and not to be served to other searchers. The search engines could either fund this by a fee, or by advertising as now.

I'll come back to the 'proper' thread of these posts later in the week.

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)