It is known that the marketing statements of vendors sometimes seriously diverge from reality. However, it is generally accepted that reputable market players do not resort to such practice. However, the SAP Business One Implementation Project Manager in a small Russian company I was convinced from personal experience that “nothing human is alien” to respectable companies.

Edge of Survival

A few years ago, almost all the world's developers of ERP systems began to move towards the SMB segment, which was declared almost the most promising and priority. New products were introduced to the market, aimed at small companies with small IT budgets. The Russian market of business applications was no exception. Convincing articles have appeared in the domestic press informing Russian businessmen that in the face of tougher competition (including WTO accession) they will not be able to survive if they do not have a modern, automated system management accounting, planning and control. The arguments presented were quite persuasive. As a result, the leadership of many medium and small enterprises in Russia is seriously thinking about the transition "to something better than Excel and 1C." Our company also belongs to the SMB segment and, due to the above factors, accepted the offer of one of the partners of SAP Corporation to introduce a then new product for the market - SAP Business One (B1).

As follows from the advertising booklets, modern software products that meet generally accepted world standards have finally become available to small businesses in Russia. It was about wide functionality, affordable price and several months of implementation. Only one thing was kept silent - that small business risks much more when entering the game of "introduction of corporate software", because, despite the modest budget compared to the sensational projects, investment in IT for not big company- a significant item in its costs. And in terms of business scale, the introduction of a “beautiful overseas box” can really put a company on the brink of survival.

Here is a new twist

SAP was no exception in the global race for SMBs and a few years ago announced "major changes in the company's product portfolio" and the decision to make a "total turn towards the SMB market" and include in its product line solution focused on small growing companies. Moreover, it was announced that the SMB solutions market is one of the priorities for SAP. SAP CIS Managing Director Alexey Shlykov then commented on this step as follows: "SAP recognized the moment when the large business market, which, first of all, the company's business applications were focused on, was close to saturation, and it was time to look for the next sales markets."

As a result, in 2003, a localized version of SAP Business One was introduced to the Russian market - a solution that is fundamentally different from what SAP was doing before. However, SAP Business One is not the development of a German company: the product was purchased from Israeli developers. It is curious that the release of SAP Business One was not accompanied by large-scale advertising campaigns- all promotional efforts resulted in several informative articles in the press and a series of regional seminars, which for potential clients organized by SAP partners. It was also officially announced that the cost of one “turnkey” workplace (licenses plus implementation consulting) will be €2,500–€3,000, and the duration of implementation will not exceed 8 weeks. In addition, it was known that the product had one significant advantage compared to alternative proposals - it is customizable, it does not need to be programmed, unlike 1C solutions, and it already contains ready-made business processes.

In fact, during the direct sale of our company, the following was stated: “In 2 months we will introduce the product, and you will have a full-fledged management accounting system.” In that marketing information about the product does not correspond to its real essence, we were convinced by our own experience later. So far, everything has sounded very convincing. We were also impressed by the demo videos of the solution presented by the SAP partner (a respected, long-standing company in our region). In addition, the most compelling argument was made - "you are under the wing of a reliable SAP brand." And it dispelled all our doubts.

harsh reality

After three months of implementation, it became clear that the functionality of SAP Business One is frankly insufficient to run even a small (70 employees) business in Russian conditions. Why didn't we understand this before? Complex issue.

The product, as we were told, is aimed at the SMB market, so as not to involve companies in a long stage of the survey followed by a multi-volume terms of reference. As a result, after the stage of testing the customized product, we were faced with a list of "bugs" for more than three sheets, and those without fixing which it is simply pointless to put the system into working condition. Some of them related specifically to errors in the operation of the product, while the other concerned the problems of insufficient functionality of the solution. According to the list we compiled, the implementing company was ready to “finish” about 30% of the requirements, while the rest could not be changed without the participation of SAP, because the product code was closed. The implementation of those “improvements” that the partner is able to perform on their own doubled the cost of the project at once. This was motivated by the fact that "the product needs to be finalized in accordance with the specifics of business processes." At the same time, improvements were really needed, but not for our “specifics”, but simply to implement in the product, in general, a standard business model. There were no unusual demands on our part.

In addition, as it turned out, SAP Business One is not a three-tier system, but is built on a client-server architecture. At the same time, the information is processed not on the server, but on the client, which directly affects the performance. By the way, when we launched the system in test mode, taking into account the hardware requirements stated in the official booklets describing the SAP Business One solution, the declared information processing capabilities of the system did not materialize.

It is also necessary to note several serious shortcomings of SAP Business One, which are not obvious at the first presentations, but “emerge” only in the process:

• the semantics of the database system is practically not described;
• there are practically no stored procedures;
• the system is slow and resource intensive;
• missing printing forms corresponding Russian standards accounting;
• the backup function is not implemented (for example, products);
• accounting for fixed assets has not been implemented;
• accounting of settlements with accountable persons is not implemented;
• incorrectly implemented accounting of payments;
• there is no possibility of attributing direct and indirect costs to the cost of production;
• cellular warehouse support is not implemented, it is impossible to keep records in the context of consignments of goods;
• the opportunity to conduct the arrival of the party at different prices is not implemented;
• MRP does not work in the context of a warehouse.

At the same time, SAP Business One accrues amount differences only in national currency, the report on amount differences is compiled based on the current exchange rate, which leads to incorrect calculation of amount differences in payments.

The listed "flaws" generally make it impossible to provide correct information about the company's activities. At the same time, it is not entirely clear how, in this case, SAP Business One can be positioned as a management accounting system. Retail, wholesale and other rapidly growing businesses will not be able to work with this system due to its performance limitations. Saving a document with 40-50 positions brings the system into a stupor. If there are at least 200-300 such documents per day, then everything just stops working.

We were offered to “optimize” the business processes of our company, which, in fact, is a restructuring of key points for us and looks more like “squeezing” an already established well-established business into the rigid framework of a solution. If we do not want to rebuild the existing system in our company, we were offered to finalize the solution. Moreover, we are talking here about expanding the functionality of the solution and requires programming using the so-called SDK package (Software Development Kit).

From a conversation with an implementing company, we learned that SAP, generally speaking, forces partners to independently refine the functionality and write so-called add-ons (additional components). These components can also be obtained off-the-shelf commercially from other partners who have already implemented this functionality. For example, to account for transactions with fixed assets, you need to buy the appropriate add-on, the same if we want to keep track of actual and planned costs, another separate module is designed to interface the solution with the bank-client system. In addition to the fact that the cost of the project increases, there is another side: if we buy an add-on from another company, then we either need to involve them in the implementation for, again, additional money, or our implementation partner will deal with it on their own but also not free. In fact, it turns out a kind of "pyramid", which grows the stronger, the wider the functionality required by the enterprise.

Sell ​​and forget?

It is logical to assume that SAP should deal directly with the correction of technical and technological deficiencies. Here, several interesting points were revealed in communication with the Moscow office of SAP. I will mention that we paid for the annual technical support and had the right to count on at least an attentive attitude as a client and a prompt response.

I must say right away that none of the points indicated by us has been corrected. Instead, there was a long correspondence between the partner and responsible persons SAP, which, in the end, our partner even showed us. Most of the answers (polite, but short replies with a pause of a week) boiled down to the fact that they are well aware of this or that “bug” and are actively working on it, since we are not the only ones complaining about it. Almost all the points we requested were allegedly corrected in new version SAP Business One. Which we have been waiting for about a year and a half.

As a result, we have the opinion that the demonstrated " technical support» reflects the vendor's overall approach to doing business with SMBs. SAP in Russia is focused specifically on large clients, because they have the opportunity to invest an indefinite amount of time and money in a project. But SMB cannot wait indefinitely and “feed” SAP consultants all this time, too. Moreover, judging by the "efficiency" and "meaningfulness" of the responses to our requests, it seems that SAP is only interested in selling licenses, and nothing is being done specifically about the product. It is also noteworthy that the people responsible for customers in SAP Business One often change in SAP. Some of them, after the start of the SAP project for SMBs, very quickly switched from solving issues of promoting SAP Business One to creating their own career within SAP, the other part moved to other companies.

Marketing Arithmetic

The statement "SAP Business One is a system for management accounting" gives a special charm to SAP marketers. I repeat, what can be accounting if the system is not able to provide true information about the activities of the enterprise? If the system is “gruntily pulled on the business” by unfortunate partners who are simply forced to drive the company into the framework of this “solution”?

From the very beginning of the launch of the SAP Business One product on the Russian market, it was stated that this is a solution for medium and small businesses. Is it really? The SAP company itself in the media announced the cost of 1 turnkey workplace (that is, license + implementation) - about € 2.5-€ 3 thousand. In addition, it was announced (as an advantage of the product) that the price is final.

In order to really automate key business processes in a small company, say with a staff of 100-200 people (finance, sales, warehouse, purchases), you need to purchase about 10-15 workstations. That is, it is necessary to count on the amount of about €30-€45 thousand. As practice shows, the owners of Russian small companies, who earn their every penny "by sweat and blood", it is not so easy to pay 30 thousand euros / dollars for "software". Moreover, it is impossible to maintain tax accounting and bookkeeping in the system and, at a minimum, "1C: Accounting" will still be needed. Moreover, if you take a closer look at the already announced implementations, you can see that full-fledged projects are a rare exception and, as a rule, we are talking about 3-5 licenses. Conclusions suggest themselves.

Thus, in our experience, SAP Business One can work with no more than 10 users, in a company where there is no full-fledged product warehouse, while no more than 2-3 product orders per day can actually be processed. The question arises: “Does a small developing company need such a system for more than two thousand euros per workplace? Why, if at this level it is enough to use just Excel?

Firstly, according to representatives of SAP partners, Business One developers are located in Israel and there is no clear product development program for Russian market. More precisely, such development on a global scale of SAP business has the lowest priority. And no matter how active the partners are, they simply physically cannot cope with this whole machine and “knock out” the necessary product improvements directly (and the Moscow representative office of SAP, according to eyewitnesses, is inactive). This situation is quite common in business, when a corporation that has made a name for itself starts releasing products at a much lower price category. Management is already at an unattainable cosmic height with "cosmic thoughts" divorced from reality.

If we talk specifically about Russian reality, then perhaps the reason is that for the last 10 years SAP has existed here in too comfortable conditions? Suffice it to recall even the official amounts of investments in IT of our industrial monsters. And when it came to real action, the normal development and promotion of a specific product, perhaps skills and competencies were required here that were not required before? And the projects have become more transparent and it is no longer so easy to silence problems as in large-scale implementations, where there are too many interests involved to expose unsightly results to publicity.

It is clear that the goals of implementing an ERP system in a large industrial enterprise often far from automation itself (and it is still a big question how such implementations have had a positive impact on the Russian industry), but in the SMB segment this approach will not work. I note that the presale is done at a high professional level, which is not surprising, given the competence of SAP employees and partners. But is it ethical to take advantage of the incompetence of Russian managers and skillfully manipulate it? And we are talking about a product that is designed to "close" all the key issues of company management. The supplier's position here must be impeccable.

By the way, additionally about this position of SAP: at the round table on November 15, 2006, new approaches to working with partners working with SMEs were officially announced. SAP says product implementation will be done entirely by partners. And the vendor "will carry out the general management and placement of orders." Well, the position is quite logical, from the point of view of the complete removal of responsibility for the result of the project. That is, on the one hand, for Russian leaders for making a decision to purchase software, there will be an argument about the solidity of the developer's brand, on the other hand, one-on-one customers will remain with the partner. And the latter, in turn, is "one on one" with the product. If you are still in doubt whether or not to implement SAP Business One, try to speak directly with the owner of the company that allegedly runs this solution. Try also asking the SAP Business One Solution Sales Manager at least some of the questions raised in this article.

Vladlen Tatarsky

Implementing SAP from scratch

Implementation of new or improvement of existing management information systems based on software products SAP SE companies are carried out by SKYRISE in the form of projects according to proven ASAP, ASAP Focus, PMBOK methodologies.

Implementation (development) projects of the ERP class IMS belong to the class of complex complex projects and cover not only technical implementation business solutions, but also the transfer of skills for setting up and using the system to the Customer's employees.

The necessary close interaction "client-consultant" at all stages of work is implemented by creating a joint working group project. The development of solutions and their implementation in the system takes place with the direct participation of experts and technical specialists of the Customer’s company, and the solutions themselves and the results already during the project become intellectual property customer company.

A systematically organized project goes through the following stages:

• Project initiation
• Conceptual design (development of design solutions)
• Technical implementation of design solutions
• Testing
• User training
• Preparations for the launch of the OPE
• Launching the system into productive operation and its maintenance

SKYRISE takes over the management of the scope of work, schedules and deadlines, resources and the quality of project results. At the same time, the Governing Council and members of the project team on the part of the Customer always have the opportunity to control and be involved in the decisions of the project.

SKYRISE attaches great importance to the existing industry experience in creating information systems and models of industry best practices (SAP Best Practices) (see also - industry solutions).

When is it necessary to implement SAP from scratch

• The company is doing business using a non-SAP solution and has encountered technological limitations.
• The company is a Startup and is considering the choice of the main information platform
• The company produces large organizational changes, including mergers and acquisitions, or a coordinated change of activity

Each of these calls has its own work scenarios. And for that
in order to offer a suitable solution, it is necessary to reflect in detail the requirements for such a system and later choose technological solution in line with the company's development strategy.

Roll out SAP corporate template

Based on the developed needs for automation, an already developed solution - Template (Template) can be used to accelerate it.

A corporate template is usually developed for a large international holding when it is required:
• Unify business
• Consider local requirements
• Combine data in a single information space

It is also possible to use an industry template from a set of industry solutions (SAP Best Practices).

Extending SAP productivity system functionality

Expanding the functionality of a productive system

Extending the functionality of a productive system has its own specifics. Incorrect changes can disrupt a productive system, which can lead to a stop in production or a stop in shipping, which is fraught with a lot of work for the business.

1. All changes must be made on the basis of a verified methodology
2. All changes must be planned
3. Always have a plan to undo changes
4. The functionality should be verified both against the expanded functional scope of key business processes,
   as well as in terms of expanded organizational scope

Extending functionality is typically done using the ASAP implementation methodology.

Development of custom functionality

The development of custom functionality is usually understood as the development of non-standard functionality.
At the same time, it is important to understand the principles of managing data (reference books), operations, and developing reports when implementing user functionality.
Examples of such developments are:

1. Barcode scanning tools with mobile devices- link
2. Commercial Equipment Management System -
   link
3. Funds management system personal protection- link

Migration to SAP HANA

The transition to SAP HANA (High-Performance Analytic Appliance) is carried out in accordance with the SAP Activate methodology.
1. First, the entire list of business processes used is described
2. The entire list of reference books used is described
3. The entire list of used interfaces is described
4. On the purchased equipment (in the case of the On Premise version), SAP HANA software is installed.
5. User improvements are being made to the functionality
6. Directory and historical data are migrated from the old system to the new one using special tools
7. The functionality is tested in the new system.
8. Interfaces are being activated
9. Transition to a new platform is in progress

Represents automated system management of the main internal processes of the company, including accounting, finance, production, trade, personnel management, warehouse stocks and many other areas of activity. Best Practice in business processes, flexibility, scalability, adaptation to the legal context of any country and the individual needs of a particular enterprise are the main success factors for the system created by German software developers and which has become one of the most used worldwide.

The introduction of SAP is a serious, multi-stage process of business transition to fundamentally different forms of management. It involves pre-project preparation and selection of optimal solutions both from the technical and financial side.

One of the most pressing issues of interest to customers who have decided to implement SAP is the cost of the project. It consists of many factors, but for our company its validity is the most important criterion for the successful implementation of the project. Our experts offer rational decisions, the financial side of which is calculated taking into account the maximum practical return for a particular client.

The implementation of the SAP system in terms of the depth of the ongoing transformations can be considered one of the most important milestones in the history of the company's development, the success of which depends on the well-coordinated work of developers and the company's own staff. At the same time, not only IT services, but also all other structural divisions take part in the implementation of the system.

Results of SAP implementation

The implementation of SAP in the enterprise allows solving diverse production, marketing and management tasks that affect both performance indicators in general and in specific areas of activity.

The main benefits achieved by implementing SAP include:

• reduction in the cost of manufactured products (works, services);
• increasing labor productivity through a qualitative change in existing approaches, management methods and business processes;
• strengthening contractual discipline and compliance with delivery dates;
• access to high-quality analytics;
• improving business process management;
• improving the quality and speed of received management decisions;
• and as a result of all these transformations - an increase in the company's competitiveness in the market, an increase in capitalization and the amount of profit received.

Main stages of SAP implementation

Successful development and implementation of SAP requires the full integration of the proposed SAP technologies with the existing information architecture of the enterprise. From the contractor, this requires, first of all, serious technical knowledge, extensive experience in implementing SAP systems and modules, as well as a deep understanding of the specifics of the business and production activities customer.

The main stages of SAP implementation are:

• Project preparation (Project charter, project plan, regulations are being prepared. A survey is being carried out and the solution architecture is being developed)
• Development of a conceptual business project (Description of "to be" in SAP terminology. Organizational structures; basic data; business processes; output forms; reports; improvements. Preparation of scenarios for functional testing)
• Setting up a prototype and FT (Setting up a prototype system and testing according to prepared scenarios. Preparation of basic data by the customer (reference books). Preparation of an integration testing scenario)
• Customizing the system and IT (Integration testing) (Tuning the system based on the results of functional testing. Conducting integration testing. Finalizing the basic data. Necessary developments during the project, which usually take no more than 10-15% of the total amount of work)
• Preparing the system for a productive start (Deploying workstations. Training end users. Loading basic and variable data.)
• Productive start and support for a productive start (Additional loading of master and variable data. Operational support for end users. Closing the first periods)

The level of training of our company's specialists, their deep knowledge production processes and business management mechanisms, as well as the availability of our own implementation methodology, allows us to guarantee the rapid and high-quality implementation of SAP systems of various levels of complexity.

Why is the project divided into phases, and what principle is usually followed when splitting the project into phases?

In fact, everything is extremely simple, the first - according to the results of the phase, the implementation of the project is monitored, its management is carried out, and the second - it is convenient to link the terms of the contract to the phases: activation, payment schedule, etc. It is clear that each phase must end with a certain product, which can be considered, from the point of view of the parties, the subject of the contract or part of it.

Establishment of a project office

The first and usually the shortest phase of the project. Very often, its name introduces the customer into a "stupor". Once, when I had the honor to work in the internal team of a brave metallurgical enterprise, rather sarcastic questions were heard from the top management: “What, will they arrange chairs at this stage?”.

In fact, of course, in this case, not chairs or even tables are placed. The product of this phase of the project is actually the main project management documents: the order to start the project, the project charter, the detailed schedule, the risk management plan, the communication plan, etc.

Often the name of the phase is chosen by another, I personally like this one, because. really matches the content.

Survey

At this phase of the project, the contractor's consultants get acquainted with the processes at the enterprise that they have to automate, study the requirements. Communication between consultants and employees of the enterprise most often takes place in the form of an interview, after which the consultant prepares a report on the meeting. The report must be signed by all meeting participants. In the future, all reports on the conducted interviews are included in the report.

The best practice is to prepare a description of business processes in the form of diagrams in a CASE product. Such a diagram is called the As-Is Business Process Diagram (AS-IS). But, unfortunately, due to the high cost of software products, as well as low demand from the customer, this technology is very rarely used on projects. It’s a pity, because its use allows you to make various analytical conclusions about the state of business processes, optimize and, most importantly, in the future, when conceptually designing and building the “As It Should Be” (TO-BE) model, it allows you to make a comparative analysis, i.e. . allows you to predict the benefits of implementing an ERP system. The result of this phase is also often an updated terms of reference.

Concept Design (Model TO-BE)

The Conceptual Design phase should actually include the work carried out in the Survey phase, but in terms of project management, and especially budget and timing, I think it's better to separate them. The fact is that at the survey phase it may already become clear to the contractor the need for adjustment calendar plan and scope of work, the issue should be brought up for discussion and appropriate measures taken. If this is not done at this stage, then it is practically impossible to do it later (although in this case it is necessary to show miracles of diplomacy).

The conceptual design phase, in my opinion, is one of the most difficult phases of a project. Here, often, there are collisions between various structures of the enterprise, and, as a result, the contractor has to constantly look for a way out of this situation. Indeed, in the end, the success of the implementation of this particular phase will give impetus to the successful automation of business processes, taking into account the requirements put forward by the system. The document being developed at this stage of the project, the conceptual design, is the rule by which not only the system configuration, but also business processes will be built in the future. It's no secret that Information system- this is the business tool that allows you to make operational, tactical and strategic decisions, and also affects the work of units involved in the preparation of information.

Also, a certain difficulty during this phase is the correction for the creativity and creativity of the members. project team. When working on a conceptual project, additional consultations with business experts should be held, brainstorming sessions should be organized. Everything must be done to ensure that the system is maximally tailored to the requirements of the customer, and this is the main difficulty.

Implementation

The most understandable and, according to many (I think in a mistaken opinion), the most important phase of the project. In fact, with the correct construction of the conceptual model of business processes and the system, the phase of implementing settings and developments is reduced to purely technical work. The complexity and importance of this phase can be explained by the events that, as a rule, crown the phase - this is an integration test and a productive start of the system.

An integration test can take place according to different scenarios, but the meaning of this event is that the performer must prove to the customer that the system is working, as well as its adequacy in relation to the requirements. The topic is so complicated that in this article I will not go into it, we will talk about it later.

A productive start of the system is, in principle, exactly the milestone for which consulting works. In my experience, there have been various productive starts, and this is also a very complex and extensive topic. Let me just say that if a productive start happened, then the project was 90% successful.

Initial support

Warranty service of the system, there is nothing special to write here. A very difficult phase for the contractor and customer. Getting started in any system is accompanied by great difficulties and an abundance of errors on the part of users, and in the system itself, as a rule, there are quite a few bugs. And the difficulty lies largely in the fact that all of the above happens simultaneously in different people. Critical to the success of this phase and the project as a whole is the rejection of parallel accounting in the historical (old) system. After the rejection of parallel accounting and the closing of the accounting period, covering the entire range of automated operations, the project can be considered successful and completed.

Good afternoon, colleagues, readers, friends!

In this article, I will try to talk about some of the misconceptions that consultants and project managers face. These misconceptions can arise on the part of the management of the company where the system is being implemented, on the part of ordinary employees who will have to work in a new accounting system and even from the most consultants.

Introduction

I will not say unequivocally, but I think that almost every consultant / project manager / change manager who has sufficient experience implementations of ERP systems (here we may not necessarily talk about the SAP system), find in this article what he really encountered, and agree (perhaps partially) with my reasoning. All that I will describe is my personal design experience. And the classification presented by me below is nothing more than a convention. Someone may see and classify it in a completely different way. Ready for discussion in the comments to the article.

The topic of the material was born spontaneously in my head, during the discussion of some working moments on the project. The issue that we discussed concerned the development and automation of a methodology for planning some indicators. At the same time, in the course of the discussion of the issue, it turned out that the methodology itself does not yet exist. The question was something like this: we implemented an Enterprise Resource Planning (ERP) system. It costs a lot of millions of money. There is a bunch of different information that a thousand end users enter there. So why can't the company's management get the necessary plan/forecast from this very system?

Familiar? And from the point of view of the uninitiated, it is quite a logical question. Perhaps colleagues heard the same questions, but in a slightly different context, but I'm sure they were. And we come to the first misconception.

Misconception #1: The System Works for You or “Red Button Syndrome”

So, we are implementing a large and expensive ERP system at the Customer's place (for simplicity, let's assume that we are talking about the implementation of the SAP system, although, as I wrote above, my arguments also apply to other large ERP systems). Most of the company's employees, even if they are not directly involved in the implementation, have heard something somewhere. We heard about the cost of a license (that they are prohibitive), the cost of implementation, the salaries of consultants, etc. Employees of the Customer's company, who work directly with consultants on the implementation, also often do not understand until the very end how all this will work after a productive start. But they also have some idea of ​​the cost of implementation. All these people have every right to assume that the implementation of the system will allow many manual / routine operations to be performed automatically, i.e. the system will work for you.

This is how a stereotype is born. If the Contractor’s team has no idea about the birth of this stereotype, then at the time of a productive start, a situation arises when users are completely sincerely surprised that they have to enter such a large amount of information into the system every day. Users who participated in integration testing. Users who have been trained. Those. those people who, in theory, should be ready to work in the system, understand and accept it. Their surprise and misunderstanding can develop into rejection and rejection of changes, into outright rebellion.

There was such a case in my experience. When, after gaining practical experience in the system, after a productive start, an "opposition coalition" was formed in the company. This group of people deliberately accumulated all the negativity, all the punctures of consultants, all the limitations of the system’s functionality (and as you understand, the “functional limitations” of the SAP system, compared, for example, with 1C, may be the impossibility of deleting many data, the impossibility of “cleaning up the tails”) . Well, the “X” hour came, when all this tub of mud poured out on the implementation team, and was also provided to the business owner as the main argument in favor of returning to the old accounting system. In the end, everything ended well. And after some time, people who were the most ardent opponents of the new system, understood what its advantages were, changed their minds. BUT, if the project manager (on one side or another) would have recognized the problem in time and made the necessary clarifications, such protests and scandals could have been avoided.

I mentioned Red Button Syndrome. This is a kind of bike among fellow consultants. The point is the same. Each user, to one degree or another, wants the number of routine operations performed by him every day to be automatically performed in the system in some fantastic way. Those. the user logs in, and the system interface consists of one big red button. The user clicks on the button and the system itself performs all the necessary operations. And the user at this time drinks tea. Consulting folklore has transformed the red button into a red pedal. Why a pedal? Then, that then you can press with your foot, and both hands are free. One - you drink tea, the other - you play solitaire. J This is all, of course, a joke, but many users do not get tired of wondering how a system implemented for such money cannot “think a little for a person”.

Misconception No. 2: The implementation of the system will “offload” end users

In fact, fallacy #2 is a special (light) case of the first fallacy. But I have separated it into a separate section, because this misconception is encountered much more often. "Legs" grow from there. Comparison of the degree of steepness and cost of the old and new accounting systems gives users grounds for incorrect and unattached reflections and conclusions in practice. New system will allow me to partially automate, or somehow magically shift some of my functions to someone else.

In this case, we have two sides of the coin. Some part of the employees sleeps and sees how the system works for them (in whole or in part - see delusion No. 1). Another part of the company's employees look further and see this as a problem. After all, if the system now performs some of the functions itself, then the number of employees required to perform routine operations should be reduced. This problem can also lead to unpleasant consequences, even sabotage of the implementation by individual employees / departments of the company.

I want to describe another example from my experience. I don't know if it belongs to #1 or #2. He (example) in varying degrees, concerns both.

For a large company, one of the world's leading consulting firms, a separate cost accounting methodology was written. The requirements for the methodology were very strict. Elaboration of the provisions of the methodology and a high degree of detail of the final results of the distribution of costs for the Customer's company was very important. The second stage of the methodology development process was its automation, which was carried out using the SAP BW system. The methodology was automated, users were trained, and the quality of work was checked by the company that developed the methodology. The customer was completely satisfied with the results of the work. However, for the methodology to work in SAP BW, a fairly large amount of initial information was needed (as I already wrote, the Customer paid great attention cost allocation details). Part of the data was loaded from SAP ERP. Part of the data from application systems. Some were entered manually in MS Excel and loaded into BW using special formats. Special people were even allocated for this work. Everything seemed to be fine. However, after some time, employees began to leave the Customer's company, who were the main ideologists of the use of the developed methodology, took part in its development and acceptance. These were people who, among other things, understood the importance of preparing the necessary volume primary information to obtain the correct results of the final distribution. Further, after some more time, the Customer received requests to simplify the level of detail in the calculations. The main reason is too much initial data that needs to be prepared. The simplification was done in several iterations (again, as the requirements from the Customer come in). And in the end, a “stump” remained from the detailed analytical model, which showed some generalized data. There was no need to talk about the former degree of detail.

What I wanted to show with this example. The fact that a misunderstanding on the part of the Customer's company of the amount of work that must be performed by its employees leads to the loss of almost all the results of this large-scale and rather expensive work.

By the way, at the beginning of the article, I mentioned the situation when the Customer requires to provide some model (plan, forecast) from the system based on the available data. It's also a very common misconception. But I will not single it out separately. This also applies to fallacies #1 and #2 (or somewhere in between). The bottom line is that the management of the Customer's company or the owner of the business does not quite understand the differences between the algorithm and the initial data. Any model, forecast, technique, finally, consists of:

A. Some kind of algorithm expressed in clear and understandable mathematical/statistical formulas;

B. The list of information necessary to fill the model with data, and on which the future forecast will be based.

People, for some reason, believe that a system filled with data will itself produce necessary calculations and make predictions. This is not true.

How to avoid problems with these two (#1 and #2) misconceptions? It is necessary to systematically explain to people at all levels of the company (ordinary employees, lower and middle managers, top management) that the system is not a robot, not artificial intelligence. She cannot make decisions on her own, or perform operations that require some kind of analysis. The system is a tool that allows you to reflect the business processes, business operations and business steps of the company with different levels of depth and detail. How deeply and in detail the processes, operations and individual steps will be reflected in the system is decided during implementation. But be that as it may, most of the analytical information is entered into the system by people. Reports are based on this information. And the depth of elaboration of analytical, management reporting (we read, the very transparency of the business that companies that implement ERP systems strive for) depends on the quality and volume of the information entered.

Another important point which, in my opinion, should be communicated to end users at all levels. The system is not being implemented for the convenience of ordinary employees. The purpose of the system implementation: Obtaining clear, detailed and timely information about the current state of the company for the management of the company to make management decisions. To achieve this goal, the amount of information entered by end users may even increase compared to what was in the old accounting system.

Misconception #3: You can always “bend” the system for business

• I don’t remember where I saw this (somewhere on the Internet), but I remember the phrase very well: “…This has always been done like this and consultant should replicate it on SAP”, is the start of a big problem.

“…It has always worked this way, and the task of the consultant is to duplicate the process in the SAP system” - this is the beginning of a big problem.

The owner of a business, buying a system and paying for its implementation, wants to squeeze out of this system everything that the old one gave him, and much more from above. From the point of view of the principle “I pay, I order the music” this is more than reasonable. Again, given the cost and steepness of the system, the wrong impression is created that it can always be bent for business, “stretched” onto existing business processes without revision / revision