According to the economical gurus, the world is coming out of the recession. After a year of cutting costs, doing more with less and outsourcing IT services, what should be the best strategy for IT executives moving forward?
Obviously, the reckless pattern of costs savings has lead to huge gaps in IT processes. Especially the maintenance of IT applications has been hit hard during the recession. In the last 9-12 months almost all companies have reduced the contracts with consultants dramatically, IT services have been outsourced and support and maintenance contracts not renewed. On top of that, internal IT resources have been cut back or reorganizations have taken people away from maintenance projects. But also new, innovative IT projects have been postponed. I’m pretty sure everyone can think of one project this year that was already approved but never executed or was killed during implementation.
However, since our gurus allows us to see some light at the end of the tunnel (which could easily be a train coming towards you from the other site of the tunnel!), what should be the recommendations for IT executives?
Allow me to come with some suggestions:
Fill out the gaps of your IT processes by implementing new processes, new application to support the processes and by hiring resources in critical spots
Gain competitive advantage by updating your website with new features such as: news feeds, newsletters, event calendars, case studies, photo galleries, customer support features, product catalogs, blogs, social networking capabilities, and SEO improvements.
Invest in the future by hiring young, talented people and by training the employees that kept your business running for the last 12 months.
I can’t help myself for writing a more marketing/salesy kind of blog today. The reason is that I’m constantly looking for that golden egg that explains the uniqueness of Westbury SMI Suite. One of the answers is: Westbury SMI Suite solved all the data warehouse issues for HP Service Manager/Center of maintaining the environment.
Let me give you an example.
One of our customers has developed a complete data warehouse solution specifically for HP Service Management. With this solution they solved all the nasty database / data model issues of Service Manager and even made the data warehouse relational. However, they are still interested in Westbury’s SMI suite.
Why?
Because maintaining this ever changing data warehouse environment is extremely expensive for them. Individual experts like database engineers (to modify the database), BI developers (to modify the Universes or Cubes) and ETL specialists to modify and develop the ETL layer are all required for making Service Manager fields/objects available for reporting.
With Westbury SMI foundation, reports are created from data stored in the dedicated SMI Database, whose structure is fixed. This enables Westbury to offer a standardized reporting environment, regardless of the (changing) structure of the back-end HP ServiceCenter software / HP Service Manager software database. SMI Foundation has been created in such a way that administrators can maintain the solution through a GUI, hence there is no need for any programming.
Again, I apologize for being so salesy in this blog, but it is so important for me to make sure that people understand the uniqueness of our solution. If Service Center and Service Manager customer really grasp our architecture, they will see that there is no solution like it available in the market.
Well, we have a new video available for you all to view, called SMI Suite: Behind The Scenes. It’s been a labor of love, involving a multi-million dollar budget, a crew of hundreds, a shoot lasting over six months and directorial tantrums left, right and center. Alternatively, it was done with a green screen and many many hours of painstaking post production. Not to ruin the illusion or anything.
The video is all about architecture, and as a companion piece to the video I wanted to write a blog entry about the same topic, just so the messages from the video are clear. After all, you might find it hard to focus on what I’m saying when you’re confronted with my boyish good looks in all their glory…
Sometimes we find it a little difficult to sum up neatly just how clever SMI Suite is, but we often find that when we get the chance to talk to experienced ITSM professionals in depth – and explain what’s going on behind the scenes, both with SM7 and with SMI Suite, that we almost always get a ‘gasp moment’ from whomever it is we’re talking to. It’s that moment when something suddenly makes sense and it usually falls into one of two camps. Either the person we’re talking to has just spent a month trying to understand why reporting from SM7 is so difficult, or they know precisely why reporting is so difficult, but were convinced that there was no possible solution. Remember the first time someone showed you the Rubik’s Cube? You probably thought that either there was no way a stupid toy could out-fox you, or you took one look and declared that even the greatest minds of our time could never crack such an intellectual nut. If I was going to stretch the analogy any further, I would tell you that SMI Suite is David Singmaster.
So we wanted to take some time to explain in some depth the key concepts around the architecture of SM7 and what SMI Suite does to solve the issues that the architecture raises.
First up is the simple fact that where Service Desk used a fixed, relational database to store its data, Service Manager uses a flat database structure. One of the upshots, from a reporting point of view, is the changeability of field names. So, say you have a field in Service Desk called “Priority”, the corresponding field in the SD database might be called “Priority”, or “Prty”, or “isd3y7j23hh2″ or whatever, but that back-end name would not change once it was set. Not so in Service Manager – everything is subject to change, even after initial setup. So if you were writing a SQL query to call that data, you would need to reference the field name, which might have changed since last month or last week or two minutes ago, and might change again in two minutes time. Also there’s a key difference in the way custom fields are handled – in SD they were custom only in the front end, so no matter how you renamed them in SD, the back-end fields were still called “CustomField1″, “CustomField2″, and so on. In SM7 custom names can be applied to the back-end as well.
SM7 also makes pretty extensive use of CLOBs, BLOBs and comma-delimited array fields, all of which are efficient ways for an application to store its data, but also efficient ways of making that data unintelligible to anyone or anything other than the application that wrote the data. You can think of it like a journalist who has developed his or her own form of shorthand to use when conducting interviews. It works great when the journalist wants to write up the article and can refer to the shorthand notes and quote the subject verbatim, but if the journalist’s editor wants to fact check the article and make sure the subject wasn’t quoted out of context, everything suddenly becomes very difficult, because the shorthand is gibberish.
If we accept that all of these factors make reporting from SM7 very difficult, then we’re going to need to see something pretty special from SMI Suite to solve these problems.
Well, actually, what makes SMI Suite so special is that it is designed, from the ground up, to deal with the particular challenges of SM7 – something that no other (and certainly no one-size-fits-all) application can boast. We already had a solid base in the sense that we had developed a robust, fully featured reporting solution for Service Desk – which, as you’ll remember, uses a fixed, relational database – so the challenge was really to get the SM7 data into a similar format as the SD data that we were used to reporting from.
So included with SMI Suite is a powerful ETL layer that parses the SM7 data into a separate, relational reporting database. And this isn’t just a straight dump, there are some pretty clever things going on, like data cleansing and translation of those BLOBs, CLOBs and array fields into a human-readable format. The mapping of data is based on the standard SM7 configuration, meaning that customers who make minimal customization to the SM7 implementation need only make minimal customization to the SMI Suite implementation. And for larger, more complex organizations with lots of SM7 customization, there’s a user-friendly, drag-and-drop GUI so the data mapping customizations can be easily and quickly without too much technical knowledge.
All of which basically gets us to the point where we started off with Service Desk, which is with good-quality data in a dedicated, relational reporting database, allowing us to bring in our years of experience in this kind of thing, which means standardized reporting universes, out-of-the-box reports and all the benefits of the market-leading BI software.
Which, when you think about where we were just four short paragraphs ago, is pretty awesome. Not only is it possible to run reports out of SM7, but it is possible for staff with no SQL query-writing experience, no database experience – in fact, no technical experience whatsoever – to write reports, refresh them, distribute them and so on. Which is really where SMI Suite sits head and shoulders above products like Crystal Reports or Cognos, which require you to directly query the SM7 database (potentially affecting performance), and to do so in the peculiar, techie way that the SM7 database understands. SMI Suite is all about dragging and dropping, it’s about using obvious and familiar terminology rather than interminable strings of code and it’s about adapting to the changing SM7 structure without you, the end-user, ever having to be aware of it.
Monitoring is embedded in the daily life of a type 1 diabetes patient. Checking the blood sugar levels with a test strip and meter helps the patient determine whether his blood sugar levels are just right, too low or too high. It is a routine that is repeated before every meal and snack. Any time a diabetic feels “strange”, light headed or hyper, or has a sudden mood swing, the blood sugar levels need to be checked as well.
The purpose of measuring blood sugar levels is twofold. First and foremost, it is meant to prevent a situation in which high or low blood glucose levels may cause severe symptoms that need to be treated right away. Depending on the glucose reading, a patient must take corrective measures to get the blood glucose levels up to par. Second, checking blood glucose will help a patient place fluctuating blood glucose levels in their correct context. High or low glucose levels may not appear from out-of-the-blue. Analyzing the context of a blood glucose measurement will help a patient learn how aspects such as insulin injections, food, activity levels and stress impact their blood sugar levels.
So where’s the link to IT Service Management? Monitoring a service desk serves two purposes that are indeed quite similar to the reasons for measuring blood sugar levels. First, it enables service desk managers to take corrective measures in order to prevent undesirable situations from occurring. Second, it helps managers understand the context of the metrics that are retrieved.
Consider, for example, a scenario in which your daily monitor indicates that a business-critical workgroup is assigned an unusually high number of calls. This may have dire consequences; the number of calls past deadline may increase, SLAs may not be met and customer satisfaction may decrease. Detecting this trend, the service desk manager can now ensure that calls are assigned to other workgroups or request additional staffing to help deal with the workgroup’s unusual workload.
Moreover, as Susan Sanderson correctly observes in her book “Introduction to Help Desk Concepts and Skills”, metrics must be evaluated in context since variation from standard levels can be the result of a wide range of factors. Analyzing the reasons behind the increasing pressure on the aforementioned workgroup may lead the service desk manager to conclude that the higher number of assigned calls is the direct consequence of a Change implemented in the organization’s network infrastructure the previous day. Rather than requesting additional staffing as a permanent measure, more staff may only be required for resolving the issues resulting from the Change.
How will monitoring your service desk help you in your daily endeavors? What daily metrics do you want to obtain? Consider these questions and share your ideas with us by posting a comment.
Get started with monitoring your service desk using Westbury’s Service Desk Monitor. Westbury’s Service Desk Monitor is a lightweight application for retrieving daily metrics from your service desk environment and distributing these metrics to a wide range of audiences via RSS. Interested? Leave an ‘I am interested’ comment and I’ll contact you.