This action might not be possible to undo. Are you sure you want to continue?
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.
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.
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. 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.
• • •
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.3 Ontology engineering
6.4 Systems thinking
• • • •
7 See also 8 References 9 Further reading 10 External links
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. 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. The term "enterprise model" is used in industry to represent differing enterprise representations, with no real standardized definition. Due to the complexity of enterprise organizations, a vast number of differing enterprise modelling approaches have been pursued across industry and academia. 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. The basic idea of enterprise modelling according to Ulrich Frank 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."
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), 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. 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. 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 followed by GRAI/GIM by Doumeingts and others in 1992. 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).
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.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." 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" 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." 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,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."
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. 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. 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. 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.
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. 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.
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.
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 modernday IT system: a banking clearing house in the 19th century may be used as an example.
There are several techniques for modelling the enterprise such as
Active Knowledge Modeling, 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), 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
Enterprise engineering is the discipline concerning the design and the engineering of enterprises, regarding both their business and organization. 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 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. 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. 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.It can also be viewed as the extension and
generalization of the systems analysis and systems design phases of the software development process. 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. This field is also called Enterprise architecture, or defined with Enterprise Ontology as being two major parts of Enterprise architecture.
Example of the US FEA Business Reference Model.
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.
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.
A model may have various parameters and those parameters may change to create
various properties. 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.
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.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. 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. 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.
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 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.
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.
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-theshelf' 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 firstname.lastname@example.org
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.
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 longterm 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 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.
● 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 inhouse. 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.
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.
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.
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.
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.
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:
SpecIT Independent Vendor Selection Management Kuiper's funnel method Dobrin's 3D decision support tool Clarkson Potomac method
• • • • •
1 Overview 2 Poor system selection 3 A proper system selection methodology 4 References 5 External links
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  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 . 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  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. Thus, it is understandable[by whom?] that "ERP Costs can run as high as two or three percent of revenues" . 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.
Companies seldom use a fully objective selection methodology when choosing an ERP System. Some common mistakes include: Incomplete requirements Because implementation of a new ERP system "requires people to do their job differently" (Wallace and Kremzar), 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". 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. 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.
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”  Inability to understand offering by ERP vendor "It is estimated that approximately 90% of enterprise system implementations are late or over budget" . 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. 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". This typical scenario is one of many issues that cause implementations to be delayed and invariably lead to requests for more resources.
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." . 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". 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.
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 lessexpensive '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 LProduc 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.
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.
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 Tools and techniques for multiple-criteria portfolio, stock analysis and forecasts.
Project planning and reporting projects: general and specific conditions, programs, schedules, stock and workl flow
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