I often come across companies that start IT projects with all fanfare, complete the initial tasks but cool off later. I first enquire, then nudge them and finally try persuading the folks to continue but they somehow go into a period of hibernation and wake up much later. I have wondered about the reasons for such phenomena and tried to analyze but have yet to come out with proper answers.
This is not a rare state that companies get into but a situation I have observed with regular frequency. Companies have always a lot of explanations to offer and look perfectly justified in their approach. To an external observer however such position doesn’t look so normal and convincing and he is at a loss to understand this period of stagnation. The blame could lay with the CIO for not being pushy enough, the users for their uncooperative attitude or with the management for turning a blind eye to the IT projects. For instance one of the companies that I am advising discussed seriously about restructuring the IT infrastructure which was in a highly decentralized mode but postponed it for two months till the start of the new financial year citing budget constraints but it has been now been several months since. Another company was to start off with their BI project and bought the product as well but couldn’t get its act together to implement for over several months now. If I try to analyze the reasons for such delays, some of the following points emerge :
Lack of budget : This is a reason often cited by the CIO or the management. Budget constraints could be true in certain cases when companies reel under depressed sales or eroded margins but in most cases it is either lack of drive or unwillingness to invest further in terms of company’s resources or funds that stalls these projects.
Not convinced of the project : The management may not be sold out to the idea and hence could hold back their approvals. The CIO may not have been able to work out a proper business justification or that the management themselves not made efforts to understand the proposal and the impact on the company.
Ignorance on IT : While the managements may profess to know, their ignorance of IT is hard to cover up. They still hold the view that the company has survived and prospered without IT so far and hence further such investment would be overkill. They would rather invest these funds in a marketing campaign or for capacity build up.
Unsure of the future plans : Managements may not be ready with their immediate business plans due to market uncertainties or may have business plans but refrain from talking of IT plans. It becomes convenient to put such investments on hold.
Conflict amongst the main stake holders : I have experienced this situation more than once. When talking of Supply Chain Management (SCM), Business Intelligence (BI) or Product Lifecycle Management (PLM), I found the main stakeholders standing their ground and not coming to a consensus, thereby holding up the project. Poor coordination at the top ensures indefinite delay in the execution of such projects.
Plain lethargy : This last point takes the cake. Sluggish companies not seriously affected by market conditions, or the ones that are happy with moderate growth or those who are monopolies, take it easy and do not see the need for hurry. They can wait and take a look at the proposal when they are in a mood to do so.
Such periods of inaction are rather intriguing. Irrespective of the reasons for delay one wonders if this stretch of time benefits anyone. Perhaps none, except the companies who are able to postpone their investments. It was amusing to hear of a senior manger patting himself on his back for holding back decision saying that the delay has really helped because they can now work on the new version of the software, not realizing the fact that they had lost the opportunity in not being to make use of the facility before. Lethargy, indecision and procrastination are qualities or habits that we can do away with and move ahead with a greater sense of purpose.
It was during a seminar a few years ago, organized by a leading software vendor, that I listened to the IT head of a large organization, a customer, about implementation of Business Intelligence (BI) suite in their organization. This lecture was a part of the key note session and it had a large attendance. The speaker spoke at length about the project describing how they had been able to generate multiple reports for decision making. Following the talk, a person from the audience raised a pertinent question. Remarking that he did not hear any reference to Key Performance Indicators (KPIs) or its equivalent, he wanted to know if they had identified critical areas in the organization which they wanted to address with information analysis. The speaker could not adequately answer the question and admitted that they had reserved such an approach for the next stage.
I later discovered that this was nothing new and that many organizations implementing BI use it for generating standard MIS reports that they have been using for a while. Being familiar using such reports they don’t see the need for a change. The advantage they derive is easy processing of reports, greater accuracy and timely reporting. The question is if they just get a little more with this wonderful piece of software, is it really worth investing so much and going through the entire grind of implementing BI.
One of the customers that I am currently advising was going through a similar phase. On my advising them to consider BI, they promptly agreed to evaluate, negotiate and buy a package. The implementation partner they spoke to lead them through the familiar approach of taking out routine reports first. The client also seemed to agree as they as they were in a familiar territory. I had then to intervene and explain to them how BI could help them address specific business challenges rather than using this tool to generate reports they already get out of the old systems. The ROI factor hit the CFO mind and he then supported the need to define KPIs for all functions before starting with BI.
The need to define KPIs
Businesses use IT to help enhance their efficiency and effectiveness in dealing with competition and market forces and information plays a key role here. Information however needs to be targeted and this can be done only if we identify the key performance parameters that we like to be met and work out a way to need to monitor them regularly. Let us first understand what KPIs are.
A key performance indicator (KPI) is a business metric used to evaluate factors that are crucial to the success of an organization. KPIs differ for every organization, for example business KPIs may be net revenue, customer loyalty metric, customer-wise profitability, sales performance, performance against competition etc.
Before KPIs can be identified, organization should conduct an exercise defining business objectives, working out measures for success, outlining approach for remedying variances etc. KPIs help an organization assess progress toward the declared goals.
To make the information easily accessible to the senior management personnel, organizations go further and create executive dashboards. Dashboards provide a visually intuitive display of data for monitoring enterprise activity and help organizations track performance from a single screen, thus optimizing decision-making. The purpose is to offer an at-a-glance understanding of the organization’s health to executives, managers, and business users. There are frameworks which are in vogue, like creating a business scorecard to improve business performance which define the overall goals and break down those goals into a series of objectives that will enable them to meet the goals. The ‘Balanced Score Card’ framework originated by Dr. Robert Kaplan and Dr. David Norton is the most popular and this approach adds strategic non-financial performance measures to traditional financial metrics to give managers and executives a more ‘balanced’ view of organizational performance.
It is important that organizations implementing Business Intelligence packages make the most of what the software offers. Companies should go beyond conventional reporting and look for strategic use of information to help meet it’s objectives and goals. Identifying KPIs and creating dashboards are some of the ways to achieve the purpose and organizations should take that path for effective use of the opportunity with them.
The position of CIO in any organization is a challenging one. He has to deal with various people within and especially his seniors. He derives his powers from the defined set of duties and responsibilities assigned to him and the support that he gets from the CEO and other senior functionaries in the organization. He draws out his IT Strategy based on business needs and he executes his plans in consultation with the CIO and other business heads. He has often to take dictats from some of these senior members, and at other times he has to listen to his professional ethics, conscience and sense of propriety. It is a fine balance – a tight rope walk that he has to carefully tread on.
One question that comes to his mind is – whether he is working for his boss or the organization. If his boss asks him to carry out a task which in his judgment is not proper he has clear his throat, pick up courage and speak out his opinion. If he still is unable to convince his boss about his line of thought he has to exercise his discretion and act in a manner that is good for the organization and at the same time ensuring he doesn’t compromise with his principles. A tough task you might say but the CIO has to work an honorable way out for coming out of such situations. Let me describe a few instances from my experiences to explain the matter.
Pressure from boss to recruit a new person
The CFO to whom I was reporting to, asked me to interview and recruit a person who was related to one of the Directors on the Board. Not finding him suitable (as he was not even a graduate and had no knowledge of the platform we were working on), I rejected his candidature. Two weeks later he appeared again with the recommendation of my boss saying he has undergone a 10 day course and learnt the language referred to. I still found him unsuitable and wrote out my remarks accordingly. My boss then gave me sermons saying I should be more mature and practical and asked me to change my remarks. I try explaining to him but he still refused to listen and therefore I suggested that he overrule my decision and instruct me to take him in. However he did not have courage to take responsibility himself and hence let the matter pass.
Instruction of CEO for acquiring certain equipment
Our CEO who had joined a year before asked for a similar hardware as he had in the previous organization. Soon after I joined the company I was asked to finalize the hardware details and place orders. I however felt uncomfortable with the old hardware platform which was getting obsolete due to emergence of new standards. When I suggested a fresh evaluation I received angry responses from the CEO and he was not on talking terms with me for the next six months but grudgingly allowed me to proceed. A year later after the new platform was acquired and after we had a few successful applications running he changed his mind and started extending his support.
CEO wanting commissioning VC just to prop up his image
This was a case some years ago when video conferencing had made an appearance and it was fashionable to have one running in the organization. Our CEO too wanted to boast of this facility in the comity of his peers in the industry and asked me to procure and install. His idea was to link the head office with two of our factories which were just 25 to 50 kilometers apart. I evaluated and expressed my opinion that this facility may not be used as people were used to meeting personally as the distances were short. Since he insisted I had to agree to assist him but excused myself from implementing the project citing busy schedule. He got it commissioned and except the first few meetings which were forced by the CEO, the facility remained unused thereafter – another example of wasted investment.
The case in point is that pulls and pressures do exist in organizations but we have to deal with them in an appropriate manner. We should either be clear and forthright in expressing our thoughts or be diplomatic but use our discretion to accept the situation or deflect it. Such issues should not get stuck in our ego but should be dealt with an open mind. There is no doubt there is an element of risk if our stand goes against the demand of the superiors but we have to take a call one way or the other. This is not just about a difference of opinion but one that stirs our conscience or challenges our professional standing. We should stand tall and act as appropriate.
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.