Smartphones have replaced desktops and laptops as the communication platform of choice. Improved bandwidth and usability on these devices have opened up new markets for interesting enterprise applications, particularly those that can improve business productivity. A few years ago, mobility in IT meant giving users laptops and maybe a BlackBerry so they could get access to email where and when they wanted. BlackBerry and Windows Mobile were the only games in town for business mobility.

Today Apple, Symbian, Palm, and Google are joining the fray. Android devices and iPhones are hot with consumers, and more and more workers are bringing these smartphones into the enterprise and connecting them to business systems. However, when it comes to smartphones that do deeper integration with business processes and the devices that companies deploy to their workers, BlackBerry remains the runaway leader. In fact, BlackBerry is actually growing stronger in the enterprise because its former archrival, Windows Mobile, has been floundering for the last couple of years and Microsoft has recently decided to focus most of its attention on the consumer market with Windows Phone 7.

Smartphone enterprise market share

Companies are recognizing that mobility is core to IT infrastructure and imperative for strategic differentiation. The mobile workforce is growing. That’s why many organizations are looking to companies like RightStar with process-oriented mobile applications to help them work and communicate more effectively.

Mobile Applications

Email has been a great first step for many IT departments to make use of mobility. The next step is to mobilize applications that create a true competitive advantage. Mobile applications leverage inherent advantages of a mobile device such as reducing the data transferred, being able to operate disconnected from the corporate network or storing critical business data.

We see the greatest opportunities for our customers to benefit from the use of smart devices lie with Asset Management and Service Management. The demand for “anywhere access” to BMC’s service management applications is increasing dramatically.

Service Management: RightStar developed MagicMobile to provide instant access to the Service Desk using a device’s wireless capability. It was designed as a web application that specifically supports mobile requirements (small screen size, lower bandwidth, etc.). MagicMobile is completely browser-based in order to leverage the widest possible array of mobile devices, most all of which have an internet browser. Popular uses for this application include:

Asset Management: RightStar’s MagicWand was created as a native application primarily used on Motorola’s MC series of barcode scanners, which are based on the Windows Mobile OS. These devices provide a robust processor and ample memory to keep a snapshot of the enterprise’s physical assets locally and close at hand even when wireless access to the enterprise is not an option. Barcoding offers many advantages, including speed, accuracy, and data integrity. Popular uses for this application include:

By waiting to implement mobile solutions like these and others, companies run the risk of failing to keep pace and being outmaneuvered by competitors that become more agile and profitable through mobility.

The Future of Mobility at RightStar

RightStar Systems continues to enhance existing products and develop new ones to further enable the growing mobile workforce. We’re giving our flagship product, MagicWand, an overhaul which will allow the user greater flexibility to customize the application to their needs. The barcode application will also provide connectors to other popular Service Management systems such as Remedy ARS and Microsoft Service Manager. MagicMobile is slated for a facelift and usability upgrades to take advantage of the latest devices and operating systems.

Recently there has been a hot debate, an ITIL forum thread of approximately 150 posts, over whether a Major Incident should automatically be classified as a Problem. It seemed that the voices advocating the creation of a Problem record for every Major Incident were more assertive and enthusiastic, to put it nicely. I’m sure my RightStar colleagues would often find me guilty of getting lost in the weeds of ITIL theory, but for this issue, I believe I’m more apt to consider what happens in real life for our organization and for our customers. I’ll share with you here some of my own thoughts and conclusions.

First we’ll look at textbook ITIL definitions. Many organizations and IT managers are still sorting out the difference between Incidents and Problems. The example I typically give is that of a user calling about a network printer issue. The user is unable to print to the network printer. What should the Service Desk analyst do? Well, since the Service Desk analyst is supposed to be responsible for Incident Management, by definition the analyst should be focused on restoring the service (in this case, printing) as quickly as possible. The analyst should follow standard troubleshooting procedures within predefined timelines. But if he or she is unable to resolve the Incident, the user’s system may need to be routed to an alternate printer. When the Service Desk analyst confirms that the user can print to the alternate printer successfully, the Incident record can be closed. An Incident is then simply defined as a disruption to normal service.

But of course the printer is still broken. This is where Problem Management steps in. The Service Desk analyst should create and link a Problem record for the printer issue to the Incident record and assign the Problem to the appropriate manager or group. The Problem Management process will be engaged to determine the root cause, develop or document workarounds (such as routing to an alternate printer) and ultimately provide a fix, whether it be to clear a printer jam or send the printer in for warranty repair. A Problem is defined as the cause of one or more Incidents, and the Problem Management process assumes that the cause of the Problem is not known when the Problem record is created.

Getting back to the debate and how that relates to real life for most of the organizations we’ve worked with—after reading some of the posts in the forum, I thought of an example of a Major Incident that doesn’t fit the criteria or definition of a Problem. What about a power outage? For smaller organizations especially, it’s not practical to have a fully redundant collocated data center for all of their services. And even if the data center is not impacted, there may be remote sites that need assistance with computer-related issues because the communication to headquarters or their own computing capabilities are compromised.

In this scenario, the power outage is the cause of one or more Incidents or disruptions to service. But we cannot assume that the cause of the Problem is not known. There was a storm, the lights are out and we should know why the computer won’t turn on. No root cause analysis is necessary. And the organization doesn’t have the influence to negotiate with the power company or with the weather if that was the cause of the outage. I would therefore argue that this situation would warrant the creation of a Major Incident, which is defined as an Incident that results in significant disruption to the organization. But it does not require the creation of a Problem record or the engagement of the Problem Management process. As long as alternate manual procedures are standardized and followed, the relevant information for handling the outage should reside within the Incident Management process.

It makes sense for the Major Incident record to be linked to the other Incident records so that IT can measure the impact of the outage. We would also like a mechanism that will allow us to share the information with the support staff and other customers as necessary. For users of BMC Service Desk Express, what should come to mind is the White Board notices module. This module, under the heading of “Crisis Management,” has many advantages. First of all, the sharing of information is facilitated by the scrolling White Board Ticker marquee. Individual records can be segmented to limit the display to a specific group or to include the display for the Self Service interface. Secondly, subsequent Incidents that are linked to a White Board notice can be automatically populated and updated with information from the White Board notice. Finally, when a White Board notice is closed, all related Incidents can automatically be closed with it, and a business rule will fire to send email notifications to affected users. I would even recommend renaming the “White Board” module the “Major Incident” module.

As always, ITIL is not a framework to be swallowed whole. It was developed to provide guidance for IT service management best practices and to be adapted to each organization’s needs. I expect that we’ll continue to debate the intentions of the ITIL authors. Ultimately, our goal is to provide better service and to deliver solutions that make sense.

What is your ITIL maturity level? At almost every RightStar monthly webinar, we poll the audience on whether they use ITIL as an organizational framework for service management. We’ve found that an ever increasing majority insist that ITIL is their de facto service management standard.

When we arrive on-site for implementation or upgrade services, however, we discover that there is rarely any thought given to the ITIL framework as it applies to the technology tool set, i.e., BMC Service Desk Express or BMC Remedy ITSM. This shows me that ITIL exists in theory more than in practice for most organizations.

It’s understandable that putting ITIL into practice doesn’t always make the “short list” given the demands IT organizations face. However, if an ITIL rollout can be done without a large outlay of time and money, it will quickly enable the organization to better deliver what the business wants and expects. Here are three steps to help jump start ITIL in your organization:

Invest in ITIL training, but don’t go overboard. We have often seen ITIL Foundation training being promulgated from the top to everyone in the IT organization. While the certification is valuable, that on its own does not guarantee service management success. Certification may be an indication that the holder can use the ITIL terminology and understand the processes, but it doesn’t provide the exact steps necessary for process rollout. A better use of your organization’s training dollars might be to begin with a small subset of ITIL champions, and then roll out training to all as an exact ITIL blueprint is defined.

Begin with Incident Management and build from there. Change and Configuration Management should follow, with Problem Management not far behind. Service Level Management is also essential.

Look at “ITIL in a box” solutions such as the Alignability Process Model (APM) for Service Desk Express and BMC Service Management Process Model (SMPM) for Remedy ITSM. These product toolsets allow organizations to quickly roll out an ITIL-based software solution. The process model is based upon a set of field-proven process flows and procedures that have been successfully deployed within numerous organizations.