In the first two parts of this series, we looked at the role mobility solutions can play in furthering the impact and reach of ITSM teams. We also considered the challenges and risks an increasingly mobile workforce presents – we saw how mobile device management can help you take control of some of the more critical components of your mobile infrastructure.
But what else needs to be in place for mobile computing to be a success story in your organization? In this third installment, we explore some of the supporting people, processes and systems that need to be considered if you’re to stand a fighting chance in the mobility revolution!
Part 3: Are you mobile ready?
Bracing for success
We’ve all read about the marketing promotion, or new retail channel, that outperforms even the wildest of the company’s projections. The unanticipated deluge of calls and requests that swamp the organization – destroying their ability to deliver against the offer they promoted. I’m told it’s the irony of the situation that hurts the most in these scenarios.
Throwing the gates wide open, and offering new IT services and support via mobile channels, can catch out even the most focused of IT support organizations. Suddenly, the team is faced with new kinds of issues, across a broader range of devices, on new communication channels at unfamiliar times and locations!
If you’re not ready, your ability to provide adequate support and therefore maintain systems stability (not to mention your reputation) can be severely impaired. There are similar gremlins lurking when you embrace mobility as a strategic operational capability for your ITSM teams…
Empowered engineers – but what about the management?
There are a couple of common mistakes made when building a mobile capability for ITSM operations:
Mistake No. 1: Giving your field engineers mobile access to key ITSM systems, but not to their authorizing supervisors and request approvers. This can cause spectacular bottlenecks in what should be a faster and more responsive service!
Make sure the people who are responsible for authorizing change requests (which can now be made anytime, anywhere) can approve them anytime, anywhere. The management, supervisory and approvers all need mobile access for the projected service improvements to be realized.
Mistake No. 2: Not giving mobile ITSM access to all of your field engineers. In this scenario some of your engineers are able to make change requests in real-time, update CMDB records, update asset information and access knowledge. The others cannot. The result? poor collaboration between engineers, inconsistency in process, patchy record keeping accuracy and an overall reduction in efficiency.
This is probably not the outcome you were looking for, so again, make sure the right people have access to mobility in ITSM and with consistency. In both cases, and depending on the kind of devices you’ve issued – the fix can be as simple as more broadly distributing the ITSM mobility app (providing adequate licensing exists.)
Here come the masses: but do you have enough (of the right) skills?
Great, finally your self-service capability is getting the uptake you’d hoped for all along. It turned out that making the service available on mobile devices was the secret to making it popular. And now they’re here, your customers, in droves and all eager for service…
You need to think carefully about the skills mix the support teams possess. Suddenly, the kinds of calls you’re taking can really shift – does your team understand:
- How to use the more popular smartphone and tablet devices?
- The critical apps being deployed, their configurations and the known issues?
- Where support begins and ends for an employee owned device?
- How to distinguish between an app and network failure?
- Good device security and app hygiene?
This is by no means an exhaustive list of the changing pattern of support that mobility brings about. But you get the point – you can’t leave it to chance, you need to look at your team’s skillset and train accordingly
It’s also true of staffing levels and shift patterns. For some organizations, a sudden surge in support service uptake can radically change the traffic volumes and timing. This may even include helping configure devices to work with the new support services and any other mobile applications under management.
You need to watch the new patterns and staff accordingly. This watching period is critical – you need to check that the new pattern of requests is a lasting phenomenon, as opposed to the initial two-day flurry of excitement surrounding the new service!
Using process automation
In the highly unlikely event that you are suddenly able to take on lots of shiny new people to support the mobile infrastructure, you’ll be fine, you won’t need any assistance from technology in meeting the new demands on your resources.
For everybody else, process automation, particularly in the fulfillment of popular requests, can make the difference between swimming and drowning. A well configured and aligned Service Request Management system can take a massive load off support teams. Particularly when coupled with other automation tools such as identity management and configuration automation systems.
The bottom line? The more processes and actions you can automate in the face of a significant increase in demand, the better. Not keeping pace with the volume and not meeting the agreed SLAs can rapidly undo any advances you’ve made in providing a better and more valued IT service.
Speaking of SLAs…
Everything you though you knew about SLAs…
In a world of ambiguous problem ownership – e.g. a personal tablet device, running a corporate application on a home-internet connection – defining and enforcing the right SLA is a nuanced business.
Organizations tend to take one of two approaches:
1. Don’t provide SLAs for people using personal devices. Regardless of what they’re accessing on those devices and where the fault lies. It keeps things simple, certainly, but it is somewhat in denial of the current and future reality of how employees will consume key IT services.
2. Provide clear and defined SLAs for those components of the infrastructure under IT’s control – i.e. corporate apps, the device (if company owned), the network (if company contracted). The trick with this approach is the accurate identification of exactly where any report problem lies. Hence the need to check your skills and training plan as discussed earlier.
The other subtlety here lies in ensuring that all of your support staff understands the scope and extent of the agreements in place: the SLAs, the OLAs and, increasingly, the Underpinning Contracts (UCs) – i.e. third-party supplier contracts.
Being able to model and enforce UCs, takes on a new significance in supporting mobile infrastructure. Often, a great deal of the actual problem resolution can lie with third parties.
Clearly, this isn’t everything you could ever want or need to know about the behind the scenes minutiae of running and supporting mobility, No doubt we’ll explore may of these themes further in the coming weeks and months.
However, I hope the central theme is clear: If you’re going to invest time and resources in mobilizing front-office systems (and the workforce that uses them), you had better be thinking about making your back office teams, processes and systems, mobile ready.
Enterprise Mobility Blog Archive