Very interesting article on Incident and Problems and how ITIL confuses the definitions of both. We all understand that ITIL is not prescriptive, but in many instances the “guidance” that it provides leave far more subjective interpretation of ITIL than is actually helpful to an organization’s implementation of certain processes. Incident and Problem are arguably two of the most important in daily operations. Getting these wrong can seriously negate any benefit of their implementations.
This is quite interesting from an IT Support perspective. While the old-school big boys of BMC and HP continue to stomp around the yard while circles are being run around them by the more nimble Service-now, new players are still trying to get in for a bite of the customer support pie.
|This post is part of a series brought to you by GoToAssist.|
We recently talked about how startups can go about setting up a helpdesk to keep their customers well supported. Customer support is one of those areas of your business where it’s surprisingly easy to differentiate yourself — you’d be surprised to find that very few startups are really putting much of an effort in here.
It got us thinking: what will the helpdesks of the future look like? Everyone loves a good spot of future conjecture, and even if these things never come to pass, it’s fun to consider.
With that in mind, here’s are a few ideas of how the industry can change, as well as the methods by which the changes could happen. Come along. This should be fun.
You remember Minority Report, of course. That awesome computer system where Tom Cruise was able to control everything with a pair of gloves that allowed his movement to be tracked had geeks around the world drooling. With Microsoft’s Kinect, we’re a step closer to this but not quite there yet.
What’s interesting is that most helpdesk work isn’t very well suited to the large-screen format upon which a system like this would thrive. However, for a macro view, having the ability to swipe out old tickets and pick them up to move them into a different order would be welcome. Motion tracking such as what we have with the Kinect could allow this in the future, even if we’re still just jumping around in our living rooms for video games right now.
This is where the idea of motion control and true immersion could come into play. Put yourself into a position where you walk into a room, sit down at a desk and then have a 120-degree display just slightly above your eye level. It would allow you keep track of everything that’s going on, without having to address it directly. In front of you, you’d have a more traditional two-monitor setup (or perhaps a non-traditional version, something akin to virtual reality glasses).
This immersion, where you could nearly cause the world around you to disappear, would allow for a more centralized workflow. Instead of having to bounce back and forth between screens or computers, you could simply flick your hand to bring down the display of information that was relevant to you at any given time. Since we’re not speaking about physical monitors, but rather about a display that can expand or contract on demand, we’re also not limited to traditional plastic borders.
This is another area where I think that the entire helpdesk system could benefit. We have already seen smart-learning algorithms for Web-based content. What about one that learns the importance of a ticket by reading the words and data inside of it, effectively turning the entire process into a semantic method instead of simply first-come, first-served.
Undoubtedly there would need to be some serious work in order to make sure that things happen in the order that they should. But with learning algorithms getting “smarter” every moment, it wouldn’t be such a far stretch to imagine one that could re-order your lower-importance tickets for you, saving you time and effort.
The beauty of the system, as we’re talking about here, is that it only furthers the current trend of a decentralization. We already have employees of major corporations working from remote locations and that trend doesn’t appear to be slowing. With that remote method, studies have shown time and again that employees are happier, more productive and generally stay with a company longer.
While the technology that I’ve dreamed up here might not even exist yet, much less be affordable today, current iterations in hardware lead me to believe that it won’t take long for that to change. In the next few years, it will be cheaper, easier and continue to be more effective to have a helpdesk a few thousand miles away, staffed by the people who otherwise wouldn’t be able to work for your company.
Call it a dream list if you will, but these are some of the things I’d like to see. Have thoughts of your own? Give us your dream setup in the comments.
The journey from application lifecycle management (ALM) to IT infrastructure library/IT service management (ITIL/ITSM) can be a mysterious and challenging transition. ALM usually puts the spotlight on rapid iterative development while the operations wizards use their capabilities to keep essential business services running twenty four hours a day, seven days a week—along with managing changes, often at a very rapid pace. In fact, many technology professionals thrive on creating complex applications while secretly dreading the dangerous realm of large-scale application deployments—generally resigning themselves to giving up yet another weekend. Many successful organizations are rising to this challenge and embracing zero-touch deployments. This article will help you get started on your way to implementing completely automated release and deployment.
Zero-touch Deployments—Myth or Reality?
The target goal of implementing fully automated, (i.e., zero-touch) deployments may seem like a wish that can never be fulfilled. ITIL has also been criticized for being an elusive ivory tower and idealistic framework. Deployments are complicated with many moving parts and changing requirements. In the real world, deployments are often very difficult to fully automate. Having been burned by painful deployments, many technology professionals surrender to the notion that deployments are always painful and don’t even consider how they might be able to engineer their systems to be more deployment friendly. Dare we even consider the possibility that applications can be engineered to deploy smoothly in what some veterans are now calling zero-touch deployment?
Checklists Are Essential
You gotta start somewhere, and a pragmatic first step is to document on paper each step, even if only at first. While checklists are essential, they also provide the motivation for putting a full court press on automation. So checklists may be essential, but scripting and automating the build, package, and deploy is an absolute requirement.
What About Ant, Maven, and Make?
Experienced technology professionals are aware of the value of automating the build using tools like Ant, Maven, or Make. These tools are great and have withstood the test of time. Developers and build engineers use build tools to create reliable scripts to compile and package applications. Some scripts get pretty elaborate and others are elegantly simple. Whether you decide to dive into the complexities of the Maven build lifecycle supported by a repository manager or just whip together some Ant scripts, your journey to release automation needs to include these old friends.
As the governance, risk, and compliance market matures, product vendors and potential buyers alike are struggling to make the case for GRC implementations–whether it’s being able to point to credible return on investment figures, or building a business case to justify the expense of a software platform. This is certainly not due to a lack of value, but rather a lack of parameters to work with when defining essential elements relating to cost, benefit, flexibility, and risk. When possible, the GRC proposition should be driven by a vision of better governance and performance, but when pressed for more specific justification, the following factors will help provide specific supporting evidence to make the case:
The IT department will need to be equipped with teaching skills if they want to be of value to businesses of the future, according to Forrester.
Speaking to Computerworld UK ahead of Forrester’s Enterprise Architecture (EA) Forum EMEA 2011, EA research director Alex Cullen said that as businesses strive for greater speed and agility, and technology becomes easier for the business to procure, IT will no longer be the first point of call.
“Business people will be able to take advantage of cloud services without involving IT. They will need people to help them think about how to do it,” he said.
This is where IT staff can demonstrate their value to the business.
“IT will teach business to procure in a reliable, scalable and secure way. Organisations will probably want staff based on their ability to teach,” said Cullen.
“It’s a big shift because people will think about the business first, and the technology second.”
Cullen also believes that the IT department will become smaller, and while they will stay technical, their skills will be more focused on integration and sourcing capabilities.
“Change won’t happen in the legacy applications – they will happen around them. IT will have to integrate those things, but they won’t be the sole technology source,” he said.
A key message from the Forrester Forum will be that the role of the enterprise architect in a decade’s time will split in half, with one part remaining in IT in the way that is described above, and the other part moving into the business.
Cullen said this could lead to the creation of a new business role, such as head of planning and innovation.
He added: “The technology architecture will stay in IT and the business aspects of applications and information will move into the business.”
All contents © IDG 2010
I see this in two ways; Consultants to the business, or ‘Teachers’ both work in their own capacity. There was a time when Technologists held the golden key to the inner workings of technology. With the commercialization of technology, more and more people are becoming quite knowledgeable about the basics behind how technology works. It is almost an evolutionary thrust in which old-school technologists are fighting that shift from being the ones in the “know” to having to relinquish power and admit that they are not the single point for all that it IT. With a support background the choice is clear… teach or deal with the ramifications of unsupervised exploration, which more often than not breaks things.
I liken it to teaching someone to drive vs. having them take the keys for the first time and going for a spin. In the latter the odds of your premiums going up are pretty high.
On the other hand, as Consultants, you are able to leverage your knowledge and experience of technology to fully grasp and align technology solutions to business strategy. That is where the true value add is. Much effort is often used to shoe-horn technology solutions in place to deliver on a business strategy which has not had much exposure to newer technology solutions. For the technologist to reverse that trend by understanding the business vision/strategy then formulating a solution to deliver with a focus on stability, scalability and cost avoidance is something that is extremely valuable and rarely exercised in most organizations.
IT needs to stop viewing itself as simply a cost center and more as a true partner to business solutions. That comes in many ways, ‘Teaching’ and ‘Consulting’ are just the beginning.
Those who can’t lead, manage. Those who can’t manage blame others.