Monday, September 27, 2010

The hidden benefits of UC

Take a closer look and you’ll find them

Whether businesses like it or not, the likelihood is that Unified Communications (UC) in some form or another will work itself into many workplaces at some point in the not-too-distant future. And this isn’t just fanciful analyst thinking, ‘bigging up’ the UC story. Recent research into UC carried out by Freeform Dynamics in December 2009 with 544 enterprises confirmed that UC is increasingly on the enterprise agenda in some shape or form. This is well illustrated in the chart below, which shows the extent to which enterprises have adopted, or are planning to adopt the different components of UC.

While businesses increasingly recognise the benefits that UC can potentially deliver, around improved collaboration, process streamlining, reduced travel costs etc, implementing a solution that actually does deliver is not without its problems. A key concern is the whether the benefits will actually be achievable in practice, and if so, will the benefits outweigh the costs associated with a UC implementation. And unfortunately, there is a lot of anecdotal evidence to support these concerns.

While there are a number of reasons why UC doesn’t turn out to deliver the expected benefits into the business that it was heralded to do, one of the main downfalls that companies make when moving forward with UC is that they expect it to bring about change in the organisation simply by the fact that it is there. The reason that this won’t happen, and why UC implemented in this way is doomed to fail, is that UC, rather than being designed to fit in with the way people work in a non-UC context, is a new system that delivers new capabilities. If businesses fail to recognise and address this, then this is where things can start to go wrong. What this translates to in practice is that, to get UC to work properly within the business requires companies to revisit how they do things currently, in a very systematic and detailed way, and look at how they can be done differently to maximise the benefits of UC.

An example of this is the process around call-handling within a call centre. In a non-UC environment, a call centre agent will take a call and if they are unable to deal with the query directly, they will note down the necessary details, with a commitment to call back the caller once they have the information they need. They will then contact the relevant experts within the company on an iterative basis, until they have the required information, and only at this point can they go back to the caller. If the caller has a follow-on query, the whole process begins again. As well as impacting on how the company is perceived by the caller, the process has to be carried out in a number of steps, and is extremely time-consuming and resource-intensive.

In a UC environment, the process is essentially condensed. For the same call coming in, the agent would try to resolve the call directly, and at the point where other people needed to be involved, would identify which experts to deal with the query, determine their availability, reach out to experts in parallel, and connect directly with the most appropriate one to obtain a response to the query. They would then either feedback the necessary information to the caller, or hand the call over to the expert to complete. And all this would appear seamless to the caller.

This example illustrates that UC brings with it the need to approach things differently. So if a company implements UC but does not change how it does things in any significant way, the likelihood is that, a few months down the line, it will be closely questioning the investment and upheaval it has endured. But changing the way that things are done in terms of communications and processes in a company needs to be dealt with properly. Failure to provide the necessary support around this, particularly in the early days, can ultimately leads to the failure of UC within the business.

Of course, part of this support is about ensuring IT staff are properly trained and have enough time allocated to deal with the uplift in helpdesk calls that are likely to follow implementation. But more importantly, businesses need to look beyond this, and proactively consider the processes that people will need to follow to make the most of UC, and communicate this effectively throughout the business.

Moreover, this will need to be done in a very specific and straightforward way. So, if someone wants to set up a videoconference meeting, what processes will they need to follow? What variants to these might exist, e.g. involving home-based workers, or individuals from outside of the company? And what is available in terms of help when things come unstuck?
Help desk is an obvious port of call, but as some people tend to avoid this route if possible, other options need to be made available, such as online resources, or even a nominated ‘friendly face’ on the same floor or in the same department, who can help out with low bandwidth queries.

It makes sense to extend this to cover what people shouldn’t be doing with UC, and putting together a set of guidelines around good business etiquette. UC by its very nature makes people more available. However, just because someone is available doesn’t mean they are open to constant interruption, particularly for trivial requests and queries.

Rather than looking at UC though rose-coloured spectacles, and believing that it will transform the workplace simply by virtue of the fact that it is there, it is vital to take the time to define exactly how UC will play out in the business, and how to make it easy for people to actually use it. Most of them will not be real proponents of UC - many may not even know what UC actually is, so the transition will need to overcome their natural resistance to embracing it. The more they see it being used around the business – particularly by senior management, and the more ‘best practice’ guidance they are exposed to, the easier, and more importantly, the more successful the transition will be.

Friday, September 10, 2010

The Time has come for “Chargeback”

Ever since the industrial revolution there have been periods when businesses have prospered simply on the back of the general growth in the economy. Equally it is true that there are periods when life isn't so simple and organisations have to retrench in an attempt to prosper on their own merits in spite of prevailing economic conditions. This is where we are today: Certainly market conditions are not good but the fact that the market is difficult should be something with which organisations can cope, even when banks appear to be doing little to make life less awkward for businesses.

The pressure is on IT to demonstrate that it is delivering value to the business. Whilst this sounds simple, it is usually extremely complex. With few exceptions, most organisations do not have established models indicating exactly how the use of IT systems correlates with “business value”. In truth not many organisations posses even a high level view of how IT resources are consumed by different business services. This is a matter which the increasing usage of virtualisation tools, if left unchecked, is going to make even more difficult. In many scenarios this is a task that would be considerably simplified if some form of internal chargeback modelling based on IT resource consumption were to be used to help set and monitor IT budgets.

Whilst the basic concepts around chargeback reporting have been around in IT for a long time, there is strong evidence that chargeback is not viewed as important internally within the business. This clearly poses a challenge as IT may have to push the chargeback concept strongly to help position the associated “value proposition” to the business. Perhaps one example of how this might be achieved would be to use chargeback tools as a reporting mechanism for the efforts currently underway to align IT resource usage with front-line business requirements. (link: http://www.silicon.com/management/cio-insights/2010/08/03/how-can-it-shake-off-the-negativity-get-feedback-from-the-business-39746147/) Such a move away from simply utilising chargeback as a throttle on IT consumption could garner a positive reaction from front-line business managers.

The fact that trading conditions are difficult obviously poses a few challenges for IT departments as they seek to deliver good service whilst maintaining at the same time a very strong grip on costs. One thing that has become clear over the course of the last five years is that IT departments are now expected to show exactly where money is being spent and to provide unprecedented degrees of transparency on such expenditure.

Alongside this, increased levels of sophistication are being sought. IT needs to be ready to support new business operations that may emerge or evolve dramatically overnight. There now often seems to be an inbuilt expectation from the business (however unreasonable that may be) that IT must be ready quickly to support any business change, frequently without having much latitude to assess or manage the potential impact these changes might have on the underlying infrastructure.

Just how can IT demonstrate to the business where the money is going and how effectively the IT infrastructure is being utilised to support key business services? Consideration of this subject naturally leads to the obvious requirement to be able, at the very least, to report on which IT resources are consumed by which applications during certain periods of time. Even in relatively traditional IT solutions where virtualisation plays little or no part, getting hold of this information usually requires considerable manual time and effort.

The ever-expanding use of virtual systems makes such reporting even more necessary, particularly if organisations wish to get themselves into a position whereby they plan to share core infrastructure resources such as server, storage and networking platforms in order to dynamically provision, run and support different applications based on changing business needs.

This scenario is simply crying out for the use of chargeback modelling, despite the likely resistance, or at least indifference, from business users. After all most business people are extraordinarily familiar with the concepts of money and budgets within their own departments or areas of responsibility. On the other hand they may be very uncertain of quite how IT actually supports their daily operations. A simple way out of this dilemma is to employ some form of chargeback modelling which allocates costs to the users of IT services based on the percentage of the infrastructure resources that those services actually consume.

Today some organisations already use a primitive chargeback model based simply around the numbers of users of a service and the “assumed” costs of delivering said service. These models are by their nature usually very simplistic and do not take any effort to allocate costs based on actual usage, which will become much more important as systems become virtualised and the allocation of physical resources varies over time.

Such resources could also expand to include electricity costs as well as building related costs such as floor space, land costs, building depreciation etc., whatever makes sense for the business to measure. Alas whilst this sounds easy in principle it can, in fact, become extremely complicated in practice.

I believe that we have now entered an era when the use of chargeback models will become prevalent in a majority of IT organisations, certainly those where the IT systems number more than a few tens of servers and where flexible virtualisation is employed to pool physical resources together rather than running individual servers and back end systems to support a single application or service. Chargeback models provide transparency in a format which is acceptable to the majority of business users since it operates using concepts of money spent for each service delivered. For line of business managers this approach should be easy to get grips with.

However from the IT perspective this places a degree of burden on the infrastructure in terms of monitoring resource consumption and then reporting on what resources each business unit is actually consuming. This reporting must be in financial and business operational terms rather than IT centric metrics. The challenge is to find a model that the infrastructure can sustain that is politically acceptable to the business users and economically acceptable to operational IT. Get it right and hopefully everybody will be happy, or at least recognise where there may be IT / business conflicts that need to be resolved.

In addition so called “Cloud solutions” are being marketed by many as being inherently lower cost than in house IT solutions, and these comparisons are causing some IT departments considerable challenges. This is especially the case as few cloud services exactly replicate specific conditions around the security of services or service level commitments. It is very easy for business managers to not realise that potentially they may be comparing a very bland apple with a specific variety of the fruit grown in house to meet very tight taste requirements, and one that it is tightly integrated into the overall business menu. The fact that there is considerable activity amongst the vendors of cloud solutions to appeal directly to business users is likely to cause them to have to defend the costs of running their own services as compared to whatever external solution is being marketed. This task becomes more straightforward if IT has a good idea on how much each service costs rather than a purely theoretical model.

So the question becomes which forms of chargeback modelling will be acceptable along with how are such models to be built, monitored and reported on? Then there is the challenge of how to sell the idea of charge back modelling it to both the business and a sceptical IT team? The answer is for both sides to recognise the opportunity charge back reports provide to monitor service levels, decide on service change requests and to report on IT / business alignment but IT is likely to have to drive things.