As we all know, Darwin proposed the theory of ‘survival of the fittest’. Species have to evolve from generation to generation, adapting to their environment to survive. Based on this theory and more than 20 years of talking about business and IT you have to conclude that by now, IT should know exactly how to incorporate business requirements and needs. Moreover, IT is crucial in surviving against the competition.
So why does this seems so terribly untrue? Why after 3 versions of ITIL, top of the bill process improvement consultants and the newest flashy service management tooling, most of the implementation projects do not deliver what the business needs? And what about continual service improvement/ASL/BIZL and more …?
From my experience the most successful IT projects and organizations start with clear goals set by people for people, motivated project members, managers and key employees knowing how to change behaviour. As science proves, success, attitudes, culture and motivation start with defined, clear objectives and changing your behaviour; walking the talk. And of course don’t forget to measure the success and to celebrate it.
IT started with people and every initiative and project still depends very heavily on the people involved. We need to start focusing on the central and most important asset, THE PEOPLE! IT for the business needs People for People and walking the talk.
Or perhaps it still takes a couple of million years of IT evolution?
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.
Implementing a service management solution within a customer environment is an easy task. Install the software, tell the customer to use it according to ITIL, import some employees, CI’s and Services and Bob’s your uncle. Nothing to it.
Alright, alright; it’s slightly more complex than that. You’ll have to try and gain insight into the processes that are in place, you’ll have to discuss the requirements and wishes of the customer and flawlessly translate them to the set up of the tool, you’ll have to train the user community and you’ll have to communicate with all of the stakeholders in the organization throughout the implementation process.
So, assuming you went through all these steps and made no major mistakes along the way; is success guaranteed? Unfortunately, no. Some of these projects will end in partial success at best and will live uneventful lives.
What then is the key to success? Tough question. It’s really a combination of knowledge, experience, patience, determination and, for a part at least, sheer luck. Let me focus on the latter, because the first four are obvious. To what extent does luck play a role?
Luck, or positive circumstances beyond our control, can make the difference between a project ending in success and a project just ending. Let me illustrate this with an example from a recent implementation I did at one of the biggest insurance companies in The Netherlands.
Due to circumstances, I was lucky enough to be involved in an implementation project for the Insurer for the fourth time in 13 years (or so). The previous three projects had all ended with a mild success; nothing fancy, just okay. This last project was somewhat different than the previous three, because this time it wasn’t a merger or an upgrade but a whole new implementation of Service Desk 4.5, SSP, Report Manager, Change Calendar and Service Desk Monitor. Why? Because 4 years ago the Insurer outsourced their IT department and switched over to ServiceCenter.
Now, the outsourcing contract had been terminated and a renewed Service Desk implementation was required. Enter Westbury. The luck factor starts here. Literally no-one within the Insurer had been satisfied with ServiceCenter and its functionality (due to the outsourcer’s implementation mainly, not due to the tool itself). The way this works psychologically is that you start to remember the good old days, when streets were paved with gold and the sky was all pink and fluffy. Their good old days were the Service Desk days. And now it was back. Praise Jesus.
This feeling, shared by most in the project group(s), meant that there was an enormous sense of positivity with everyone and a real drive to make the project a success. This really started off a chain reaction. Because everyone was positive, they were very flexible in accepting the limitations of the project and the tools, and because they were flexible we were able to move forward within the projected time frame and within the projected budget. This in turn lead to more positivity.
Added to that was a project manager who played a very active role in the project and really fought like a lion to get everyone on the same page and protect the scope of the project. Also lucky because you can never choose your project manager.
The result of all this: A project that ended on time within budget and with a happy customer. And with an additional project and the purchase of 50 additional Service Desk users. And with this blog entry.
Is there a way to influence this luck factor? Yes, maybe. By making sure the customer is aware of this factor and by driving home the notion that enthusiasm for the tool implementation as well as a very active and dedicated Project Manager are just as important as the other factors that determine the outcome of a project. Still, the luck factor cannot be overlooked. Hopefully you are lucky enough to find it on your path.
In a recent report (registration required) the Aberdeen Group described the success rates of enterprise companies (which it groups into Best-In-Class, Average or Laggard) in Business Intelligence projects. Some of the result are very interesting to share.
For example, the report identified the four top hidden costs of Business Intelligence as:
Year-after-year budget increases: The typical best-in-class company sees a drop in year-after-year BI budgetary costs. Average and laggard companies, however, can witness increases in BI expenses that range from 2 percent to 9 percent.
Cost per user: Best-in-class companies lower per-user costs by 4.3 percent whereas average performers and laggards often see increases ranging from 1 percent to 7 percent.
Time to complete projects: Best-in-class achievers complete BI projects, on average, within 14 days. Average performers take nearly three times as long (approximately 39 days) to complete a project, and the typical laggard company takes more than 12 times as long (177 days).
Modifications to BI software: Altering a BI program takes less than a day for best-in-class companies; three days for average performers; and up to eight days for laggard organizations.
Or as author David Hatch put it:
“The overall cost of ownership is not about the costs of purchasing the software,” Hatch says. “The real cost factors are the hidden or the soft ones that have to do with indirect and ongoing factors.” Hatch contends that a justifiable fear of such factors hinders adoption. “People are finding [that] the resources the company needs to acquire to properly implement, deploy, support, and maintain a BI solution are far greater than the solution providers lead [users] to believe or that [users] assume on their own.”
Interesting, because that is what Westbury has seen over the last years in dealing with BI projects for HP Service Management. But a report of the Aberdeen Group isn’t complete without some recommendations. On what areas should companies focus in order to improve the success rate of their BI projects?
Aberdeen suggests that investments in the following areas will maximize results from a BI initiative:
Data integration and cleansing: “Companies are finding it difficult to bring data together from multiple, disparate sources,” Hatch says. Investing in tools for data management can be of help in this regard. Best-in-class companies are twice as likely as their counterparts are to institute data integration and cleansing capabilities.
Westbury recommends: make sure the back end of your BI environment can be used by non-technical people
End-user requirements: “You really have to stop and think about why…so many companies have deployed tools that so many aren’t able to use,” Hatch says. Companies must understand that end-users — especially nontechnical, non-data-guru types — may need different approaches. Hatch advises companies to focus on end-user needs before deploying a solution.
Westbury recommends: make sure you talk the same language as your end-users
Training: Top performers are 37 percent more likely to invest in extensive user training on BI solutions and 40 percent are more likely to have formed formal user committees to encourage adoption. Additionally, best-in-class companies are twice as likely as laggards and average performers are to sign up for vendor-provided services.
Westbury recommends: the more accessible your BI solution is for the end-users, the better your processes should be around training
Operational BI: Successful users of BI use the technology on an everyday basis rather than merely getting a summarized spreadsheet version of performance and high-level trends. Hatch says that operational BI seems to be gaining traction as companies look to make comparisons over shorter time spans rather than just examine large-scale trends.
Westbury recommends: integrate your BI solution with the supported applications, so it is readily accessible for your end-users
Great to see our own own experiences in working with the HP Service Management software backed up with a solid research like this one from The Aberdeen Group.
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.
Chances are that if your company is using HP Service Desk or HP ServiceCenter, that you are contemplating a move to HP Service Manager. Such an undertaking will undoubtedly be coupled with a review of existing IT Service Management processes and the way in which HP Service Manager will support these processes. Having learned from experience, most companies recognize that there is no need to reinvent the wheel and are therefore minimizing customization and sticking to the out of the box configuration as much as possible. However, and this is a surprising industry trend, most companies are still paying little to no attention to the reporting requirements from HP Service Manager. Without a proper reporting solution and strategy in place, your HP Service Manager implementation cannot succeed as you will have no way to properly measure and communicate IT’s performance.
Common themes that accompany the (planning of the) implementation of HP Service Manager include the sensible improvement goals around:
Business and IT alignment
Quality of IT services
Transparency of IT services to IT customers
Given the above themes it is therefore surprising to see that getting the right information out of your HP Service Manager implementation is often an afterthought. Or as one seasoned ITSM consultant put it, ITSM reporting is often dealt with as the ‘red-headed step child’ of any ITSM implementation. “We’ll deal with that when we get to it” however by the time you ‘get to it’ you’ve got your hands too full to properly address the issue.
At Westbury we are constantly running into customer scenarios where all the focus is aimed at getting HP Service Manager up and running and yet reporting often seems to be an afterthought. Interestingly enough, that same ‘red headed step child’ suddenly becomes of utmost importance the moment HP Service Manager’s live date approaches . The reasons are obvious:
At a minimum IT wants to provide at least the same reports as existed before the move to Service Manager
Additionally IT managers & supervisors need insight to better oversee, drive and improve the performance of the various support teams and services they provide
Going forward the IT department would like to prove its value by objectively demonstrating improvement in the delivery of IT services
Customers of IT will demand insight into the delivery of IT services and will require increasingly more in-depth reporting from IT
We in roles of ITSM are being asked to do more with less and to improve the delivery of IT services to our customers. This means we have to be smarter as to how we go about this. Let’s all agree that it is not about what we put into the ITSM processes and tools, rather it is about what we can get out of it.
As we all know, Darwin proposed the theory of ‘survival of the fittest’. Species have to evolve from generation to generation, adapting to their environment to survive. Based on this theory and more than 20 years of talking about business and IT you have to conclude that by now, IT should know exactly how to incorporate business requirements and needs. Moreover, IT is crucial in surviving against the competition.
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.
Implementing a service management solution within a customer environment is an easy task. Install the software, tell the customer to use it according to ITIL, import some employees, CI’s and Services and Bob’s your uncle. Nothing to it.
Now, the outsourcing contract had been terminated and a renewed Service Desk implementation was required. Enter Westbury. The luck factor starts here. Literally no-one within the Insurer had been satisfied with ServiceCenter and its functionality (due to the outsourcer’s implementation mainly, not due to the tool itself). The way this works psychologically is that you start to remember the good old days, when streets were paved with gold and the sky was all pink and fluffy. Their good old days were the Service Desk days. And now it was back. Praise Jesus.
In a 
