The Next Big Thing
Posts about next generation technologies and their effect on business.

Does management in services differ from management for product?

business choice.pngThis week I was talking with some of the leaders at the SMU business school curriculum advisory group for Information Technology and Operations Management. During the meeting, we had a discussion about the differences between service organizations and product companies in the areas of governance, finance and HR. Sometimes these differences can be jarring for someone (or whole companies) moving from a product market to the services market or vice versa.

 

Services have definitely become the largest part of the GDP for many countries.

 

One of the most obvious differences has to do with personnel. For a product organization, people can be considered overhead and a resource that needs to be minimized. For many types of service organization, what is actually being sold is access to people and process. If you have no people, you have nothing to sell. Having a bench is what gives the organization the flexibility to grow. With the increase in analytics, more of these knowledge worker roles may be automated, but that just focuses the individuals on higher value activities.

 

The governance in the services space is also quite different. For IT roles as an example, there are industry processes and methodologies like ITIL or CMMi that the industry accepted as a constituent, best practice to produce work products enabling business leadership to make better and more consistent decisions.

 

SMU is defining an IT management certification executive education program to strengthen the understanding of leaders concerning best practices. Since IT is only a small part of the leadership within most organizations, this kind of external program seemed to be a good idea to focus on the skills an IT leader needs. I tried to get them to make it an on-line course, but that is not likely to happen, at least at this point.

Social Media for Tech Support – Consider Carefully

In a recent blog and briefing, Hank Marquis considers the pros and cons in the use of social media like Facebook and Twitter to augment or replace IT technical support functions, by creating a community of users that can support themselves.  While the notion of self-service via social media seems to be an easy and cost-effective method of serving a large community, Hank correctly points out many of the shortcomings and drawbacks to replacing a formal technical support function with a self-organizing community.


Using social media to address technical support issues can results in multiple answers being given, leading to a lack of correctness, inaccurate answers, and a loss of organizational knowledge capture resulting from ad-hoc methods.  It can also reduce the productivity of the IT organization as well as users, as they attempt to use crowd-sourcing to get answers to support questions.


Another drawback, and potentially very serious concern, is an increased potential for social engineering attacks.  Social engineering is the ability "to manipulate people, by deception, into giving out information, or performing an action".


One of the favorite targets for social engineers is the IT helpdesk staff as outlined in Kevin Mitnick's book "The Art of Deception".  The helpdesk or IT support group's main function is to "help people" in their use of corporate IT applications and services.  Social engineers will create a ruse and use the support center personnel to aid in their attempt to bypass security.  This is why a solid identity management and authentication function is required in providing IT support services in accordance with best practice standards like ITIL.


The use of social media to augment or replace IT Technical Support opens at least two possible social engineering attacks, due to a lack of identity management.  First, it makes it easier for an outsider to masquerade as an employee or authorized user and request the support of the community.  By simply monitoring the community dialog, an outsider will be able to learn on the "lingo" and develop his alternative personality as an "insider" for further attacks. 


In the second scenario, a skilled social engineer can adopt the persona of a Tech Support expert and guide un-suspecting users into revealing passwords, access codes, and or the location of sensitive information.


In my view, the current social media platforms lack the strong identity management and authentication mechanisms needed for providing critical IT Technical Support Services.

Self- help vs. starvation

One of the interesting phenomenon taking place in the IT support space is the focus on end users helping themselves rather than relying on IT professionals for IT Service Management. This approach of letting the end users to fend for themselves does make sense for a number of reasons:



  • 1) The average worker is much more computer savvy than they used to be

  • 2) There is a high cost for support structures to handle problems, and those benefits are hard to quantify.

  • 3) For some, the interaction with the help desk is frustrating and they'd rather rely on their co-workers or social media tools for help.


There is a whole other school of thought -- that people are hired for a particular reason and anything that distracts them from meeting that objective is a problem, and nothing is quite a distracting as having a computer problem that you don't know anything about and there being little help for you other than having someone on the end of a phone line walking you through the tedious process of getting the system working again.


The same support solutions may not work for everyone and knowing how the systems are used is crucial to both making everyone more productive and minimizing support costs. Sometimes updating the hardware with newer management capabilities can improve the reliability and supportability. Self-healing tools (no it does not involve hypnosis) can also address some of the issues. These started on the servers, and are becoming more common in the PC environments as well. Change is coming and the days of dictating the hardware that everyone will use is coming to an end. For many organizations, bring your own PC to work is happening. This causes a whole other dimension of support issues. There are application virtualization and virtual machine techniques that can be used to make this more manageable though.


There are best practices for service management and lots of people who blog about ITIL and service management if you need ideas.

What's this thing called DevOps?

During a conversation last week with a Forrester senior analyst (Dave West) from the UK, I learned about a new term and a new industry "movement" - DevOps.  He said that there has been recent interest in this topic which combines, both literally and figuratively, the terms "developer" and "operations".  So of course when our call ended, I did some searching on the term and learned that there is indeed a fledgling "DevOps" community of developers and sysadmins who have recognized - as many of us - that applications should get built with full knowledge of the operational environment in which they will run. This group of primarily UK/Northern European IT professionals has collaborated on recommendations to remove some of the silos between those who build and those who run applications. This represents a cultural change as much as a need for integrated teams and processes. Two years ago in this space I spoke of the need for developers to use ITIL practices "to understand the real impact of new applications on the run-time environment and how they need to be designed differently for the complex, distributed environments we have today".  Perhaps not much has really changed, but at least the conversation has broadened.


The DevOps community sees agile and lean teams better suited to collaborate and drive DevOps thinking because of their matrixed approach, but I don't see why two-way communication, which is both the bridge needed and the current barrier, should be limited to small teams. We need to see push and pull of information equally from both developers and operations.  Silos within the IT organization or even when traditional outsourcing and multi-vendor partners are engaged are challenges but not insurmountable. 


Just as one example, when developing a web application I really do need to understand the capacity (network, servers, storage, database) of the current run-time environment as well as the security levels, and I need to work with both sysadmins and service management personnel to have them understand the service level, security and run-time requirements, work out conflicts, and also engage them as necessary for integration and other testing. EDS had the right idea with an initiative called Designed for RunTM that has continued to evolve towards what I believe the DevOps folks envisage, but there is still work to be done.


I do really agree with the recommendations of the DevOps gang that a multi-disciplinary approach must be taken between developers, testers, change and release management, and operations engineering groups such as system administrators and those who manage system capacity and availability. They suggest that team members might gain expertise across the divide.  Understanding the best practices from both CMMI and ITIL would help, as well as having the IT skills and experience to go along with them.  I've studied this "CMMI & ITIL" process integration area fairly deeply and have spoken at several conferences on the need for integrated application development, service management and infrastructure engineering processes. Drop me a line if you would like to discuss further or pick up a presentation. 

Search
Follow Us
About the Author(s)
  • Steve Simske is an HP Fellow and Director in the Printing and Content Delivery Lab in Hewlett-Packard Labs, and is the Director and Chief Technologist for the HP Labs Security Printing and Imaging program.
Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation