Not so scary ERP project as painted

Hello, Habr!

Under the pressure of such a lively interest in enterprise resource planning (ERP) systems, he tore the real estate from his chair and decided to share his impressions. Let’s try to understand who, why and how much ERP, whether it is necessary to regulate something at all, and where, with all this, the same flexibility that ERP supposedly does not have.

When SAP, as Wikipedia tells us, in 1972 took the first steps ...

... what was the first functional? Accounting. And until now, they often start to implement SAP precisely from accounting - everything is relatively clear there, and "completely strangers, not from our area" took care of the regulations.

What does any company do? The firm makes money. That is, everything that happens is reflected in the financial status. Money came - we paid the bill. Raw materials arrived - finished goods left the warehouse. They scrubbed around the barn - we baked a bun (that is, they made something) ... well, in general, I brought it, accountants! You know what I mean. Italians came up with it in the 13th century, before SAP.

After SAP crept into accounting and data entry was started not from punch cards, but from the keyboard, lazy smart heads decided to use the same approach for procurement, production, quality control, etc. And this is what came of it.

ERP systems - a huge number. Large, small, for different industries ... I had a chance to work with three and a half, and all three were very different. And yes, dear lovers to write something of their own, you will not be bored with ERP either.

Almost everything that (from the point of view of the manufacturer) is designed to make life easier for the manufacturing enterprise, has an ERP tag. God be their judge ... I don’t want to polish topics like “ERP has a warehouse accounting system” in this article - firstly, it doesn’t always exist there (but in some places there is a hotel room reservation system) secondly, it’s not for you which does not oblige. You don’t want to - let your storekeeper bring the warehouse list to the accounting department every month, no problem.

I would like to dwell on the fact that, as one colleague puts it, such a system “gives” us.

The eternal problem of the developer: which stack to use; how to conduct development; where to get the developers; who know this stack; who to contact if everything is bad; how to control the quality of development ...

Specifics of business applications (in addition to the above): how to make your program work in 10 - 20 - 30 years, please, with all the historical data; HOW TO PRINT (for those who were surprised: printing is a separate issue in general, there are three engines in parallel in SAP); How to guarantee data consistency.

A good ERP will solve these problems for you. In the heat of battle, we forgot that SAP is a development system (in which ERP functionality is implemented and much more). Do not believe me - download a mini-SAP. It is “naked” - it contains only this very development system, server, database and client. You will not find any ERP functionality there. But you will find graphic designers of database tables, your own programming language, a packaging system for transporting programs between systems, a window designer, user management, access rights, etc. (Now they shower me with rotten tomatoes, because much has changed in the "new" SAP. I repent, repent ...)

If you came up with your own language for ERP, then it is also tailored to this class of tasks. And that’s all - to speed up the development process! (laughter)

And you will always find SAP specialists - you only have to pay. And so - the place of bread ... It’s another matter if the only programmer at YOUR firm, who over the past 10 years has rewritten in Java, well, really all the programs from the button for opening the door to the warehouse automation system, have come under the roller. Everything is bad here, and there is no one to help. But IT costs have been ridiculous all these years. Well, he laughs well ... you know.

Years passed, SAP overgrew customers, and each client has its own cockroaches in his head. Someone loads oranges in barrels, someone gives loans, and someone provides services. And so it turned out (1) multi-level logic, which is configured for a specific client; (2) entry points for programming in a project; (3) a huge ecosystem of modules - maintenance, for example, or import-export.

What's so bad?
Well, it’s a sin to hide ... The code, which can be up to 30 years old, and which was written according to the then canons, is not very pleasant to maintain in the 21st century. Therefore, three print engines. That's why there are different options for working with memory, therefore object-oriented ABAP and "normal". Anyway, a lot of "old", "new" and "completely new" technologies. Are there many more systems in which programs of thirty years ago work in parallel with new ones?

On top of this layer, programs are written in the project that automate frequently repeating situations even more. Much can be done manually, but few users know the system so well.

As for me, most projects fail because

  • chose the wrong ERP
  • no luck with consultants
  • failed to systematize what is happening in the company
  • that it was possible to systematize doesn’t work in ERP, but I really want to (and disfigured ERP)
  • employees still did as before
  • they wanted to immediately automate everything by 110%
  • decided that ERP is another toy for IT specialists, let them implement and do it

So if we are talking about implementing ERP, and not about switching to another ERP, you go quieter, you will continue. And it is very important to remember that ERP is for centuries to decades. Implementation is only the beginning.

On this, let me take my leave.

Yours, m_OO_m

Also popular now: