ERP Wiki
ERP Wiki
Enterprise Resource Planning systems (ERPs) integrate (or attempt to integrate) all data and processes
of an organization into a unified system. A typical ERP system will use multiple components of
computer software and hardware to achieve the integration. A key ingredient of most ERP systems is
the use of a unified database to store data for the various system modules.
Contents
MRP vs. ERP - Manufacturing management systems have evolved in stages over the past 30 years from
a simple means of calculating materials requirements to the automation of an entire enterprise. Around
1980, over-frequent changes in sales forecasts, entailing continual reajustments in production, as well
as the unsuitability of the parameters fixed by the system, led MRP (Material Requirement Planning) to
evolve into a new concept : Manufacturating Resource Planning (or MRP2) and finally the generic
concept Enterprise Resource Planning (ERP)[1]
The term ERP originally implied systems designed to plan the use of enterprise-wide resources.
Although the initialism ERP originated in the manufacturing environment, today's use of the term ERP
systems has much broader scope. ERP systems typically attempt to cover all basic functions of an
organization, regardless of the organization's business or charter. Business, non-profit organizations,
nongovernmental organizations, governments, and other large entities utilize ERP systems.
Additionally, to be considered an ERP system, a software package generally would only need to provide
functionality in a single package that would normally be covered by two or more systems. Technically, a
software package that provides both payroll and accounting functions would be considered an ERP
software package.
However, the term is typically reserved for larger, more broadly based applications. The introduction of
an ERP system to replace two or more independent applications eliminates the need for external
interfaces previously required between systems, and provides additional benefits that range from
standardization and lower maintenance (one system instead of two or more) to easier and/or greater
reporting capabilities (as all data is typically kept in one database).
Examples of modules in an ERP which formerly would have been stand-alone applications include:
Manufacturing, Supply Chain, Financials, Customer Relationship Management (CRM), Human
Resources, Warehouse Management and Decision Support System.
Overview
Some organizations - typically those with sufficient in-house IT skills to integrate multiple software
products - choose to implement only portions of an ERP system and develop an external interface to
other ERP or stand-alone systems for their other application needs. For instance, the PeopleSoft HRMS
and Financials systems may be perceived to be better than SAP's HRMS solution. And likewise, some
may perceive SAP's manufacturing and CRM systems as better than PeopleSoft's equivalents. In this
case these organizations may justify the purchase of an ERP system, but choose to purchase the
PeopleSoft HRMS and Financials modules from Oracle, and their remaining applications from SAP.[citation
needed]
This is very common in the retail sector[citation needed], where even a mid-sized retailer will have a discrete
Point-of-Sale (POS) product and financials application, then a series of specialised applications to
handle business requirements such as warehouse management, staff rostering, merchandising and
logistics.
Ideally, ERP delivers a single database that contains all data for the software modules, which would
include:
Manufacturing
Engineering, Bills of Material, Scheduling, Capacity, Workflow Management, Quality Control, Cost
Management, Manufacturing Process, Manufacturing Projects, Manufacturing Flow
Supply Chain Management
Inventory, Order Entry, Purchasing, Product Configurator, Supply Chain Planning, Supplier Scheduling,
Inspection of goods, Claim Processing, Commission Calculation
Financials
General Ledger, Cash Management, Accounts Payable, Accounts Receivable, Fixed Assets
Projects
Costing, Billing, Time and Expense, Activity Management
Human Resources
Human Resources, Payroll, Training, Time & Attendance, Benefits
Customer Relationship Management
Sales and Marketing, Commissions, Service, Customer Contact and Call Center support
Data Warehouse
and various Self-Service interfaces for Customers, Suppliers, and Employees
Enterprise Resource Planning is a term originally derived from manufacturing resource planning (MRP
II) that followed material requirements planning (MRP). MRP evolved into ERP when "routings" became
major part of the software architecture and a company's capacity planning activity also became a part
of the standard software activity. ERP systems typically handle the manufacturing, logistics,
distribution, inventory, shipping, invoicing, and accounting for a company. Enterprise Resource
Planning or ERP software can aid in the control of many business activities, like sales, marketing,
delivery, billing, production, inventory management, quality management, and human resource
management.
ERPs are often incorrectly called back office systems indicating that customers and the general public
are not directly involved. This is contrasted with front office systems like customer relationship
management (CRM) systems that deal directly with the customers, or the eBusiness systems such as
eCommerce, eGovernment, eTelecom, and eFinance, or supplier relationship management (SRM)
systems.
ERPs are cross-functional and enterprise wide. All functional departments that are involved in
operations or production are integrated in one system. In addition to manufacturing, warehousing,
logistics, and Information Technology, this would include accounting, human resources, marketing, and
strategic management.
ERP II means open ERP architecture of components. The older, monolithic ERP systems became
component oriented.
EAS - Enterprise Application Suite is a new name for formerly developed ERP systems which include
(almost) all segments of business, using ordinary Internet browsers as thin clients.
Before
Prior to the concept of ERP systems, departments within an organization (for example, the Human
Resources (HR) department, the Payroll (PR) department, and the Financials department) would have
their own computer systems. The HR computer system (Often called HRMS or HRIS) would typically
contain information on the department, reporting structure, and personal details of employees. The PR
department would typically calculate and store paycheck information. The Financials department would
typically store financial transactions for the organization. Each system would have to rely on a set of
common data to communicate with each other. For the HRIS to send salary information to the PR
system, an employee number would need to be assigned and remain static between the two systems
to accurately identify an employee. The Financials system was not interested in the employee level
data, but only the payouts made by the PR systems, such as the Tax payments to various authorities,
payments for employee benefits to providers, and so on. This provided complications. For instance, a
person could not be paid in the Payroll system without an employee number.
After
ERP software, among other things, combined the data of formerly separate applications. This made the
worry of keeping numbers in synchronization across multiple systems disappear. It standardised and
reduced the number of software specialities required within larger organizations.
Best Practices
Best Practices were also a benefit of implementing an ERP system. When implementing an ERP system,
organizations essentially had to choose between customizing the software or modifying their business
processes to the "Best Practice" functionality delivered in the vanilla version of the software.
Typically, the delivery of best practice applies more usefully to large organizations and especially where
there is a compliance requirement such as IFRS, Sarbanes-Oxley or Basel II, or where the process is a
commodity such as electronic funds transfer. This is because the procedure of capturing and reporting
legislative or commodity content can be readily codified within the ERP software, and then replicated
with confidence across multiple businesses who have the same business requirement.
Where such a compliance or commodity requirement does not underpin the business process, it can be
argued that determining and applying a best practice actually erodes competitive advantage by
homogenizing the business compared to everyone else in their industry sector.
Implementation
Because of their wide scope of application within a business, ERP software systems are typically
complex and usually impose significant changes on staff work practices. Implementing ERP software is
typically not an "in-house" skill, so even smaller projects are more cost effective if specialist ERP
implementation consultants are employed. The length of time to implement an ERP system depends on
the size of the business, the scope of the change and willingness of the customer to take ownership for
the project. A small project (e.g., a company of less than 100 staff) may be planned and delivered
within 3 months; however, a large, multi-site or multi-country implementation may take years.
The most important aspect of any ERP implementation is that the company who has purchased the ERP
product takes ownership of the project.
To implement ERP systems, companies often seek the help of an ERP vendor or of third-party
consulting companies. These firms typically provide three areas of professional services: Consulting,
Customization and Support.
Consulting Services
The Consulting team is typically responsible for your initial ERP implementation and subsequent
delivery of work to tailor the system beyond "go live". Typically such tailoring includes additional
product training; creation of process triggers and workflow; specialist advice to improve how the ERP is
used in the business; system optimization; and assistance writing reports, complex data extracts or
implementing Business Intelligence.
The consulting team are also responsible for planning and jointly testing the implementation. This is a
critical part of the project, and one that is often overlooked.
Consulting for a large ERP project involves three levels: systems architecture, business process
consulting (primarily re-engineering) and technical consulting (primarily programming and tool
configuration activity). A systems architect designs the overall dataflow for the enterprise including the
future dataflow plan. A business consultant studies an organization's current business processes and
matches them to the corresponding processes in the ERP system, thus 'configuring' the ERP system to
the organization's needs. Technical consulting often involves programming. Most ERP vendors allow
modification of their software to suit the business needs of their customer.
For most mid-sized companies, the cost of the implementation will range from around the list price of
the ERP user licenses to up to twice this amount (depending on the level of customization required).
Large companies, and especially those with multiple sites or countries, will often spend considerably
more on the implementation than the cost of the user licenses -- three to five times more is not
uncommon for a multi-site implementation.
Customization Services
Customization is the process of extending or changing how the system works by writing new user
interfaces and underlying application code. Such customisations typically reflect local work practices
that are not currently in the core routines of the ERP system software.
Examples of such code include early adopter features (e.g., mobility interfaces were uncommon a few
years ago and were typically customised) or interfacing to third party applications (this is 'bread and
butter' customization for larger implementations as there are typically dozens of ancillary systems that
the core ERP software has to interact with). The Professional Services team is also involved during ERP
upgrades to ensure that customisations are compatible with the new release. In some cases the
functionality delivered via a previous customization may have been subsequently incorporated into the
core routines of the ERP software, allowing customers to revert back to standard product and retire the
customization completely.
Customizing an ERP package can be very expensive and complicated, because many ERP packages are
not designed to support customization, so most businesses implement the best practices embedded in
the acquired ERP system. Some ERP packages are very generic in their reports and inquiries, such that
customization is expected in every implementation. It is important to recognize that for these packages
it often makes sense to buy third party plug-ins that interface well with your ERP software rather than
reinventing the wheel.
Customization work is usually undertaken as bespoke software development on a time and materials
basis. Because of the specialist nature of the customization and the 'one off' aspect of the work, it is
common to pay in the order of $200 per hour for this work. Also, in many cases the work delivered as
customization is not covered by the ERP vendors Maintenance Agreement, so while there is typically a
90-day warranty against software faults in the custom code, there is no obligation on the ERP vendor
to warrant that the code works with the next upgrade or point release of the core product.
One often neglected aspect of customization is the associated documentation. While it can seem like a
considerable -- and expensive -- overhead to the customization project, it is critical that someone is
responsible for the creation and user testing of the documentation. Without the description on how to
use the customisation, the effort is largely wasted as it becomes difficult to train new staff in the work
practice that the customization delivers.
Once your system has been implemented, the consulting company will typically enter into a Support
Agreement to assist your staff to keep the ERP software running in an optimal way. To minimize
additional costs and provide more realism into the needs of the units to be affected by ERP (as an
added service to customers), the option of creating a committee headed by the consultant using
participative management approach during the design stage with the client's heads of departments (no
substitutes allowed) to be affected by the changes in ERPs to provide hands on management control
requirements planning. This would allow direct long term projections into the client's needs, thus
minimizing future conversion patches (at least for the 1st 5 years operation unless there is a corporate-
wide organizational structural change involving operational systems) on a more dedicated approach to
initial conversion.
A Maintenance Agreement typically provides you rights to all current version patches, and both minor
and major releases, and will most likely allow your staff to raise support calls. While there is no
standard cost for this type of agreement, they are typically between 15% and 20% of the list price of
the ERP user licenses.
Advantages
In the absence of an ERP system, a large manufacturer may find itself with many software applications
that do not talk to each other and do not effectively interface. Tasks that need to interface with one
another may involve:
design engineering (how to best make the product)
order tracking from acceptance through fulfillment
the revenue cycle from invoice through cash receipt
managing interdependencies of complex Bill of Materials
tracking the 3-way match between Purchase orders (what was ordered), Inventory receipts (what
arrived), and Costing (what the vendor invoiced)
the Accounting for all of these tasks, tracking the Revenue, Cost and Profit on a granular level.
Change how a product is made, in the engineering details, and that is how it will now be made.
Effective dates can be used to control when the switch over will occur from an old version to the next
one, both the date that some ingredients go into effect, and date that some are discontinued. Part of
the change can include labeling to identify version numbers.
Computer security is included within an ERP to protect against both outsider crime, such as industrial
espionage, and insider crime, such as embezzlement. A data tampering scenario might involve a
terrorist altering a Bill of Materials so as to put poison in food products, or other sabotage. ERP security
helps to prevent abuse as well.
Disadvantages
Many problems organizations have with ERP systems are due to inadequate investment in ongoing
training for involved personnel, including those implementing and testing changes, as well as a lack of
corporate policy protecting the integrity of the data in the ERP systems and how it is used.
Limitations of ERP include:
Success depends on the skill and experience of the workforce, including training about how to make
the system work correctly. Many companies cut costs by cutting training budgets. Privately owned
small enterprises are often undercapitalized, meaning their ERP system is often operated by personnel
with inadequate education in ERP in general, such as APICS foundations, and in the particular ERP
vendor package being used.
Personnel turnover; companies can employ new managers lacking education in the company's ERP
system, proposing changes in business practices that are out of synchronization with the best
utilization of the company's selected ERP.
Customization of the ERP software is limited. Some customization may involve changing of the ERP
software structure which is usually not allowed.
Re-engineering of business processes to fit the "industry standard" prescribed by the ERP system may
lead to a loss of competitive advantage.
ERP systems can be very expensive to install often ranging from 30,000 to 500,000,000 for
multinational companies.
ERP vendors can charge sums of money for annual license renewal that is unrelated to the size of the
company using the ERP or its profitability.
Technical support personnel often give replies to callers that are inappropriate for the caller's corporate
structure. Computer security concerns arise, for example when telling a non-programmer how to
change a database on the fly, at a company that requires an audit trail of changes so as to meet some
regulatory standards.
ERPs are often seen as too rigid and too difficult to adapt to the specific workflow and business process
of some companies—this is cited as one of the main causes of their failure.
Systems can be difficult to use.
Systems are too restrictive and do not allow much flexibility in implementation and usage.
The system can suffer from the "weakest link" problem—an inefficiency in one department or at one of
the partners may affect other participants.
Many of the integrated links need high accuracy in other applications to work effectively. A company
can achieve minimum standards, then over time "dirty data" will reduce the reliability of some
applications.
Once a system is established, switching costs are very high for any one of the partners (reducing
flexibility and strategic control at the corporate level).
The blurring of company boundaries can cause problems in accountability, lines of responsibility, and
employee morale.
Resistance in sharing sensitive internal information between departments can reduce the effectiveness
of the software.
There are frequent compatibility problems with the various legacy systems of the partners.
The system may be over-engineered relative to the actual needs of the customer.