Theoretical

Enterprise Resource Planning (ERP) is (now) understood to mean the massively software-supported, needs-based planning, control and administration of all operational resources in the sense of constant optimization of the value creation process in terms of its efficiency. Resources include personnel, capital, materials, operating resources as well as the company's information and communication structure. ERP covers the following areas:

• Materials management (procurement, warehousing, scheduling),
• Production or production planning and control,
• Needs assessment,
• Finance and accounting,
• Controlling and risk management,
• Human resources management,
• Research and Development,
• Sales and marketing,
• Master data management,
• Parts list,
• Product data management,
• Document management,
• Disposition and
• Customer Service

The integration of all of these areas cannot be achieved without basic and extensive software support. To digitize resource management, software applications are used, which are consequently referred to as ERP systems. There are a large number of providers of such systems on the market, with SAP, Oracle, Sage, Microsoft and Infor being among the most prominent and top-selling names. ERP systems differ primarily in terms of area of application (industry), scope of functions, scalability and the technologies and platforms used. Investment and follow-up costs can also be an important comparison parameter. The introduction of an ERP system in the company is a strategic step that should be preceded by an extensive evaluation. It should be considered when the company is doing as well as possible - not when it is in a crisis that is already making human resources and liquid assets scarce. In terms of its complexity, such a project is critical to the company.

So much for the theory.

Historical

Basically, ERP systems have been around for several decades. When I was studying, the term was just coming into fashion for the first time. Higher education institutions in the still young area of tension between business administration and computer science presented the theoretical concepts of such systems in more or less detail, and for the first time the PC and server systems available on the market as well as the intermediate networks seemed to have the necessary resources to implement them in one to make a reasonable extent possible. This was initially met with limited success; It was not uncommon for the majority of storage and computing power to be used to conjure up the graphical user interfaces on the monitors instead of enabling consistent data storage and manipulation. To fix the frequent system crashes - including large-scale data losses - entire teams were initially needed, who were often inadequately trained and hardly had the necessary contacts with the actual developers. Or didn't exist at all.

Of course, a lot has changed since then; However, above all, the complexity in the economic environment has increased - to the extent that the available systems can hardly keep up with the fidelity of the representation.

Standard processes and risks

ERP systems usually come with fully implemented processes for standard procedures that are typical for companies. When a system is introduced, existing structures must be aligned with these processes - which are often declared as business excellence in complete misjudgment. On the one hand, this can reveal serious weak points in existing processes and interfaces, but on the other hand, it also has the potential for conflict and frustration. Not everything that was different before was automatically worse. Especially when standardizing and rationalizing processes as part of a software change, employees are often reduced to purely mechanical production factors. The idea that even everyday procedures can have an individual, positive touch is often not foreseen in ERP systems - because it was already a missing piece in the minds of the development teams and countless senior consultants. Personally, I consider this to be a shortcoming in the theory-based, often too narrow-minded university education.

Core processes and risks

Things get even more exciting when it comes to tailoring, i.e. adapting the system to the actual core competence of the company or group. The replacement and content coverage of existing isolated solutions (often without sufficient questioning; many special requests fluctuate with the personal needs and working environments of individual employees and have therefore grown historically) and the most silent, largely uninterrupted integration (as far as possible) into ongoing operations result in a planning phase that is usually far too short and criminally underestimated by those responsible for the project and also the management; often resulting in a large number of expensive additional, individual programming tasks, which over time cause considerable follow-up costs (maintenance, expansions, compatibility, etc.). This work always takes longer than expected and therefore often takes place under time pressure, which is reflected in three typical problems: Insufficient direct contact with the actual users on site; lack of or no documentation; completely inadequate practical tests. Especially when introducing large ERP systems across a group or at least a site, downtime must be planned for to be on the safe side. Practical experience shows that these downtimes can range from a few weeks to several months - existentially critical periods in which huge, unreconciled amounts of data are often generated, be it through Excel lists or even handwritten notes on anything that looks like paper. Basically, there is a desire among a company's employees to keep business operations running as well as possible even in such a phase - at least in the beginning. These phases can quickly lead to physical and psychological overload - also a factor that those responsible do not want to acknowledge - and of course they have a grossly negative impact on the very planning and data quality that one actually wanted to improve. Nevertheless, the complexity of internal processes in a market with global dependencies is now so enormous that in most cases there are no viable organizational alternatives. The complete individual development of an ERP system has been tried again and again, from medium-sized companies upwards; However, if you consider that such a task ties up entire teams of developers and analysts over several man-years, the purpose of such an undertaking is rightly questioned from the outset.

Critical remark

The bottom line is: I often get the impression that today's ERP systems (have to) justify their existence primarily by getting the increasing complexity of operational processes under control and breaking them down into blocks that are manageable for the user. They primarily only counteract deterioration, but for the end user they are often little more than a wall with increasingly smaller peepholes. A large number of colorful management reports, the meaning of which is often misunderstood, cannot change this. Controllability, data consistency across all areas of the company and ultimately the (almost) optimal use of resources often remain target states. In my opinion, the actual potential for improvement or even relief that was originally in the foreground - even if no one would like to admit it - is little more than a hedonistic ideal that can hardly stand up to current reality. However, my personal assessment is that the use of AI will bring about structural change here in the next decade or two - although that direction still seems unclear to me.