Business Process Management (BPM) is a subject which has been discussed widely since early 2000s but did not go far during the early years after its debut. Like many other technologies this too was shrouded in mystery till it attained maturity over time. It is perhaps necessary to demystify the concept and explain it in simple terms.
BPM can be defined as a holistic management approach to aligning an organization’s business processes with the wants and needs of business. It is a systematic approach to continuously improve business effectiveness and efficiency while striving for innovation, flexibility and integration with technology. In effect it is about attaining a certain level of operational excellence through business processes which run seamlessly across functions facilitated by technology. It is argued that BPM makes organizations more capable in handling change than functionally focused, traditional hierarchical management entities. As a managerial approach I would say that BPM sees processes as strategic assets of an organization that must be understood, managed and improved to deliver value-added products and services to customers.
BPM is often compared with TQM and continuous process improvement methodologies. In my opinion all these approaches have a lot in common though BPM goes a step further by taking support of or getting enabled through technology. In fact BPM offers an approach to integrate an organizational change capability that is both human and technological.
The need for BPM
Companies in the past developed pockets of automated systems over time which many cases were not integrated. The difficulty got further accentuated due to use of different platforms that were not compatible. Business processes therefore experienced disconnect, as users had to wade through difficult interfaces to complete their transactions. In some cases customers needed special integration tools and other generic tools but found it difficult to manage. BPM then came as a suite of tools that could help provide integration across applications in a way that business processes could proceed without break or interruption. They also offered various value-added features that could help organizations perform better.
Operational excellence can be achieved either through the use of a BPM software suite or with use of other integration tools like SOA, web services, RFC, content management, business intelligence or other proprietary tools like BAPI etc. The purpose would be to work out a wholesome solution which addresses business concerns and enables the organization to tackle competitive forces better.
A BPM initiative should be run as a formal project with essential steps like developing a vision, working out a design, doing data and information modeling, execution with tight project monitoring, and process optimization using business reengineering principles. The effectiveness of the BPM can be known by measuring specific parameters or KPIs and comparing it with status that existed at the start of the project.
Features of BPM suites
BPM suites are rich in features and can be very helpful. The four critical components of BPM include the process engine, business analytics, content management and collaborative tools. Listed below are a few features that enable business to get better:
– Allows process composing and simulation. Provides flexibility and agility to business through process orchestration.
– Allows specifying business rules which can then automatically control business processes.
– Enables integration across applications on different platforms so long as they conform to industry standards.
– Facilitates collaboration among business users and improves efficiency
– Can define metrics and key performance indicators and helps the business monitor performance and provides data for continuous process improvements.
– The Business Activity Monitoring (BAM) sub-module which can provide real-time information about the status and results of various operations, processes and transactions. Can generate alerts when any crosses a defined threshold.
It is important to optimize and improve business processes in order to get better and be operationally excellent. When automating, it is essential to choose the right technology to enable good process management. While many organizations use different tools to achieve the purpose, adopting BPM package has a distinct advantage. Given the importance of this approach, the term is nowadays even referred to as Business Performance Management. BPM is now also available as a SaaS model and for those who have not yet got initiated in this process, can consider the cloud option as a possible solution.
There is no denying the fact that users play a significant role in a CIOs life. Some say it is they that we work for and we should not falter when serving them. They may have their idiosyncrasies and tantrums but they after all are our customers. ‘Customer is the king’ – so the saying goes and sowe are supposed to hold them in high esteem and serve them well.
This scene is not new and I am sure all CIOs will agree, having experienced it all. The fact is, we may find it easier to pacify a crying child than to manage these intelligent and mature blokes. All niceties and diplomacy we may adopt and wish them well every morning but these intelligent beings could still be unrelenting. They are smart and often see through our diversionary tactics and not willing to let go off their demand.
In the years gone by, users were novices and had very little idea of technology and hence we could take them for a ride. Today, however the users are IT aware, are IT professionals by the half and often flaunt their expertise at the drop of their hat. They can operate all these new fangled gadgets whether they are smart phones, note pads, fancy laptops, wi-fi enabled physical objects, and strongly believe in the ‘internet of things’. Dealing with them therefore gets a lot tougher.
I will classify the venerable users into four types and explain their characteristics truthfully.
Users who want it as of yesterday
These are users who are always in a tearing hurry. They approach us with all seriousness and emphasize the urgency even before they spell out their need. When asked about the required date they wish if it could have been done yesterday. To quote my experience with the sales function of an automotive company – the sales manager brought the revised price list of spare parts to be made applicable from the beginning on next month which was just 4 days away. These rates which were decided in the sales summit, were a complete revamp and the list sported flexible pricing varying from one state to another and also for certain districts. When I explained that this involved configuration and that the pricing structure was not amenable to automation and therefore it was not possible to do by the time desired, the immediate reaction was that they thought with ERP everything should be simple. It required a lot of persuasion to make them drop their immediate demand.
Users who demand without examining feasibility
These users have their demands and pass on their laundry list to the IT department without ever studying it at their end. Like in one of the companies, the user from production came out with requirement of usage parameters and costs analysis at the machine level. I had to remind him that data was being captured only at the line level and if their requirements were to be met they would have to enter production data for each machine separately. The user was caught on the wrong foot and did not return.
Users who demand citing examples from other organizations
These are users who have contacts outside of the organization and brace themselves with developments in various companies. They come up with requirements with examples of how it is being done in other places. Sometimes it needs explaining how our situation is a bit different and may require a different solution. For instance the sales manager once came to me with a proposal to introduce mobility with the field sales force and when questioned on the expected benefits he came out with examples of three other companies where this was being practiced. Those companies were from the FMCG block and therefore the needs were different and this had very little use for the company in question. The user murmured a few inaudible notes and left with a complaint.
Users – the IT aware and pseudo experts
These users are smart, have a penchant for the latest gadgets and their fingers move fast on note pads, smart phones, laptops and the like. They book tickets, make payments online, and do banking and investments on the go. These users want all these features from the enterprise systems and want everything including production data, sales figures and analysis, financial data, salary particulars, leave data, stock reports, MIS etc. either on the web or on their mobiles. It is difficult to argue with them citing our present application architecture, inadequacy of the application or upgrades necessary as they argue that if Banks can why can’t we.
So friends, here we are trying to deal with highly evolved customers who cannot easily be dislodged from their position. One has to learn diplomacy, negotiation skills, special combat training and great story telling to wind our way out of this puzzle. So long as the users are in their true colors, the life of the CIO will continue to be interesting and adventure filled.
Companies often get into emergency situations which may have descended upon them unannounced or could be one of their own making. Some problems crop up when we least expect them or perhaps when they could not be anticipated ; the least we can do in such cases is to get act immediately to address the problem. However in most situations problem develops over a period of time but we ignore the signals or are complacent till we see the water rising over our heads. This is an area that needs our attention and I will discuss this citing a few examples.
The problem as it evolves
Many problems that we face, develop over time but manifest themselves when operations are impacted adversely. However we tend to ignore the signals or are casual in dealing with them often hoping that the situation will correct by itself. These are risks which the CIO needs to take cognizance of and initiate steps to mitigate the losses. It is not uncommon to make mistakes or to misread a situation but the approach should be one which takes note of signals and act on them expeditiously. Common reasons for not acting on time are as follows :
a. Problem not understood : The risk is not comprehended and its impact is not understood.
b. Ignoring or not seeking more info / research : The signals are ignored assuming that it is not significant and no effort is taken to find out more. The likely impact is not assessed.
c. Hoping it will resolve itself : Simple shirking of responsibility hoping that the problem will disappear on its own. We are guilty here of inaction and negligence.
d. Buying time / procrastination : Period of indecision and avoiding upsetting the applecart. This is about deferring action and waiting for the time when the going gets really bad.
e. Reluctance to change : A sense of insecurity when dealing with a new solution and therefore an effort to make do with the current situation with a few corrections here and there.
A few examples
Let me describe a few instances from my experiences to explain to buttress my views.
In one of the companies where I was the CIO, I inherited systems which were developed by a few software houses, some of them being boutique or specialized outfits. The systems therefore were developed in not so popular platforms but they extended support for a smooth running. A little later their support deteriorated with some problems taking long to attend. Personnel working on our account started disappearing. I took time to react assuming this to be the normal attrition that plagued the software sector and seemed satisfied with the owner’s assurances. I finally acted only when the situation became impossible and had to get the system redeveloped by another vendor which took time, during which the users had to undergo considerable hardship. There was a lesson for me to learn here.
A company that I am an advisor to, suffered disk crashes on their servers and the CFO requested me to speak to the vendor to set this right. The hardware vendor reverted with their analysis stating that the disk surface had suffered erosion and blamed the environment. The issue was clear – the factory environment (chemicals) was the reason and I advised them to move the servers and storage to an external data center. The company took time to decide fighting off internal resistance of people who didn’t want the data center to move out. The shift took place finally when the systems went down and the hardware vendor refused to service unless the equipment was moved out.
In another case, the company had servers, storage etc. hosted in an external data center and working smoothly over time. The services started deteriorating with the connectivity which was also handled by them failing a little too frequently. The news was out in the market about the vendor facing financial difficulties. The company dithered, hoping that the vendor will turn around but got caught when services broke down in several areas and then they had to work on borrowed facilities till they moved their equipment to another data center.
There is lesson here for all of us. Risks do arise and start affecting us but it is for us to manage those risks. There are always early signs which are visible but we need to take note of them. We have the responsibility to prevent the company from risks and hence necessary to analyze all such situations and take preventive steps to avoid or mitigate losses that the company might be exposed to.
I have often faced this dilemma when moving to a new organization. In new organizations, the systems I had to deal with were either in a good shape or in a bad condition with very little documentation. Places where the systems were well defined and documented, I had very few problems. All I had to do was to review and determine whether they were in the right direction or needed suitable changes. At other places where I landed up with systems in a mess, recreating new systems proved to be a massive challenge. Let me deal with both these situations.
In any new organization that we move into, systems do look alien and different from what we may have been doing in our previous engagement. A natural tendency would be redraw plans to bring it in line with what we are familiar with – the same hardware platform, software packages or vendors. That would really be a waste of effort and a move just for our comfort but not necessarily for the good of the organization. Such a situation calls for a dispassionate assessment of the status and determination of what is best in the circumstances.
Bad state of systems
In a couple of situations I had landed up in organizations which had no real enterprise IT worth its name. In one place I found a host of disjointed systems developed over a period of time for individual functional use and a later attempt to force integration by writing some programs for data transfer. There was no method in the build up to the final architecture and some of the systems used different platforms perhaps born out of personal preferences of the then software developers. Another situation was one in which the company installed a certain ERP though not successfully and therefore topped it up with a host of external systems to supplement unfulfilled requirements. In the absence of good documentation, handling of the systems was best left to a few individuals in the IT department. Sorting out such a mess I thought would have been a nightmare and therefore recommended to the management that a fresh study be instituted to assess the company’s requirements anew and that we redraw a new IT Strategy. These were right decisions in my opinion and it worked out well in the long run.
Reasonably good systems
Even organizations that have reasonably good systems pose a challenge to the new CIO. The CIO has to exercise discretion and draw up new plans that do not carry a personal bias. Let me illustrate through two examples.
In one of the organizations that I got into, the team had decided to go ahead with Oracle ERP and had also placed order on them. Having been on SAP for the last few years I had a strong feeling within that I should persuade them to change their decision and get in SAP instead. In fact I had started asking questions about their choice in an effort to prove them wrong. A little later however I realized my pretenses and decided to get along with my colleagues to build further with the platforms and tools available.
In another organization the situation was very different. Systems were reasonably good and were well documented too. The previous incumbent had drawn up an IT Plan which had been presented and agreed with the management. The plan also carried a roadmap for the next three years. While all this looked impressive I was only worried about one aspect of the approach. The plan reflected a strong personal bias of the previous CIO. He had, perhaps because of his previous background, based his entire plan on the basis of tailor made systems, and that too developed by small boutique software firms (he had a particular dislike for large firms) and even elements like system interfaces, security, identity management were sought to be developed using web based software or scripts written specifically for our needs. I somehow felt this would place the company at the mercy of developers and a strategy that could turn company’s attention to IT instead of focusing on the needs of business. I decided to redraw the strategy placing emphasis on using enterprise packages and solutions and away from software development. That put us into the mainstream of business and we derived wonderful results over the next few years.
Drawing from experience I would opine that taking up a new assignment always poses a challenge. We stand at cross-roads not knowing whether to toe the same line or make changes. We have to act in the best interest of the organization and keep our personal preferences and bias at bay so as to make the right choice.
I have been in several companies as CIO during my tenure but the ones which had extensive Quality (TQM) related programs were a little difficult ones to handle. Not that I disliked the quality movement, for I myself was part of the core group in a couple of companies, spreading quality awareness and monitoring progress of projects. I would not even say that this interfered directly with my department’s working but being company-wide programs we were asked to fall in line with the activities.
Quality circles formed seemed very effective on the shop floor, in quality control, field service etc. but running them in administrative departments like ours was always a challenge. We had to pick up some innocuous projects and were frowned upon when presented. A few indoctrinated individuals, intoxicated with the quality approach, would preach their methods to us asking us to make the pareto-chart, fish bone diagram etc. for every presentation ignoring the beautiful and meaningful graphs drawn and statistics made out by our staff. This was really a dampener.
A further prescription pushed on us was that of process orientation, one which says that if your process is right good results will automatically follow. Nobody can dispute the concept, however a single minded push (of this idea) creates an imbalance in our minds. For example I had an sweet little memento on my table given by our technology vendor, which read “Think…results”. A big objection was raised by the overzealous quality followers saying that as a department we were deviating from the quality ethos which says think process and not results. I took pains to explain to him that in a different context it means our actions should culminate in our getting clear business benefits. Similar were other run-ins which acted as hurdles for us to overcome.
Let me also cite example of my experience of engagement with a client for whom I was an advisor. The company is in the business of manufacturing and is in the engineering sector. The CEO of the company had engaged me to guide the company in making IT more effective. The company has a strong orientation towards quality processes and the head for IT & ERP happened to be one who was earlier engaged in planning and quality processes. The IT set up and ERP implementation were very well handled and all processes were running smoothly. Documentation was maintained, regular presentations were made to the management committee, review audits were conducted for various units, several cross functional teams were constituted to solve various problems etc. All seemed perfect and therefore any observer would wonder what more needs to be done.
There was the catch. If everything were so hunky dory, why would the CEO feel the need to hire an external consultant to get more out of IT. I remembered what the CEO said, ‘we do not get much out of IT and I want it to be more effective’. Now as I studied the whole set up in detail, the problem seemed to get clearer and way to overcome them got crystallized. The whole IT program was being run as a quality project. The entire emphasis was on process and the focus was on getting each step right and in doing so they lost sight of the intended results. For example when I pointed out that the MRP results were not being followed completely and considerable manual intervention was required in raising purchase orders on suppliers, the department promptly constituted a cross functional team (CFT) to discuss and work out a solution. As the CFT progressed, small solutions emerged to narrow the error gap and after a few sittings they decided to declare the CFT as a success and to close the exercise. I raised my objection saying that the problem was not yet solved and that the objective of zero error was not achieved. It was argued that the process was right and that gaps would be addressed over time. The team was then reorganized to start another CFT. Similar orientation was observed in the implementation of other systems and even if the systems failed, the team took refuge in the fact that all correct processes were observed. Again the focus was not the end result but the processes. It was difficult to cut through organization culture and make things work. They say excess of everything is bad and therefore excess quality orientation is also counter-productive.
Does that mean Quality approach is not right for IT. Well, no. The philosophy and methods are dot on but the trouble arises when people follow the approach in letter but not in spirit. We have to follow standard and formal processes but keep an eye on our targets and goals. In so far that we maintain our balance things work beautifully and we get the desired results.
Application systems in organizations today cover a plethora of functional systems and are expected to provide a unified view of information for organization decision making. The old stand-alone systems or loosely connected application systems were replaced by standardized ERPs many years ago. ERPs covered many functional areas including sales, finance, purchase, inventory, production, operations, quality, human resources etc. and all these systems were fully integrated on a on-line real time basis.
Companies however go beyond the basic ERP to meet the organization requirements. They add new systems to cover their specific needs which the ERP cannot address. Two types of applications have emerged :
– Special systems either in the form of packages or developed applications that address requirements not covered or adequately so by ERP. These include various web based systems to connect people and partners external to the organization. Since these too are business critical systems they need to exchange information with ERP.
– Additional packages covering supply chain management, supplier/customer relationship management, business intelligence, product lifecycle management etc. These packages could either come from the same ERP vendor or from other software houses. These have to closely work with ERP to execute business processes seamlessly and have to use common data to give consistent information to the management.
These separate systems are organization systems and need to interface with the ERP for exchange of data in an on-line mode. As long as the extended systems or packages come from the same ERP vendor there are no integration issues. However, solutions chosen by us usually come from different sources and this is where the problems begins.
Realizing the fact that various systems need to talk to each other, industry bodies came up with standards and wherever the software packages followed standard methods and protocols of exchange, all systems could work seamlessly. An interface is the communication and data integrity between multiple production applications. The solution is however is not as simple as it seems – to enable systems to communicate you need a middleware to make this happen. These middleware solutions come from different vendors but are prohibitively expensive and I do not understand why it should be so. Let me illustrate this with my experiences in three different situations.
Company 1 : The first phase of the ERP project covered a few modules like purchase, materials and finance and therefore the ERP had to interface with homegrown systems covering production, sales and service. The vendor suggested the SOA layer that they had just then introduced but it did not fit into our budget. Since the vendor was keen to have initial customer for this new introduction, they brought down the rates to the levels that we could agree to. We were lucky and could work on integration though had to bear consequences of being the early users and were used as guinea pigs.
Company 2 : The company had successfully implemented ERP which was running well. They extended further to put in BI system from the same vendor. At the same time they implemented a couple of other systems from other vendors and also an intranet portal which was custom built. The senior most executives were still not comfortable in using the ERP by logging in and navigating through the ERP menu screens. I suggested that they access systems through the enterprise portal which could link all systems so that they use the single sign-on and customized home page facility. Though the enterprise portal was bundled in with the ERP, it could only give access to their own products and for linking to external software packages we had to pay a hefty sum for the interface. Other vendors too were called but they too quoted a fortune for their middleware. The client then decided to defer the proposal for a later date.
Company 3 : The company has just signed off for the ERP but still has a lingering dissatisfaction of not being able to work out the complete solution. The company which is in the medical equipment business has a couple of applications covering their service, quotation and equipment demo activity which they wanted to interface with the ERP. The ERP vendor dished out the usual license fee for interface which shut the lights out of the client’s mind. He decided to revisit this requirement at a later date.
These examples illustrate the fact that online interface between diverse applications using industry standard methods is still a little out-of-reach of the normal user organizations. Increased competition may force a reasonable pricing at a later stage but the pricing as on date continues to be unreasonable. Vendors need to revisit their pricing policy if they want to increase sales and popularize this technology solution.
I have been trying to find answers to this question. Many organizations choose enterprise systems ranging from ERP, CRM, SRM, PLM to SCM and the like but have sometimes very little idea what they are getting in to. Many who purchase feel this is the in-thing and take comfort in the fact that many others have gotten into the same game. Some complain about the failed experiment but others feel content or are indifferent. ERP is the most used among enterprise systems and therefore I undertook an informal survey to find out how these companies took to ERP. Reasons that emerged were varied and often funny. Let me list a few of these situations.
Replacing legacy systems – This is the case that I come across most often in companies. When the old legacy systems start creaking at its seams and are unable to address business requirements, the management, users or the CIO deem it appropriate to replace the old systems with an ERP. If the main purpose of ERP is replacement of earlier systems, the outcome of implementation will always be limited to replication of old features in the new system. Bigger Issues like transformation, business process improvement or new ways of doing business, don’t find traction. Since they start with humble moorings, they stay happy with what they get.
Where users dominate – There are few organizations with a federal IT structure, where strong business or functional heads call the shots with respect to the IT solutions they need. They argue in favour of the best-of-breed packages and keep their focus on what they need. I have known organizations where users in HR chose Peoplesoft, IT & Finance chose SAP, Plant maintenance chose IFS and Marketing went for Siebel systems. The poor IT manager was left with the task of integrating them.
CEOs diktat – Here the CEO takes the call. This could be after a consultant filled his ears with the grand concept or when he finds himself out of place in a party where his friends discuss ERP. So he comes back to his office and issues a terse command asking ERP to be bought. I remember of one instance when this CEO went on an official visit to their collaborators in Germany and on noticing them using SAP successfully, called up his CIO from there and told him that he would like to see SAP running in the organization on his return the following week. Fast decisions are always welcome but in such cases no one knows what to expect out of such systems and are left grappling with it for long.
Managements’ informed decision – This is the most desirable of all cases. Here the seniors consider the market trends, the competitive situation and strategies for growth. They feel the need for enhancing organization’s capability and decide on ERP after discussing with consultants and informed sources in the industry. The whole project then proceeds as per plan and with clear objectives. They achieve breakthrough and bring about significant improvements in the way they conduct business and leave many others far behind. Other companies try to emulate their success.
When CIO proposes – God save such companies – these are usually from the SME sector. The CIO strongly recommends an ERP and gets away with it. His sole interest is to enhance his profile and having dabbled with the system for a few months to a year, finds another opportunity and coolly abandons them leaving the company in the lurch.
Many companies complain that they have not got enough from their enterprise systems. They however need to ask themselves if they made themselves aware of the intended deliverables before approving the project, like they do it for other business projects, and if they had at all enquired or lent a helping hand when the project was in progress.
I have dealt with quite a few companies either as a CIO or as a consultant but except for two instances, I got into these companies after they had decided on ERP or other enterprise systems like CRM, SRM, BI, PLM etc. Incidentally even as a consultant I am usually called in by clients for help after they have begun implementation or later when they want to get more out of the systems implemented. I only wish that companies call in advisors before they begin so that they take the right direction at start rather than doing course correction later when it is too late.
Learning never stops and as the saying goes ‘it is never too late to learn’. New challenges appear every day and we are forced to deal with them. If the same problem crops up every time we will know how to deal with it but that is not what usually happens. We live in an environment that is rapidly changing which throws up new challenges and we always need new knowledge and skills to effectively deal with them. It is therefore important not to remain static but to keep improving.
It is natural for us to stay in the comfort of the world we know. We may, at many times keep doing the same thing day in and day out and feel like an expert in the area. We then flaunt our experience to claim superiority over those who have spent less time. Once when one of our seniors proudly proclaimed that he had 20 years of experience, my boss quietly whispered into my ears saying ’20 years of experience or one year of experience 20 times’. That was quite a loaded comment and that little expression stayed with me for long. Experience has very little meaning if it is not rich with knowledge gained over this period.
CIOs shouldn’t miss out the opportunity
While learning is essential for everyone, I will specifically speak about the learning culture that CIOs need to adopt in order to stay relevant. There are many a chances that CIOs miss out. Take for example interaction with vendors – they hand out hardware or software specifications to vendors and ask for the price quote. Selection is often based on superficial comparison of features and commercials. However if CIOs define their requirement and let vendors suggest solutions, they may get new ideas and if they raise queries on technology, the vendor would educate them for free. CIOs again would do well to attend external events like seminars, symposiums, user group meets etc. which could accord a great opportunity to understand the current trends and new solutions. I have also seen a lot of CIOs being shy of networking with fellow professionals from other companies where they could share ideas and also experience of dealing with various situations. Nothing could be better than hearing from users who have done it themselves.
Learning cannot be in vacuum as all the knowledge we gain is based on interaction with others. It is a good practice to involve our team in an act of discovery. If we involve our team members and throw up a challenge asking them to work out solutions, you may see innovation at work. The interaction that ensues creates a learning environment where each of the stakeholders benefits. While we can learn on our own, a collective effort makes learning faster and well grounded. A well informed and an intelligent team carries much more weight than stray individual brilliance.
Putting learning into practice
Knowledge gained remains incomplete till it is applied in the real world. So here is the catch. New ideas, new technologies learnt and new solutions evolved have to be put into practice. The CIO has to overcome the challenges of budget, approvals and getting users on board. New initiatives always come with a risk element and it is important for the CIO to muster courage and be ready to put his neck on the block. Great leaps take place when there is a will to win and a desire to go where we have not been before.
Learning should not be a forced activity or a routine to be prescribed and followed. It is the hunger to evolve and get better, a desire to break new grounds and a commitment to excel that gets us into a continuous learning mode. It is a habit that does not require extra effort but sets us on the path of excellence.
We always choose the easy way to take care of issues we face. When confronted with a problem, we wish for a readymade solution to make use of, or having successfully solved a difficult problem, we want to use this success mantra in every situation that we are faced with. We tend to pick up a solution from somewhere and try to plant it in our environment ; and I have seen this happening in many places, often with undesirable results.
The problem could be with the CIO who brings in technology solutions from his previous company or vendors that he is comfortable with. At other times it could be the user who tries to suggest the same process or systems that they had experienced with their earlier organization. We may have also to contend with the CEO who may insist on installing the environment that he is familiar with. Let me delve into such cases based on my observations and experience.
The CIO syndrome
Being the chief architect of the IT play in the organization, CIOs orientation is key to the right solution mix that the organization adopts. In many occasions he may be influenced by solutions that he had put up in his previous organization, on grounds of familiarity or from fear of treading into the unknown. He may also want to deal with the same technology vendor or service provider rather than trying new ones. I have often seen CIOs insisting on say a Microsoft solution, Oracle database or a certain ERP irrespective of what the organization already has or what suits them. They try to justify the change stating various reasons that managements don’t understand. Some CIOs also tend to replace the current consultants or service providers with those that they are familiar with explaining a close working relationship as justification even though the existing vendor could have had a good run with the organization. These cause disruption and the organization may not really benefit from such a change. Early in my career I also tried a similar trick that did not work and soon realized the folly of replicating systems. Thereafter I made a point not to carry any papers or solutions prints from my previous organization or refer to them when I made a change.
The users push
The users too may want to put their stamp on the systems they run. Why wouldn’t a HR head who had used Peoplesoft solution or a functional head who used SAP or the CFO who used a certain dashboard not insist on the same solution for his needs. This situation is not unfamiliar. I have come across situations where companies put in say a Peoplesoft package for HR, BAAN for manufacturing, or IFS solution for Plant maintenance in spite of having implemented another enterprise ERP package in the organization. CIOs sometimes feel helpless when a strong willed functional head says that it will be his choice or none. I have come across situations where business heads keep opposing measures in the steering committee just because their choice of package was overruled. In one instance I had to give in to the demand of the Sales head to introduce mobility for sales force automation (he had done so in his last outing) as he convinced and got a go-ahead from the CEO. It was clearly not a viable solution for the organization and it finally met its fate a year later and got into disuse. Users also wish to play favour to their old contacts who come to them for business and they then put their overt pressure on the CIO to act.
The CEO dictat
The boss often has his way and especially so if he claims to be IT aware. I have seen two kinds of their interference – one when he has just come from another company that used a certain solution or when his advisor or a fellow CEO from another organization recommends a particular technology or a solution. I once got into one such tense situation when the CEO almost ordered a proprietary large server at a time when standard unix systems were gaining ground. He didn’t understand that his earlier organization had installed the system many years ago and that the scene had changed since then. It took considerable convincing to shake him off his stand.
Kicking the habit
This habit obviously is not rewarding – it provides only a temporary comfort but spanks you at the end. Solutions cannot just be lifted from one place and planted at another. Each situation is different and needs a fresh look without bias. Solutions emerge as we analyze the requirements dispassionately and it is fun to explore new solutions that fit the scene better.
Use of IT in organizations is all pervasive. IT penetrates into every function and most users are dependent on IT systems in one way or another. It is not only large corporations today but the small and medium sector that are impacted by IT. Deployment and usage however differ from one organization to other. Large corporations often have high profile managers or hire consultants to help them strategize, plan and define a proper IT architecture for moving ahead. While some of the medium sized organizations too have a good set up, others stutter and struggle with their IT plans.
Lack of an enterprise approach
I have been associated with a few such organizations and I see the need for many of these companies to rework their approach and make IT work for business. This is more true of medium sized organizations which have grown in size to match their larger counterparts and small organizations that have expanded to come into the medium sized category. I see these companies struggle with their IT set up leading to a certain level of dissatisfaction at the management level. Though basic operations run well, expectations of the management are higher than what IT can deliver. Reasons for this situation are many but let me deal with a few.
Linear expansion of IT: As the business grows, IT heads add on more servers, storage, network equipment etc. for handling more users, larger data and to cater to additional traffic on the network. While some additions are in order, there comes a stage when the entire architecture needs a re-look. The IT capacity starts cracking at the seams and the IT man is left chasing the needs expressed by the business. For example tailor made applications become woefully inadequate but the CTO may take too long to make the required transition to newer software packages.
Lack of the required skill at the CTO/CIO level : Some of the companies I interacted with understood the inadequacies of the current set-up but could not proceed because the IT team with them did not have the required knowledge or skill to identify, evaluate and decide on newer and contemporary solutions. Quite often they are stranded and some of them are forced to consult external experts for help.
Maintaining status-quo: There are other CIOs who keep on giving various explanations to the management and try to maintain status-quo. They are rich with explanations why a new system will not apply to them and that their needs are very different from others or that if they make any change, much of the current investment would be laid to waste.
Budget constraints: A few other organizations get caught in a bad business cycle and decide against further investment in IT. Unfortunately IT gets the first kick during budget cuts and any talk of IT restructuring is deferred to a later date which is often indefinite. Surely management personnel here display a lack of appreciation for modernization at a time when the environment is moving ahead with increased automation.
When companies get into such a bind, they limp, stutter and fall and the same time lament the poor status of their IT which is of very little help to business. They may be right in many cases but in other case it is because of their own making. They have however, to move, take the right measures so that they correct the situation without much delay. Some of the steps that can be taken are :
Management should seek to understand : Awareness at the management level is crucial. CEOs in some of the companies are well updated of the situation and get into conversation with IT vendors and other experts but in many of the other companies, the awareness level is low. They need to open up to the market realities and come out of their conventional mindset. Cutting down the IT budget may be the easiest of things to do but they fail to realize the damage they do to the IT support that the organization needs to measure up to the competition.
Take external help: When requisite knowledge does not exist within, it makes sense to step out and tap experts who can advise the company of the right path to take and to guide the local IT team in implementing the new measures. Companies adopt various modes, they sometimes ask their main IT vendor to draw the right path, or hire a consulting organization or seek guidance of a known expert to take them through.
Management to participate or form a Steering Committee : It is not enough to just sanction budgets and give approval to projects. It is essential for the CEO to participate and monitor the progress of IT projects or set up a steering committee and place senior management personnel there to guide the teams to achieve the end result.