ERP software, which is implemented and running successfully in any other industry vertical like Engineering, Chemical, Healthcare, Real Estate and Hospitability etc, will not cope-up with the specialised needs of Pharma Industry. Since all other industries are not regulated and Quality and Documentation are not the fundamental requirements of these industries, ERP for pharmaceutical industry is the only solution for Pharma Manufacturers. QUADS^TM is designed and developed keeping the needs of Pharmaceutical Products Manufacturing Industry. 
 

QUADS^TM keeps track of information RM, PM, WIP and FG inventory party-wise. So communication of these data viz. inventory positions (approved stock, quarantine and under test), FG / WIP / Recovery in production stage and BSR etc with LLU / P2P units can be done in electronic formats, as and when required. 
 

QUADS^TM is a web-based ERP software using database which resides on a centralised server at one of the locations. This data is accessed by a browser based application from various units of the organisation. So the information / data on the server is updated immediately after transaction entry. So the management can get latest information in a summarised format using application dashboard. 
 

QUADS^TM provides facility to maintain BMR, BPR, Equipment Calibration etc documents in a writable Adobe Acrobat PDF format. The documents are created, maintained, retrieved and have controlled access as per 21 CFR Part 11 (Sub-part B-11.10-(b) & (c)). Information generated online at shop-floor can directly be entered into the system to avoid manual paper work. 
 

QUADS^TM is designed to follow various processes to comply with WHO cGMP, cGLP, 21 CFR Part 11, Q7A Guidelines etc. All the documents generated by the system are inline with these regulatory requirements. Thus system can generate various mandatory reports and data required for audit purposes and statutory compliances of various external entities. This enables the organisation and working individuals to focus on their core competencies while process driven system adheres to the set rules to comply with various regulations. 
 

QUADS^TM provides a message / alert driven workflow. People who are working on sequential tasks, gets system generated messages of completion of earlier task. Respective manager gets a notification mail for information. Similar notification gets generated after completion of the task by assigned individual. If the task is not completed during stipulated time period, reminder is generated by the system. Involuntary tasks are handled by a scheduler running in background and alerts are generated of such events which will be happening shortly. This creates a tremendous management control over the process and enables them to take appropriate action in time. Similarly, MIS reports generated on historical data gives a bird’s eye view on the summarised information for decision support. 
 

ERP is an acronym that stands for Enterprise Resource Planning. ERP is package software solution that addresses the enterprise needs of an organisation by tightly integrating the various functions of an organisation using a process view of the organisation. It is package software and not custom made software for a specific firm. It understands the needs of any organisation within a specific industry segment. Many of the processes implemented in an ERP software are core processes such as order processing, order fulfilment, shipping, invoicing, BOM processing, purchase order processing, preparation of Balance Sheet, Profit and Loss statement etc., that are common to all industry segments. That is the reason why the package software solution works so well. The firm specific needs are met through a process of customisation. ERP addresses not merely the needs of a single function such as finance, marketing, production or HR. Rather it addresses the entire needs of an enterprise that cuts across these functions to meaningfully execute any of the core processes. ERP integrates the functional modules tightly. It is not merely the import and export of data across the functional modules. The integration ensures that the logic of a process that cuts across the function is captured genuinely. This in turn implies that data once entered in any of the functional modules (whichever of the module owns the data) is made available to every other module that needs this data. This leads to significant improvements by way of improved consistency and integrity of data. ERP users the process view of the organisation in the place of function view which dominated the enterprise software before the advent of ERP. The process view provides a much better insight into the organisational systems and procedures and also breaks the "kingdoms" that work at cross-purposes in many organisations. To implement such a demanding software one needs high performance computing, high availability systems, large, high speed high availability on line storage and high speed, high reliable net works, all at affordable cost. Though many ERP software vendors have been around for more than two decades, ERP software started to make major inroads into the corporate world only in the last couple of years. Interestingly Indian corporate houses are taking the ERP route exceptionally fast, even by world standards in the past two years. The investments on a complete ERP implementation for a Rs. 100+ core corporation would easily run into Rs 10+ crores. ERP is the only software whose deployment decisions are made in the corporate boardrooms and not by EDP / MIS departments. ERP software today represents possibly the single most expensive piece of general-purpose software. 
 

Corporations go for ERP either to solve the existing problems or to explore new opportunities. These two approaches are called as negative & positive approaches respectively. One aspect of the negative approach forces some corporations to go for ERP to solve their Y2K problem. This is particularly true of those corporations that are heavily dependent on legacy systems running on old main frames. The second aspect of the negative approach is to get over the problems of islands of heterogeneous and incompatible information systems that were developed over the past several years in many organisations. Functional modules representing areas such as Finance, Marketing, HR, and Production in these organisations would be running on diverse hardware and software platforms leading to nearly insurmountable problems of reconciling data locked up among the diverse systems. From a positive perspective many organisation look at the great opportunity provided by ERP software that lead to almost instant access of transactional information across the corporation. Such an information rich scenario permits organisation to reduce inventory across multiple units/ departments/ plants; reduce cycle times from weeks to hours; and improve customer satisfaction by orders of magnitude. All these translate to increased profitability or increase in market share and in turn much larger market capitalisation. However ERP is only means and not an end by itself. ERP provides an opportunity for a corporation to operate as an agile entity to improve production / operation, customer service and customer satisfaction. The creative ingenuity of an organisation to drive towards these corporate goals determines the extent of success an ERP implementation can deliver. 
 

Many professionals perceive ERP as a paradox. "How can a software company located remotely understand the needs of my organisation operating in a distant location?" is the question they generally ask. Many of them feel that custom software should work far better than packaged software. For many of them holding this view, the success of ERP is a paradox. What they miss out is the point that the core processes of most organisations are by and large, the same. Thanks to globalisation, there has been a significant amount of uniformity, standardisation and simplification of the core processes across the industry. Some of the technologies such as EDI have even standardised the contents of critical documents, such as shipping and purchase orders. By pumping in billions of dollars in understanding the business processed used by thousands of corporations worldwide, the ERP software vendors also bring in world-class practices to any company that implements the ERP software. In a similar vein, large ERP software vendors are also able to employ and retain thousands of software professionals who can continuously improve their ERP software product. No individual end user company can afford such large pool of software professionals. This is the secret of success of ERP. 
 

The answer to this question is Yes and No. ERP software has the benefit of understanding the best practices followed in thousands of corporations worldwide, where the particular ERP software has been implemented. In a sense, ERP software embeds these best practices inside their software. This explains the Yes part of the answer. One reason why end users pay an exorbitant amount to buy ERP software is the fact that ERP is not just a piece of "shrink wrapped" software. The embedded business processes inside provide the real value to the ERP software. So, ERP can bring "best of the breed" practices to any organisation. However, the onus of profiting through these best practices entirely lies on the end users. An organisation suffering from "Not invented here" syndrome may do too much over customisation and build into ERP implementation the archaic practices followed for decades in a specific company. This in turn may deprive the benefits of the best practices to that company. This explains the No part of the answer. {For core Business Processes it may be the best to follow the best business practices of the ERP vendor, but there is always a percentage of customisation required for any ERP implementation. The ability of the ERP to extend easily is a critical factor to evaluate.} 
 

Companies that install ERP do not have an easy time of it. Don’t be fooled when ERP vendors tell you about a two - or four-month average implementation time. Those short implementations all have a catch of one kind or another: The Company was small, or the implementation was limited to a small area of the company, or the company used only the financial pieces of the ERP system. To do ERP right, the ways you do business will need to change and the ways people do their jobs will need to change too. And that kind of change doesn’t come without pain. Unless, of course, your ways of doing business are working extremely well (orders all shipped on time, productivity higher than all your competitors, customers completely satisfied), in which case there is no reason to even consider ERP. The important thing is not to focus on how long it will take—real transformational ERP efforts usually run between one and three years, on average—but rather to understand why you need it and how you will use it to improve your business. 
 

BPR as an acronym stands for Business Process Reengineering. An organisation can go for standalone BPR or they can choose ERP. Since ERP anyway comes bundled with several of the best practices, a well implemented ERP exercise leads to some amount of BPR, though the reengineering effort may not be full-blown. However, reengineering through ERP, generally termed package enabled process reengineering (PEPR) leads to less drastic change in an organisation. Such package enabled reengineering through ERP has been received much better by the end users rather than stand alone BPR in many companies around the world. 
 

There is no easy algorithm that can give a simple answer. A BPR exercise preceding the ERP implementation can help the organisation significantly. It may also increase a combined time of implementing BPR and ERP significantly. There is also a risk that particular ERP software selected later may not be able to implement the reengineered processes. A simultaneous BPR and ERP exercise saves time and also minimises the risk of sequential implementation of BPR followed by ERP. One rarely comes across the instance where BPR is followed by ERP. As such the ordering of ERP & BPR must be based on the needs of a specific organisation. 
 

ERP will ultimately affect everyone in the organisation. An ERP implementation represents a major organisational intervention. The process view of ERP would remove many of the "kingdoms" in the organisation. This would lead to a shift in power centres; naturally ERP represents a major change. Managing change of such high order cannot be done without top management commitment. ERP exercise is also a major exercise and can cost anyway from several lakhs to several crores of rupees. Such large resource requirements also necessitate commitment from top management. Last, but not the least, ERP implementation is a long process, generally running into several months. Keeping an activity alive for such long duration would be nearly impossible without top management commitment. 
 

The top management commitment in ERP is not limited to writing a big cheque, which is very much necessary. But it has to go much beyond that. ERP exercise in India represents a paradigm shift in the way many CEO run their corporations. ERP software implementation vendors often make it mandatory for the chief executive and his / her team to spend a full one week listening to ERP consultants. Such an exercise is unheard of at least in the Indian corporate history. The core committee of ERP needs champions who are well respected, very knowledgeable and often impossible to spare for any organisation. The success of ERP implementation needs the full-time attention of these champions who must be drawn from the key functions and detained for ERP project implementation for a long period of six to nine months. ERP project cannot be managed by people who "can be spared"; it must be managed by the "indispensable" personnel. Top Management commitment must ensure the release of such key people for the ERP core committee. The ERP software often brings the best practices from the industry. To benefit from such best practices, existing business practices may have to be altered. Top management commitment should include the political will to implement such changes. 
 

ERP being a major initiative costing significant amount of money, lasting several months and ultimately affecting everyone in the organisation, change management is the key for the success of any ERP project. ERP software brings along with them some of the best practices. Implementing such practices would need change. To profit from ERP such change must be managed. That is the reason ERP needs top management commitment. 
 

There are five major reasons why companies undertake ERP. Integrate financial information: As the CEO tries to understand the company’s overall performance; he may find many different versions of the truth. Finance has its own set of revenue numbers, sales has another version, and the different business units may each have their own version of how much they contributed to revenue. ERP creates a single version of the truth that cannot be questioned because everyone is using the same system. Integrate customer order information: ERP systems can become the place where the customer order lives from the time a customer service representative receives it until the loading dock and finance sends an invoice. By having this information in one software system, rather than scattered among many different systems that can’t communicate with one another, companies can keep track of orders more easily, and coordinate manufacturing, inventory and shipping among many different locations simultaneously. Standardise and speed up manufacturing processes: Manufacturing companies especially those with an appetite for mergers and acquisitions, often find that multiple business units across the company make the same widget using different methods and computer systems. ERP systems come with standard methods for automating some of the steps of a manufacturing process. Standardising those processes and using a single, integrated computer system can save time, increase productivity and reduce headcount. Reduce inventory: ERP helps the manufacturing process flow more smoothly, and it improves visibility of the order fulfilment process inside the company. That can lead to reduced inventories of the materials used to make products (work-in-progress inventory), and it can help users better plan deliveries to customers, reducing the finished good inventory at the warehouses and shipping docks. To really improve the flow of your supply chain, you need supply chain software, but ERP helps too. Standardise HR information: Especially in companies with multiple business units, HR may not have a unified, simple method for tracking employees’ time and communicating with them about benefits and services. ERP can fix that. In the race to fix these problems, companies often lose sight of the fact that ERP packages are nothing more than generic representations of the ways a typical company does business. While most packages are exhaustively comprehensive, each industry has quirks that make it unique. Most ERP systems were designed to be used by discrete manufacturing companies (that make physical things that can be counted), which immediately left all the process manufacturers (oil, chemical and utility companies that measure their products by flow rather than individual units) out in the cold. Each of these industries has struggled with the different ERP vendors to modify core ERP programs to their needs. 
 

It is a loaded question. The cost of ERP software should not be viewed as an expense. It is an investment towards an ability that provides better profitability, market share or customer service. Of course, the up-front cost of ERP software is very high. Most software pieces used by the corporations for commercial applications never had price tags of crores of rupees which ERP software carry. ERP decisions are a "high-risk high reward" decision. The view that ERP is expensive only looks at the risk but not the rewards. 
 

There aren’t any good numbers to predict ERP costs because the software installation has so many variables, such as: the number of divisions it will serve, the number of modules installed, the amount of integration that will be required with existing systems, the readiness of the company to change and the ambition of the project—if the project is truly meant to be a battering ram for reengineering how the company does its most important work, the project will cost much more and take much longer than one in which ERP is simply replacing an old transaction system. There is a sketchy rule of thumb that experts have used for years to predict ERP installation costs, which is that the installation will cost about six times as much as the software license. But this has become increasingly less relevant as the market for ERP has slowed over time and vendors have offered deep discounts on the software up front. Research companies don’t even bother trying to predict costs anymore. A few years ago, the dearly departed Meta Group did a study looking at the total cost of ownership (TCO) of ERP, including hardware, software, professional services and internal staff costs. The TCO numbers include getting the software installed and the two years afterward, which is when the real costs of maintaining, upgrading and optimising the system for your business are felt. Among the 63 companies surveyed—including small, midsize and large companies in a range of industries—the average TCO was $15 million (the highest was $300 million and the lowest was $400,000). While it’s hard to draw a solid number from that kind of range of companies and ERP efforts, Meta came up with one statistic that proves that ERP is expensive no matter what kind of company is using it: The TCO for someone who uses the system a lot over that period was a staggering $53,320. 
 

It is difficult to calculate return on investment for ERP decisions, though several successful installations of ERP had dramatic returns on investment. For example, Microsoft estimates that the investments in ERP will be paid back by way of better performance in flat two years. It must be realised that the ERP is an enabler. ERP gives agility to organisation, which can be exploited to improve profitability, market share or customer service. Without ERP, the organisation may not be in a position to handle larger business or provide faster response to customers. The results from enlarged business or faster customer response should pay back for ERP investment. It is predicated on the fact that the organisation would leverage the agility towards such corporate goals. ERP helps in pursuing such goals often successfully. But mere ERP implementation does not necessarily translate to benefits. Better health enables a human being to do things, which would have been difficult, if not impossible, without such sound health. But if the individual does not make use of his improved status towards the pursuit of any goal, he or she is not capitalising on the improved health. ERP must also be viewed as a way of providing a better health to an organisation. 
 

Don’t expect to revolutionise your business with ERP. Its contribution is optimising the way things are done internally rather than with customers, suppliers or partners. Again, value depends on ambition. If ERP is the focus of an effort to bring dramatic improvements to the way a company does business, it will bring more value than if the project is treated as a simple systems replacement. And even if ERP does bring dramatic change, because it affects mostly existing "back office" processes such as order management rather than creating new revenue opportunities, the bottom-line value may not be much. Veterans say ERP is more a cost of doing business to make the company operate more efficiently than something that offers dramatic payback. And most veterans say it takes six months or more to get the new systems and processes running up to snuff. A Meta Group study of 63 companies a few years ago found that it took eight months after the new system was in (31 months total) to see any benefits. The median annual savings from the new ERP system were $1.6 million—pretty modest, considering that ERP projects at big companies can cost $50 million or more.  
 

The set of activities through which ERP is implemented in an organisation constitutes the ERP life cycle. This can be compared to the well developed System Development Life Cycle (SDLC) in the traditional Structured System Analysis and Design (SSAD). Typical ERP project consists of the following steps: Step 1: ERP readiness assessment Step 2: Preparing the organisation for ERP Step 3: ERP Feasibility Study Step 4: Process modelling and documenting the "AS IS" processes & "TO BE" processes (along with BPR) Step 5: Detailed plan for ERP implementation (includes ERP software selection, selection of implementation partners, implementation methodology - "Big Bang" or Modular Implementation - and the final and precise extent of implementation) Step 6: Detailed implementation including development, quality assurance and production system Step 7: Preparing to "go live" including data migration Step 8: Going live Step 9: Performance assessment, documentation, training (continues in early stages also) and future plans. 
 

Yes. Most implementations of ERP include financial module. Every organisation has a financial (fiscal) year both for internal use as well as far legal / governmental consolidation. Since the account books must be closed and financial reports prepared (including the balance sheet and the profit and loss statement) for the financial year, most ERP implementations try to synchronise their "go live" date with that of the financial year. If for some reason it cannot be on financial year start, many organisations "go live" at the end of the half-year completion. Technically ERP software doesn't impose any restrictions. Any day is good enough to "go live" as long as it is not "tomorrow"! 
 

Process Modelling provides a means to map the organisation processes and visualise it in a graphical manner. This helps in communication, clarification and documentation of the "AS IS" and "TO BE" processes. Process modelling can be used to reinforce the central theme of ERP, namely, a shift from function orientation to process orientation. 
 

Customisation is the process of fitting the chosen ERP software to the needs of a specific organisation. Whenever the processes represented in the ERP software differ significantly from the processes used by the firm one has two options. First is to build the organisational process into the ERP software through customisation. The second one is to change the practice followed by the firm to suit the process native to the ERP software. Traditional common sense would force people to customise the software to suit the individual demands of the organisation. This leads to two problems. The first one arises out of the fact that any customisation done locally is outside the core ERP software. Accordingly, the next release of the ERP software would not support local customisation. They have to be re-done by the end user for the new release. Second the very purpose of ERP is to take advantage of the best practices in industry that come embedded with the ERP software. By over customising the implementers would deprive the benefit of world - class practice to the organisation that is implementing ERP. 
 

The three dominant approaches to ERP implementation are "big bang", location-wise and module-wise implementation. In the big bang approach the organisation decides to implement all relevant modules, for example - Financials, Logistics & HR- all at the same time. This has the advantage of getting the full benefit of the integrated software across all functions of the organisation. However there is a risk of the implementation getting out of control. In "Location-wise" implementation, the organisation chooses a specific location, say, the head office, one of the new plants etc. The choice could be based on better infrastructure, better IT culture, more co-operative set of users, higher level of automation etc. In "module-wise" implementation individual modules are taken up for implementation in a phased manner depending on the criticality of applications. Once again a module taken up for implementation can be implemented across all locations or just one location. Later they can be rolled out to other locations. 
 

Yes. The full benefit of ERP would accrue if all the ERP modules are implemented. However many organisations implement ERP only in those functions, which are, considered to be of strategic importance. Some of the modules, though they appear to be limited to specific functions, in fact integrate with many other functions indirectly. For example finance module primarily targets the accounting and finance functions. However the accounts payable module addresses all the material purchases and in turn impacts the entire materials management functions. Many more examples can be quoted to reinforce our viewpoint. The process orientation of ERP software definitely contributes to a better management of the organisation. Even partial implementation of the ERP therefore leads to significant benefits. But it is advisable to implement all the modules to leverage full benefit of ERP implementation. 
 

Financial modules provide the basic pulse of an organisation. It also impacts all other modules. Successful implementations of financials show up immediately reinforcing the faith of an organisation in ERP. Other modules cannot be implemented without the financial module in place. All these factors explain the fact that financial modules are taken up first. 
 

There is no easy magic through which one can prepare an organisation for ERP implementation. Exposing the top management to the benefits of ERP through the real world case studies, sharing of experience by other corporations that have successfully implemented ERP and creation of awareness is the first step. Convincing the top management to use a high risk, high reward scheme such as ERP is a major challenge. Almost all the members of the organisation should get the excitement about ERP project implementation. Communicating and sharing of the ERP vision is the most important organisational preparation for a successful ERP implementation. 
 

Critical success factors for ERP include top management commitment, clear focus about the goals of ERP project, readiness to invest in high risk, high reward project, and management of change and faith in package software. 
 

ERP software must address all the enterprise needs of an organisation within the social context in which the enterprise operates. This would imply that the local accounting practices, locally applicable taxation laws (excise, customs, sales tax and income tax) are fully adhered to in implementing the various business processes. The software vendor must incorporate India specific features before selling the software. The specific ERP software that has been adapted to suit to Indian statutory laws is called India specific ERP. 
 

ERP is a major organisational intervention. As such it affects everyone. It changes the functional focus of an organisation to a process focus. It will also bring an element of customer focus to entire organisation. A well-implemented ERP can make an organisation very agile permitting the organisation to perform at a much higher level. However if not well executed ERP can destroy the very organisation. This is the risk of ERP. While the rewards are high, the risk too is high. 
 

ERP project team would be charged with the responsibility of implementing the ERP for the specific organisation. A champion, who is skilled in communication and understands the organisation well, should head the ERP team. The leader must be well accepted by the most employees of the organisation. The leader also must be a person who can keep the motivation level of the implementation team at fairly high levels throughout the several months of implementation. The implementation team would consist of dozens of people. There will be a number of teams for each of the functional area with every team consisting of key users and IT personnel to provide technology support. 
 

Project champions (for the core processes that are taken up for implementation) would be those individuals who would take the ownership of implementation. They are expected to provide the leadership so as to sustain the trials and tribulations of ERP implementation. 
 

After many months of implementation plan every organisation would decide a particular date when they would shift from their legacy system to the ERP system. Up to that time the ERP software would be under development followed by testing and quality assurance as well as parallel run with manual work or existing legacy system. Once by ERP implementation team feels convinced that the development is complete and testing is satisfactory, they would decide to "go live". In a sense "go live" date marks the end of ERP project completion and UAT – User Acceptance Testing. Generally most ERP project "go live" on the starting of the fiscal / financial year. 
 

ERP speaks the end user language more than any other software piece. ERP implementation had been successful whenever it was driven by business goals and not IT goals. ERP vendors have been successful in convincing the end users to take ERP decisions. Rarely IT departments take the decision to go for ERP. The ERP training and skills to use ERP can be developed by end users quite easily. All these together have generated substantial user acceptance of ERP. 
 

Today the cost of ERP software, the resources needed to run the ERP software and the fee charged by consultants to implement the complex ERP software together make ERP only for the big corporations. Recently all the large ERP software vendors through their industry solution focus have started addressing the medium companies as well. Small enterprises cannot afford to go for ERP solutions using leading edge product. The situation will change very soon but estimation of times scale is difficult. 
 

Although different companies will find different land mines in the budgeting process, those who have implemented ERP packages agree that certain costs are more commonly overlooked or underestimated than others. Armed with insights from across the business, ERP pros vote the following areas as most likely to result in budget overrun. Training: Training is the near-unanimous choice of experienced ERP implementers as the most underestimated budget item. Training expenses are high because workers almost invariably have to learn a new set of processes, not just a new software interface. Worse, outside training companies may not be able to help you. They are focused on telling people how to use software, not on educating people about the particular ways you do business. Prepare to develop a curriculum yourself that identifies and explains the different business processes that will be affected by the ERP system. One enterprising CIO hired staff from a local business school to help him develop and teach the ERP business-training course to employees. Remember that with ERP, finance people will be using the same software as warehouse people and they will both be entering information that affects the other. To do this accurately, they have to have a much broader understanding of how others in the company do their jobs than they did before ERP came along. Ultimately, it will be up to your IT and businesspeople to provide that training. So take whatever you have budgeted for ERP training and double or triple it up front. It will be the best ERP investment you ever make. Integration and testing: Testing the links between ERP packages and other corporate software links that have to be built on a case-by-case basis is another often-underestimated cost. A typical manufacturing company may have add-on applications from the major—e-commerce and supply chain—to the minor—sales tax computation and bar coding. All require integration links to ERP. You’re better off if you can buy add-ons from the ERP vendors that are pre-integrated. If you need to build the links yourself, expect things to get ugly. As with training, testing ERP integration has to be done from a process-oriented perspective. Veterans recommend that instead of plugging in dummy data and moving it from one application to the next, you should run a real purchase order through the system, from order entry through shipping and receipt of payment—the whole order-to-cash banana—preferably with the participation of the employees who will eventually do those jobs. Customisation: Add-ons are only the beginning of the integration costs of ERP. Much more costly, and something to be avoided if at all possible, is actual customisation of the core ERP software itself. This happens when the ERP software can’t handle one of your business processes and you decide to mess with the software to make it do what you want. You’re playing with fire. The customisations can affect every module of the ERP system because they are all so tightly linked together. Upgrading the ERP package—no walk in the park under the best of circumstances—becomes a nightmare because you’ll have to do the customisation all over again in the new version. Maybe it will work, maybe it won’t. No matter what, the vendor will not be there to support you. You will have to hire extra staffers to do the customisation work, and keep them on for good to maintain it. Data conversion: It costs money to move corporate information, such as customer and supplier records, product design data and the like, from old systems to new ERP homes. Although few CIOs will admit it, most data in most legacy systems is of little use. Companies often deny their data is dirty until they actually have to move it to the new setups that ERP packages require. Consequently, those companies are more likely to underestimate the cost of the move. But even clean data may demand some overhaul to match process modifications necessitated—or inspired—by the ERP implementation. Consultants ad infinitum: When users fail to plan for disengagement, consulting fees run wild. To avoid this, companies should identify objectives for which its consulting partners must aim when training internal staff. Include metrics in the consultants’ contract; for example, a specific number of the user company’s staff should be able to pass a project-management leadership test—similar to what the consultants have to pass to lead an ERP engagement. Implementation teams can never stop: Most companies intend to treat their ERP implementation as they would any other software project. Once the software is installed, they figure the team will be scuttled, and everyone will go back to his or her day job. But after ERP, you can’t go home again. The implementers are too valuable. Because the implementers have worked so closely with ERP, they know more about the sales process than the salespeople and more about the manufacturing process than the manufacturing people. Companies can’t afford to send their project people back into the business because there’s so much to do after the ERP software is installed. Just writing reports to pull information out of the new ERP system will keep the project team busy for a year at least. And it is in analysis—and, one hopes, insight—that companies make their money back on an ERP implementation. Unfortunately, few IS departments plan for the frenzy of post-ERP installation activity, and fewer still build it into their budgets when they start their ERP projects. Many are forced to beg for more money and staff immediately after the go-live date, long before the ERP project has demonstrated any benefit. Waiting for ROI—One of the most misleading legacies of traditional software project management is that the company expects to gain value from the application as soon as it is installed, while the project team expects a break and maybe a pat on the back. Neither expectation applies to ERP. Most of the systems don’t reveal their value until after companies have had them running for some time and can concentrate on making improvements in the business processes that are affected by the system. And the project team is not going to be rewarded until their efforts pay off. Post-ERP depression—ERP systems often wreak cause havoc in the companies that install them. In a recent Deloitte Consulting survey of 64 Fortune 500 companies, one in four admitted that they suffered a drop in performance when their ERP system went live. The true percentage is undoubtedly much higher. The most common reason for the performance problems is that everything looks and works differently from the way it did before. When people can’t do their jobs in the familiar way and haven’t yet mastered the new way, they panic, and the business goes into spasms. 
 

At its simplest level, ERP is a set of best practices for performing the various duties in the departments of your company, including in finance, manufacturing and the warehouse. To get the most from the software, you have to get people inside your company to adopt the work methods outlined in the software. If the people in the different departments that will use ERP don’t agree that the work methods embedded in the software are better than the ones they currently use, they will resist using the software or will want IT to change the software to match the ways they currently do things. This is where ERP projects break down. Political fights erupt over how—or even whether—the software will be installed. IT gets bogged down in long, expensive customisation efforts to modify the ERP software to fit with powerful business barons’ wishes. Customisations make the software more unstable and harder to maintain when it finally does come to life. The horror stories you hear in the press about ERP can usually be traced to the changes the company made in the core ERP software to fit its own work methods. Because ERP covers so much of what a business does, a failure in the software can bring a company to a halt, literally. But IT can fix the bugs pretty quickly in most cases, and besides, few big companies can avoid customising ERP in some fashion—every business is different and is bound to have unique work methods that a vendor cannot account for when developing its software. The mistake companies make is assuming that changing people’s habits will be easier than customising the software. It’s not. Getting people inside your company to use the software to improve the ways they do their jobs is by far the harder challenge. If your company is resistant to change, then your ERP project is more likely to fail. 
 

No. Every company needs a core transactional system that records the information from its most important business processes. But companies are realising that ERP is shifting from being the sum total of their software architecture strategy to being a component of a larger strategy based on expressing technology as specific business services that business people can easily understand—such as “customer record” or “get credit rating,” for example—rather than arcane software applications like ERP. The services strategy entails building an integration layer that is separate and distinct from any of the software applications—including ERP—in a company’s portfolio. The foundational piece—known as the messaging infrastructure—is like a good executive assistant—translating, routing and monitoring information from different systems without these systems needing to connect directly. Adding, changing or removing a system becomes a matter of modifying a single link, rather than ripping apart connections to all the different systems it may need to communicate with. But while the messaging infrastructure makes connecting systems easier, it doesn’t free business processes from their mainframe prisons, or eliminate redundancies in applications, or provide any impetus to create a useful architecture. Indeed, a good messaging infrastructure can perpetuate the chaos by making it easier to deal with. Messaging has long lacked a higher purpose, a strategy. Service objects (or just plain “services”) are that strategy, and it is the second core piece of the integration layer. This is an old concept, based on object-oriented programming from the ‘80s. Services extract pieces of data and business logic from systems and databases around the company and bundle them together into chunks that are expressed in business terms. The most interesting new “feature” being developed by the ERP vendors today is the extent to which they will make their software part of a service SOA using their own home-grown integration software, known as middleware, and Web services so that customers can more easily link ERP with other types of software in the architecture. Each vendor has claimed fealty to the concept and each has its own vision of how to create an integration layer independent of its own software that is capable of linking to any other piece of software in the universe. But view their pronouncements sceptically because if they do it well they will eliminate an important piece of their competitive differentiation: dominance over the software acquisition process of their customers.