The complexity of ERP systems
Surely you have seen such a picture.
Everything, absolutely all of my colleagues, friends, acquaintances, even I myself laugh at these unfortunate developers who have crammed the program with buttons, links and other slag.
Although I have something to laugh at. I, as an architect of ERP systems, regularly apply my own hands to this, and I understand where this chaos comes from.
When you buy yourself a home, let's say, Windows 8 or your Favorite Game (at least you buy something, I hope?) You personally decide on the choice of this system, and you will personally use it.
So, in the corporate sector is not so. In the process of choosing, buying and using is divided between different people. There is:
And yes, they are all different people. This is the root of the problem, which I will now tell you about.
For a better understanding of the problem, you can familiarize yourself with the typical process of purchasing information systems in large corporations.
Three key issues that make soft candy a bit dismal:
1. In the buying process, key decisions are made by people who will not use the software.
When buying look at the cost and functionality at the level of the jackdaw, "can this software or not." To delve into HOW it can and compare it with other solutions is too difficult for these people.
Moreover, there is no some functionality, but the seller convinces that it will appear AFTER implementation (see Section 6). In the process of buying, it is simply fixed that they promised us this functionality.
')
Result:
Customer expectations coincide with the functionality of the product, well, 50 percent. The problem is that corporate software is complex and too universal. Buyers do not know how to buy it correctly, what can be set up and what will have to be seriously processed. Sellers, without delving into the delicate needs of the client, promise more than what is in the product. The devil is in the details!
2. During the implementation of the key decisions are made by people who will not use the software.
Implementation usually goes messy. As he said, in fact, 50% of software is added on the spot.
The collection of requirements goes something like this: a lot of small department heads whose signatures will stand on the implementation report, at the beginning of the project at the requirements collection stage, just when they understand the least, write disparate requirements with a very simple structure: “add a button that will do thats something. ”
Result:
Many different people from different departments create a FLOW OF CONSCIOUSNESS, which is issued for a list of improvements, which will be paid for if developed. And that means it will be developed!
However, when the employee of department Y asked to make a copy button, he did not expect that another cloning button from department Z would appear next to, as well as the button for export, move, register, etc. But its button is developed and claims, like as, there is no one to show!
3. Information systems reflect the company's business process superimposed on the universal box-box dummy.
They do not just keep records, they MANAGE the activities of the company, and changing software should lead to the correction of the business processes themselves. But the company usually does not have those people who could change the processes of the company under the software.
The same development department in the company's hierarchy, which could occupy this place, stands on the corporate ladder far below the Production Department X and cannot indicate how they work. And the installed program did not set the task to come up with a new way of interaction and only patchworked the current processes under one roof, adjusting a little to the existing relationships.
Result:
There is no person in the company who could look at the program “as a whole” and at the same time had enough weight to make changes in the company's activities. Therefore, the software is already globally unchanged, and it will be just that all my life.
In general, do not expect beautiful corporate ERP systems in the near future.
And now the fun part! It seems that there is something wrong in the scheme described. Here are answers to frequently asked questions:
Q: Why should customers not buy software correctly by buying 90% of the finished functionality?
A: First try, find such software, especially if you have 200 people in the department. And by the way, if you do not have a department for 200 people, then you are not sure that you understand the complexity of the problem.
Secondly, try to choose the software from what is, for example, for Depository Accounting (). You are either an accounting specialist or IT specialist. Both that and another you will become AFTER purchase and implementation at least TWO systems. And this is 5-7 years. The lifetime of the software is 5 years. And the average duration of work in one place in Russia is 3-4 years.
Q: Why not combine and harmonize requirements?
A: First, you can do it yourself in 5-7 years (see the previous paragraph).
Second, it’s easy to write requirements for adding something. But on the fact that something to change, merge or delete, for this you need to take responsibility for the fact that such a change does not spoil anything and will suit everyone. No one involved in the implementation can usually take such responsibility on themselves.
Q: I have such software at work. I am the head of that same department for 200 people and I want to try to do something. What to do then?
A: Difficult question. As with traffic jams in Moscow, one cannot come up with one magic pill. I will give one piece of advice:
In the implementation process, there is usually at least one person who is trying to reduce the amount of heterogeneity in the system. It happens that this is a young employee with a “low weight”. It happens that this person from the developer’s company.
So, lure him to work, give the position of “analyst of the information system”, and give him only one task - “reduce the number of buttons”.
Let him write a document in which he will try to describe the consequences of reducing processes in the system and the consequences for all users. And then goes and coordinates these requirements with all heads of departments.
Let it be his only job. And maybe you will have the best system in the world.
By the way, here are my thoughts on what can be done.
I tried to tell my personal opinion about why ERP systems look like this:
Maybe you will be the very person who can solve this problem.
Do you know how to change this world? Welcome to the comments!
Everything, absolutely all of my colleagues, friends, acquaintances, even I myself laugh at these unfortunate developers who have crammed the program with buttons, links and other slag.
Although I have something to laugh at. I, as an architect of ERP systems, regularly apply my own hands to this, and I understand where this chaos comes from.
When you buy yourself a home, let's say, Windows 8 or your Favorite Game (at least you buy something, I hope?) You personally decide on the choice of this system, and you will personally use it.
So, in the corporate sector is not so. In the process of choosing, buying and using is divided between different people. There is:
- The one who chooses the software
- The one who pays for it
- Several different groups of people who use it
- The one who writes software developers error reports and requests for modifications
And yes, they are all different people. This is the root of the problem, which I will now tell you about.
For a better understanding of the problem, you can familiarize yourself with the typical process of purchasing information systems in large corporations.
Familiarize
All 12 years of developing information systems, I have seen the following scheme for buying software in large companies:
- At a high level, the Strategic Decision on the Development of the Information Environment of the Enterprise will be adopted. This document will contain many words such as “integration of business processes”, “increase in labor productivity” and “increase return on capital”.
- Under this will allocate a budget and, for example, will create a group of interaction on information development. Or maybe the company already has such a person heading the Information Systems Development Department.
- The development department was created for a reason, it holds tenders, makes inquiries, notifications of intent, a framework agreement and other integration actions.
- The representative of the company "Best Soft" decided to participate in the tender. He prepared a presentation, spoke. And, let's say, by a strange coincidence, it was from this company that they finally began to acquire the program. At the same time, the program costs 100 rubles and the introduction is estimated at another 200 rubles. It is important! Most often, the implementation is more expensive than software, because ... see p.p.6
- The implementation phase begins.
- Consultants come and “customize” (i.e., they add 50%) of software.
Bingo! This is a very important point! 50% of the ERP system in a particular company is not a boxed product, but is written in the shortest time under the name “setup”.
Not a bad article on this topic from A. Popov. - The project starts, users of department X use the program.
- All errors and improvements are centrally collected by the IT support department and sent to the manufacturer.
- Every two to three months, the manufacturer updates the program.
Three key issues that make soft candy a bit dismal:
1. In the buying process, key decisions are made by people who will not use the software.
When buying look at the cost and functionality at the level of the jackdaw, "can this software or not." To delve into HOW it can and compare it with other solutions is too difficult for these people.
Moreover, there is no some functionality, but the seller convinces that it will appear AFTER implementation (see Section 6). In the process of buying, it is simply fixed that they promised us this functionality.
')
Result:
Customer expectations coincide with the functionality of the product, well, 50 percent. The problem is that corporate software is complex and too universal. Buyers do not know how to buy it correctly, what can be set up and what will have to be seriously processed. Sellers, without delving into the delicate needs of the client, promise more than what is in the product. The devil is in the details!
2. During the implementation of the key decisions are made by people who will not use the software.
Implementation usually goes messy. As he said, in fact, 50% of software is added on the spot.
The collection of requirements goes something like this: a lot of small department heads whose signatures will stand on the implementation report, at the beginning of the project at the requirements collection stage, just when they understand the least, write disparate requirements with a very simple structure: “add a button that will do thats something. ”
Result:
Many different people from different departments create a FLOW OF CONSCIOUSNESS, which is issued for a list of improvements, which will be paid for if developed. And that means it will be developed!
However, when the employee of department Y asked to make a copy button, he did not expect that another cloning button from department Z would appear next to, as well as the button for export, move, register, etc. But its button is developed and claims, like as, there is no one to show!
3. Information systems reflect the company's business process superimposed on the universal box-box dummy.
They do not just keep records, they MANAGE the activities of the company, and changing software should lead to the correction of the business processes themselves. But the company usually does not have those people who could change the processes of the company under the software.
The same development department in the company's hierarchy, which could occupy this place, stands on the corporate ladder far below the Production Department X and cannot indicate how they work. And the installed program did not set the task to come up with a new way of interaction and only patchworked the current processes under one roof, adjusting a little to the existing relationships.
Result:
There is no person in the company who could look at the program “as a whole” and at the same time had enough weight to make changes in the company's activities. Therefore, the software is already globally unchanged, and it will be just that all my life.
In general, do not expect beautiful corporate ERP systems in the near future.
And now the fun part! It seems that there is something wrong in the scheme described. Here are answers to frequently asked questions:
Q: Why should customers not buy software correctly by buying 90% of the finished functionality?
A: First try, find such software, especially if you have 200 people in the department. And by the way, if you do not have a department for 200 people, then you are not sure that you understand the complexity of the problem.
Secondly, try to choose the software from what is, for example, for Depository Accounting (). You are either an accounting specialist or IT specialist. Both that and another you will become AFTER purchase and implementation at least TWO systems. And this is 5-7 years. The lifetime of the software is 5 years. And the average duration of work in one place in Russia is 3-4 years.
Q: Why not combine and harmonize requirements?
A: First, you can do it yourself in 5-7 years (see the previous paragraph).
Second, it’s easy to write requirements for adding something. But on the fact that something to change, merge or delete, for this you need to take responsibility for the fact that such a change does not spoil anything and will suit everyone. No one involved in the implementation can usually take such responsibility on themselves.
Q: I have such software at work. I am the head of that same department for 200 people and I want to try to do something. What to do then?
A: Difficult question. As with traffic jams in Moscow, one cannot come up with one magic pill. I will give one piece of advice:
In the implementation process, there is usually at least one person who is trying to reduce the amount of heterogeneity in the system. It happens that this is a young employee with a “low weight”. It happens that this person from the developer’s company.
So, lure him to work, give the position of “analyst of the information system”, and give him only one task - “reduce the number of buttons”.
Let him write a document in which he will try to describe the consequences of reducing processes in the system and the consequences for all users. And then goes and coordinates these requirements with all heads of departments.
Let it be his only job. And maybe you will have the best system in the world.
By the way, here are my thoughts on what can be done.
I tried to tell my personal opinion about why ERP systems look like this:
Maybe you will be the very person who can solve this problem.
Do you know how to change this world? Welcome to the comments!
Source: https://habr.com/ru/post/172073/
All Articles