Evolution of erp

ERP is an outcome of 40 years of trial and error. It has evolved as a strategic tool because of continuous improvement in the available techniques to manage business and the fast growth of information technology. Prior to 1960s, business had to rely on the traditional ways of inventory management to ensure smooth functioning of the organization. These theories are called classical inventory management of scientific inventory control methods. The most popularly known amongst them is EOQ (Economic Order Quantity). In this method, each item in the stock is analyzed for its ordering cost and the inventory carrying cost. A trade off is established on a phased out expected demand of one year, and this way the most economic ordering quantity can be decided. This technique in principle is a deterministic way of managing inventory. Along with EOQ, we find various inventory models such as fixed order quantity, periodic order method, optional replenishment method, etc., which were in practice earlier. These theories were very popular in pre-MRP era. In 1960s, a new technique of Material Requirements Planning, popularly known as MRP, was evolved. This was a proactive manner of inventory management. This technique fundamentally explodes the end product demand obtained from the Master Production Schedule (MPS) for a specified product structure (which is taken from Bill of Material) into a detailed schedule of purchase orders or production orders, taking into account the inventory on hand. MRP is a simple logic but the magnitude of data involved in a realistic situation makes it computationally cumbersome. If undertaken manually, the entire process is highly time-consuming. MRP successfully demonstrated its effectiveness in reduction of inventory, production, and delivery lead times by improving coordination and avoiding delays, thus making commitments more realistic. MRP proved to be a very good technique for managing inventory, but it did not take into account other resources of an organization. In 1970s, this gave birth to a modified MRP logic, popularly known as closed loop MRP. In this technique, the capacity of the organization to produce a particular product is also taken into account by incorporating a module called capacity requirements planning (CRP). In 1980s, the need was felt to integrate the financial resource with the manufacturing activities. From this evolved an integrated manufacturing management system called Manufacturng Resource Planning (MRP II). Transition from MRPII to ERP happened during 1980-90. The basic MRP II system design was suffering from a few inherent drawbacks such as limited focus to manufacturing activities, assumption of the mass or repetitive production set ups, and poor budgetary and costing controls. The shortcomings of MRP II and the need to integrate new techniques led to the development of a total integrated solution called ERP, which attempts to integrate the transactions of the organization to produce the best possible plan. Today we see further development in the ERP concept and evolution web-based ERP.

ERP Architecture
ERP applications are most commonly deployed in a distributed and often widely dispersed manner. While the servers may be centralized, the clients are usually spread to multiple locations throughout the enterprise.

Generally there are three functional areas of responsibility that is distributed among the servers and the clients. First, there is the database component - the central repository for all of the data that is transferred to and from the clients. Then, of course, the clients - here raw data gets inputted, requests for information are submitted, and the data satisfying these requests is presented. Lastly, we have the application component that acts as the intermediary between the client and the database. Where these components physically reside and how the processes get distributed will vary somewhat from one implementation to the next. The two most commonly implemented architectures are outlined below. Two-tier Implementations In typical two-tier architecture, the server handles both application and database duties. The clients are responsible for presenting the data and passing user input back to the server. While there may be multiple servers and the clients may be distributed across several types of local and wide area links, this distribution of processing responsibilities remains the same. Three-tier Client/Server Implementations In three-tier architectures, the database and application functions are separated. This is very typical of large production ERP deployments. In this scenario, satisfying client requests requires two or more network connections. Initially, the client establishes communications with the application server. The application server then creates a second connection to the database server.