One of my summer jobs in college was working on a boat that supplied drilling rigs in the Gulf \nof Mexico. We would set out, often at night, to a point on a map. This was in the pre-GPS days, \nso our autopilot did not account for the ocean's currents. As a deckhand, it was my role to watch \nthe helm while the captain got some rest before the real action started. I would have to adjust the \nautopilot to correct for the drift we encountered. \nFast forward to today. I am again in the position of charting course, this time as the CIO for a \nnew company. And just as before, it requires constant attention to reach our destination. \nMy company, Inteva, began its life as a division of Delphi Automotive before being sold to a \nprivate equity investor March 1, 2008. Our division, which makes automotive interior and door \ncomponents, was sold since it was not considered to be a core business for Delphi. I came on \nboard September 1, 2007, as CIO for the new company, six months before we were to be spun \noff. My task was to determine where we wanted to go "after we grew up." \nOne thing was certain: We were going to be a much smaller organization than we had been \nbefore the spin-off. Yet despite our size, we still faced the challenges of a global organization \nsince the new company has 13 manufacturing and engineering facilities in Western Europe, \nNorth America and the Asia Pacific region (APAC). IT would need to offer a level of service \nthat is more difficult to provide when compared to servicing an organization that works within a \nsingle boundary or region. To complicate matters, the Transition Service Agreement that was \nbeing negotiated gave Inteva just twelve months to migrate the entire infrastructure and \napplication environment away from the former parent. So, we were a startup company with a \nninety-year history. The Need for Change\nWe faced a complete overhaul of our IT environment. In addition, I was challenged by our CEO \nto reduce IT costs dramatically (dropping from two percent of revenue to less than one percent). \nTo accomplish this would require a new mind-set with radically different solutions to our \nrequirements. SaaS, NaaS, and AaaS would be the only options we would have to make this type \nof change in such a short period. We've all heard by now of SaaS\u2014software as a service. \nIn some corners, I've heard of NaaS\u2014network as a service. Some people go as far as \nsaying AaaS\u2014anything as a service, including communication, infrastructure and \nplatforms. I am working to implement all three. \nAn AaaS approach frees IT to be a strategic partner\u2014aligning our team with the business \nunits by providing support staff for each function. My career has been built around servicing \ninternal, and occasionally external, customers. Alignment only occurs when you dedicate time \nand resources to go out and work with the business. It never happens with a skeleton support \nteam that stays focused on technical issues. \nOur moves to SaaS for ERP and NaaS for our wide area and local area network functionality \nallows the IT organization to work on business process reengineering and support. While \nremaining a very lean organization, our 14-person group can now focus on the various business \nareas (sales, finance, engineering, etc.) without the challenge of maintaining a large \ninfrastructure. This has changed the face of IT within the organization\u2014moving it from a \nboxes-and-wires organization to a partner in growing our business. \nThe greatest challenge we faced was to move off of Delphi's existing, client-server-based ERP \nsystem. We had 15 months to move off of the existing SAP systems. As a part of Delphi, our \nEuropean and North American operations ran on separate instances of the heavily customized \nsoftware. Our APAC facilities did not use an ERP system. \nThe SAP ERP system also did not support all of Inteva's business processes. We knew going \nforward that we required a robust engineering release and change management facility, the \nability to track tools for reimbursement from our customers, and communicating to our suppliers \nfor orders and quality issues. But we did not want to bring in a large system that would require a \ndedicated army of programmers to support. \nWe searched for and found an ERP provider that fit our needs. They provided a SaaS model, \nallowing us to run as one client among many on a single instance of their software. This would \nallow us to have customized applications, running within their support environment. This \napproach will let us beat the transition deadline of July 2009. The provider has a robust, SAS 70 \ncompliant environment that we could not duplicate, and it will have an operating run rate that is \n75 percent cheaper than the client server model we were on. IT would also be freed from \nsupporting a large server environment to host the system. \nThe network migration would be another major challenge. We would depend on this happening \nbefore we could begin the migration of our infrastructure services. The initial plan was to stick \nwith the network provider of our former parent. It quickly became evident, however, that this \nwas not a viable option due to cost. \nWe began looking for a virtual network operator, one who could provide service globally \nwithout the overhead of a carrier. We would require a much different environment than in the \npast. We would use the Internet more for services, so we had to build an environment that \nfocused on Internet access rather than WAN services. We wanted firewalls, filtering, telecom \nand all network services to be provided by a single vendor. And we wanted to eliminate the need \nfor a network manager on staff to oversee this, again freeing IT staff to focus on business rather \nthan technology. \nWe found such a provider and began discussing our requirements and negotiating price. In the \nend, we will cut our network costs in half while replacing the entire network infrastructure from \nthe switches and PBX up. Most of our sites will see a dramatic increase in network capacity, a \nreal bottleneck in the past. Our WAN and LAN migration will be complete by January 2009. \nBumps in the Road\nOf course, there were some bumps on the road. One was management's concerns about the \nsecurity and viability of running ERP and e-mail as SaaS-enabled functions. These are \ndefinitely two of the biggest sacred cows in the mind-set of most companies. Cost was one of the \neasier arguments for making this move, but the ability to focus the IT group on business \ntransformation ended up being the winning point. \nSo, how to meet these challenges internally? I had to step back and try to build a complete road \nmap. After a long IT career, it's easy to jump in and start solving problems. But I knew building \na road map was critical to the success of this endeavor. My take was that the first step was to \nbuild up the infrastructure and project management organization so they would own the solutions \nthat we sought to put into place. Once we had a skeleton staff for the infrastructure and project \nmanagement areas, the team could begin analyzing the current structure and cost elements of the \nWAN, LAN and server environments. \nWe quickly determined that a basic support plan for each country made better economic sense \nthan the global structure we used as part of Delphi. Between that step and selectively insourcing \nsome functions, we were going to drive our desktop and server support down by 66 percent (and \nyes, that included the insourced staff). In some low-cost country locations, we hired the support \nstaff that had been onsite. In the US, we've gone to a provider than can support us in our region. \n\nWe did recognize, however, that we would still have several global needs. One would be the \narchitectural design for servers, network and e-mail. We had also decided that we would be \nrunning one ERP with all of the entities connected. \nE-mail was the first element to migrate since our goal was to be seen as a separate company on \nour first day in operation. We found a hosted mail service that would allow us to transition our \n1,100 users in a matter of weeks. We now pay for e-mail by the mailbox with the monthly fee \nbased on the size of the mailbox. BlackBerry support has an additional small monthly fee. An \nadditional benefit is that users can check mail directly over the Internet. IT's only support \nrequirement is to add new users, reset passwords and upload a file to the provider to periodically \nupdate phone numbers and other data. \nOur plan to minimize the impact of the move is to leverage the existing AD structure, private IP \nnumbering, and file and print naming conventions. As our facilities move to the new \nenvironment, nothing would need to change. Our support structure involves our help desk \nprovider also monitoring our servers on a 24\/7 basis, freeing IT from providing around-the-\nclock monitoring. Measures of Success\nSo, have we been successful? While we are still working on the process, at this point I can \nconfidently say yes. Our planned systems are meeting the goals of reducing cost and support \nrequirements. We're achieving that elusive alignment goal, we've built our business support \nteam up and have a good working relationship with the business. And our CEO has stated that he \ndoes see IT as being a strategic partner with the rest of the company. \nAs private equity acquisitions accelerate in the current economic environment, more CIOs will \nface the challenges we're going through today. Swallow hard and take a long look at AaaS. \nInvest wisely to achieve your primary goals. \n Charting a course in unknown waters is challenging. But it can be done, provided \nyou have both vision and the right tools for the job. \nDennis Hodges is the CIO for Inteva Products in Troy, Michigan.