online resources to understand basic concepts of 0

ERP
Reply from jlolverah | posted May 25, 2007 | Replies (6)

You can split ERP concepts in 2, Technical and Functional

You need to decide what you want the technical side, means, installation,
patches, bugs, database admin, etc,
or the functional side, meaning General Ledger, Accounts Payables, Account
Receivables, Purchasing, Inventory, etc

For the functional side you need to understand also the business process,
knowing the ERP only is just a start, but to be able to have a conversation
with a functional user who has been working on his/her area for more than
5/10 years, you need to talk the same language, at least understand it.

Enterprise modelling
From Wikipedia, the free encyclopedia

Graphical representation of some types of models in enterprise modelling. A business model illustrates the functions
associated with a process that are performance and the organizations that perform these functions. In software development
often both business process modelsand data models are being developed as part of the process of creating application
programs on the one side and databases on the other side.[1]
Enterprise modelling is the abstract representation, description and definition of the
structure, processes, information and resources of an
identifiable business, government body, or other large organization.[2]

It deals with the process of understanding an enterprise business and improving its
performance through creation of enterprise models. This includes the modelling of the
relevant business domain (usually relatively stable), business processes (usually more
volatile), and Information technology.
Contents

[hide]

• 1 Overview

• 2 History

• 3 Enterprise modelling

basics

○ 3.1 Enterprise

model

○ 3.2 Function

modelling

○ 3.3 Data

modelling

○ 3.4 Business

process modelling

○ 3.5 Systems

architecture

• 4 Enterprise modelling

techniques

• 5 Enterprise engineering

• 6 Related fields

○ 6.1 Business

reference

modelling

○ 6.2 Economic
 modelling

○ 6.3 Ontology

engineering

○ 6.4 Systems

thinking

• 7 See also

• 8 References

• 9 Further reading

• 10 External links

[edit]Overview

Enterprise modelling is the process of building models of whole or part of

an enterprise with process models, data models, resource models and or
new ontologies etc. It is based on knowledge about the enterprise, previous models
and/or reference models as well as domain ontologies using model representation
languages.[3] An enterprise in general is a unit of economic organization or activity. These
activities are required to develop and deliver products and/or services to a customer. An
enterprise includes a number of functions and operations such as purchasing,
manufacturing, marketing, finance, engineering, and research and development. The
enterprise of interest are those corporate functions and operations necessary to
manufacture current and potential future variants of a product.[4]

The term "enterprise model" is used in industry to represent differing enterprise

representations, with no real standardized definition.[5] Due to the complexity of enterprise
organizations, a vast number of differing enterprise modelling approaches have been
pursued across industry and academia.[6] Enterprise modelling constructs can focus upon
manufacturing operations and/or business operations; however, a common thread in
enterprise modelling is an inclusion of assessment of information technology. For example,
the use of networked computers to trigger and receive replacement orders along a material
supply chain is an example of how information technology is used to coordinate
manufacturing operations within an enterprise.[4]

The basic idea of enterprise modelling according to Ulrich Frank[7] is "to offer
different views on an enterprise, thereby providing a medium to foster dialogues between
various stakeholders - both in academia and in practice. For this purpose they include
abstractions suitable for strategic planning, organisational (re-) design and software
engineering. The views should complement each other and thereby foster a better
understanding of complex systems by systematic abstractions. The views should be generic
in the sense that they can be applied to any enterprise. At the same time they should offer
abstractions that help with designing information systems which are well integrated with a
company's long term strategy and its organisation. Hence, enterprise models can be
regarded as the conceptual infrastructure that support a high level of integration."[7]

[edit]History

Enterprise modelling has its roots in systems modelling and especially information systems
modelling. One of the earliest pioneering works in modelling information systems has been
done by Young and Kent (1958),[8][9] who argued for "a precise and abstract way of
specifying the informational and time characteristics of a data processing problem". They
wanted to create "a notation that should enable the analyst to organize the problem around
any piece of hardware". Their work was a first efforts to create an abstract specification and
invariant basis for designing different alternative implementations using different hardware
components. A next step in IS modelling was taken by CODASYL, an IT industry
consortium formed in 1959, who essentially aimed at the same thing as Young and Kent:
the development of "a proper structure for machine independent problem definition
language, at the system level of data processing". This lead to the development of a specific
ISinformation algebra.[9]

The first methods dealing with enterprise modelling emerged in the 1970s. They were
the entity-relationship approach of Peter Chen (1976) and SADT of Douglas T. Ross (1977),
the one concentrate on the information view and the other on the function view of business
entities.[3] These first methods have been followed end 1970s by numerous methods
for software engineering, such as SSADM,Structured Design, Structured Analysis and
others. Specific methods for enterprise modelling in the context of Computer Integrated
Manufacturing appeared in the early 1980s. They include the IDEFfamily of methods (ICAM,
1981) and the GRAI method by Doumeingts in 1984[10] followed by GRAI/GIM by
Doumeingts and others in 1992.[11]

These second generation of methods were activity-based methods which have been
surpassed on the one hand by process-centred modelling methods developed in the 1990s
such as Architecture of Integrated Information Systems (ARIS), CIMOSA and Integrated
Enterprise Modeling (IEM). And on the other hand by object-oriented methods, such
as Object-oriented analysis (OOA) and Object-modelling technique (OMT).[3]
[edit]Enterprise modelling basics
[edit]Enterprise model
An enterprise model is a representation of the structure, activities, processes, information,
resources, people, behavior, goals, and constraints of a business, government, or other
enterprises.[12]Thomas Naylor (1970) defined a (simulation) model as "an attempt to
describe the interrelationships among a corporation's financial, marketing, and production
activities in terms of a set of mathematical and logical relationships which are programmed
into the computer."[13] These interrelationships should according to Gershefski (1971)
represent in detail all aspects of the firm including "the physical operations of the company,
the accounting and financial practices followed, and the response to investment in key
areas"[14] Programming the modelled relationships into the computer in not always
necessary: enterprise models, under different names, have existed for centuries and were
described, for example, by Adam Smith, Walter Bagehot, and many others.

According to Fox and Gruninger (1998) from "a design perspective, an enterprise model
should provide the language used to explicitly define an enterprise... From an operations
perspective, the enterprise model must be able to represent what is planned, what might
happen, and what has happened. It must supply the information and knowledge necessary
to support the operations of the enterprise, whether they be performed by hand or
machine."[12]

In a two-volume set entitled The Managerial Cybernetics of Organization Stafford Beer

introduced a model of the enterprise, the Viable System Model (VSM). Volume 2, The Heart
of Enterprise,[15]analyzed the VSM as a recursive organization of five systems: System One
(S1) through System Five (S5). Beer's model differs from others in that the VSM is
recursive, not hierarchical: "In a recursive organizational structure, any viable system
contains, and is contained in, a viable system."[15]
[edit]Function modelling

Example of a function model of the process of "Maintain Reparable Spares" in IDEF0 notation.

Function modelling in systems engineering is a structured representation of the functions,

activities or processes within the modelledsystem or subject area.[16]

A function model, also called an activity model or process model, is a graphical

representation of an enterprise's function within a defined scope. The purpose of the
function model are to describe the functions and processes, assist with discovery of
information needs, help identify opportunities, and establish a basis for determining product
and service costs.[17] A function model is created with a functionalmodelling perspective. A
functional perspectives is one or more perspectives possible in process modelling. Other
perspectives possible are for example behavioural, organisational or informational.[18]

A functional modelling perspective concentrates on describing the dynamic process. The

main concept in this modelling perspective is the process, this could be a function,
transformation, activity, action, task etc. A well-known example of a modelling language
employing this perspective is data flow diagrams. The perspective uses four symbols to
describe a process, these being:

 Process: Illustrates transformation from input to output.

 Store: Data-collection or some sort of material.

 Flow: Movement of data or material in the process.

 External Entity: External to the modelled system, but interacts with it.
Now, with these symbols, a process can be represented as a network of these symbols.
This decomposed process is a DFD, data flow diagram. In Dynamic Enterprise Modeling,
for example, a division is made in the Control model, Function Model, Process
model andOrganizational model.

[edit]Data modelling

The data modelling process.

Data modelling is the process of creating a data model by applying formal data model
descriptions using data modelling techniques. Data modelling is a technique for defining
business requirements for a database. It is sometimes called database modelling because
a data model is eventually implemented in a database.[19]

The figure illustrates the way data models are developed and used today. A conceptual
data model is developed based on the data requirements for the application that is being
developed, perhaps in the context of an activity model. The data model will normally consist
of entity types, attributes, relationships, integrity rules, and the definitions of those objects.
This is then used as the start point for interface or database design.[20]

[edit]Business process modelling

Example of business process modelling with the Business Process Modeling Notation.

Business process modelling (BPM) is the activity of representing processes of an

enterprise, so that the current ("as is") process may be analyzed and improved in future ("to
be"). Business process modelling is typically performed by business analysts and managers
who are seeking to improve process efficiency and quality. The process improvements
identified by business process modelling may or may not require Information
Technology involvement, although that is a common driver for the need to model a business
process, by creating a process master.

Change management programs are typically involved to put the improved business
processes into practice. With advances in technology from large platform vendors, the
vision of business process modelling models becoming fully executable (and capable of
simulations and round-trip engineering) is coming closer to reality every day.

[edit]Systems architecture
The RM-ODP reference model identifies enterprise modelling as providing one of the five
viewpoints of an open distributed system. Note that such a system need not be a modern-
day IT system: a banking clearing house in the 19th century may be used as an example.

[edit]Enterprise modelling techniques

There are several techniques for modelling the enterprise such as

 Active Knowledge Modeling,[21]

 Design & Engineering Methodology for Organizations (DEMO)

 Dynamic Enterprise Modeling

 Enterprise Modelling Methodology/Open Distributed Processing (EMM/ODP)

 Extended Enterprise Modeling Language

 Multi-Perspective Enterprise Modelling (MEMO),[22]

 Process modelling such as CIMOSA, DYA, IDEF3, LOVEM, PERA, etc.

 Integrated Enterprise Modeling (IEM), and

 Modelling the enterprise with multi-agent systems.

More enterprise modelling techniques are developed into Enterprise Architecture
framework such as:
 ARIS - ARchitecture of Integrated Information Systems

 DoDAF - the US Department of Defense Architecture Framework

 OBASHI The OBASHI Business & IT methodology and framework

 RM-ODP - Reference Model of Open Distributed Processing

 TOGAF - The Open Group Architecture Framework

 Zachman Framework - an architecture framework, based on the work of John

Zachman at IBM in the 1980s
And metamodelling frameworks such as:

 Generalised Enterprise Reference Architecture and Methodology

[edit]Enterprise engineering
Enterprise engineering is the discipline concerning the design and the engineering
of enterprises, regarding both their business and organization.[23] In theory and practice two
types of enterprise engineering has emerged. A more general connected to engineering and
the management of enterprises, and a more specific related to software engineering,
enterprise modelling and enterprise architecture.

In the field of engineering a more general enterprise engineering emerged, defined[24] as the
application of engineering principals to the management of enterprises. It encompasses the
application of knowledge, principles, and disciplines related to the analysis, design,
implementation and operation of all elements associated with an enterprise. In essence this
is an interdisciplinary field which combines systems engineering and strategic
management as it seeks to engineer the entire enterprise in terms of
the products, processes and business operations. The view is one of continuous
improvement and continued adaptation as firms, processes and markets develop along
their life cycles. This total systems approach encompasses the traditional areas of research
and development, product design, operations and manufacturing as well as information
systems and strategic management.[24] This fields is related to engineering
management, operations management, service management and systems engineering.

In the context of software development a specific field of enterprise engineering has

emerged, which deals with the modelling and integration of various organizational and
technical parts of business processes.[25] In the context of information systems development
it has been the area of activity in the organization of the systems analysis, and an extension
of the scope of Information Modelling.[26]It can also be viewed as the extension and
generalization of the systems analysis and systems design phases of the software
development process.[27] Here Enterprise modelling can be part of the early, middle and
late information system development life cycle. Explicit representation of the organizational
and technical system infrastructure is being created in order to understand the orderly
transformations of existing work practices.[27] This field is also called Enterprise architecture,
or defined with Enterprise Ontology as being two major parts of Enterprise architecture.[23]

[edit]Related fields
[edit]Business reference modelling

Example of the US FEA Business Reference Model.[28]

Business reference modelling is the development of reference models concentrating on the

functional and organizational aspects of the core business of an enterprise, service
organization or government agency. In enterprise engineering a business reference model
is part of anenterprise architecture framework. This framework defines in a series of
reference models, how to organize the structure and viewsassociated with an Enterprise
Architecture.

A reference model in general is a model of something that embodies the basic goal or idea
of something and can then be looked at as a reference for various purposes. A business
reference model is a means to describe the business operations of an organization,
independent of the organizational structure that perform them. Other types of business
reference model can also depict the relationship between thebusiness processes, business
functions, and the business area’s business reference model. These reference model can
be constructed in layers, and offer a foundation for the analysis of service components,
technology, data, and performance.
[edit]Economic modelling

A diagram of the IS/LM model

Economic modelling is the theoretical representation of economic processes by a set

of variablesand a set of logical and/or quantitative relationships between them. The
economic model is a simplified framework designed to illustrate complex processes, often
but not always using mathematical techniques. Frequently, economic models use structural
parameters. Structural parameters are underlyingparameters in a model or class of models.
[29]
A model may have various parameters and those parameters may change to create
various properties.[30]

In general terms, economic models have two functions: first as a simplification of and
abstraction from observed data, and second as a means of selection of data based on
a paradigm of econometric study. The simplification is particularly important for economics
given the enormous complexity of economic processes. This complexity can be attributed to
the diversity of factors that determine economic activity; these factors include: individual
and cooperativedecision
processes, resource limitations, environmental and geographical constraints, institutional
and legal requirements and purely random fluctuations. Economists therefore must make a
reasoned choice of which variables and which relationships between these variables are
relevant and which ways of analyzing and presenting this information are useful.

[edit]Ontology engineering
Ontology engineering or ontology building is a subfield of knowledge engineering that
studies the methods and methodologies for building ontologies. In the domain of enterprise
architecture, an ontology is an outline or a schema used to structure objects, their attributes
and relationships in a consistent manner.[4]As in enterprise modelling, an ontology can be
composed of other ontologies. The purpose of ontologies in enterprise modelling is to
formalize and establish the sharability, re-usability, assimilation and dissemination of
information across all organizations and departments within an enterprise. Thus, an
ontology enables integration of the various functions and processes which take place in an
enterprise.[31]

One common language with well articulated structure and vocabulary would enable the
company to be more efficient in its operations. A common ontology will allow for effective
communication, understanding and thus coordination among the various divisions of an
enterprise. There are various kinds of ontologies used in numerous environments. While the
language example given earlier dealt with the area of information systems and design, other
ontologies may be defined for processes, methods, activities, etc., within an enterprise.[4]

Using ontologies in enterprise modelling offers several advantages. Ontologies ensure

clarity, consistency, and structure to a model. They promote efficient model definition and
analysis. Genericenterprise ontologies allow for reusability of and automation of
components. Because ontologies are schemata or outlines, the use of ontologies does not
ensure proper enterprise model definition, analysis, or clarity. Ontologies are limited by how
they are defined and implemented. An ontology may or may not include the potential or
capability to capture the all of the aspects of what is being modelled.[4]

[edit]Systems thinking
Main article: Systems thinking

The modelling of the enterprise and its environment could facilitate the creation of enhanced
understanding of the business domain and processes of the extended enterprise, and
especially of the relations—both those that "hold the enterprise together" and those that
extend across the boundaries of the enterprise. Since enterprise is a system, concepts used
in system thinking[32] can be successfully reused in modelling enterprises.

This way a fast understanding can be achieved throughout the enterprise about how
business functions are working and how they depend upon other functions in the
organization.
Some of the ERP packages are as follows:

On the basis of application

Customized package
ERP packages will be helpful to the company when it is designed in consultation with the In house People. This is not
equally free from limitations. It can play havoc in the due course because the customizations can defeat the
functioning and objective of the ERP process.

Readymade packagesThis type of ERP packages require the company to adjust to the business process. The
company experiences a paradigm shift in the way it transacts business. This is intended to set the business process
to become more ERP friendly.

On the basis of implementation

Big Bang
Some large companies choose this sort of package whereby they can go ahead with ERP implementation at one
stroke. The entire process in the organization will be rejuvenated. This means they can experience the working of
ERP in the whole organization right from the day one after it is implemented.

Franchising option
This package is about partial implementation whereby the company chooses to implement ERP in selected functions
that do not need or have a familiar interface. ERP package will perform that particular function or functions for which it
is implemented. The rest will be going on as usual.

Slam DunkThese ERP packages are similar to the readymade one discussed under application category. The
company modifies and restructures its process in tune with ERP functions. The only difference between this and the
packaged software is that the company chooses to go for the former irrespective of the size whereas only small
companies desiring to become ERP friendly can afford this because it calls for a great amount of restructuring which
is practically not possible in big companies.

Making the choice

The major issue in choosing ERP package reflecting the purpose of implementing ERP in the organization and the
areas or troubles intended to be covered. This will give a fair idea on the type of ERP package that the company has
to choose. This has two aspects. The company needs to identify the avenues for improvement. The company then
has to see that are of services specialized by the vendor. The requirements of the company have to be matched with
the ERP Vendor.

At the same time it has to square the procedures whose efficiency needs to be improved from the good state to
excellent trademark. If a company is successful in spotting these elements then it will be able to decide the
appropriate ERP package.

Conclusion:
Whether the company goes for customized or readymade is purely dependent on the company's requirements. The
impact of ERP on the company's business process and its willingness to adapt to change is equally important to
decide this issue and the manner in which it is to be implemented.

ERP Packages

A LARGE number of players are currently in the market today in the ERP segment. Though some of these
ERP solutions are tailor-made for certain industry segments only, most solutions are designed to cover a
range of industry segments.
The extent of customization/configuration and modification of these packages mostly depend on the
particular ERP solution shortlisted for implementation and its applicability for a particular organization,
as well as the extent to which the organization is willing to change its business process.
ERP systems do not neatly fit the traditional distinction between custom-built software and the 'off-the-
shelf' packages in several aspects. First, the ERP packages are much broader than that of early enterprise
solutions. ERP packages integrate many formerly discrete applications around a common database. They
enable the adapters to integrate data and process through the organization and thy support nearly all
functions
This means that they are much more complex than traditional packages requiring more knowledge, effort
and skill to adapt them to the characteristics of a particular organization. Second, ERP packages allow for
a great deal more flexibility in the way of a company operates than traditional packages do.
In traditional packages, business processes and procedures are hard-coded making them inflexible.
Adapting them to the unique business procedures of a particular organization usually requires
modifications in the package code. It should be noted that modifying ERP packages is often strongly
discouraged.
Mostly, the vendors may refuse to make changes themselves, claiming high development and
maintenance costs and low market demand. Even when vendors allow access to the source code by the
adopter or a third party, they may refuse to provide future support for the package. In additional, the risk
involved in making modification to the software code is much greater.
However, because of the way ERP packages are developed, some customization/modification is always
required to get them up and running. But the extent of the above customization/modification may vary
from one organization to the other.

We invite our readers to contribute their views and opinion on ERP. Articles which is suitable for
publication will be featured in erppandit.com. You may post your views here [email protected]

Common ERP Myths

ERP means more work and procedures

ERP will make many employees redundant and jobless

ERP is the sole responsibility of the management

ERP is just for the Managers/Decision-makers

ERP is just for Manufacturing Organizations

ERP is just for the ERP implementation team

ERP slows down the organization

ERP is just to impress customers

ERP package will take care of everything

 One ERP Package will suit everybody

ERP is very expensive

Organization can succeed without ERP

Significance of ERP Implementation

Companies must know thoroughly what enterprise resource is planning before thinking of implementing
them. The catch word of ERP implementation is speed. The quicker it is realized the quicker and better
are the advantages and delivery in terms of results. This in the early hour procedure has one more grasp.
The returns are sought at a shorter period. This deviation from the conventional practice has become the
order of the day as far as many companies are concerned. Previously Business Process Reengineering
(BPR) played an essential role with respect to implementation. It is significant to distinguish the
components of Enterprise Resource Planning.

This obviously cemented way to progress of gaps between the definite results and the one derived during
the process of foreseeing. Tuning ERP as per the whims and fancies of the practices followed in the
company became an everyday affair. This led to slogging and dragging beyond the time limits permitted.
It was financially pinching and played confusion in the customer's confidence. It is also essential to know
that sheer ERP planning does not promise the profit of ERP. It has to be implemented as planned after
understanding the components of enterprise resource planning.
In spite of having improved the implementation issues what remains still and unfettered is the way in
which companies go ahead with ERP implementation. They do it for the heck of it and without following
systematic procedures. In fact they don't even test the desirability of going into ERP. Some issues that an
organization has to address after defining enterprise resource planning are
• Popular information systems
• Likelihood of fluctuations in the choice of technology
• The ability of market players to stay in tune with it
• The ways and means to implement a business applications like ERP
• To benefit from the same so as to gain a competitive edge
• Their usage and services
• The necessity for innovating software application

Overview
While ERP systems have delivered proven value in streamlining enterprise processes,
organizations face the associated immense challenges of support, upgrades,
integration, change management, and controlling cost and schedule overruns. For most
 global companies, speed of ERP implementation coupled with a worldwide rollout
delivery capability is critical for maximizing the ROI from ERP investments.
We have helped many global companies successfully implement large, complex ERP
systems effectively through our end-to-end ERP services portfolio. Our extensive
experience in ERP implementation, ERP integration and extending ERP functionality
has helped us develop capabilities in architecting scalable and adaptive customer
solutions, which support incremental enhancement with built-in modularity. As a result,
our clients have access to real-time business information that is intelligible and useful,
across the enterprise.
Our ERP implementation and ERP integration methodologies speed time-to-value
delivery for a number of reasons, including their incorporation of the right analytics for
real-time decision-making. Patni's ERP implementation solutions also seamlessly
integrate applications across disparate platforms and technologies, to increase the
value of IT investments, and enhance productivity and profitability.
Patni's partnerships with leading application vendors give enterprise clients access to
expertise that builds competitive advantage quickly. Our core ERP implementation
practices include SAP, Oracle, PeopleSoft and J.D. Edwards. We offer ERP consulting
across functional boundaries including Finance, Sales and Distribution, Human
Resources, and Costing. We work with clients from diverse vertical industry sectors,
including:
• Engineer-to-Order (ETO) and Manufacture-to-Order (MTO) Manufacturing
• Automotive
• Electronics
• Batch/Continuous Process
• Consumer Goods
• Banking & Financial Services
• Transportation
• Insurance.
Our ERP services expertise includes both packaged suite implementation and the
integration of diverse and distributed application portfolios - within and across the
extended enterprise. We support customers across the entire range of the application
life cycle, from package evaluation through implementation, to post-implementation
support.

If an organization is capable to answer these questions without any uncertainty and validate the results
then it can be said that it has a path or up focus in taking ERP. The questions mentioned above are
fundamental and will even fix on the business model of the company. ERP implementation is essential in
the entire procedure of ERP. They can take place only if one understands "What is enterprise resource
Planning" and defining enterprise resource planning in their organization.

ERP Vendors

VENDORS are the people who have developed the ERP packages. They are the people who have invested
huge amounts of time and effort in research and development, to create the packaged solutions. If one
studies the history of ERP packages and finds out how each package evolved, then it soon becomes
evident that every ERP package grew out of the experience or opportunity of a group of people working in
a specific business who created systems that could deal with certain business segments.

Now with the ERP marketplace become crowded with more and more players entering the market and the
competition increasing, today's ERP packages have features and functionality to cater to the needs of
businesses in almost all sectors.
ERP vendors spend crores of rupees in research and come up with innovations that make the packages
more efficient, flexible and easy to implement and use. Also, with the evolution of new technologies the
vendors have to constantly upgrade their products to use the best and latest advancements in technology.
Choosing the right software vendor goes beyond evaluating software functionality. There has been a
gradual movement among a handful of the largest software vendors to take a one-size-fits-all posture.
Some vendors believe functionality ratings are no longer important since all software systems are
beginning to look alike. While appearances may tend to support this theory, reality paints a different
picture.
Merely having a particular function does not guarantee that users will be able to capably work with it. If
two vendors offer a function required in a specific industry segment, and one specializes in deploying it in
that segment while the other does not, the difference can be dramatic. The one-size-fits-all garment may
fit everybody, but the question is does it look good to everyone?
Vendor selection is not a popularity contest and bigger does not always mean better. While the financial
stability, ensured longevity and broad spectrum of offerings provided by the top vendors are good reasons
for selecting them, size is not without its downside. Size breeds bureaucracy and bureaucracy hamper
personal attention and agility.
While small vendors that are not quite household names may carry increased risks in the area of long-
term longevity, they may actually provide a better solution if they specialize in your industry segment
rather than covering a broad spectrum of industries.
You have the greatest leverage with your vendor once you have made the decision to buy their software
but have not yet issued the purchase order. Waiting for the end of their quarter can help you get the best
price.
Also view the financial stability of your future relationship as important - you will receive positive support
from your vendor as long as it is profitable for them to do so. The relationship is a balancing act. Interest
your vendors to get the job done right, on-time and within budget, but watch out for penalties that may
increase project pressure and sour the relationship.
It is important to remember that the vendor, as long as they provide working software and capable
personnel, really as very little responsibility for your overall success. Responsibility for success of failure
lies within the four walls of your business, and if you import failure in the form of a third-party, it's still
your responsibility.

ERP Consultants

ERP consultants are professionals who specialize in developing techniques and methodologies for dealing
with the implementation and the various problems that will crop up during the implementation. They are
experts in the administration, management and control of these types of projects.

Each of them will have many man-years of implementation experience with various industries and have
knowledge of time-tested methodologies and business practices that will ensure successful
implementation. They will be good at all phases of the implementation life cycle right from package
evaluation to end-user training.
Consultants provide a wide variety of functions often filling in the gaps. Some of the positions that
consultants can fill include project manager, team leader, team member, service representative and end-
user. A consultant's success depends upon a number of factors including computer literacy, conceptual,
skills, software knowledge, industry knowledge, maturity, problem-solving capability, communication
skills and organizational skills.
The success of any particular consultant can vary tremendously from company to company and from
situation to situation. Surprisingly, a consultant's industry and software knowledge does not correlate
strongly with his or her success or capability to help a company.
Many cases have been identified where consultants lacking in software and industry knowledge who were
able to consistently out-perform other consultants considered the most knowledgeable in software and
industry. These consultants showed strong interpersonal communication skills, were self-starters
requiring little or no training, had good computer literacy, problem-solving capability and conceptual
skills.
Many of the big consulting firms, having forecasted the ERP boom, invested a great deal of money in
developing a range of consulting services in this field and assigned many of their professionals to become
specialists in the various aspects of ERP packages and their implementation.
These firms researched various products, developed an in-depth understanding of each product's
strengths and weaknesses, worked by the side of the ERP vendors, confirmed that the vendor's package
worked and learned the tricks and techniques of the trade, found out the pitfalls and mistakes that should
be avoided and thus created a pool of experts who could handle the ERP implementation without failure.

India ERP Market – A scenario

Posted: Jun 29, 2010 |Comments: 0 | Views: 512 |
Ads by Google
Rs. 1500 Free Advertising www.Google.com/AdWords
Start Running Your Own Ads Here. Fill Out the Form & We'll Help You!
GE Finance www.gemoney.in/html
Apply Now & Get Money The Next business Day!

In the last decade, ERP software has exploded into the global business landscape. With the opening up
of the Indian economy, there has been a turnaround growth in different industry verticals thereby
helping them reach a level of maturity that demands advanced technology to efficiently manage and
streamline their processes. This growth and along with the associated competition and quest for
enhancing market share has led the organizations to re-look at its processes and procedures and put
in place proper processes enablers and solutions to make its business more efficient and effective.
Many Indian industries already have realized the need for ERP solutions, and the industry-related
market growth should match the expansion of the sector as a whole.

According to a research report, The Indian ERP market experienced compounded annual growth rate
of 25.2 per cent during the period 2004-2009. The market was $83 million in 2004, and is projected
to be around $160-180 million in 2010. Some of the potential target segments which have shown high
penetration are Automotive, Steel, Consumer Durables, Engineering, Retail, Communications and
Textiles thereby making it attractive for the ERP vendors

An ERP package can streamline and automate different important functions of an organisation such as
accounts payable, accounts receivable, activity management, benefits administration, and billing,
invoicing and cost tracking (for project-based businesses), payroll, Sales and Marketing. With ERP,
companies can also improve cash management, while manufacturing firms can practice more effective
capacity planning and cost containment.

Major Benefits

● A primary benefit of ERP is easier access to reliable, integrated information, elimination of

redundant data and the rationalization of processes, which results in substantial cost savings.

● It enables decision-makers to have an enterprise-wide view of the information they need in a

timely, reliable and consistent fashion. The system provides consistency, visibility and transparency
across the entire enterprise.

● The integration among business functions facilitates communication and information sharing,
leading to dramatic gains in productivity and speed.

Market Trends in the Indian ERP Market

● SMBs as a potential market for ERP Vendors: Most of the mid sized organizations are
working with applications which are non-integrated and on disparate technology architectures, built in-
house. This has resulted redundant technology, loss of support, non availability of critical information
at the right time resulting in overall business loss. ERP vendors in India will have a great opportunity
when they explore into the untapped areas of the SME segment with innovative practices tuned to mid
size organisations processes and business needs. Companies like Sage Software has focused on this
segment in a major way, which we can see their various product offerings for SMBs
on http://www.sagesoftware.co.in

● Adoption of ERP as a Service (SaaS)-SaaS (Software-as-a-Service)-based Enterprise

Resource Planning (ERP) is an on-demand deployment of ERP software, where the user can access the
software through license as a Web-based service. It provides an alternative to implementation or
maintaining ERP software. SaaS - based ERP includes finance, order management, inventory control,
purchasing and manufacturing functionality. The increasing popularity of the SaaS-based applications
account for the growth of ERP, as the enterprise resources are maintained by a service provider.

There needs to be no doubt in the promising opportunities and prospects of ERP in the future in both
software and non software sectors. Whether your growth plans include buying and selling in the global
marketplace, adding more talent to your team, or expanding your services, ERP has the tools and the
flexibility to successfully accelerate your business expansion and streamline existing business and
operational processes thereby improving efficiency and productivity.

What are the common problems for ERP in SME'S?

Enterprise Resource planning helps S.M.E.'s to enjoy unimaginable benefits.
Nevertheless the problems of ERP in S.M.E.'s remain unsolved. There are still ups and
downs in it. There are some problems for S.M.E.'s in the ERP market .They are not only
from the addressed in the company's perspective but also in the vendor's perspective.

The problems of ERP in S.M.E.'s are as follows:

Cost
The small size of the companies proves to be another challenge to the vendor. Since
there are too many S.M.E.'s in the market they demand a very low price from the
vendor. It becomes practically impossible for the vendor to offer at such quotations as
he would not even be guaranteed of a return in the costs. Small business erp is not
expensive software but still requires lot of work.

Another issue is that there are a large number of companies in the segments and the
vendors are few in numbers. Hence the former is able to exercise a considerable
influence over the later. This issue also makes things difficult for the company. At times
they have to comprise on quality due to unfair demands. There has been no full stop to
this as the companies have failed to change their attitude in this regard.

The companies can definitely claim cost advantages due to the competition .But if they
are bound to be unreasonable they cannot expect the vendor to deliver the best. They
need to keep in mind that the vendors have come a long way after exploring their
segment which was untouched for quiet a long time. The companies are not able to
avail the best business erp small software due to these difficulties.

Choice
Companies have to exercise adequate care in choosing their ERP vendor and Small
business erp Software. This is a big dilemma for companies because they are unsure of
choosing software offered by a branded player or a small player. That really makes no
difference as long as the software and vendor suits all the requirements.

Some companies debate that only a branded player can satisfy the requirements even
though the recipient is a small concern. While the other argues that only small vendors
are flexible when it comes to customizations. Each argument has its own merits and
demerits. However companies tend to select the wrong option on the basis of these
prejudices. As said earlier the companies need to take care of their requirements as the
first priority before deciding on the software or vendor.

Customization
The bigger players have a trouble when it comes to offering solutions for S.M.E.'S. The
level of customization and the work demanded by the S.M.E.'s some times appear to be
too much for a bigger player. Moreover their businesses have always been focused to
corporate giants. So when it comes to the question of S.M.E.'s it takes a great deal of
time for them to understand the business and design software programs based on
modality.

Even if they are able to meet the requirements the companies always demand more.
Branded and big vendors don't even yield to the first level and the software programs
supplied by them prove to be of little use to the company. On the other hand companies
also find that small ERP vendors are not competent enough to match the requirements
of the companies. So they approach the bigger companies. Finally they land up in
understanding that no one can help them to the desired extent.

Confidentiality
Big vendors don't even offer the source code when it comes to S.M.E.'s. This has
resulted in lots of functional errors and the very purpose of ERP has been questioned
by and large. On the other hand when it comes to the companies they hesitate to
disclose confidential information because they are well aware of the fact that the
vendors are limited, few and far between in the S.M.E.'s market. This means your
vendor and the company's vendor could be one and the same. The apprehension of the
companies look natural but it stops the vendor in restructuring the minutest detail in the
software to match the company's needs for lack of adequate details.

Conclusion
S.M.E.'s market still continues to be a "bed of opportunities" for ERP Vendor in spite of
the above mentioned drawbacks. Equally promising is the demand for ERP from Small
and Medium enterprises. Some proposal should be put forward for the welfare of both
parties to counter the problem of ERP in S.M.E.'s.

Other experiences.
A survey of organisations that have implemented ERP's was carried out recently. It identified "10
Common Causes of Disaster".
• Change Management and Training.
This was mentioned as the major problem with implementations. Changing work practices to
fit the system is a major difficulty. Also mentioned were training across modules and starting
training sooner.
• To BPR or not to BPR
• It is difficult to draw the line between changing Business Processes to suit the system or
retaining Business Processes and paying the cost, in dollars and time, to change the system.
As time and cost squeeze the implementation, the usual path is to not modify the system, but
to change the way people work. This feeds back into Change Management and Training.
• Poor Planning
Planning covers several areas such as having a strong Business Case, to the availability of
Users to make decisions on configuration, to the investing in a plan that captures all the issues
associated with implementing it.
 • Underestimating IT skills
As most people are upgrading from old technology, the skills of the staff need to be upgraded
as well. The upgrade is also going to place significant demands on a team who are geared to
maintain an old but stable environment. Usually this effort is underestimated.
• Poor Project Management
Very few organisations have the experience in house to run such a complex project as
implementing a large-scale integrated solution. It usually requires outside contractors to come
in and manage such a major exercise. It can be a fine line between abdicating responsibility
and sharing responsibility. Many consulting firms do a disservice to their clients by not sharing
the responsibility.
• Technology Trials
The effort to build interfaces, change reports, customize the software and convert the data is
normally underestimated. To collect new data, and clean the data being converted, will also
require an effort that is beyond what is normally expected.
• Low Executive Buy-in
Implementation projects need Senior Executive involvement to ensure the right participation
mix of Business and IT, and to resolve conflicts.
• Underestimating Resources
Most common budget blow outs are change management and user training, integration testing
, process rework, report customisation and consulting fees.
• Insufficient Software Evaluation
This involves the surprises that come out after the software is purchased. Organisations usually do not
do enough to understand what, and how the product works before they sign on the bottom line. The
Bleeding Edge ERP is so massive and integrated that reporting and linking to other systems (either
your own or your customers and suppliers) can be much more difficult than you expect. Companies
looking at ERP need to examine how they accept online feeds from a customer, or a customers'
customer, and examine the technological enablers as well as the implications of these technologies
inside of the Business.

Summary.
All this leads to a list of likely problems with an ERP system.
• The cost is likely to be underestimated
• The time and effort to implement is likely to be
underestimated
• The resourcing from both the Business and IT is
likely to be higher than anticipated
• The level of outside expertise required will be higher
than anticipated
• The changes required to Business Processes will be higher than expected.
• Scope control will be more difficult than expected
• There will never be enough training - particularly across different modules
Most important of all, and the single biggest failure point for ERP implementations, is the need for
change management. The need for change management is not likely to be recognized until it is too
late. The changes required to corporate culture are likely to be grossly underestimated. It is going to
be hard enough to cope with the technical issues without having to address major people issues as
well.
 If you found this interesting you might also find our white paper on the tricky pricing options that
vendors can often hide away until you come to sign the cheque. See the White Paper onSoftware
Pricing
Four problems with ERP
Recently, a company asked my firm to do an evaluation of its ERP system. Users had
become increasingly unhappy with the system, and management wanted an independent
assessment to determine whether they had chosen the wrong system.

After a couple of weeks of interviewing users and studying the many complaints about the
system, we sat down and analyzed the causes of each problem. In the past I have found it
most helpful to group ERP problems into four categories.

1. You've got a bad system. This category includes lack of needed ERP functionality,
system performance problems, lack of scalability, system bugs, and ERP processes
that don't match business processes. For example, the system might lock up
whenever two users attempt to update the same customer master record. Or, the
company might be a process industry manufacturer that is trying to use a package
that was developed for discrete manufacturing. These problems are usually quite
easy to spot. But although they can be serious, they do not always mean you'll need
to replace the system. Sometimes a software or hardware upgrade will do the trick,
or a customization may be possible.

2. You've got a good system, but you set it up incorrectly. These problems
include incorrect configuration settings and other problems with how the
implementation was performed. For example, users might be complaining that
product costs are not accurate, but the company has not set up the system with cost
elements that are detailed enough. Or, users might be complaining that inventory
counts are inaccurate, but the system has been set up with one big "four wall"
inventory bucket, instead of bin location level tracking.

3. You've got a good system, but you aren't using it. Examples could be that the
original implementation was incomplete, or that the implementation was broken into
phases and Phase II was never started. Other times, the problem is ignorance. It's
surprising how often companies don't know what features they have in the software
they already own. I have seen companies buy additional point solutions, or modify
their systems, all the while their original system could have provided the same
functionality, if they had just looked for it.

4. You've got a good system, but you're using it ineffectively. In this category, I
lump together all kinds of problems with business practices, such as data inaccuracy,
lack of user procedures, lack of training, lack of discipline, and organizational
problems. The system never has a chance to perform well, because the business is
not using it effectively.

ERP system selection methodology

From Wikipedia, the free encyclopedia
 This article needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced material may
be challenged and removed. (September 2010)

This article is written like a personal reflection or essay and

may require cleanup. Please help improve it by rewriting it in
an encyclopedic style. (September 2010)

An ERP system selection methodology is a formal process for selecting an enterprise

resource planning (ERP) system. Existing methodologies include:[1]

 SpecIT Independent Vendor Selection Management

 Kuiper's funnel method

 Dobrin's 3D decision support tool

 Clarkson Potomac method

Contents

[hide]

• 1 Overview

• 2 Poor system selection

• 3 A proper system selection

methodology

• 4 References

• 5 External links

[edit]Overview

Irrespective of whether the company is a multi-national, multi-million dollar organization or a

small company with single digit million turnover, the goal of system selection is to source a
system that can provide functionality for all of the business processes; that will get complete
user acceptance; management approval and, most importantly, can provide
significant return on investment for theshareholders.

Since the mid-1970s, when there was widespread introduction of computer packages into
leading companies to assist in material requirements planning [2] software companies have
strived, and for the most part succeeded, to create packages that assist in all aspects of
running a business from manufacturing; supply chain management; human resources;
through to financials. This led to the evolution of ERP Systems.

Accordingly, a significant number of packages purporting to be ERP systems have entered

into the marketplace since 1990 [3]. There are packages at the upper end of the market and
a vast quantity of other packages that vendors claim to be ERP Systems. There are also
packages that claim to be best of breed for certain processes [such as planning] and sold
merely as an add-on to an ERP System. The options are many and this, in reality, creates a
problem for the company who has to make a decision.

Attempting to select an ERP system is further exacerbated by the fact that some systems
are geared for discrete manufacturing environment where a distinct amount of items make
up a finished product [4] while others are more suited to process industries such as chemical
and food processing where the ingredients are not exact and where there might be re-work
and byproducts of a process.

In the last decade, companies have also become interested in enhanced functionality such
as customer relationship management and electronic commerce capability.

Given all of the potential solutions, it is not uncommon for companies to choose a system
that is not the best fit for the business and this normally leads to a more expensive
implementation.[citation needed] Thus, it is understandable[by whom?] that "ERP Costs can run as high
as two or three percent of revenues" [5]. A proper ERP system selection methodology will
deliver, within time and budget, an ERP system that is best fit for the business processes
and the user in an enterprise.

[edit]Poor system selection

Companies seldom use a fully objective selection methodology when choosing an ERP
System.[citation needed] Some common mistakes include:

Incomplete requirements
Because implementation of a new ERP system "requires people to do their job differently"
(Wallace and Kremzar[6]), it is very important to understand user requirements, not only for
current processes, but also future processes (i.e., before and after the new system is
installed). Without detailed user requirements, review of systems for functional best-fit rarely
succeeds. The requirements must go into sufficient detail for complex processes, or
processes that may be unique to a particular business.

Reliance on vendor demos

Vendor demonstrations tend to focus on very simplistic processes. A typical demonstration
shows an ideal order to cash process where a customer orders a quantity of product that is
in stock. The reality in most businesses is that most customers have varying and more
complex commercial arrangements, and products are not always in stock.

Over-emphasis on system cost

According to Finlay and Servant, “The differential in purchase price between packages is
unlikely to be the dominant factor".[7] While the cost of an ERP system is significant for a
company, other important decision criteria, such as functionality; future proofing; underlying
infrastructure [network & database]; and e-commerce capability among others, may be
understressed.

Selection bias
It is not unusual that the decision on which system to purchase is made by one individual or
by one department within the company. In these situations, an ERP system that may be
excellent at one function but weak at other processes may be imposed on the entire
enterprise with serious consequences for the business.

Failure to use objective professional services

One of the main reasons for failure in system selection is the understandable lack of
knowledge within the company.[citation needed] Experienced consultants can provide information
on all of the packages that are available in the marketplace; the latest functionality available
in the most common packages and, most importantly, can assist the user in deciding
whether a specific requirement would provide added value to the user and to the business.
[citation needed]
However, it is worth noting that the professional help must be provided by
objective consultants who have no affiliation with ERP system vendors. "If a consultancy
has built up an expertise in the use of a particular package then it is in its interest to
recommend that package to its client” [7]

Inability to understand offering by ERP vendor

"It is estimated that approximately 90% of enterprise system implementations are late or
over budget" [8]. A plausible explanation for implementations being late and over budget is
that the company did not understand the offering by the vendor before the contract was
signed.[citation needed] A typical example of this would be the scenario where a vendor may offer
5 days of services for the purpose ofdata migration. The reality is that there is a huge
amount of work required to input data onto a new system. The vendor will import the data
into the new system but expects the company to put the data into a file that is easy to import
into the system. The company are also expected to extract the data from the old system;
clean the data and add new data that is required by the new system. "ERP, to be
successful, requires levels of data integrity far higher than most companies have ever
achieved – or even considered. Inventory records, bill of materials (BOM), formulas,
recipes, routings, and other data need to become highly accurate, complete and properly
structured".[6] This typical scenario is one of many issues that cause implementations to be
delayed and invariably lead to requests for more resources.

[edit]A proper system selection methodology

To address the common mistakes that lead to a poor system selection it is important to
apply key principles to the process, some of which are listed hereunder:

Structured approach
The first step in selection of a new system is to adopt a structured approach to the process.
The set of practices are presented to all the stakeholders within the enterprise before the
system selection process begins. Everyone needs to understand the method of gathering
requirements; invitation to tender; how potential vendors will be selected; the format of
demonstrations and the process for selecting the vendor. Thus, each stakeholder is aware
that the decision will be made on an objective and collective basis and this will always lead
to a high level of co-operation within the process.

Focused demonstrations
Demonstrations by potential vendors must be relevant to the business. However, it is
important to understand that there is considerable amount of preparation required by
vendors to perform demonstrations that are specific to a business. Therefore it is imperative
that vendors are treated equally in requests for demonstrations and it is incumbent on the
company [and the objective consultant assisting the company in the selection process] to
identify sufficient demonstrations that will allow a proper decision to be made but will also
ensure that vendors do not opt out of the selection process due to the extent of preparation
required.

Objective decision process

"Choosing which ERP to use is a complex decision that has significant economic
consequences, thus it requires a multi-criterion approach." [9]. There are two key points to
note when the major decision makers are agreeing on selection criteria that will be used in
evaluating potential vendors. Firstly, the criteria and the scoring system must be agreed in
advance prior to viewing any potential systems. The criteria must be wide-ranging and
decided upon by as many objective people as possible within and external to the enterprise.
In no circumstance should people with affiliations to one or more systems be allowed to
advise in this regard.

Full involvement by all personnel

The decision on the system must be made by all stakeholders within the enterprise. "It
requires top management leadership and participation… it involves virtually every
department within the company".[6] Representatives of all users should:

 Be involved in the project initiation phase where the decision making process is agreed;

 Assist in the gathering of requirements;

 Attend the Vendor Demonstrations;

 Have a significant participation in the short-listing and final selection of a vendor.

[edit]

Future Directions in ERP

The only constant is change. No more so than in the constantly evolving, high-speed
world of technical innovation.
Therefore, the question is: How will these inevitable changes affect the ERP market?
In this chapter, we will survey the industry landscape and find out what is on the horizon
—keeping in mind that often what appears to loom large in the distance, turns out to be a
mirage.
ERP industry watchers are agreed on at least one point: 'one-size-fits-all', across the board
integration is no longer seen as the unwritten law. As revolutionary as the ERP concept
was, and to a certain extent still is, giventhe number of companies yet to implement it, it
is doubtful whether it canhold onto its overall position as the 'hottest' dominating
technology in the faceof competition from new cutting-edge technologies such as
Internet commerce and EDI (Electronic Date Interchange), and competitive new business
practices involving supply chain and customer self-service.

NEW MARKETS:
As larger enterprises become saturated with new-generation client/server
ERP systems, vendors are being forced to find new markets for their product
suites in order to grow. This pressure is causing ERP vendors to increase their appeal to
small business clients through a number of initiatives.
These initiatives include the following:
1.Supplementing their direct sales force with reseller channels
2.Lowering the entry price point of their software to make it financially viable
3.Stratifying their software offerings to appeal on the basis of reduced functionality
4.Improving the implementation methodologies for faster deployment
5.Porting the products to platforms such as Microsoft Windows NT.

NEW CHANNELS
Vendors such as SAP AG Inc., Oracle Corporation, and Baan Co. have been building
reseller channels—both in the US and worldwide—to reach the smaller businesses that
are looking for the complete-one-stop shopping for their ERP solutions.
The ERP software is made more financially attractive by lowering the entry price point
for each module and by ramping up the total costs by basing price on user licenses.
Oracle is being particularly aggressive in this respect with software pricing comparing
favourably with middle-market client/server offerings from companies such as Platinum
Software and Great Plains Software.
Although JD Edwards ventured in these waters by complementing its OneWorld suite
with a lower-cost line called Genesis, most of the vendors have avoided producing less-
expensive 'lite' versions of their software. SAP abandoned its SAP Lite project some time
ago and it looks as if the lite versions will have to wait for some more time.

FASTER IMPLEMENTATION METHODOLOGIES:

All ERP vendors have suffered from the perception that their software is difficult
and costly to implement. This perception has provided huge profits to the 'Big 6'
accounting firms (now Big 5 with the merger of Price Waterhouse and Coppers SB
Laybrand) that have generated billions in fees from their ERP software implementation
'practices.'
Even though only 10-15% of the implementations have taken years to complete and have
eaten up millions of dollars of consulting costs, the fact remains that implementing ERP
packages is difficult.
An ERP system may consist of dozens of modules that are deployed on a multinational
basis to service hundreds of users from many different business departments.
There may also be a complete change of infrastructure—say from a mainframe to a
UNIX platform—while a number of core business processes are being simultaneously
reengineered.
ERP vendors have thus begun to focus their effort on making the implementation
process easier by:
1.providing more effective tools
2.better methodologies to speed up the process,
3.creating elite consulting teams to intensify resources when required, and
4.Using model-based approaches and opening up their systems for easier
integration.
For example, SAP has introduced a program called Accelerated SAP (ASAP) that takes
the knowledge gained from thousands of R/3 implementations to date and consolidates
this expertise in a product called the Business Engineer.
This product helps implementation teams configure the SAP modules to conform to the
processing style of some 100 business operating scenarios.
Methodologies such as ASAP help reduce SAP implementation times to less than six
months in many cases.
Oracle recently introduced a similar program called Fast Forward, to help speed up
implementations of Oracle Applications suites and nail down the costs up-front.
Business models and business application programming interfaces
(BAPIs):
By: M H Lakdawla
2

SAP has attacked the notion that the R/3 system is not open by releasing the
specifications for some 170 business application programming interfaces (BAPIs), which
help third-party applications interact with R/3 directly.
BAPIs are simply, sets of methods that allow external applications to collaborate with
specific R/3 business objects, such as customers, accounts, or employees.
The fact that the R/3 data is addressable through these callable methods, (BAPIs) gives
the third party application vendors a lot of flexibility to build supporting applications for
the R/3 system.
In a similar manner, Baan provides an offering called OrgWare that is based on the use of
a tightly integrated business-modeling tool, combined with business-specific templates
that help to automatically configure the software to suit specific operational needs.
Baan is currently in the process of enhancing this tool with new setup wizards to
accelerate software implementation on the Windows NT platform.
APPLICATION PLATFORMS
ERP vendors already deliver comprehensive suites of application modules that support
multinational deployment, Year 2000 compliance, and the Euro (European single
currency).
But each vendor is trying to extend the reach ofits software and make it more like an
application platform than a suite of modules.
SAP is already ahead in this race; its R/3 product is one of the few that can be managed,
centrally using popular platform management tools from vendors such as Computer
Associates (UniCenter TNG) and Tivoh (TME),
NEW BUSINESS SEGMENTS:
All the ERP vendors are now capable of delivering specialized variants of their
applications to service vertical markets such as government, healthcare, financial service,
or retail environments. Some vendors are also moving into more specialized areas, such
as supply chain management and demand forecasting or sales automation and marketing.
PeopleSoft bought Red Pepper Software to enhance its supply chain offering while Baan
recently acquired Aurum Software for its Aurum Customer Enterprise suite of customer
relationship management tools.
To strengthenits financial modules,Baan also teamed up with Hyperion Software to
linkHyperion's financial accounting, budgeting and reporting solutions to Baans
distribution and manufacturing modules.
MORE FEATURES...
 Improving decision support has been another focus of almost all the ERP vendors.
Baan is linking its applications to the Gentia product (from Gentia Software Inc.) to
provide OLAP capabilities, and for the setup and monitoring of key performance
indicators.
JD Edwards teamed up with Information Builders to deliver a data mart, based on
Information Builders Inc.'s.
SmartMart suite'of database access middleware, data transformation, reporting, and
OLAP tools.
By: M H Lakdawla
3

•
Hom L- Produc Servic Projec New New Blo
e Class ts es ts TECHNOCLASS s g
ERP - Basic Business Management Concept

ERP system is a united,

tools, covering all aspects of the business management and providing
departments to immediately
related to an operation processes by the
treatment in all interlinked areas and should become immediately available to all interested partie
To overcome various problems related to
people and application specialists have
concept is about ensuring maximum integrated information
government authorities and other potentially related to the enterprise entities.

The main characteristics of an ERP system are:

 • A single database;
• Functionality covering all
• Maximum capacity for system modification in a changing
• Full and immediate usability of all data;
• Availability of integrated business data to all specialists.
The conclusion is that if different information systems are used to support different business
the modern requirements for effective business management.

Systems implementing the ERP-concept should cover the following functional areas: procedures and operations related to
potential customers and suppliers, management structure and product/service life cycle, forecasting, planning and reporting
product/service development, human resources management, fixed assets and costing, projects and investments, account
financial management, business analysis and decision making.

Functionality related to customers

The vital goal of any enterprise - increasing the number of satisfied customers -
and analysed. Required information: characteristics, habits and behavior of the clients, their
related costs for customer service, current and expected operations, sales

For software packages possessing

• CRM (Customer Relationship Management)

and behavioral patterns;
• SCM (Supply Chain Management)
with the partner business information;
• OSL (Order processing, Sales and Logistics)
• E-commerceor electronic commerce - making real-time trade
As shown, there is no exact distinguishment
another class is determined by the specific focus of each company.

Functionality related to suppliers

Functions, providing relations with suppliers mirror the related functions to clients. All listed above should be repeated with
direction. However, there is some

• Deficit forecasting - with multivariant

stocks, planned supplies from internal /
• Data and/or planned amounts
• Planning the incoming flow - by
• Selection of suppliers - based on diverse and often difficult for estimation
• Contract preparing
The overall objective of the tools

Product / service life cycle

This type of functionality is necessary for every business but difficult to be implemented in practice. These
available from CRM system information about the
and development plans of
Applications of this class include
organization, production and operational maintenance, analysis of market reactions, analysis of the
of products, etc.

Production

ERP-systems historically have arosen from systems for production

includes all functions related to definition of the product
assessment the availability and utilization of various types of resources, consideration of quantitative and qualitative results

There are diferent software

• BM (Bill of Materials)
• MPS (Master Production Schedule)
goals within a specified time;
• MRP (Material Requirments Planning)
• CRP (Capacity Requirments Planning).
The development of the above functional packages consistently has led to:

• MRP II - Manufactiring Resource Planning

• CSRP (Customer Synchronized Resource Plannig)
Human resources management

This group includes functions and procedures:

• People as manufacturing resource - accounting qualification categories interchangeability, load value of individual
production process;
• Psychological aspects of staff - down behavioral profiles and compatibility of the teams;
• Pay - and assessment of individual contributions, form and payment of salaries;
• Management skills - to identify training needs based on development plans, formation and management of program
and retraining, implementation of company policy to work commitment;
• Social aspects of staff - zakonovoopredeleni and corporate security and social programs for company employees a
families.
Fixed assets

Separating the functions of this group is necessary because traditional their misjudgment in Bulgaria, or to bring them to ne
impact of the ongoing depreciation of assets. From ERP-view are essential:

• Usability of any asset for other technological purposes;

• Distinction to "accrued depreciation and cost of use in the manufacture or provision of services;
• Reporting the extent of the depletion of resource exploitation and mezhduremonten every asset and related rehabi
evaluation, conversion, etc.;
• Analysis of economic efficiency of the use of assets in view of current market price of the corresponding analogue
implementing the same production stages from outside contractors;
• DRAM market revaluation of assets;
• Using the methods of accounting depreciation stimulating as the efficient use of assets and reinvestment ensuring
modernization of production.

Costs
ERP-functions of this group (CA - Cost Accounting) are:

• Determining the full cost of

• Determining value of the components of the total
• Calculation of the amount of direct and indirect costs and
• Monitoring of components of the
• Maintaining the characteristics of the profit / cost centers, distribution of revenue and indirect cost by profit / cost ce
and weighted assessment,
Projects and investments

Project management (PM) is usually associated with:

• Definition of total budgets for all corporate projects;

• Definition of individual project
• Procedures and reporting techniques with different lever
• Project planning and reporting projects: general and specific conditions, programs, schedules, stock and workl flow
• Tools and techniques for multiple-criteria
portfolio, stock analysis and forecasts.
Financial management and accounting

The functions of accounting

tools needed in terms of ERP-concept and especially important for multinational enterprises:

• Use of several different

• Input of accounting operations in different account plans;
• Parametrizirano transfer operations from one to another accounts for consolidated accounts;
• Immediate generation of accounting transactions in the confirmation of the transaction, ensuring prompt many inter
generated by a business operation;
• Definition of various accounting procedures to ensure not only quick formation of the final period results, but for pro
optimization of the type "What if?"
• Conversion of the main financial accounts in that currency at selected rate fixed for different dates;
• Maintenance of forecast operations and transform them into real, with or without change of dates and currencies;
• Calculation of interest on cross-credit operations;
• Generated by users of various balance and post-balance and reports on the financial statements of the enterprise.
Business Analysis

The functional tools of this group are

application fields. Therefore we usually talk about sales, marketing, manufacturing, financial, etc. analysis.

All analysis, reports and forecasts can be divided into the following main types: -

• Factual - data for a particular object or event information;

• Chronological - data on operations related to classified resource flows - stock, cash, etc.;
• Working capital - summurized information about classified resource flows;
• Correspondence - data on resource flows, classified by flow factors;
 • Comparative - by
• Statistics - summarized data flows, mostly aimed at determining the weight characteristics;
• Balance and post-balance;
• Cascade - data sequence (cascade) of events occurring as a result of a particular event (decision).
The BI tools facilitate the business analysis and managerial decision making.

Author: Nedialko Todorov, Marketing & Business Developemnt Director of L-CLASS

Resource: CEO Magazine, 2/2002

Copyright © L-CLASS, 2009