ERP systems: what is it in simple terms, the pros and cons of ERP, an overview. V Implementation of an ERP system in the enterprise. Where to get an ERP system for an enterprise

The market for ERP systems in Russia is growing rapidly. However, projects to implement ERP-systems often end in failure. According to experts, approximately 70% of ERP systems implementation projects do not achieve their stated goals. We propose to discuss the main reasons. After all, forewarned is forearmed.

The ERP (Enterprise Resource Planning) systems market remains one of the fastest growing software markets in the world. The volume of the Russian market of ERP system at the end of 2015 grew, according to TAdviser, by 9%, having reached 108 billion (see the picture). Revenue 8 out of 10 major players domestic ERP-market also showed a positive trend for the reporting period.

Picture

First of all, the interest shown in ERP systems associated with the expectations of significant benefits that enterprises can receive as a result of the use of such systems. But these expectations are based, most often, on the promises of the companies implementing this software. However, very often projects for the implementation of ERP-systems end in failure. Approximately 70% of projects for the implementation of ERP systems do not achieve their stated goals due to a banal lack of understanding of what an ERP system is.

What is the reason for such sad statistics and how, having spent significant financial and time resources, not to prove it? We offer the TOP 10 mistakes made in the implementation of ERP projects. This list is not exhaustive and is a list of errors found by our experts and consultants in the course of working with clients.

Download helpful documents:

Mistake #1. Do not describe business processes before the start of ERP implementation

It is impossible to qualitatively implement the ERP system without the described business processes of the “as it should be” level, or at least a clear understanding and display “on paper” of information and material / documentary flows in your company. We often come across an option when consultants are involved in the work at that critical moment of implementation, when the system fails and does not give the desired effect, and the implementers and the management team cannot direct it in the right direction. Getting to the bottom of the causes of such failures, we reveal serious inconsistencies in the understanding of the processes by those who implement the system and by the company itself - there is simply no description of them, or it is done formally and does not reflect the real production cycle.

The most common reason for such situations is the client's desire to save on the description and development of this step, which, indeed, can be quite costly. The client expects that adjustments to the processes can be made already at the implementation stage. On the one hand, this is logical, since the project, with correct construction, will unfold progressively, including more and more zones and sites, modernizing and improving something as the project develops. But this does not mean that business processes can constantly change during development - it's like renovating an apartment, constantly changing the design project ... Someday you will still repair it. The only question is when and how much will it cost you in the end?

One of the reasonable options, from our point of view, is a preliminary description of business processes “as is”, imposing them on a software platform with the help of a team of implementers and transforming them into “to be” is, in fact, the basis for implementation. In parallel, together with the project team, you can modify processes as development progresses, finding the best solutions and ideas for optimizing ongoing and automated processes.

Mistake #2. Continually make changes to the future system

Another common mistake is to make adjustments to the future system and not keep track of them (do you want to “sit on the needle”?). ERP implementation is always long and laborious. But this process can be further complicated if you fully trust the implementers and do not require them to describe in detail the changes made to the original platform. The result can be the most deplorable - in case of termination of the contract, you risk getting a lot of incomprehensible code, which you will not be able to continue working on on your own, or you will be forced to interact with a limited circle of specialists, since only they understand the essence of the system they created. Business should not and cannot depend on partners and their good will (or lack of it - the courts, according to our practice, can help in this matter, but they take too much precious time). Require your implementers to maintain project documentation, in order to be able to continue the project on their own by hiring specialists, or change the contractor.

Mistake #3. Rely completely on automation

It is not worth believing that automators will do everything for you. They won't, period. They will not be able to take into account all the features of your company, the nuances of interactions and the intricacies of doing business. Each company is different. If you want to get a good result, join the EPR system implementation project from the very beginning! The project team must necessarily include key company specialists, which will significantly reduce the risk of project failure and allow you to create a management tool that is useful for the company, and not a "data entry system for reports." Keep in mind the purpose of the implementation - to improve the operational efficiency of the company.

Mistake #4. Develop TK for all occasions

It is impossible to take everything into account, some moments will be “born” in the course of implementation, and there must be a certain degree of freedom, including that fixed in the contract with the implementers. Alternatively, you can specify in the contract the number of consulting hours for additional developments - it can be included in the cost of the project if it is implemented on a turnkey basis, or it can be calculated additionally at a man-hour rate. An attempt to develop a technical specification taking into account all the nuances will lead to the creation of a huge Talmud, which is unlikely to even be read and studied by the project team.

Mistake #5. Ignore personnel resistance

If the company's specialists are not involved in the ERP project, then the risk resistance to change , the introduction of a "system for leadership" can destroy all good undertakings. In our practice, there are cases when, under pressure from the management, the company lost about 50% of its personnel in the process of implementing the system.

Mistake #6. Not paying enough attention to the ERP system implementation project

Automation is optional in any case. In our practice, there was a case when a system implementation project was transferred to a top manager as an additional option. As a result, the terms and cost of implementation exceeded the planned ones by 2 times.

An ERP implementation project requires full immersion and, ideally, a separate project manager from the company who will integrate all the information about the project and communication in his hands. A project manager only on the part of the implementers will be absolutely not enough.

It is important to understand and accept - ERP implementation-system is your company's first need. Unfortunately, the implementation company is less interested in this - they are satisfied that you regularly pay the bills.

Mistake #7. Trying to do everything at once

Based on our experience in supporting implementation projects, we are convinced that the concepts of deploying projects based on scrum (agile software development methodology) really work and give results (read also about Agile methodology). The main principles that we focus on are work within small modules (cycles up to 1 month) in order to obtain a working version of the product at each stage. Further, adjustment and alignment of other modules with the developed one can go on. The system unfolds progressively, flexibly adapting to the tasks of the company. Trying to deploy the system completely at once and then test it, you run the risk of spending all the budget and time, and at the end you get an unpleasant surprise in the form of a non-working product.

Mistake #8. Choose the wrong platform

When choosing a platform, make sure that it really meets the needs of your business and will support not only finance, accounting, but also basic operations (production, sales, etc.). Make sure that it is intended specifically (universality here can hurt) for your type of company (manufacturing, logistics, etc.). This requirement applies to both functional and hardware-software platforms.

The better the system fits your operations, the less time and money you will spend on modifications, and the more comfortable the system will be to use.

Mistake No. 9. Wrong team of automators

Find consultants who understand your business. It is important to understand that the business processes of a manufacturing company cannot be approximated by the management methods common in retail or in the service sector, whatever good system they were not supported and no matter what consultants implemented it. Knowledge of programming, DBMS, accounting and trade are important, but they will not help much to implement the system in a company whose main business is production.

Mistake #10. Incorrect goals for implementing an ERP system

Implementation problems usually increase as the project progresses to those stages of the project that automate the company's most important business processes. Namely, business processes corresponding to the type of activity that brings the main profit. For trading companies are purchases/sales, for transport companies- transportation, for industrial enterprises - production, etc.

Unfortunately, very often the goal of implementing ERP systems is not so much to improve production activities how much to reduce the effort to maintain information flows within the enterprise. A classic example is the implementation of a system for combining financial and operational information in a single database.

Most ERPs claiming to be integrated enterprise systems were originally created for the purposes of customer relationship management, finance, and accounting. Accordingly, they were developed by accounting and finance professionals with the help of IT professionals. As a result, ERP systems provided the information required by accounting and finance departments, while production and other operating units (sales, supply, warehouses) provided this information. The implementation of such systems, which do not affect the core business of companies, usually does not lead to any significant results.

The process of implementing ERP systems is conditionally divided into 7 stages: organizational work, enterprise survey, choice of automation methodology, system design, software deployment at employee workplaces, system launch into commercial operation, maintenance.

We propose to consider the procedure for implementing ERP in more detail.

I organizational stage

Work on the ERP implementation project in the enterprise begins with defining goals and objectives. It should not be automation for the sake of automation - the customer must clearly know what business effects he wants to achieve in the end.

At the preparatory stage, it is also necessary form a working group on the client side. It should include:

Supervisor (preferably from among the top managers of the company). This person should be well versed in all aspects of the enterprise and the organization of business processes. In addition, the ERP implementation project manager should be able to make sole decisions on any issues that arise.
Specialists responsible for the compliance of the system with the requirements of the current legislation and corporate standards. This category includes: Executive Director, chief accountant, head of IT service.
Heads of all departments who will work in the ERP system. Their tasks will include advising implementers at the stage of studying the business processes of the enterprise and organizing the work of departments upon completion of the automation process.
General IT Specialist . His area of responsibility will be the technical support of the project.

If you want an automated control system manufacturing plant brought tangible business results as soon as possible, you must ensure that it is used as actively and effectively as possible by employees. To do this, staff must be trained to work in ERP and strictly controlled at the initial stage of operation. These responsibilities also fall on the shoulders of the representatives of the working group.

In addition, at the organizational stage, it is necessary to determine the sources of financing and the integrator company.

II Stage of enterprise survey

Upon completion of organizational work, an examination of the business processes of the enterprise is carried out. This procedure is necessary to accurately determine the timing and cost of implementation work. Depending on the scale of the project and the tasks set, the IT integrator can offer the client one of 2 survey options:

Express examination. It is carried out within 1.5–2 months. Based on its results, a document "Pre-project analysis" is drawn up. It reflects the features of automated accounting and a list of tasks that will need to be solved in the implementation process.
Full examination . It is carried out within 3-5 months. Based on the results of a thorough examination, a “Terms of Reference” is drawn up, business processes for automated accounting are developed and a list of necessary software improvements is described.

The choice of survey option is determined by the preferred ERP implementation methodology.

III Choice of ERP implementation methodology

The implementation of ERP solutions on the 1C:Enterprise platform can be carried out according to one of 4 scenarios:

Subscriber service . The integrator company conducts an express survey of the enterprise, draws up an enlarged ERP implementation plan and, on the basis of it, determines the maximum possible cost of the project. This cost is specified in the contract, the cost of one hour of work of the programmer-implementer is also fixed there. The general work plan is divided into months. Based on the number of working hours, the size of the monthly budget is determined. A fixed payment amount is also included in the contract.
Phased technology implementation . This ERP implementation methodology involves a complete survey of the enterprise, the definition of all automated business processes and the preparation of technical specifications. The terms of reference reflect: the volume of improvements to the standard configuration of the program, a complete list of works broken down into fixed stages, the timing and cost of each stage of ERP implementation. The main disadvantage of this technology is inflexibility. Making the slightest adjustment to the project entails a change in the TOR: a revision of the timing and cost of performing individual stages of work.
Quick result technology . The ERP implementation algorithm is approximately the same as for subscription services. An express survey is also carried out, the maximum cost of the project is calculated, the hour of the programmer's work is estimated. Payment is also made once a month, but not at a fixed rate, but according to the number of hours actually spent by programmers. There are no strictly regulated work plans for a month, a week - the list and sequence of tasks may vary depending on the actual needs of the enterprise. Flexibility is an undoubted advantage of quick result technology. You can include additional business processes in the project at any stage and without lengthy approvals. The only drawback of this implementation scheme is the blurring of the project implementation timeline.
One-time calls . Installation of the program on the workplaces of employees and automation of business processes are carried out to the extent possible by the client. The enterprise purchases a box, and all implementation work is carried out according to the scenario of one-time calls.

IV Designing an ERP system

According to the results of the enterprise survey, the functional requirements for the key modules of the system, the need for loading initial data and setting up an exchange with an already used software. The main business processes of the company are designed in the system, the standard functionality is improved to suit the specifics of the enterprise.

V Implementation of an ERP system in an enterprise

The software is installed on the workplaces of employees. Access rights and reports are configured. Loading work data and reference information from the old system, Excel files, etc.

VI Putting the system into commercial operation

To begin with, about the project itself: the introduction of 1C: ERP on industrial enterprise. When we came to the client (in 2015), the number of the plant was 5 thousand people. During the project, the plant has grown significantly and increased production volumes, now it employs about 6.5 thousand employees. 1C is installed on 1.2 thousand jobs. Actively working users now (June 2017) are about 350, it is planned to increase to 450.

The enterprise is part of the military-industrial complex of Russia, and, therefore, has its own specifics.

Before this project, I started medium-sized enterprises (1000-1500 employees, 50-150 jobs). We have already learned how to do them, having developed a clear methodology (now my team and I have an average time for transferring a project to commercial operation 7-10 months, depending on its complexity.)

But, as it turned out, with more than 2.5 thousand employees, there is a qualitative leap in the complexity of the project, which requires a revision of the technology.

So, in order. We arrived at the plant at the end of 2015. Initially, the task was to launch regulated accounting. In the course of functional modeling, the Customer's management (at the suggestion of the chief accountant) decided to transfer the function of entering primary documents "into the field". The scope of the project has been revised to include central warehouses, storerooms, shop floor accounting, contract management and BDDS. The deadlines for the introduction of regulated accounting were shifted to 2017, and during 2016 the “primary” was automated.

The decision that the functional blocks will be launched into pilot operation (hereinafter referred to as the “OPE”) in stages, although it brought us a lot of headaches, globally turned out to be correct: by launching all at once, we would simply drown in a shaft of problems, oh which I will tell later.

To be honest, I thought that the main difficulty would be sabotage by users. Before the introduction of 1C, they did not enter anything centrally anywhere: someone worked in Excel, someone worked in self-written systems. The basis of the workflow was "papers", which were then handed over to the automated control system for input by operators into the accounting program. Here, the project team on the part of the Customer competently approached the issue - a number of orders were issued, signed CEO that closed the issue. The orders were not drawn up in the usual style “a system is being launched at our enterprise ...”, but were quite specific “from such and such a date, the accounting department accepts only documents issued from 1C from warehouses.” To remove a possible misunderstanding, we immediately turned on the bar-coding of documents and distributed scanners to the accounting department (in fact, there were attempts to hand over documents “drawn” by people in Word).

The launch sequence was determined as follows: central warehouses, contracts, BDDS, workshop storerooms, workshop accounting, and as a result, already regulated accounting, which was also divided into separate functional sections.

The first (although not the main) problem was quite predictable - these are data volumes. However, I initially underestimated the scale of it. For example, just loading (without any processing) the balances for the “low estimate” takes about 4 days. And if the results suddenly reveal discrepancies, then another four days, and then another ... That is, this stage of work must be carefully worked out together with the customer during planning, literally by the day. For example, here we went the usual way: we downloaded only directories and put users on the “primary account” so that after the download of the balances was completed, everything would be done, checked and entered into operational records. As a result, we physically did not have time to reduce the accounting and accrue the repayment of the cost by the end of the month, and in order to submit management reports, we had to manually transfer the cost amounts from the old system, and then adjust them due to different accounting methods.

Also, the customer does not have many of the necessary data in a normal form, and, accordingly, it is necessary to ask for them to be prepared much in advance: for example, we began to collect a list of open orders for three (!!!) months. It would seem, what is easier? The enterprise must have information about what to whom and when it should produce and ship. But, as it turned out, in a formalized form, they only had order numbers (the requirement to organize separate accounting for the State Defense Order), and the name of the product, quantity, timing, etc. were stored either somewhere in Excel or in paper contracts.

In subsequent projects, we begin preparations for data migration with clients immediately after the first stage of the project - functional modeling.

And scale handmade we must always keep in mind when designing: for example, initially, when designing mutual settlements, the client wanted to break down the debt into stages of contracts, but after analyzing the labor costs of the preparatory work together with us, this idea was abandoned.

Also, a large number of “primaries” increases the cost of mistakes: if you suddenly forgot about filling in some props or taught to fill it out incorrectly (which, unfortunately, happens), then you won’t be able to “quickly go through everything with your hands”. In the best case, you will receive correctly filled data from the next month. That is, on such projects, only a very experienced project team can be used - the "jambs" of beginners can simply not be able to be corrected.

In addition, such a scale imposes specific requirements for pilot operation: I usually provide one and a half to two months of support for simple areas (for example, central warehouses), which is quite enough to work out the unit. And here, some storekeepers began to seriously analyze the data in the program only after 3 months. That is, before that they just learned to enter documents into the system. It turned out that in the course of work on the launch of other sections, it was necessary to divert resources to support closed functional blocks. This must be taken into account when planning people and budget.

Separately, it is worth mentioning the organization of informing users of the program. It is necessary to build modules into the configuration in advance to display mandatory messages: calling 350 people and saying that the instruction has been updated or that the cost calculation will be launched today is unrealistic. Here a patch from the BSP (library of standard subsystems) helped us a lot.

In addition to the problem of scale described above, the second and main problem of the project was that the enterprise did not have people who fully own the work of some accounting area. At first I thought that these were the features of only this plant, but now I understand that for large organizations this situation is rather the norm. There are several key users who lead their own "piece" and there is a department head who has his own idea of how they work. And between them - the abyss.

How I worked before: for each process, its Owner was determined, who formed requirements for it, we developed a work scheme, went through it with key users, and then approved it with the owner. Typically, this technique closes 80% of operations well, and the remaining 20% are "tightened" at the stage of pilot operation. We have followed this path here as well. The difference between reality and the perceptions of department heads emerged almost immediately. But the bosses said “it can’t be!”, And the subordinates corporate culture they didn't mind. As a result, the approved scheme of work contained a part of too laborious operations, a lot of redundant controls and did not contain a certain amount of “what they definitely don’t have”. All this had to be redone during the pilot operation. As a result, the already implemented and submitted improvements were radically rewritten, and the OPE itself required the constant presence of programmers.

To the problem of “smearing” knowledge about each process among dozens of people, a large number of seemingly similar departments were added (they only have about 30 central warehouses), which, despite the similarity of functions, had their own specifics and their own accounting features - which means that even the same operations can be performed in several ways. The slogan "unification of processes", declared at the start of the project, died during the first combat launch.

Analyzing the results of the project, I still don’t see a way to particularly reduce the risk of a significant discrepancy between the described processes and reality: in order to work out the scheme in detail with each department, and then with their leaders, the budget of Functional Modeling will have to be increased by 5-7 times, and it is usually difficult for customers to understand the value of this stage and pay 25% of the project cost just for a “piece of paper”. There was an idea about a test run of the system on several divisions, which I tried on another project, but it did not fully justify itself.

At the moment, I have determined for myself that on projects of similar scale, I will have to put up with iterative refinement - just organize it correctly, and immediately include in the assessment the work of programmers for the entire pilot operation, and increase the terms of user support at least twice.

The third problem of the project follows from the first two: a large number of users (for which many consultants are needed) and a large number of design decisions that are made right at the stage of the OPE. And since in ERP the same task can be solved different ways, then different consultants use different methods, and as a result, the system begins to "spread". No “end of the day meetings” help here, because due to the volume of different issues, consultants simply forget a lot by the evening.

In the future, I will introduce a separate architect into such projects, who will be isolated from users for the duration of the OPE, and through whom all design decisions will be made. He will also update user instructions daily (they are really needed for a large number of users).

What is the result? Despite the bumps, tears and gray hair, the client's management unit was launched. Now we have moved to regulation. I hope that the experience gained at the first stages will help in its launch.

(32%). After the choice is made, the popularity of the systems remains comparable: 21%, 18% and 14% respectively (meaning those cases when these platforms are chosen for implementation).

In general, the timing of ERP projects remains one of the painful problems for this market: only 36% noted that they were able to meet the predetermined time frame, and 62% went significantly beyond them, and only 3% were able to complete implementation projects ahead of schedule. Projects based on Microsoft Dynamics solutions were the most behind schedule, averaging 12.5 months, which is 4 months (47%) more than planned.

Oracle-based projects averaged 22.5 months, with a 29% time overrun versus an average planned 17.5 months. As for SAP ERP, the average duration of such implementations was 18.5 months with a minimum delay of 16% or 2.5 months against 16 months originally planned.

Average duration of ERP projects: planned and actual

Panorama Consulting, 2014

Top Reasons for ERP Project Delays

№	Cause	2011	2012	2013
1	The scope of the project has been expanded	17%	29%	29%
2	Organizational matters	14%	20%	29%
3	Data issues	14%	17%	29%
4	Unrealistic timelines	8%	11%	25%
5	Resource limits	13%	17%	21%
6	Learning problems	10%	15%	17%
7	Problems with platform functionality	8%	4%	13%
8	Other technical questions	7%	14%	8%
9	Conflict of priorities within the project	10%	12%	8%

Panorama Consulting, 2014

The main reasons why ERP projects run out of time, as follows from the table above, is the expansion of the planned scope of projects, as well as organizational problems, data problems - all this happens in a third of projects that are delayed.

The good news was, perhaps, only that in the period from 2012 to 2013, analysts recorded a decrease in the average payback period for ERP projects from 2.4 years to an average of 1.7 years. However, the number of organizations that have not been able to recoup their investment in automated systems enterprise resource management increased from 31% to 38%. The longest payback period was found for Microsoft Dynamics solutions (24 months), for SAP it is 23 months, for Oracle - 16 months.

And one more important point: the actual budget of the projects relative to the planned one at the end of 2013 increased again. At the same time, the most expensive implementation is the implementation of SAP ERP, on average, the budget of such a project is $2.55 million, followed by Oracle - $2.25 million, Microsoft Dynamics - $1.8 million. From the annual turnover of enterprises, the implementation of Tier I systems is 2-4 %, but the share of the cost of ERP projects based on Tier II and III can be significantly higher in the turnover of companies that have chosen them for implementation.

Only 66% of companies achieved at least 50% of their goals

As for ERP projects as a whole (regardless of specific vendors), at the end of 2013, only 66% of companies were able to achieve at least 50% of their goals within the framework of implementations. In 72% of cases, the project turned out to be longer than previously planned, with an average duration of 16.3 months. In 54% of cases, budget overruns were recorded, the average project budget was $2.8 million.

Average indicators of ERP projects 2012-2013

Panorama Consulting, 2014

63% recognized the implemented ERP projects as successful, 21% found it difficult to assess the effect of the implementation, 16% admitted that the implementation ended in failure.

Russian realities

One of the reports from The Standish Group points out depressing statistics about the state of affairs in the software industry in the US market:

only 32% of projects were completed successfully,
44% experienced various difficulties (exceeded budget, missed deadlines, etc.),
24% of projects simply failed.

The situation on the Russian market is hardly better, experts of the First BIT company say.

The statistics of the "success" of ERP projects were shared in the company 1C. According to a study of 555 implemented implementations of 1C ERP solutions in 2010-2013:

66% of projects met the deadline or have a slight, up to 10% deviation from the deadline,
24% of projects deviated from the deadline by 11-30% and
only 10% of projects deviated from the deadline by more than 30%.

As for project budgets, the situation for customers is even more encouraging:

78% of projects are on budget or exceed budget by no more than 10%,
19% of projects are 11-30% over budget and
only 3% of projects are over budget by more than 30%.

Among the main reasons for the failure of ERP projects, Russian integrators distinguish:

High expectations

The big problem is when there is no clear understanding of the desired result, what the customer wants to achieve, notes Efim Fish, director of business development Microsoft Dynamics AX Tops Consulting (Tops Consulting). In this case, to paraphrase a well-known saying, the project cannot be completed, it can only be stopped. Customers often misjudge their desires and the costs involved. Both parties must agree on the objectives of the project and key points what is necessary for the successful implementation of the project.

“It is important to understand that the process of implementing ERP is a process of two-way painstaking work. Here you can’t take sleeping pills and wake up to find that the system is implemented and working by an external supplier, all the staff readily accepts any proposals and gladly accepts all the changes that are brought to the company with new system. And they are introduced in any case, because there are no changes, only if nothing happened. And this is clearly not the goal in the case of ERP,” he commented.

Human factor, lack of management support

The introduction of an ERP system is not only an IT component, it is also a change in business processes in a company, because during implementation, many processes are improved, areas of responsibility are redistributed. Customers must be prepared for and support these changes in order to achieve results. Considering that human resources are one of the most valuable resources, good reception of the system is very important, as well as personal interest and participation throughout the organization. Lack of support senior management companies during the implementation of the project is one of the key reasons for the failure, according to 1C.

In 1C, for example, to meet project deadlines, a technique called "Quick Result Technology" (TBR) is used. According to the statistics of the timing of the implementation of ERP solutions by 1C (1420 projects for 2010-2013), on average, it takes about 3 months before the first subsystem is put into trial operation, and from 6 to 10 months before the last subsystem is put into commercial operation. . depending on the scale of the project. On a special large enterprises implementation may take 1-2 years.

As Aleksey Petrushov clarified, one of the main indicators of the project's inefficiency is the delay in terms. The main reason for this problem is, of course, human factor he added.

* Payment after implementation. Successful implementation.

“We are not looking for “guilty” (both parties are always to blame) for unsuccessful implementations, we take money from the customer only when he is satisfied with the result,” says Sabina Borshchevskaya, eBusinessDrive. We carry out the implementation of ERP, practically, at our own expense, and if the client is not satisfied with the result, he simply does not pay. At the moment, such conditions in the Russian, and even more so global, market for the implementation of ERP systems are as fresh as the air in the mountains of Switzerland. Come.

Budget shortfall or overspending

The spread of prices for Russian market ERP systems is significant: this is determined by the fact that the ERP system is a complex product, on final result The project is influenced by many factors, ranging from the functionality of the ERP system to the management system in the customer's organization.

First of all, in order to calculate the real cost of the project, it is necessary to conduct an express survey, having familiarized yourself with the current business tasks of the enterprise, and agree on the target state organizational system management of the enterprise in the end, says Alexey Petrushov. According to his estimates, the average budget for ERP implementation in Russia ranges from 1 million to tens of million rubles.