This site requires JavaScript to be enabled.
IE BUMPER IE BUMPER




IE BUMPER

Case studies  | World Wide Technology, Inc.

We're spending more time negotiating and getting better pricing on our service agreements, instead of being up against a deadline and dealing with the latest vendor contacting us to renew.


–Sarah Goellner, Director of IT Governance at World Wide Technology, Inc.
World Wide Technology, Inc.

 


The World Wide Technology, Inc. case study is based on an interview with Sarah Goellner, Director of IT Governance at World Wide Technology, Inc.


Founded in 1990, WWT has grown from a small startup to a world-class organization approaching $3 billion in revenue and over 1,000 highly trained employees. 


We're a systems integrator providing technology products, services and supply chain solutions to our customers who include the federal government, Fortune 500 companies and large telcos. We have 13 warehouse distribution centers across the United States and sales offices around the globe. 


Within IT, we've got about 120 people, all of them here in St. Louis. That includes the service desk; traditional IT operations with DBAs, infrastructure and end-user computing; and an applications team that includes developers and business system analysts. We run Oracle operations with our ERP systems and we have a standard development staff supporting a variety of technologies like Oracle, Java and Web messaging integration. 


We think we're a pretty good IT organization. At any given time, we have about 60 active IT projects, not to mention the significant queues of support and minor incidents that we're trying to manage with 120 people. 


My own responsibilities include service management, enterprise architecture and project management.


Time to rethink IT


Coming off a significant upgrade of our ERP system, we enacted our "IT Optimization Goal," with the objective of rethinking IT and running it like a business. Frankly, though, we needed to organize our efforts, and limit the firefighting. As a growing team, we tended to go from one emergency to the next, and while we excel at rallying our troops and delivering good results in those conditions, it's an exhausting way to run IT. So, we decided to organize our department better, with these goals: 


  • Streamline our support process so we can focus our resources on projects and enhancements and drive value for the business. We do feel lucky that we are an organization where IT is a partner with the business. Management understands that in order to work efficiently and grow, we need to automate our business processes as much as possible. 
  • Share resources more effectively, reduce our expenses and see our asset base more clearly. 
  • Centralize data on all the assets that we were maintaining. Different infrastructure teams had their asset database in an Excel spreadsheet, but there was no centralization of license management or vendor agreements. 
  • Consolidate tools. For internal incident tracking, we were using the same customer service application the company used for external customer inquiries. And, our application development team was using another custom application to track the movement of code through the environment. 


So we had these homegrown applications, neither of which we were actively maintaining, and neither of which were meeting our needs. Since our primary focus was on providing projects and support management for the business, tending to our own, internal IT needs around a tool set had never been a priority. We made it clear that we wanted to make improvements in IT, but it took too much of our time to maintain these two tools.


First, the processes


So to get away from the firefighting and move beyond the homegrown tools, we looked at the market and educated ourselves around ITIL. We saw this as an opportunity to standardize a couple of inefficient, disparate processes that different groups were using at different levels of maturity and, even more important, to put in place processes for approaching and resolving incidents, communicating back to the business, prioritizing our work and moving changes through the environment. 


I created a small IT governance team with two coworkers and we began educating ourselves on ITIL. We brought in an outside company to do an awareness class for all of our managers so they understood where we were going and why we were spending time on this initiative, and then we selected "process owners" throughout the organization. We wanted champions throughout IT who understood those disparate processes and would make sure that their needs were represented in our new processes. 


Next, we performed an internal, informal assessment of our maturity in incident management, change management and release management. We found out that we had processes in place, but that they were not documented or consistent. So, instead of jumping straight into buying a new technology or product, we started designing processes and relying on ITIL. 


We had a lot of process work to do. We spent three and a half to four months on incident management, and about six months on change management. 


Because we're a lean, light team, we compared what we had to ITIL and asked ourselves, "What are the big pieces of this? What are the must-haves? How can we apply this to our environment?" Now, we spent time understanding the material, but we're not the kind of company that will take a process flow out of a book and simply apply it. We made sure that the process owners bought in.


Next, the tool


We moved on to selecting tools to replace our homegrown applications. We had been in talks with Remedy for a couple of years, and there was some momentum around it. In fact, before we were introduced to ServiceNow, Remedy was probably the path we would have taken. But what always stopped us was the big-dollar figure around the purchase. Other companies using large IT management products told us about the need for a significant support staff and the complexity of customizing these applications. Every time we compared an expenditure like that to the business needs, it proved too expensive overall. 


When we came across ServiceNow, we saw it as a lighter-weight solution: less costly, more flexible, easier to customize and easier to implement. We were already customers of Salesforce.com, so we were familiar and comfortable with software-as-a-service (SaaS), and we spent some time with ServiceNow to understand them as a company. They spent time with our executive team and we found a good match between their culture and our own. 


When we announced our selection of ServiceNow internally, we noted that it: 


  • was the most cost-effective solution 
  • was evaluated and approved by a cross-functional IT team comprising operations, the IT governance team, the applications team, managers, associate level people and senior management 
  • provided best ITIL practices and good functionality around Web services 
  • could address, right out of the box, 85% of the enhancements we had proposed for our homegrown incident management application 
  • offered very good reporting, which we did not have at all with our homegrown applications 
  • would involve a smooth integration path, even as a hosted application 
  • had tremendous potential not only for configuring the modules for incident, change, release and so forth that come out of the box, but also for building our own modules and applications 
  • had a record of innovative enhancements and periodic releases of new functionality, so we saw that we could grow with them 
  • fit our company best in ease of use for our employees, applied to our processes and allowed us to customize the GUI.


Success to date in each application


Over the past two years, we've implemented four ServiceNow applications: incident management, change management, configuration management and asset management. 


One of our goals was to have better collaboration and communication between the application development organization and IT operations. And, by standardizing processes, we've seen a lot of progress in that area. 


Our first phase encompassed incident management and configuration management, and we now have processes that all of the teams use, including how we prioritize our work. We have improved analytics and reporting so managers can see the workload of each individual. The service desk now has a much easier way to understand and assign new requests. In the past, that was very difficult, but now they can take advantage of the CMDB and its integration with incident management to see how to assign an issue based on the application or the configuration items. 


Our employees can create and check the status of their own IT incidents and changes through the employee interface. 


Our second phase included change management and asset management. I think change management was the biggest ITIL leap for us as an organization. In the past, we didn't log operational changes at all, and the application development changes were a disparate process. Now we get together once a week as an entire IT organization and discuss significant changes, schedule them and prioritize them. We have a standard way of assessing the risk of all of our changes as one IT team, and we use ServiceNow to facilitate that entire process. 


Thanks to asset management, we finally have a central repository of both our logical and physical assets, and it's integrated with the other modules. As an infrastructure person, I can see that a configuration item (CI) is tied into a contract, so if I need support on this server, here's who I call, here's the level of maintenance I have, and here's what it costs to bring an engineer on site. Before, I would have had to run around and collect the information from several different people. 


Our entire IT organization uses ServiceNow; all of IT, operations and the application development group, currently about 120 people. Also, since we are a systems integrator, we have a managed services offering with an engineering staff providing support primarily for Cisco technologies, and we manage that through ServiceNow. They too need incident management, change management, release management and asset management. 


The real win for us is that configuration and asset management are on a single platform with other processes.


Cost savings


We've saved a lot of money in reduced management time thanks to ServiceNow. Before we had this consistent process and single tool set, our managers and team leaders used to spend a lot of time gathering a hodgepodge of data in spreadsheets, updating this, sending out that information, and so on. After massaging it, they had to spend time administering our work, prioritizing, escalating, and reporting status. Now that's all logged in a single fulfillment and different items are assigned to different individuals in different groups. Instead of gathering data, we can report on them and spend our time making decisions on them. 


Service desk saves us lots of time in figuring out where the knowledge is, who supports a particular configuration item and who can troubleshoot it. We were able to retire our two homegrown applications, which saved us a lot of time and maintenance, and we can support more groups and processes than we did before with the single ServiceNow application. 


We also save management time and effort by allowing ServiceNow to assure the data integrity, operational recovery and overall disaster recovery naturally as part of SaaS application.. ServiceNow has a certified data center, with their own procedures around backup and recovery, and we work with them to understand that and rely on them to provide those services. 


We've improved the timeliness of our contract renewals now that we can see when maintenance agreements are coming due. We're spending more time negotiating and getting better pricing, instead of being up against a deadline and dealing with the latest vendor contacting us to renew. 


The single, biggest area of improvement has been the cooperation and teamwork between our operations and application development teams. Thanks to ITIL processes and meetings, we've avoided many of the past situations in which we wanted to make a change and did not understand the impact that it would have on another team, or didn't understand the need to schedule the change around a major project or initiative.

IE BUMPER
IE BUMPER
Detail - Knowledge Detail Have a Question? Access the Community Demo Now
IE BUMPER