Thursday, 15 December 2011

Streamlining purchases with Adempiere ERP

By Zeeshan Hasan
(First published in the November 2011 issue of CIO magazine, Bangladesh edition)

It is easy to manage purchases in a small company. The management can easily see what sales orders are coming in, whether enough stock is present to deliver those sales orders, and take steps to purchase whatever goods are short. However, once a company becomes larger than a single production location, it becomes more difficult to do the above. With physical separation of purchase, production and sales activities, the communication of sales orders, inventories and shortages that are required for efficient purchase becomes a problem. Any communication gap is likely to result in too much stock being wastefully purchased, or in a raw materials shortage which causes production delays and lost customers. This is the point at which ERP (Enterprise Resource Planning) software becomes a necessity. ERP software is an integrated business software designed to bring all the above departments together and help them to work in a coordinated way. In this article I will use the term ERP mainly with reference to the features of the Adempiere community-supported open-source ERP system, since that is what is used at my company (Kazi Farms, Bangladesh's largest poultry producer).

There is a simple logical method which ERP systems use to ensure efficient purchase. The initial requirement of raw materials is justified in any ERP system by a link to a sales order for finished product. The link between finished products to be sold and raw materials to be purchased is integral to the system; each finished product which needs to be delivered is defined as a list of component raw materials, referred to in the system as a Bill Of Materials (BOM). Thus, by ordering sales orders by delivery date and then calculating the associated raw materials required from the BOM, an ERP system can estimate raw materials requirements at any moment in time. Since inventories in all locations are also in the system, purchase orders can also be generated from the system to meet the requirements of sales. All of this, in fact, is not even ERP but MRP (Manufacturing Resource Planning), which was developed in the 1960's and 70's as a means of coordinating purchases, inventories, manufacturing and sales. MRP software evolved into modern integrated ERP by the addition of accounting and budgeting features into the basic sales, production and purchase cycle.

From the above, it is apparent that ERP is particularly useful to an organization which is trying to systematize its operations through Sales and Operations Planning (often referred to as SOP). The idea is that sales orders should justify and drive purchases, thus ensuring that unnecessary purchases are minimized. Indeed, SOP is one of the “best practices” built into ERP software; this is why ERP is usually implemented in a large company at the instigation of a management consultant, since it is usually a management consultant who is pushing for implementing a practice such as SOP. The benefits from ERP implementation usually come from aligning often-disorganized company business procedures along logical and established best practices such as SOP.

The above is the standard Sales and Operations Planning story which often forms the justification of ERP implementation; but it is in fact not applicable to all industries and businesses. For example, Kazi Farms is in the livestock business; and it is almost impossible to implement any kind of meaningful SOP in the livestock business. This is because the production process is a live animal with a natural live-cycle that limits how quickly any change in production can happen. Even if sales orders increase or decrease, livestock production is fixed in the short term as flocks which are in production will continue to produce until age reduces their productivity, regardless of any fall in demand. Likewise, immature flocks cannot be matured more quickly and be made productive ahead of schedule regardless of excess demand. So what benefit was there in implementing ERP in Kazi Farms?

As it turns out, even without Sales and Operations Planning there are many benefits to ERP. Any properly configured ERP software helps to bring management control and transparency to an organization regardless of whether or not SOP is implemented alongside the ERP. For example, in any purchase department a logical sequence of activity becomes essential to ensure that the right items are purchased at the right time without wasting money on excess inventory. At the same time, there should be appropriate checks and balances built in to the purchasing system to ensure that management has approved purchases where required. Transparency of operations is helped immensely by the fact that ERP forces all departments to use the same system; no department, purchase or otherwise, can “hide” information from other interested parties, particularly accounts, audit and top management.

The truth is that in a growing organization that has rapidly increased in size from one or two persons to many, there are often practices in the purchase cycle which can be improved. For example, a basic problem which Kazi Farms had in the pre-ERP days was that storekeepers in many locations were continuously requisitioning items to be bought by the centralized purchase department. The problem was that, without a networked, multi-location inventory system, there was no way for the purchase department to verify whether the requisition could be fulfilled by transferring excess existing stock from another location. This is true for most organizations which have no ERP; inventory in different locations is only known a few times a year when a physical inventory is done. The rest of the time, the purchase department doesn’t have enough information at its disposal to avoid unnecessary purchases. This result is that purchase managers have no choice but to purchase whatever is requisitioned, and lose the opportunity to save money by transferring and reducing excess stocks.

Once an ERP is implemented, the purchase department continuously gets to see a live figure for all inventories at all locations. This allows management to implement many policies which would otherwise be difficult, for example setting high levels and low levels for each inventory item in each location. A high level could raise a flag telling the purchase department that they should try to move the excess item to a different location where it is more likely to be utilized; a low level alerts the purchase department to plan a purchase quickly, and possibly pro-actively reminding the location manager that their stock is low. Once the basics of multi-location live inventory are enabled by ERP, companies can actually try to implement further cost-cutting initiatives like Lean manufacturing / Toyota Production System / kanban, all of which focus on reducing waste and unnecessary stock.

Of significance to many Bangladeshi companies is that ERP can also help to reduce corruption by enforcing discipline in the purchase cycle; this arises because the ERP automatically maintains a paper trail for audit purposes. Once the purchase department receives a requisition, there is a series of steps it has to go through; first, it has to create a Request for Quotations document, which ensures that all suppliers get the same specifications against which to quote prices. The suppliers have to give bids, which can be stored in the system. The system can even be configured to automatically issue purchase orders to the lowest-bidding supplier once the bidding is completed. All of these steps are required to be followed if a purchase department is to function in accordance with best practices and be easily audited; however, without an ERP it is often difficult in a large organization to check if all the above are being followed for every purchase. Once the ERP system is in place, the system itself can alert the purchase manager and the audit department if (for example) there is only one bid stored against the Request for Quotations, alerting everyone that there may be a problem with that purchase. 

ERP allows many further refinements of the purchasing process; for example, what is the approval process for large purchases? Usually there is a requirement for higher level approval than just the location management. ERP systems allow for customizable “work-flows”, meaning that different users can be assigned permissions to approve particular requisitions; without the approval, the item cannot be purchased. Furthermore, the date of the requisition being raised in the location, the date of the higher authority approval and the date of the final purchase by the purchase department are all stored; this allows for identification of where delays are occurring and rectifying them.

The basic rule in any organization is that you can only improve what you can measure; by recording minute details of the purchase procedure, ERP give organizations unprecedented scope for improving it. Since purchase is the basic generator in cost for manufacturing organizations, this can translate to significant savings and higher profits.

Tuesday, 13 December 2011

The art of ERP software selection

By Zeeshan Hasan
(From the October 2011 edition of CIO magazine, Bangladesh edition.)

One of the natural difficulties of a company which has quickly grown from a small size is that it is likely to have its accounting software centralized in a single head office with no distributed accounting or management information system. This sort of legacy accounting system becomes harder and harder to manage as the number of purchase, production and sales locations increases, simply due to the difficulty and delay of manually moving information from various locations to the head office and then processing it in the centralized accounting system. Furthermore, in a situation where purchase, sales, accounts and manufacturing all maintain separate records systems which are not integrated, any error anywhere creates a discrepancy which is difficult to locate and correct. In this respect, rapidly growing Bangladeshi businesses are now experiencing the same problems that companies in the West have been dealing with since the 1980s. The experience of the MIS and management disciplines in developed countries fortunately reveals the solution to the above problem in the form of Enterprise Resource Planning (ERP) software.

Almost everyone has heard of ERP software, but not many are clear about what it does. Primarily, ERP systems integrate all corporate operations and data, including purchase, inventory, manufacturing, sales, accounts, costing and human resources. Modern ERP systems are generally web-based to enable easy access for from multiple locations. Since all information is stored in a central database, everyone always sees the same data and there is no disagreement between figures used by different departments.

Due to the communication difficulties inherent in a big organization, large and even medium sized companies will see the need for ERP software sooner or later. However, this creates a difficult decision; which ERP system is best? The choice is quite bewildering. On the high end of the market there are the established multinational ERP providers such as SAP, Oracle and Microsoft, which have comprehensive functionality proven over thousands of client installations. However, they come at a steep price, invariably costing thousands of dollars per user in up-front software licence costs, as well as hefty customization costs by foreign experts who stay in five-star hotels. At the low end of the market there are local Bangladeshi software companies offering much cheaper solutions, usually costing in the region of tens of lakhs of Takas; however, these can be a risky proposition, having usually been developed for and deployed by only a handful of customers in a limited range of industries. With all due respect to the Bangladeshi software industry, these local solutions cannot really be considered to be proven, general-purpose ERP software, since they simply haven’t been tested in enough varied business contexts. Relying on an unproven, untested ERP system is indeed dangerous, since once an ERP is implemented, every department in a company is dependent on it; major bugs in the system could throw the entire company into chaos.

Obviously both high-end and low-end ERP systems have major disadvantages in terms of cost and risk respectively. Fortunately, a new alternative has emerged as a mid-range compromise; namely open-source ERP software. Open-source software such as the Firefox web browser, LibreOffice word processor, spreadsheet and presentation suite, and the Linux operating system are developed by international teams of programmers collaborating on shared source code which is downloadable from the internet. The successes of these open-source projects have proven over the last decade that the open-source development process is capable of producing high-quality software comparable to the best proprietary products. The open-source software revolution is now beginning to penetrate the ERP space as well.

The major open-source ERP systems such as Adempiere and Openbravo have a simplified but comprehensive feature set comparable to the proprietary ERP products, providing web-based integrated business software which can be downloaded and used without any software license fee. However, implementing ERP will never be free, regardless of the licence cost; this is because each customer requires their ERP software to be customized to their business needs. Therefore ERP software providers need to charge money for software customization, regardless of the license cost of the software. Nonetheless, open-source ERP still can save a lot of money, and can even compare to the low cost of locally produced ERP companies if sufficient open-source ERP expertise is available locally. Furthermore, open source solutions have a big advantage in they have been implemented in hundreds of diverse businesses around the world, and can truly claim to be proven, general purpose business software that will work in any real business setting.

Open source ERP does not just differ from proprietary ERP in terms of license fees; the common feature of all open-source software is that it gives the customer more choice. For example, one can simply download and use a community-supported open-source Linux operating system such as Debian without paying anyone; or, if corporate support is desired, one can choose to buy Red Hat Linux and pay the Red Hat company for the desired services. Similarly, open-source ERP gives the user the choice whether to go with a community-supported or corporate supported version. A short history of a few of the major open-source ERPs will clarify these choices.

The first fully functional open-source ERP product was Compiere ERP, which was produced and supported by Compiere Incorporated in the USA in 2000. However, it initially lacked a web user interface; hence the Compiere open-source code was forked by the Openbravo company in Spain. The Openbravo company added a web user interface and now markets the resulting ERP product as the Openbravo ERP system. Compiere Inc. was then acquired by Consona, a proprietary ERP company, resulting in large portions of its code (including web user interface and manufacturing module) no longer being fully open source and downloadable. This left Openbravo as the remaining commercially supported open-source ERP derived from Compiere. However, the user community of Compiere again forked the code to create the Adempiere open-source ERP project, adding their own community supported web user interface and other features. So now there are two open-source Compiere derived products; the corporate-supported Openbravo and the community-supported Adempiere. Adempiere and Openbravo are both very similar, having been derived from the original Compiere code; both are developed in Java and use Compiere’s concept of a data dictionary which enables customization to be done quickly with little programming and no bugs introduced by fresh programming.

Which is better, a community-supported open-source project like Adempiere, or a company-sponsored open-source product like Openbravo? There is not a simple answer.

Company-sponsored ERPs have an clear element of leadership and accountability provided by the sponsoring company; but there is a cost for this. The Openbravo company does charge money in the form of annual per user support fees. With company-sponsored open source ERP products, there is also always the risk that the sponsoring company will be acquired by an entity not interested in continuing open-source development, as happened to Compiere.

Community sponsored projects like Adempiere may not have a single company making decisions, which can result in lack of direction. Since there is no single company backing the product, it could be difficult to find high quality support and technical expertise for a community-supported product; in fact, availability of support and expertise should always be the deciding factor for any ERP implementation, as poor support will invariably lead to problems . As opposed to the uncertainty over support, there is the long-term guarantee that the ERP software will always be free, as no one entity can claim ownership of it.

Ultimately the decision of whether to go for a proprietary ERP, commercially-supported open-source ERP or community-supported open source ERP is a judgement call that the customer has to make based on their own IT department skills and availability of local support. A table below summarizes some of the costs and benefits of each.

ERP SystemTypeIncludes web interface for purchase, inventory, sales and accounts?    Includes manufacturing?Initial license cost + annual support cost
Oracle, SAP, MicrosoftProprietaryYes, at high costYes, at high additional cost$3000 to $6000 per named user initially + 15% to 20% per year
OpenbravoCommericially supported open-sourceYes, for 365 Euros per user per yearYes, for 500 Euros per user per yearNo initial license fee, 365 to 500 Euros per month per concurrent user
AdempiereCommunity supported open-sourceYesYesNo initial license or annual support fees

Please note that the above table only mentions license and support fees, not customization fees. All ERP systems will require customization fees, and the cost of customization is likely to be substantial for a large organization, regardless of which ERP system is used. Customization cost is likely to depend more on the complexity of the business processes involved, as well as the skills and experience of the company providing the ERP consulting and implementation services.

In spite of many challenges, Bangladesh has been growing. As a result, a number of sectors have expanded rapidly in the last decade or two; including telecoms, garments, textiles, food products, pharmaceuticals, real estate, steel, cement, ceramics, etc. This has naturally created a need for better management and financial control within many rapidly growing companies. Increasing adoption of ERP systems is going to be inevitable as we go forward; as that happens, more and more companies will be faced with the choice of which ERP system to use. Hopefully this article will give people some guidance when they come to that decision.

Kazi Farms' ERP implementation experience

By Zeeshan Hasan
(From the August 2011 issue of CIO magazine, Bangladesh edition)

Practically everyone has heard the ERP buzzword, but many are still unclear what it means; in brief, ERP (Enterprise Resource Planning) is integrated business software which combines accounts, costing, purchase, inventory, manufacturing, sales, human resources and project management. In other words, it’s the holy grail of MIS (Management Information Systems); it puts all company information in one live, constantly updated database where whatever reports anyone requires can be instantly produced.

Three years ago Kazi Farms, the largest poultry company in Bangladesh, decided to embark on its own ERP implementation journey. In the course of it, many mistakes were made and lessons learned. When I started doing research into typical ERP implementations, I realized that the mistakes we made were typical; ERP implementation is a complex business, touching every department in an organization, where many things can and often do go wrong. The academic field of Management of Information Systems largely grew up due to recognition of the fact that around 50% of large software projects (typically ERP) usually fail. This sounds like an incredibly high number, but it’s one that has been repeatedly found by survey after survey around the world.

Why should ERP systems fail so often? The simple reason is their very nature; ERP integrates all departments in an company. But these departments, in the real world, may not be accustomed to working with each other so closely, and may not want to cooperate. Prior to implementing ERP, a company’s sales, purchase, manufacturing and accounts departments operate in relative isolation, since no one else is directly using their data; this means every department is fairly independent. Usually, in companies without ERP, all departments have to reconcile their data only once every thirty days to produce the monthly accounts. But once ERP comes along, everyone is forced to work together and reconcile stocks and other data on a daily basis. People who hardly know each other have to work together very closely. The result is that all the interpersonal and interdepartmental politics lying under the surface of the organization is aggravated. Any such intra-company politics and disagreement is likely to cause the ERP effort to fail, since an integrated ERP system requires coordinated input from every department.

The Kazi Farms experience here will be illustrative. Prior to our ERP effort, Kazi Farms was a highly distributed company operating in many locations; however, there was no distributed information system other than e-mail. The standard way that information was exchanged was by a daily transfer of huge quantities of paper vouchers and documents from each location to a massive team of accountants in the head office, who then put in a superhuman effort to enter all that data into a central Tally accounting package. The old way of doing things had obvious drawbacks; the huge volume of paper vouchers and documents being transfered every day from locations to the head office meant that things sometimes got lost, and the huge pressure of Tally data entry at the head office meant that errors were made. Both of these errors caused problems that took time to resolve. The net result was that accounts could never be made more frequently than once a month, and at a delay of several weeks at that.

Around 2008, GPRS connections finally became sufficiently widespread and reliable that we could think about integrating all these departments and locations with a modern web-based ERP. This was the solution, obviously, to our absurd data entry workload in the accounts department. The central feature of any ERP software is that there is practically no accounting data entry workload; ERP means that all operational data entry such as purchase, manufacturing or sales automatically generates accounting entries in the system. This profoundly changes the work of accountants; they no longer have any data entry to worry about. Instead, they can concentrate on the real work of accounts, which is financial control and cost control.

The first thing we did was recruit a Cheif Technology Officer (CTO), an experienced ERP implementation person with the same status as our existing General Managers of accounts, sales etc. The CTO was given the responsibility of coordinating all the ERP related efforts of different departments. Appointment of the CTO immediately created problems with several General Managers, particularly in the accounts department, as the GM of accounts was suddenly no longer the expert on the accounting system; as an ERP novice, he obviously knew much less about the new accounting system than the CTO.

This started a game of non-cooperation between the GM of accounts and the CTO that severely hampered the ERP implementation. Even though the accounts department was no longer supposed to do the bulk of data entry, they still needed to check all balances and the verify the accuracy of each entry. An ERP software is still an accounting system, and accountants have to ensure the validity of data in any accounting system. That means that, if the ERP is to work, accountants have to minutely supervise the daily data entry work in every single location by every single department; this is a task they may not be prepared for or willing to do. Any wrong data entry anywhere will result in wrong accounting entries being made. If this is not found and corrected immediately, there will be a huge mess in accounts. The fundamental rule of any computerized system is that if you put garbage in, you get garbage out; there is no alternative to correct data entry.

Once the Kazi Farms ERP project began, the accounts department had a vastly changed job; it was more managerial in nature, in that they had to check the data entry work of all departments every day. It was also more distributed, in that they had to do this job in every location every day. That was where the problem lay; the junior accounts people in remote locations were not ready to take on these new responsibilities. They had always done a simple clerical job of writing paper vouchers by hand and sending them to the head office for entry in Tally. This job changed completely; these junior accounts staff suddenly had to make all the real entries into the ERP system. Many of them had never used a computer before, and it required a huge HR effort to arrange training for them.

But even after the junior accounts people were trained in the data entry job, they could not be expected to take over the responsibility of checking all the accounting entries and adjustments that had to be made each month. That was supposed to be the job of the senior accounts staff in the head office. But senior accounts people were busy with their game of non-cooperation with the CTO, and simply refused to take responsibility for data entry accuracy happening at remote locations; they had never visited those places in their lives as accountants, so why should they care about them now? The junior accounts people posted in remote locations were simply not qualified to do the whole job of checking everything themselves without the aid of the senior accountants, who were not interested.

Before we realized what was happening, we saw unacceptable data entry errors creeping into our ERP accounting reports. When asked what was going on, our senior accountants had no answers as they had simply not fulfilled their responsibilities to check all data entry in all locations.

What was the solution at that point? Quite simply, the senior accountants who were becoming the barrier to the ERP running smoothly had to go. We realized that our most senior and highly qualified accountants were not going to accept the new way of working required by the ERP. The management of Kazi Farms made it clear that we were now married to our ERP solution, not to our senior accountants. Ultimately, the senior accountants left or were sidelined to non-critical duties. They were replaced by a new set of senior accountants, recruited from companies which had already implemented ERP solutions, and came in knowing what was expected of them.

In retrospect, we would have had a much easier time implementing our ERP if we had taken three steps to prepare for it better.  Firstly, we should have recruited a number of senior accountants of at least Assistant General Manager level from companies experienced with ERP implementation so that someone senior in the accounts department could be relied upon to take the ERP implementation seriously. Secondly, we should have had a much stronger internal audit department. If internal audit had been stronger, any failure in the accounts department would have been found and highlighted immediately, and been easier to correct. Thirdly, we should have had a better Human Resources department. Our HR department at the time was only concerned with paying monthly salaries and overtime with Excel spreadsheets. But HR should have been the department which identified that our locations were weak in terms of experienced accountants who would not be able to manage the job of checking all data entry; at that point, HR should have pro-actively recruited and trained better people in locations to overcome this weakness.

The good news is that, two years later, our accounts department is reorganized with more capable people in remote locations as well as ERP-savvy senior accountants at the head office; our internal audit and HR departments are also much stronger than they were. In retrospect, strengthening of all these departments was required to make the whole company better managed. The ultimate benefit is that our ERP software is now working, and has made the organization much more efficient and transparent. We have capabilities we could only dream of before, such as up-to-date product costing, live inventories visible in all locations, and the ability to get daily income statements from each location.

As Bangladesh develops, companies will become bigger, and it is inevitable that more of them will be turning to ERP. I hope that this recollection of Kazi Farms’ experience with ERP implementation will be of use to others in their own attempts. As someone once said: “Fools learn from their own mistakes; wise men from those of others.”