The CIO is a champion when it comes to procuring and deploying new technology elements in an organization. However, IT as a function does much more than making the tasks run faster; much of the advantage comes from generating information for decision-making, as well as in helping the organization become more efficient through better processes.
Now, it is at this point that the CIO becomes a bit shy at times. He wonders about how can he think of (and suggest) better processes in, say Production, Sales, Maintenance or Finance. Users in these areas are domain experts, and know the processes inside out. It will be odd to go and discuss improvements with them. He feels that a CIO is not equipped to deal with this task, and he would be better off dealing with the task he knows well. Some may find that this argument makes sense. However, isn’t the CIO missing a chance of playing a greater role in the organization?
In my opinion, a CIO has the rare distinction of being part of designing processes that cover various functions. Over a period of time, he develops knowledge of the business processes and inter-linkages between various systems. When discussing the process specifications, he comes across differing views of people. This opportunity gives him an insight of not just the possible solutions, but also about the underlying cultural issues. When he weaves these systems together to generate MIS for the top management, he has a chance to view the entire organization from a management perspective.
I have seen many a CIO playing significant roles in what is called ‘business process improvement’. I have also been a part of such exercises, especially so with ERP implementation projects. All that I had to do was to get engaged in a discussion with the users, raise innocent queries, or suggest changes (when appropriate). Things worked even better when I could put words into their mouth as they spoke about these changes. I applauded them and gave them full credit.
While it sounds simple, I had to work hard and make several attempts to be successful. I had to go around and study these processes in-depth before I could enter into such discussions. But what I learnt was that not being in operations was an advantage; I could look at the processes from an entirely different perspective. For instance, when I was with an automobile company, I could initiate discussions on inventory control measures which resulted in considerable inventory savings. It was possible to seed thoughts of declaring buffer stocks and transparency, thereby optimizing shop floor stocks. I could push towards synchronization in planning processes across sales, purchase and production functions which lead to arresting several redundancies. These opportunities came in purely through interactions with some of the senior managers and being persistent with reforms, despite being under fire for disturbing the prevailing serene environment.
More often than not, we find that a CIO initiates the idea of getting ERP into an organization for managing enterprise data. So the CIO has to go through the initial barrage of questions relating to the need of ERP; later on he has to prepare for the financial justification. Once he’s through with all these hurdles, the CIO then makes a plan for ERP procurement, and its subsequent implementation.
At this point, the CIO faces a dichotomy. The CEO sends the message that since the CIO got what he advocated for, he should manage the show. This means that the CIO should lead the project and make it successful. Now that the trap is set for him, the CIO picks up the bait.
Now comes the critical question—is the ERP just an extension of the other software packages that the CIO has been running? Since the ERP is another software, is the CIO is obligated to run the show? Many CIOs are possessive, and don’t want to hand over the mantle to someone else. He takes up the challenge, and in many a case, struggles to keep his head above water. Why does this happen?
The rest of the organization perceives of ERP as just another IT project. As a result, they pass on all privileges and responsibilities to the CIO. Now, the poor CIO has to live up to the generated expectations. Therefore, he proceeds ahead with the sole purpose of getting the ERP to run and generate promised reports. The organization does not get much out of its investment, and the CEO is obviously not very happy.
It’s not too difficult to find the reasons in such situations. An ERP project is more about helping businesses to run efficiently, rather than being a mere software implementation. Therefore, it calls for a greater participation from the business. Since an ERP implementation’s scope extends to improving business processes and generating better quality of information, various business heads (as process owners) have to come forward and take ownership for their respective areas. If there is so much play at the business level, is it not prudent to call in someone from business to head the project?
On this front, I will share my experiences with you. After having persuaded the management to introduce ERP in the organization (in 1998), I suddenly found myself in this familiar position. The CEO gave me the go ahead to start the project. I took the courage to tell him that this project’s head should be from business, along with the suggestion that he speaks to the ERP vendor as well as the implementation partner for advice. So the CEO searched for people within the organization based on this suggested profile, but not finding a suitable person, he reverted back to me and suggested that I fill the position.
I had then set two conditions for accepting this offer–first, that he should announce ERP as a business project, and not an IT project. Next was the clarification that I was chosen since I was the most suitable for that position—not because of my IT connection. These moves worked wonders, as the perception of the organization to this ERP project changed, and thereafter we received good support from everyone.
The outsourcing story is gaining ground in India, and is now widely practiced. Many organizations now look at external sources to manage some of these services, and all have their own logic about what they have outsourced. There has perhaps been no study to assess whether outsourcing has really been able to deliver the results in each case, and whether the model adopted by them was the best one possible.
Some organizations believe in outsourcing routine repetitive activities like facilities management, data center management, and software development, but keep the high level tasks in-house. Others believe in strategic outsourcing, and involve high profile consultants as advisors to give directions while keeping the menial functions within their organization. So the outsourcing story is not uniform, and depends on the organization’s stated purposes.
The question is not whether to outsource or not, but of which IT functions to outsource. It is important to choose the right outsourcing model that is most suitable for the organization. Models of outsourcing vary; it could be a complete outsourcing of IT, with only the CIO being retained as a co-coordinator. We have seen such examples in MNC organizations; examples in the telecom sector and among big IT players do suggest such a route to the corporate. The other model is one of partial outsourcing where one or more IT functions are completely outsourced. Some of the best exampled include passing on of routine tasks like facilities management, help desk, data center management, software development, application support, or tasks like 24/7 security monitoring. This eases the CIO’s burden, and he can then concentrate on delivering value to business.
In some cases, outsourcing is initiated by the management when they feel that services delivered by the IT Department are not satisfactory—either due to low performance, or due to attrition. In the other cases that I have seen, CIOs take the lead and put up a proposal to the management with sufficient explanation citing better delivery and cost savings, besides other factors like making use of external skills and service level agreements (SLA). As CIOs, we have to seize the initiative.
Perhaps, outsourcing has become so common and easy to practice that I often wonder whether this topic is now too relevant to debate. I would love to hear from people who hold contrary views.
Today you are the CIO, but what next? Truth be told, this question may not have clear answers.
Views vary, and so do the aspiration levels of CIOs. For a person starting at the lower level, getting to a C-level position could be the ultimate destination. Some may hold ambitions of getting to the Board level, while some may be taken in by the rants of ‘Can the CIO become a CEO?’ discussed as a topic in various seminars.
I have met quite a few of my fellow CIOs who rose up from being CIOs to become CEOs (of their outfits spun off as separate companies). Out of these, some managed it very well; others did not. A couple of others took the courage of taking over charge of a software (or service) company as CEOs. Many CIOs are members of the management or executive committees, and play a part in organizational decision making. Maybe, it’s that only a few CIOs get to be Board members, and a very few get to the CEO level of large organizations. However, becoming the CEO stays an unfulfilled dream for many, perhaps more because of the widespread debate generated at various forums.
Well, a few our CIO friends may beg to differ about this pipe dream. They say that they would like to grow in stature, and be more meaningful to the organization, rather than chase such a dream. For them, becoming more powerful is about getting to a position of influence where they can alter the organizational course. They could become trusted advisors to the CEO; help the company grow and get to be more profitable through IT interventions and in bringing about business process improvements. They could one day become a CEO too, but that thought is not overbearing on them. Others feel that the goal of becoming a CEO limits their thinking, and takes them away from playing a larger role at the industry level. Some maybe considering research, or becoming a consultant of repute, or of coaching and teaching. These too are positions of significance in society.
So can we say that attaining one such stated positions mean the end of the road for a CIO? Or is there more that he can aim for? Is there too much hype on this subject (thereby confusing the CIOs), or do people initiate this talk just for discussion purposes. It may perhaps be important to really understand the CIO’s need to connect with what he wants to do in life, rather than trying to push him into a race that he is not too keen to enter?
The phrase “IT should talk the language of business”, often makes a lot of CIOs self conscious. At the same time, this prompts the CIO to make this transition. To be able to talk the right language, the CIO has first to learn the business of the company that he serves, understand the market, competitors, challenges that the business faces, and the hurdles to growth. Once he has this background, he can confidently engage in a conversation with the business heads to understand their pain points and aspirations for growth.
For instance, to understand business, the CIO can volunteer to make market visits to understand the market, dealers and customers. He can go around the Plant to understand the manufacturing process, visit procurement centers (if any), or read the company annual reports for the last few years to understand the business philosophy as well as growth patterns. It may be important to meet all the functional heads to understand their perspectives on business and their expectations from IT. Once the CIO understands these business imperatives and concerns, he will be in a position to strike a much more meaningful conversation.
Now what stops the CIO from doing so? Is it the absence of an MBA degree, or that he has never been taught these in his technical course in college? Or is it that his talking of business may shift his focus from the responsibility of managing the technical environment?
These are all matters that we should seriously ponder upon. Now, some of these issues may be genuine in their own way. Nothing stops the CIO from pursuing a MBA course and understanding various aspects of business and management. But that need not be the only route; he can also read articles, have discussions with learned professionals, or attend seminars. He can shrug off the past and learn things afresh, even if he has not had a business orientation earlier. However, if he chooses to stay within his technical domain and excel, then it’s his own choice.
I have met a large number of CIOs in the industry and talked about this subject. While quite a few of them are eager and make attempts, many others are shy or short on confidence. If they really want to take that jump, they could seek assistance from their seniors in the profession.
“IT’s alignment with business”. We often hear this line spoken in various group discussions and seminars. But what does this term really mean for CIOs?
Does it mean building rapport with management personnel, or making the right noises in the corridors of power? Does it mean ensuring that IT plans follow the short/medium term business plan (if there is one), or towards your role in providing assistance for various functions in meeting their yearly targets?
For many CIOs, IT’s alignment with business may mean prioritizing projects as agreed with business, or building capability of business to compete in the markets. For others, it could be all about envisioning new areas and opportunities that executives may not have put their thought to.
I was also confused over this aspect earlier, and tried to unravel its meaning. Till then, I had made some IT plans which only I understood (but not the CEO). It took me some time to understand why he wouldn’t comment on my plans. Later I struck gold, and I think now’s the time to share my experience.
When I was with an automobile company, making an IT plan used to look difficult in the early days. Application of IT used to be meager in those days, and users had very little faith in the IT setup. Now, the good part was that I was fortunate enough to be part of the management committee, and therefore privy to discussions on various business issues. I used that information to draw out the main business challenges, priorities and possible solutions—this caught the committee’s attention.
The main concerns at that time turned out to be our ability to manage tremendous growth targets over the next five years, management of material availability, production scheduling, scaling down inventory (while ensuring availability to production), management of working capital, and being in a position to optimize the supply chain. Definition of a few business drivers and a measure of quantification helped me convey the message and draw out an IT roadmap for the next three years. But this was just half the story, since the real test proved to be execution.
Truth be told, the journey was tough, and I often felt like giving up. However, successful implementation of various systems (including ERP) and realization of benefits by the business really caught the interest of various functions. IT was then moving along with business, and all those in power started participating.
Back to the present, we may often claim to have perfect alignment with business, but vendors complain of certain CIOs being rigid when it comes to being open to new solutions. Sometimes, we are apprehensive of talking about technology in certain forums—just due to the fear that others will take us to be pure techies, and not real CIOs.
It sure is a dilemma, but is there a way out?