Recently I published an article on a project to developing free/open-source software for livestock feed formulation. Hope it's useful.
Thursday 30 November 2017
Wednesday 5 April 2017
Migrating a TV station to Free/Open-Source Software
Recently I spoke at the 2017 LibrePlanet conference organized by the Free Software Foundation at the MIT campus in Cambridge, USA about Sysnova's experience of migrating a TV channel in Bangladesh from proprietary to free/open-source technology. Hope the presentation slides are informative.
Previously I wrote about this project in a shorter newspaper article.
Previously I wrote about this project in a shorter newspaper article.
Wednesday 1 February 2012
Controlling Costs With Adempiere ERP
by Zeeshan Hasan
(First published in the January 2012 edition of CIO Bangladesh)
One of the benefits of ERP software is greater ease of monitoring and controlling costs. Traditionally, costing was a difficult and laborious process requiring a cost accountant to manipulate massive spreadsheets summarizing purchase, inventory and manufacturing data. As these numbers are generated in different departments, just finding them is difficult without an integrated ERP. Simplification of data-gathering from differerent departments is in fact the basic promise of any ERP software; including the open-source Adempiere ERP used in my company, Kazi Farms.
Once an ERP is implemented, the first hurdle of acquiring costing data from its sources in different departments is overcome; the integrated database of any ERP contains all the data of the whole organization. However, the question then arises as to whether the accounts department uses a costing method which makes controlling costs easier. Many companies have their beginnings in simply trading; especially in developing countries like Bangladesh, where many items are traditionally imported as finished goods. For a trading company, the main generator of cost is in purchase. In this case, any costing method, whether average costing or FIFO (first in, first out) will work, as both these costing methods focus on monitoring the prices at which inventories are purchased.
But the scenario is more complex in a manufacturing setting. Once a company makes the jump to manufacturing, simpler costing methods such as average cost and FIFO are generally of limited usefulness. This is because purchase of raw materials is only one of the elements of the cost of the manufactured product. Other cost elements also need to be monitored, such as labour, power, spare parts used and depreciation expense incurred. The price and quantity of each of these required for a unit of production can vary depending on how efficiently the production process is managed.
Cost control of manufacturing generally requires a manufacturing budget to be established for the finished product which will specify target costs of raw materials, labour and power and depreciation. This is best done through adoption of standard costing. Like most ERP softwares, the Adempiere open-source ERP package supports standard costing.
Implementing standard costs accordingly requires estimation of target costs for each individual input. As each item of production is actually completed, the ERP system will capture actual data of those costs. These are then compared with the standard (budgeted) costs by means of variance accounts. For example, an inefficient production process which wastes raw materials will show positive variance on raw materials; an efficient production process which used less than the budgeted raw materials will show negative variance. By examining variance accounts, more efficient production processes, workers and managers can be identified. This can result in cutting costs and a better bottom line, which is the efficiency that ERP promises.
The difficulty with the above is that many costs are only available at the end of the month (for example, when monthly salary and utilities bills are paid). Therefore, an ERP system has to include some means of estimating what those costs will be with each item produced. By including this estimation of monthly costs as a monthly provision distributed to each unit of production, Adempiere ERP can give an estimated daily costing and (when combined with actual sales revenues) a daily income statement.
Daily product costing, detailed monitoring of the costs through variances with standard/budgeted costs and actually being able to provide a daily income statement are ultimately the tools which management requires in any company to understand which products, workers and managers are more effective. Identifying and replicating such successful practices are key to the goal of continuous improvement and lean manufacturing as exemplified by the incredible successes of the Toyota production system in Japan. There is often a tendency on the part of complacent managers to assume that such modern business philosophies are foreign to Bangladesh and will never work here; but being competitive in the global economy requires that these ideas ultimately be made to work. Modern ERP softwares are one tool to help companies cut costs and realise these gains.
(First published in the January 2012 edition of CIO Bangladesh)
One of the benefits of ERP software is greater ease of monitoring and controlling costs. Traditionally, costing was a difficult and laborious process requiring a cost accountant to manipulate massive spreadsheets summarizing purchase, inventory and manufacturing data. As these numbers are generated in different departments, just finding them is difficult without an integrated ERP. Simplification of data-gathering from differerent departments is in fact the basic promise of any ERP software; including the open-source Adempiere ERP used in my company, Kazi Farms.
Once an ERP is implemented, the first hurdle of acquiring costing data from its sources in different departments is overcome; the integrated database of any ERP contains all the data of the whole organization. However, the question then arises as to whether the accounts department uses a costing method which makes controlling costs easier. Many companies have their beginnings in simply trading; especially in developing countries like Bangladesh, where many items are traditionally imported as finished goods. For a trading company, the main generator of cost is in purchase. In this case, any costing method, whether average costing or FIFO (first in, first out) will work, as both these costing methods focus on monitoring the prices at which inventories are purchased.
But the scenario is more complex in a manufacturing setting. Once a company makes the jump to manufacturing, simpler costing methods such as average cost and FIFO are generally of limited usefulness. This is because purchase of raw materials is only one of the elements of the cost of the manufactured product. Other cost elements also need to be monitored, such as labour, power, spare parts used and depreciation expense incurred. The price and quantity of each of these required for a unit of production can vary depending on how efficiently the production process is managed.
Cost control of manufacturing generally requires a manufacturing budget to be established for the finished product which will specify target costs of raw materials, labour and power and depreciation. This is best done through adoption of standard costing. Like most ERP softwares, the Adempiere open-source ERP package supports standard costing.
Implementing standard costs accordingly requires estimation of target costs for each individual input. As each item of production is actually completed, the ERP system will capture actual data of those costs. These are then compared with the standard (budgeted) costs by means of variance accounts. For example, an inefficient production process which wastes raw materials will show positive variance on raw materials; an efficient production process which used less than the budgeted raw materials will show negative variance. By examining variance accounts, more efficient production processes, workers and managers can be identified. This can result in cutting costs and a better bottom line, which is the efficiency that ERP promises.
The difficulty with the above is that many costs are only available at the end of the month (for example, when monthly salary and utilities bills are paid). Therefore, an ERP system has to include some means of estimating what those costs will be with each item produced. By including this estimation of monthly costs as a monthly provision distributed to each unit of production, Adempiere ERP can give an estimated daily costing and (when combined with actual sales revenues) a daily income statement.
Daily product costing, detailed monitoring of the costs through variances with standard/budgeted costs and actually being able to provide a daily income statement are ultimately the tools which management requires in any company to understand which products, workers and managers are more effective. Identifying and replicating such successful practices are key to the goal of continuous improvement and lean manufacturing as exemplified by the incredible successes of the Toyota production system in Japan. There is often a tendency on the part of complacent managers to assume that such modern business philosophies are foreign to Bangladesh and will never work here; but being competitive in the global economy requires that these ideas ultimately be made to work. Modern ERP softwares are one tool to help companies cut costs and realise these gains.
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.
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.
(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 System | Type | Includes web interface for purchase, inventory, sales and accounts? | Includes manufacturing? | Initial license cost + annual support cost |
| Oracle, SAP, Microsoft | Proprietary | Yes, at high cost | Yes, at high additional cost | $3000 to $6000 per named user initially + 15% to 20% per year |
| Openbravo | Commericially supported open-source | Yes, for 365 Euros per user per year | Yes, for 500 Euros per user per year | No initial license fee, 365 to 500 Euros per month per concurrent user |
| Adempiere | Community supported open-source | Yes | Yes | No 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.”
(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.”
Subscribe to:
Posts (Atom)