Transcription
Okay, everything, we are live. Hello everyone. Uh, colleagues, as is our tradition, yes, we will now literally, well, I don't know, let's wait a minute for everyone. Someone is still connecting, someone's notification hasn't arrived yet. We'll wait a little bit for everyone and then we'll start. Yes, good afternoon, Stanislav. So, well, let's start slowly, yes, because there is a lot of content. Anyway, I'll start with organizational matters. Anyone who missed something will be able to listen again, yes, because we will have a webinar recording. That's it. In general, if there are any problems with the sound, the easiest option is to reconnect. That's it. I hope everyone will have a stable connection today and there won't be any pauses. Let's address the most important questions, yes. So, the webinar recording will be available, you can listen to it again. If anything, if there are any questions, you can ask them. In the upper right corner, there is a "Questions" tab. Write them there, and my colleagues will put the questions that were asked during registration for the webinar there. Well, and accordingly, we will answer them at the end. That's it. If there are any questions that are really, well, questions where we will need to communicate in detail for a long time, we will move them to offline, that is, we will call, discuss all the moments, details, to provide a full answer. Okay. Uh, well, let's go. My name is Alexander Ashal. I am the head of RDV. With me today are my colleagues Ivan Arnoldov. He is the head of the operational and production accounting automation department. Vanya, hello. Colleagues, good afternoon. Yes, and Sasha Morozov, a functional architect. Sasha, hello. Hello everyone. What is our webinar plan? We will start a little bit about us. For those who don't know us, what we do, what we specialize in, then we will talk about the prerequisites for transitioning to ERP, why it is needed at all. Well, as it is, there is UPP, everything is fine. Why do people switch to it, who needs it at all? Then we will talk about the functional coverage map. This is a kind of architecture, yes? So, most often the question is asked: "What is actually in this ERP?" Like, yes? What can it give me when transitioning? Any new functionalities. And so we made this big map. What's in it. Then we will talk about the difficulties of transition. Well, some, yes, starting steps, so all sorts of details, nuances. We will discuss strategies for different enterprises. We decided to, uh, like, make super content, yes, even segment it, some scales of client businesses and what decisions they make, about transition options, even with possible budgets, yes, for these projects. Then we will talk about cases that we have already had regarding point five, yes, regarding all strategies. We will discuss the project methodology, including what important aspects to look at, that your suppliers offer, yes, and how to note important things for yourself in these plans, yes. Well, and we will talk, accordingly, about the next steps and answer all sorts of questions. About us, we have been on the market for 8 years, we have more than 130 full-time employees. We do all projects solely by ourselves. And in 2023, we won top five nominations for Project of the Year. This is the best transition project from UPP to ERP. We are among the top 500 companies according to TAdviser and in various Runet ratings we hold the number one position for various developments and integrations of corporate solutions, for working with marketplaces, and so on. We mainly work with the commercial sector. That's it. Many know us from the e-commerce and distribution sectors because we help many large companies work with marketplaces. These are our project clients, and our main focus and main clients are in the manufacturing, distribution, and e-commerce sectors, but we also have various other industries, but the focus is specifically on them. What do we do? So, in general, we adhere to our mission, yes, which is to support business growth and scaling for clients through digitalization, so-called digital platforms, which allow us to reduce various labor costs, speed up business processes, and increase their efficiency. What I wanted to tell you about, well, so-called, yes, probably the prerequisites. We all know that 1C wanted to withdraw UPP from support in April 2026, yes, accordingly, and everyone was prepared for the fact that by January 2026 everyone should have already, figuratively speaking, launched into pilot operation, yes, and started using the system. Many companies have actually already transitioned, and we have clients who have launched and are already working fully in ERP or ERP Enterprise Management. But very many large enterprises, yes, have not managed to do so. So many programs and projects take 3-5 years, there are huge enterprises, the largest taxpayers, yes, who simply haven't managed. And 1C postponed this deadline, but not just for nothing, they made a paid support package, and now we will be able to receive updates for UPP only if we have the so-called KP UPP Industry. So, you will need to buy this subscription and, accordingly, you can download new, regulated updates from your personal account. So, in general, today we will talk more about proper project planning, yes, so that we can account for all your customizations that have been made over 15 years, yes. Well, and we will talk a little about why it is important to initiate these projects in advance, yes, and not at the last moment. This is important both from the perspective of stress deadlines, yes, potential budget, considering various inflations. Today we will discuss both deadlines and costs. Let's talk about the prerequisites for transitioning, yes, to UPP. Vanya, tell us. Yes, of course, colleagues, let's talk. Well, the first thing, Alexander already said, is difficulty with submitting reports. Those who have various difficulties with regulated reporting due to the fact that there are no more updates, they need to invent something themselves or update themselves. In general, if these difficulties exist, then, of course, the client comes and says: "We want to switch to a new system." And when new standards come out, so now new FSBU often come out, you need to adhere to them. Well, and accordingly, all this needs to be customized in UPP yourself. And someone already says: "That's it, we're tired, let's switch, maybe to a new system." And when we adopt a new assembly methodology, for example, for management reporting, then many clients come and say, they say, we collect, I don't know, a month after closing the current period for management reporting, some even say cost, yes, we calculate it in Excel somewhere, some have it on the twentieth day. So many come and say, we want it to be collected on the fifth day, preliminary management reporting, and on the tenth day to collect the final one and give it to the owner. Well, for this, you can adopt a new methodology, change your processes. This is precisely what drives the transitions from UPP to ERP. Some come for business process reengineering, they want to introduce some new processes, I don't know, for example, from the latest production cost accounting, or calculation of production personnel workload, or switch to piece-rate wages, or some state orders. The organization comes, and this is also a driver for transitioning from UPP to ERP. Some are no longer satisfied with the functionality and constantly customize it. They say, we constantly come to the IT department to do something else, change something, they can't keep up anymore. Let's switch to ERP, it seems like this functionality is already there, ERP is constantly updated, new functions are released, new functionality, and you can already use it. There are clients who are sitting and choosing now whether to stay here and customize, or to take it, it seems like they have already published it, they looked at it, damn, we need exactly this. That's it. Well, and accordingly, the development stack of UPP is also quite old, an outdated platform. You need to find specialists who are willing to work with it, who will be interested in it. That's not so easy to do on the market. Everyone comes and says: "Damn, we want to work on a new platform, on a new development stack, new algorithms, we want to use all of this." And finding someone to support the old one is problematic. There is mandatory labeling. Now many goods are subject to labeling. And I think in the near future, most, almost all, will probably switch to labeling. There are also clients who came and said: "We need to label in UPP, labeling is in a year, but we are sitting and choosing." So, we will probably go to ERP, because UPP will do all this for us, change our entire process so that labeling appears in production. It's problematic to invent everything from scratch. That's it. Well, and in general, business development, when they want to transition, to take the first step towards digitalization, to start calculating their processes, how much time they take, where they can optimize, save, to see, they say, we spend a lot of time, let's reduce it here, by implementing a new system, they reduce it and can directly calculate how much time has been reduced, how much costs have been reduced, and after what time all the costs for our implementation will be recouped. We have prepared an ERP functional coverage map from our side. What Alexander said, well, using ERP Enterprise Management as an example. What blocks are there in this system? There are many different blocks for various, many different blocks. Sash, can you please pick it up? Tell us what we have selected here? Of course. Here is our functional coverage map. As Ivan said, this is a more extended map than ERP. This is specifically the functional coverage map of ERP plus Enterprise Management. Well, let's start from left to right. Operational accounting. What's interesting there? Well, in sales, the most interesting thing, perhaps, is managed shipments, when a manager can manage shipments for their order. And, for example, control the possibility of shipping orders. Overdue accounts receivable or unpaid advances on orders. Reservation. A wide functionality, in principle, reservation is done on the basis of 1sP, implemented. Reservation can now be performed not only for a specific order, but also for a line of business. If the company separates business by lines of business and needs to segregate inventory for them. Purchases of various purchase schemes. Purchases of goods by schemes, commodity paths, unscheduled deliveries. Mutual settlements. What do we have here? Here we have the ability to track overdue accounts receivable in detail by days of occurrence, as well as the terms of accounts payable. Warehouse. Here is a wide range of configuration options for the variability of the order-based document flow scheme in the warehouse. Depending on your business processes, you can configure the order-based document flow scheme in the warehouse in completely different ways without any system development. In ERP, a logistics block has appeared. We can use ERP functionality to plan transport, shipments, and cost calculation. The most interesting thing in cost calculation, perhaps, is that costs can now be attributed even to a specific production batch. The production block has been separately выделен from operational accounting, because, well, the functionality in the production block has been very widely developed in ERP. I will not dwell on things like reflecting production results in accounting. It's clear, it exists. The most interesting thing about the path 1C has taken in its 1C ERP system is building not just a system for reflecting production in accounting, but a system for managing production, at different levels, at the production dispatcher level, this is managing production orders, their priorities, execution deadlines. Then it's the inter-shop level, when each shop receives its tasks according to agreed production order plans and tracks the execution of these tasks at the shop level. And intra-shop management, operational planning is provided by the ERP system, and accordingly, operational production management, when you can print, generate either in electronic form or print shift-daily tasks for foremen, which will be executed. So, such digitalization of shift-daily tasks. At the same time, this still covers the capabilities for quality control of operations performed by the foreman, and wide capabilities for accounting and tracking of defects. Also, in the production block, the T&IR functionality is separately highlighted. Now, using ERP functionality, you can plan repairs in the repair schedule, create planned or create and manage urgent repair requests for equipment, as well as digitize things in repair such as defect lists. In addition to operational production accounting, a wide range of functionality has been added in terms of accounting, tax accounting, and financial accounting. Sasha will tell you about them now. Rashal, Sasha, it's your turn. Yes, I want to. Let's go, yes, further from left to right. We have the RASBU block. What's the most important thing here? Well, of course, regulated changes, yes, our legislative changes, but I would always divide them into two main tasks. The first is form support. So, everyone is fighting for this, to submit reporting from 1C, so to speak, regulatory reporting. It's clear that ERP supports this, but I consider this to be the simplest task, yes, although it is important. It's more complicated when legislative changes occur that require changes in production and operational processes, yes? This is what the guys were talking about, state orders, labeling, our favorite changes in VAT, changes in excise tax, this is when not just reporting forms change, but we rework all primary documents, yes, and to some extent even change all registers. And these are the most significant changes, yes, including in the updates that 1C releases and, accordingly, well, UPP itself will be hard to support such things. Further, as Vanya already mentioned, these are our new standards, yes, FSBU, which appear, various assistants. This is, for example, I don't know, an extended settlement scheme, which now more flexibly allows automatic advance settlement through order linking, yes. So, a more flexible methodology for this settlement allows us to live more easily, yes, in terms of settlements, recalculations, various VAT. Yes. And the various extended functionality of operational production accounting allows accountants to check and reflect all these operations faster, yes. But there is also a nuance. Yes, everyone knows, probably, I think everyone has already talked about it, about these offline postings. Don't be too scared. There will be a little unusual for the first 3 months. But in general, I'll say from the end, someone asks: "And they are only formed at the end of the month?" No. So, you can press the "post" button, say, every 5 minutes, 15 minutes, once an hour. So, there is no "once a month" there. They are just really done a bit offline. So, it is implied that this is not an accounting system, but a management system. Accordingly, our users, yes, are sales managers, procurement managers, logisticians, warehouse staff, yes, production personnel, various foremen. They enter all these primary operations, and we check and post them. Accordingly, the processes will change a bit. Let's move towards management functions and analyze the budgeting block. If we take UPP, we only had a budgetary operation, yes? And, accordingly, very limited functionality. You can even say that it didn't exist. Now, in ERP Enterprise Management and in ERP, there are separate budgeting blocks. In ERP, it's a bit simpler functionality, in Enterprise Management, there's a lot of various process-related things for large companies. What's the core? It's the ability to automate business planning. What is that? Budgets, of course, we are all used to. P&L, Balance Sheet, or some say, yes, Cash Flow, Profit and Loss, Balance Sheet. This is our, well, essentially, cost-based, yes, cost plan. Business planning is still working with natural indicators, yes, it's various economic models, it can be a detailed production plan, yes, in quantitative terms, it can be a pricing model or a revenue calculation, yes, it can be a forecast model for inventory, a demand forecast model. In general, we were given a very Excel-like constructor that has various formulas, dependent cells, coloring, like in Excel, but this is a well-developed methodology, yes, embedded in the system, with which you can organize the process, yes, and enter these models, and approve all budget forms, and subsequently collect our beloved P&L, Balance Sheet. So, in general, very extended functionality in the budgeting block. Regarding treasury, here we have a standard linear process. These are payment requests for all types of operations, yes, taking into account various specifics. These are mandatory approvals, payment registers, payment calendars, automatic creation of payment documents, bank exchanges, including direct bank exchange without this text file, yes, that we upload back and forth. We have an expanded block for foreign currency operations, currency control, various financial instruments have appeared. These are credit/debit management, various loans, borrowings, working with deposits. So, in general, it's even called that, yes, corporate treasury, payment factory. We separately highlight the financial controlling block. It's not directly highlighted as a standard block, yes, like a menu item, but a separate philosophy has appeared. So, if previously most companies in Russia controlled their limits at the cash flow level, yes, directly in treasury, then, I would say, international companies have brought a completely different approach. So, they don't understand this cash flow control. They believe it's too late when everything has already happened. What's the point of controlling it, as they don't do business like that? And two more control options have appeared. So, the first is procurement control, and the second is contract control. Procurement control is when, even before conducting a tender, we submitted a request for budget allocation. Only after that did our procurement department conduct a tender. We always compare it with the allocated budgets, yes, and accordingly, during contracting, we also check how it all matches with our P&L first and foremost. So, we control obligations. And many companies that implement financial controlling subsequently abandon cash flow limits, because, well, they get the most extensive automation at the procurement request level, yes, and precisely control various obligations, payment schedules. And they say: "Why? We have already agreed everything. At the procurement stage, and at the contract conclusion stage, accounting remains, that is, execution. Yes, some even say purely accounting. And people simplify approval processes, remove 10 approvers from payment requests. Treasury and an accountant remain, who checks, yes, precisely the details, the payment purpose, general financial control. Well, and accordingly, they ensure, yes, the outflow, yes, of funds from the company. Plus, it's always a very good tool for an extended payment calendar, yes, such a forecast, when we already have a complete schedule of obligations in the order, and we can create a forecast even when there are no applications or expected receipts. Management accounting, it has three methodological foundations here. The first, well, probably everyone knows it, is transactional. Some call it, some say simply by documents, some say translational. The meaning is simple. You have a parallel chart of accounts for management accounting with its own analytics, as financiers need. This chart of accounts can be equal to the Russian chart of accounts with some minor deviations, but the point is that every primary operation that is performed in RASBU is immediately reflected in management accounting. The second method is transformational reporting. Tabular, yes, this is when we pull tables from different sources, take something from the operational contour, something from production, something from RASBU, take 20 sources, put them on a line-item basis, yes, such fact collection of the budget, and accordingly, well, such an Excel-like, yes, fact collection. And there is also a third option. It is mainly used by large companies, especially divisional ones, with different types of activities. This is transformational on a separate chart of accounts. This is when, well, people with such SAP backgrounds, and they have many different operations, are still used to the chart of accounts, but they don't need these specific registrars, yes, primary documents, transactions. And it doesn't matter to them on what day it happened, they collapse all primary documents, take the period at the end of the month, and they get a cube, yes, a snapshot of postings. Some call it a snapshot of the trial balance, which they put on a separate chart of accounts and then perform all consolidated adjustments, corrections, eliminations, and so on. So, the main task is to reduce the system's performance, and to remove those multi-million transactions at the bottom, which, accordingly, they don't need for collection. In general, we have now reviewed the entire functional coverage map, yes? Let's move on to the issues of digital platforms. Who are they? What are they? Why are they? We talked about it, yes, UPP is an accounting system. Well, unfortunately, that's how it turned out. So, everyone wanted management, but it still turned out to be accounting. Why? Most often, the owner of the UPP system is the chief accountant. That's it. And, well, naturally, we have always built accounting processes, specifically reflecting the fact of economic activity. ERP advocates a slightly different approach. We have operational and production processes at the lower level, yes? The main task, as soon as we automate operational departments, that is, build a foundation, we increase transparency, yes, then we can directly influence various control tools, increase efficiency, debug business processes, remove bottlenecks, digitize some processes, yes, and people already understand that even production is not just, say, a production order, yes, output, yes, or some batch accounting. It's the real work of people in production, organization, yes, interaction of various departments, units, so that everyone works in a coordinated sequence. And the result of this management process is the reflection of the fact of economic activity. In ERP, the lower layer is the foundation, so if you have processed it correctly, it will be 70% of your project's success. We move up to level two. This is resource optimization and efficiency. What do we have here? This is essentially, well, compliance with legal requirements. This is compliance, if someone is indirectly related to international companies, receives some investments, this is IFRS reporting. Well, and of course, top management. What is management focused on? The main focus now is maximum analytical depth. Minimum discrepancy with regulated accounting. So, everyone is trying to align accounting policies, many even round off various reserves directly in RASBU. So, we are aligning completely. But the main task is to speed up, to collect it in an expanded form by the fifth day. Why? The faster it's collected, the faster it's given to top management, the faster we make the right decision, find the bottleneck. Therefore, the entire focus is on analytics. This allows us to optimize resources and efficiency. Probably, international companies have accustomed us to these deadlines. So, when we all switched from various SAP systems, international companies don't understand how we don't get management reports by the fifth day. So, for them, this is unacceptable. And accordingly, all IT and business processes, experienced people have started to rebuild them precisely for the fact that these deadlines can be very flexibly reduced. We move up even higher. So, we have collected all the facts. It's all detailed, great, controllable, transparent. Then digitalization begins, or data transformation of the organization. What is DataDve? In fact, the concept has existed for a long time, but in Russia it has come relatively recently, but especially in the world of 1C, it's about digitizing business. The meaning is simple. So, we manage companies not based on emotions, but based on numbers. And people, even sometimes top managers develop a dependency. When they start digitizing everything. The most popular, yes, examples are digitizing production, digitizing procurement, digitizing sales, logistics. So, they start measuring everything: loading percentage, defect percentage, percentage of shipments by one employee, number of orders, yes, how many, I don't know, sales can be made by one manager. So, they start digitizing everything, yes, and set goals. Let's become a digital company. As soon as a number appears, we start wanting to forecast it: "Let's improve something." We did this for 2 days, let's do it in 1 day. What needs to be done? And you start managing the company and making decisions based on these numbers. So, you develop some hypotheses, go and test them, look at the numbers, did it work or not? So, this is, well, an approach that is mainly used by large businesses, to the point that it even builds pre-calculation models of changes before these changes are actually implemented. So, that's why it's important for them. In total, we have various forecasting models. Well, and we move up, yes, here we have BI, analytics, various consolidated reporting. So, this is an important part for top management, to control that we are moving within the strategy we planned for, and everything is working out, yes? In total, from the bottom, we have the foundation, which is processes, and the upper two blocks are normalized data, methodology, yes, which allow us to build this digital transformation. Sash, tell us, what difficulties do companies encounter when transitioning to ERP? Yes, colleagues, well, let's look at these difficulties and understand the nature of their origin. But
The main problem, here we have looked at the ERP functional coverage map, at the pyramid, accordingly, of the goals that the company is currently setting for itself. And it becomes clear that, in principle, 1SP in relation to UPP is some kind of different software product with its own philosophy, with its own architecture, with its own understanding of business values in general. And based on this, the first problem arises – there is no such upgrade, that you can simply take and transfer everything from UPP to ERP and just start working with ERP. No, it is always indeed such a transition, implementation through the implementation of a new system. Well, because it is a fundamentally different solution. And there is, you know, so to speak, a moment that always sits in people's minds when transitioning to ERP, that let's just take the customizations, the developments that we have made in UPP at some point, transfer them to ERP, that is, in fact, go the way of making ERP a second UPP. That won't work. And those who offer you such a transition method, well, immediately, um, don't believe them. This is a dead-end path. It will be a completely failed transition project. So, this is the main problem. Further, well, there are such sub-problems, so to speak. First, as we already talked about today, UPP, no matter how hard they tried, was still a more accounting system than a management system. But nevertheless, businesses implemented UPP for themselves. UPP existed in companies and still exists today. Businesses tried to use UPP to its full potential and enrich it with some new capabilities. That is, to digitize business processes. This is what Alexander was talking about, including in the operational loop. And since the functionality of UPP was weak, therefore, over the years of its development in the company after implementation, the functionality of UPP was increased through development, and thereby, as I call it, deep digitalization of business was achieved through these customizations. We calculated that an average company accumulated approximately 14,000 hours of customizations over 10 years. For some, this figure may be slightly lower, for some it may be slightly higher. For super large companies, it is generally gigantic and scalable.
And, accordingly, the question always arises, but we did this, we did this for ourselves, and we need to transfer what we did over these years, what we developed, to ERP. Let's look at the second problem. Everyone always wants to transition to ERP in a short period of time with a reasonable budget. And then we conclude an agreement with you for the transition from UPP to ERP. we start consulting, that is, we study your processes, find some functional gaps, because, yes, ERP functionality is broad, but still something may be missing, something may be suboptimal, because therefore, well, customizations, functional gaps will surface. And by the time the transition deadline is approaching, the number of customization hours remaining is, well, on average, in our projects, it was 3.5 to 4 thousand hours of customizations. This figure, well, it doesn't match the figure of 14,000 hours in the cube. And then we face the reasonable question: how do we actually launch? Yes, what do we need to do to actually launch, to achieve our main goal? The solutions to this problem are as follows. Well, the first way, after all, the functionality of ERP was much richer than the functionality of UPP. And the customizations that were made in UPP are implemented using standard ERP methodologies, accordingly, in ERP itself. We always suggest using the methodology that is embedded in ERP. For example, as I gave one of the examples today. We don't want to ship orders to those who have overdue accounts receivable. Or if an order needs to be secured by an advance payment, and we haven't received the advance payment for the order, we also don't want to ship, right, such restrictions are often requested. In ERP, in UPP, I myself implemented such restrictions. In ERP, such restrictions are implemented. That's it. Minus some number of customization hours here, we reduced production. What has always been important here in production for production? This is the normalization of production costs, this is some kind of limitation, to limit production in terms of materials they will use. Well, based on the same norms. This is, accordingly, labor costs, product quality indicators, that is, indicators for scrap, indicators for returnable waste, which inevitably arise in any production. These are indicators, for example, of setup losses. And losses are always something that you want to reduce and track, in fact. And what, well, in UPP there was no such functionality at all to track all this. And some tried to develop it, some didn't. Well, for example, what was always done in UPP with scrap? An actual vs. planned material consumption analysis was done in production, and they looked: "Ah, here we have some excess consumption. Why did it arise? Because there was scrap. Well, and outside the system, they wrote official explanatory notes why this scrap occurred. In ERP, using the methodologies embedded in it, already without any customizations, without anything, just by looking at your processes, well, as we usually do, we conduct a process audit, we ask what improvements you want to get here, what metrics, for example, to collect for production accounting. And we say: "This is available in ERP, it can be done without customizations. It can be done like this. Normalization of production costs is done like this. Normalization of labor costs is done like this. That's it, just use the system, but most likely you will have to restructure your business processes to effectively use the ERP modules provided in this way. Or, for example, very frequent requests in production, right, no one is interested from the perspective of finished products, in finished products to see, if it's a multi-stage production, only the costs of the last stage in the form of semi-finished products and items that have been allocated to the last stage. Everyone wants to see in finished products, well, so to speak, through disassembly, the costs that arose at all levels. To achieve such an effect in UPP, it was necessary to spend a large amount of labor on solving this problem. In ERP, there are methodologies that allow, again, using standard functionality without any customizations, to obtain such an opportunity. That, in fact, is how you can, I gave examples, reduce this number of customization hours. Third, the cornerstone of any successful project is data quality. UPP has existed for many years in companies, 10-15 years, some even longer. And over these years, data has accumulated, and very rarely, in my experience, this data quality has been monitored. That is, non-normalized directories appeared. Well, the classic example is the nomenclature directory. Well, often there are always duplicate items, there are some service nomenclatures entered to solve some local tasks. So, in ERP, you need to transition with normalized data, therefore, when transitioning to ERP, you need to consider performing this normalization. We also, on our part, when we conduct consulting, have certain stages in projects for surveying reference and master data. We ask some questions based on our experience that allow us to identify this non-normalization. And, accordingly, we suggest ways and solutions to perform this normalization and optimize a particular directory, again, using the capabilities embedded in ERP. Fourth, yes, I call this point for myself that ERP is truly a capricious system, a capricious lady. Well, it's capricious about data, it wants everything to be neat, and it's also quite capricious about the processes that exist in the company, because, well, ERP is more about order than chaos. And, accordingly, when transitioning to ERP, you also need to think about this question. How do we prepare our business processes, make some changes, implement some control functions so that the processes for ERP are debugged, controlled, verifiable. Why is this important? Because if, well, there is non-normalized data, or some operations are carried out without control, without checks, then we will get to the point where we cannot close the month on time and submit reports.
The fifth point is purely human – it is stress, psychological resistance to transitioning to something new. Well, imagine your average employee who has worked in this UPP system for many years. For him, everything was familiar: the usual interface, the usual buttons, the usual processes, and the usual scenarios for handling some non-standard situations that can occur in one process or another. That is, it was a well-established workday when a person came and day after day, year after year, did the same thing, understanding everything perfectly and knowing how to do it. When we transition to ERP, a new interface, possible changes in processes, as I said, and, in principle, well, something new, right, and the person starts to feel stress. How will I do this? And what if this happens to me, how will I reflect it in the system, and so on and so forth. And, naturally, unpleasant things arise. What do we do here to minimize this stress? Well, first, we conduct training before the system launch, and user training for the operational loop, warehouse workers, foremen, buyers, sales managers, we conduct directly on-site. That is, our team goes to the site, to the enterprise, and conducts training there at people's workstations. Next, this is, naturally, documentary support, that is, instructions for working with the system are prepared. And this is not just a reference to ITS, but it is precisely an instruction for the process, for each process, that in such a process, step by step, you do 1, 2, 3 in the system. And the most important thing, when the launch date arrives, people must switch to ERP and perform their operations there. From a certain date. Our team goes, again, to the sites and is present with users on-site until, well, plus or minus, they start working stably in the system. They always thank us for this, we hear such words at launch, but if it weren't for you, we would have gotten completely lost here. Thank you very much. The sixth, also a very important point, is customer involvement in the project. That is, well, it's not enough to just buy the ERP box and say that's it, now we'll install this box, find some inconsistencies, the developers will quickly do it, and everything will be fine. Well, no, you need to prepare personnel for this transition in advance, even before signing any agreements, knowing that such a transition has been initiated in the company, gather people, explain to them why it is important for the company and why the company needs to switch to ERP. And, well, don't do it a month in advance, or there have even been situations when we arrived at the plant, and what, a new program is being implemented? No, that's not how it should be done. Everything needs to be done in advance. Further. And this involvement must be at all levels, from company management to warehouse workers, foremen, and so on. Perhaps, somewhere, it will be necessary to additionally motivate users to create this involvement for this transition. This, again, minimizes the level of stress, and, accordingly, creates a favorable environment for the transition. There are different options for transitioning to ERP. Ivan will tell you about them now. Ivan, it's your turn. Yes, Sasha, thank you. Let's talk about it. We have prepared different options here. We see two options in general. Each has its own sub-options. The first option, so-called Big Bang, we can call it, when everything is prepared, prepared over some period of time, and all users log in on one date. As a rule, on January 1st, January 9th, 10th, they come to work, close the old system, log into the new one, and everyone starts working here at once. They don't return to the old one, it's forgotten, closed, and so on. Such an option is possible, but as Alexander said earlier, and I also said, we get a lot of stress. Users log in, it's all new to them, something wasn't finished, something might have been tested, something they remembered, they say: "Ah, I forgot, I have this, what should I do in this situation?" And so on, and so on. In general, the stress is gigantic. And, according to our experience, in many projects, it happens that employees have to come in on a weekend to finish some of their things or stay late. In general, for the first time, it will indeed be difficult, but everything is solvable within a month or two. For some, three. Everything returns to normal. People get used to the system, everything stabilizes, and then it works as it works.
There is no integration of the system, it is forgotten and that's it. Well, and the second option is a kind of modular transition, when we, yes, work everything out, but launch only, for example, the financial module. That is, the financiers, accountants log in, work from the new year. All the rest work as before in the old system. For this, well, the entire business remains there, they don't stress, calmly, gradually test further, and then departments gradually switch. In this case, integration with the old system, with the historical UPP, appears. We develop this integration, data goes back and forth, financiers check what was done in the old system, how it all came into the new one, whether it was entered correctly. That is, they stabilize, reconcile all these issues. In this case, there will be a load, yes, but only on the financial service. They will need to look at two systems and work for some time to check everything. After they are convinced that everything is going correctly, they calmly work in one system. Well, when needed, they go and check what's wrong in the old one, and the rest gradually start logging in here. That is, this is a softer transition, there is no stress for the business, when, I don't know, 500,000 or more users, that is, when there are many different systems, it is a perfectly viable option. The first, natural option, is faster, cheaper, but with more risks, more stress, more administrative personnel involvement is needed. The second option is longer, more expensive, but the risks are significantly lower here, because the business can always, well, I'll finish something here, finalize something in the old one, well, it will come into the new one through integration, and that's good.
So, how to choose between these two options? We have identified three indicators for ourselves, so to speak. First, the start date, when the project is ready to start at all. Second, the company's turnover, well, the size of the company and how complex your business processes are. That is, whether everyone can quickly switch to the new system, or if it requires long, persistent effort and some integration, and so on. Well, and, accordingly, the project budget, how much are you willing to allocate for this whole story? Because integration, of course, is cool, it's safe, meaning it's not so risky, but at the same time, you need to allocate money for it, work for six months, a year, as soon as everyone else switches, well, figuratively speaking, throw it away. You need to spend some budget on this. Let's break down the sub-options of each of the options. Let's start with the first option, when everyone switched to the new system at once. That is, the table is large, we will send it. After that, you can review everything in detail, read each one, study it, but in brief. So, the first option is when we are ready, I don't know, approximately, now it's mid-August, well, some time to spend on project initiation and start a new project somewhere in November. This is also for companies, so to speak, statistically around up to 10 billion. So, for companies of this size, this option can be applied. Launch date, well, January 1, 2027. There is the current year and, well, 2 months of the current year and the entire next year for system development. That is, fundamental implementation, we work out everything. The business has time for verification, for document approval, for system testing. There is time for the implementation of necessary and sufficient customizations. So, the risks in this case are minimal. We write all the necessary project documentation. The business manages to approve it. So, well, everything is good here, everything happens. There are, yes, its own disadvantages, that the project duration is long, and during this time, first, the current system changes, the market changes, some new business wishes appear, new processes, all this needs to be taken into account in the old system, and also brought into the new implementation. And the risks of legislative changes, of course, are also not removed. Something changes, it needs to be taken into account and updated before launch, and so on.
The second option is a mid-year transition. That is, here we get a faster result, you can start from July. That is, we have projects where people actually started in mid-year, are working, and everything is fine. So, we choose this as a kind of indicator. Well, who is ready to start the project a little earlier, from October, so that there is more time left. Company turnover, well, average up to 5 billion, also. Well, plus or minus statistical data. And the most important thing is the ability to submit regulated reports from Excel, because you will have to collect half a year in one system and half a year in the new system. I repeat, we have experience, everything is fine, it's collected and submitted, so there are no special issues here. We transition to mid-year, for ERP with the necessary set of customizations, a little less, because there is little time, and the business is already starting to stress, because they need to be pushed. Let's agree faster. There is no time for warming up. Let's agree on documents faster. Perhaps, even if the business takes a long time to approve some documentation, we start writing a little simpler so as not to delay approval. Smile in the system. Well, and here's a brief document. Let's look, approve, let's start doing it. But at the same time, we get a fast transition to the new system. The project takes less time, we get results quickly. Stress appears at launch, as the business starts to push during the project. The business starts to push at launch. They say: "Let's finish it." They say: "I didn't make it." Well, it's okay, the Olympics have started, you can't leave anymore. That's it, let's go to the new system, the old one is turned off. So, the risks are higher operationally, we need to involve administrative personnel, monitor all this.
And the third option, well, it's for those who, I don't know, are not very large, turnover up to 2 billion, who are ready to start the project in 2 weeks, figuratively speaking, so that by autumn and then, 2 months of winter, even a month of winter, to launch. Well, and those who have a more or less standard UPP, maybe some customizations, but most importantly, the processes are not very complex, so that they can be quickly transferred, and switch from January 12, 2026. A quick transition in minimal terms, but the process, we keep the current ones, we don't reorganize anything, there is no time to change significantly. We rely on the most standard system. So the business gets quick results. From January, they start using the new system and start developing it, adding or organizing their processes, changing it in 2026 with confidence. Here, perhaps, the most stressful launch, well, again, it depends on the size of the company. For small ones, everything can be worked out, there will be no stress. But on average, there is a stressful launch, high operational risks. And you need to start this project as soon as possible, for those who want to make it by 2026. And, plus or minus, the project budget, it is also statistical, but it is like a fork, a figure that you can roughly orient yourself by. Of course, each project needs to be calculated individually, but roughly you can look at the first option, launch in 2027, a budget of 50-100 million for such a project. The second option, 20-50. And the third, the fastest option to launch in 2026, from seven to twenty, depending on the company's turnover. Approximately so.
Let's see what the architecture will be in the case of a Big Bang. Sasha, will you help me here, will you tell me? Yes. Well, the architecture here is very simple. There was UPP, now it's ERP, all users logged into ERP on the same date, started working there, reflecting their operations. These are operational loop users, warehouse workers, production workers, managers, accounting, and finance. And around ERP, if necessary, some service systems spin. But it's always, as a rule, one of the integrated systems, where HR accounting, payroll. If there is a process for approving internal documents, contracts, 1C Document Management for customer relationship management, CRM, for example, some BTRC. If the company has its own B2B portal where customer orders are accepted, then, accordingly, a B2B portal and BI for generating reports, dashboards. All of them interact with 1SP. Sasha, what other transition option is there? Let me tell you. Yes, the most, perhaps, that business wants, because they always say, right, fewer risks, less stress. Let's break down the modular transition. We divided companies into up to 50 billion and after 50 billion, but this is deliberate, because the approaches are fundamentally very different. That is, up to 50 billion, they are still, in principle, ready to enter a monolith, let's call it that, into a monolithic architecture, but in stages, modularly. And they want a single system. That is, most often, it's not about divisional structures, it's, say, not about three legal entities, two main ones, one sales one, there are intra-group transactions, but in general, the company worked in a single UPP database, and everything was fine with them, but their projects are often 2 years or more. Accordingly, the business says: "Listen, 2 years, various crises, some 3 years, can we get results step by step?" That is, we don't want to do it on a single date, in short, this big bang in 3 years, who knows what. Let's cut our project into pieces. Accordingly, in the first option, when we look, right, at July 2026, for example, what they most often do is take the financial loop, and, accordingly, integrate it with the historical UPP. The task here is very simple, that is, people are trying to de-risk these updates, they are already trying to launch some new methodology, a new accounting policy, but their operational departments, that is, the entire operational loop plus production, plus all their know-how, industry solutions, they leave them in UPP for now. And for these companies, well, in principle, this investment in integration is considered acceptable. That is, it's not like, you know, trying to save money. That is, they understand that I will invest, say, 15-20 million in integration development, and then over the next year or two, I will continue my digitalization, and I will use these corporate buses for other integration solutions. For them, integration is a normal investment in IT technologies. But those who choose the Big Bang have a slightly different mindset. They say: "We'd rather spend 20-25 million on functionality." And this eternal scale, right, which sways, whether to invest in IT integration technologies or to invest more in functionality.
Accordingly, if we take companies with more than 50 billion, the Big Bang is generally impossible for them. There are often divisional structures, different types of activities, different businesses. They can be completely decentralized, local management, with their own administrations, and a separate management company. They generally don't have Big Bangs. There is always a very meticulous, long, phased transition, always modular, but also most often they start with the foundation, with the financial function, and then gradually build up. By budgets. Here, there is a certain starting cost. Well, now, of course, the indicative cost is from seventy. The meaning here is simple, right, from the Big Bang plus integration. Here we have a range. And then there are large companies. There is no point in even writing how much, right, because there are companies that, yes, can spend 120 million, some 200, around 300, half a billion, a billion, that is, depending on the scale of their digitalization project.
Let's break down the architectures, how it looks. The first modular option is when we have left the operational activities in UPP, right, but we have ERP or PPU on the side, which is responsible for the financial function. Here, we essentially have, well, the entire buying and selling, production, and initial cost, right, so the entire operational activity remained in UPP. In finance, we have fully tested all processes, launched the distribution, and are living happily, but there is a certain attachment, which many companies dislike. I want to change, for example, even accounting processes, but I am very tied to the UPP architecture, and there is simply no such analytics, no such rules, no such accounting principles, and you can never achieve a complete transformation because you are tied to this historical past. This is another driver when they say: "No, we don't need this integration, it's an extra reconciliation hassle." Let's just build the functionality in a single database right away. Invest all the money in the functional part and, accordingly, switch to extended support. Well, and, собственно, large business. How does it look here?
Ah, well, some call it a zoo, but what's the point here? And we, you and I, the operational lower level is most often accompanied by various industry-specific solutions. That is, we made such a picture, right, when there are standard ERP blocks, let's call them that, right, but business always lacks this. That is, in principle, large businesses either rewrite everything for themselves, as it were, or implement industry-specific solutions, right. PNC is our MDM, sales is the server, warehouses are implemented by everyone in MS various, right, equipment. Production can be even more mesolevel integration with various SCADA, right, there were resource specifications, they implement various PDM systems, right, for procurement, I don't know, some MRP systems, SRM systems, right, that is, which allow expanding the functionality. And further, you see, for each functionality, we have another bunch of systems. Then we moved higher. In principle, there are the same ERPs there, but there is a specificity, namely, that it may not always be one database. That is, it may be that for each division there will be its own database. And like, and that's normal. That is, due to the fact that there are different types of activities, not everyone needs to be crammed into a single system, as it were, right, and live only this way. That is, there are normal stories when you have such divisional automation, right, you take into account more specifics in this division. Above us, we always have various integration modules. Most often, there are either corporate buses, or these various message brokers that we use, right, it's RabbitMQ and all sorts of APIs. Well, and above us is the ABI holding. There, we are already building centralized processes, right, this is what we talked about, business planning, budgeting, corporate reporting, management, consolidation, right, some centralized functions. That's it. And, accordingly, the modularity here is that, ah, you take this part of the financial function, right, first, ah, you build it up, then you gradually start to transfer each of these blocks of modules, as I call it, right, vertical automation, to the target solution. And due to these integration buses, you load data in two directions: both into the historical system and into the new one. That is, such a double exchange. And due to these integrations, business gradually transitions. As for cases, that is, who chose what, let's figure it out. Uh, well, we'll talk about our projects as they are. Here we have Velomotors, we talked about it at the last webinar, it was chosen as project of the year, the best project of transition from UPP to ERP. We also discussed it for a long time, but their situation is very simple, actually. They just didn't like UPP at all, it happens. That is, it's when they customized so much that they broke everything. Well. Accordingly, the question of preserving the historical system was not raised. All budgets were allocated to new digital processes. Accordingly, ERP was launched, as it were, from the beginning of the year in MVP version, then developed in stages. We supported the client fully throughout the entire stage of submitting his regulated management reporting, all his changes in business processes. That is, everything is fine, we launched. Next, literally, we can't talk about it yet, there's no feedback yet. We have just launched two large car repair plants in the twenty-fifth year, from the new year. Also, UPP is very heavily customized, a lot of know-how. Like, they also chose, the client considered a modular transition, and it just fit these options by turnover volume. But then the general director said: "Listen, no, ah, I wanted, when implementing UPP, I wanted a management system, but I got an accounting system." Let's do it differently. Let's start with my production, right, with repairs, with supply, as it were, build a management system and put the accounting system on top of it. And he then, we already practically entered the project through a modular transition. Then he says: "No, we're doing a monolith, I need a management system, I don't want to be tied to the historical accounting past." And they actually launched from the new year. Quite a complex project, considering the number of personnel and customizations, but we launched with a big bang and, accordingly, submitted all the necessary reporting, stabilized the system, the company is working. Next, the third project, it's the company Wienerberger. They worked on SAP, and, accordingly, they didn't have a question of deadlines at all. They themselves said: "Guys, we have no options, they will disconnect us, as it were, let's switch." Accordingly, from the middle of the year, from July, the client joined, we submitted reports with Excel. In principle, people are used to it, they asked for help with exports, right, with various consultations, to support them during this, and everything worked out. That is, we built the system as they needed, taking into account even those developments and customizations that the parent company from abroad did not give them. Well, and on modular transitions. The first option is how we considered it, right, when you have different divisions and even to the point that you have four UPP databases, each developing in its own way, and you have some separate systems for MTO, for treasury, for document flow with various contracts, right, separately you have a system for budgeting, business planning, and you need to make this transition, right, this is one of those companies that actually connected its four UPP databases into a single ERP in terms of the regulatory contour. This was the first such fundamental project, right, for consolidating and unifying the accounting policies of all enterprises, and then in ERP, the functionality began to grow. That is, both through industry-specific solutions, such as, for example, Tair, right, various custom developments, and through migration from historical systems, treasury processes, procurement, and so on. That is, such a large transformation project. And Elcom Elra is one of the large distributors of electrical engineering goods. They had a system written from scratch for trading, I don't know, I think more than 100,000 man-hours, probably, are invested in it. And there is, of course, huge specificity for the client. He loads day by day or the next day. Accordingly, for him, the issue of business downtime or some stressful transitions is out of the question. That is, the business must run like clockwork. There can even be such cases, right, when, if something is wrong, you can accidentally create a traffic jam on the approach and, as it were, stop some, say, highway. Right. And if even the slightest failure occurs. Therefore, all issues were resolved here through integration of two-way exchanges, so that the client could gradually migrate to ERP and transfer all his business functions. That is, being at the stage when they had already hit a wall in development, both in terms of performance, right, and functionality, the client made such a strategic decision to move to ERP with a focus on scaling, and the historical system could no longer do that. And here, thanks to integration, everything went successfully. As for project methodology, what I wanted to talk about? I tried, well, we came up with it, we thought for a long time how to depict it, we showed it in the form of a bridge. That is, we have two banks and the bridge itself, right? Here is one side of the bank, which is most often lost - this is, well, IT consulting and methodology development. Rarely does a partner say: "Let's develop a methodology, we'll write a target chart of accounts, a journal of economic operations, we'll understand your processes, formalize them somehow, right, offer you unification, optimization." Well, you will very rarely hear such words in the market, but the point is that this is the foundation, right, of digital transformation itself. And as a first step, you need to invest there, not immediately go into conditional modeling, right, перекладывать, look at some different buttons, how they are arranged in the system. It is clear that it is an important stage to look at the system, but most often everyone is interested in only one thing: how will my target system function, what processes in the company do I need to change, what is the difference from my current state to the future. And mainly, business is interested in its internal reorganization, changes in organizational structures, right, various types of such IT projects. It is clear that after consulting and methodology, we will look at all these system buttons, figure them out, go into development, optimize all the functionality, do all the necessary customizations, right, and then we will start with the questions of preparing for the launch. A very important part, which is also important to pay attention to. What does it consist of? First, I don't know why, but the market somehow always avoids the topic of working with data. Well, it's about normalization. But the most interesting thing is that if you, in principle, well, as it were, say that this is solely the responsibility of the customer, then the problems in projects are always the same. You have the first 2 months of a very bad launch with a constantly unclosed month. Accordingly, the business itself cannot understand this volume of normalization and allocate a working group, right, and most often in 90 percent of cases, it cannot cope alone. We understand this, we don't quite understand how it's possible not to do this. And we have a separate stream for working with data. That is, we, essentially, from the very start of the project, when we have defined the entire target model, we begin to delve into normalization processes separately, so that by the launch, we have a more stable state than if we just loaded some garbage from Excel, right, and then can't close the month. Training, documentation. What is important here? There are different camps. Mostly, well, we are still under budget, right, everyone tries to approach it somehow, but what is important here? First, it is to visit the sites, especially if you are launching production, it is imperative to visit the sites, to support employees there, it is a difficult time for them, to answer all questions, at least to be there for the first 2 weeks, as it were, right, to stabilize the enterprise, to launch, so that the factory, as it were, does not stop. And it is important, if you start letting operational personnel into the system, to make instructions correctly for them. That is, it is clear that there are standard operations that can be viewed through ITS, right, some kind of, I don't know, standard postings, right, accounting, very simple blocks, but operational personnel and all complex blocks should be documented specifically in terms of roles, so that people understand what they need to do. Well, and the launch itself. Here we launch, we often encounter in the market, we launch the factory in the first month, and then support will begin. And everyone sits and thinks: "What is the result?" Well, that is, we don't just want to launch the factory, we also have regulated management reporting, and we want the system to be stable, right, stabilized. And it is very important, as it were, to understand that the result of launching ERP is, at least, with the submission of regulated management reporting. Why is this important? To launch a factory in some state within a month. Well, that's clear, that's an operational process. Then, the second month you will struggle with normalization. Well, that's a classic story, right? The first time you calculate the cost, the first time you try to close the period, you will find all possible errors. In March, you will really only understand how it all works, and in April you will already need to submit regulatory reporting. So that this layer of problems does not wash anyone away or lead to deep stress, depression, or night work, it is advisable to plan the project so that our final deadline, if you are launching from the beginning of the year, right, April 25th, so that we submit this excellent reporting together with you and you sleep peacefully. What else is important? If you pay attention to the bridge itself, then performance is our foundation. And here you don't need to forget about it. When your enterprise is planned for 300 users or you have, I don't know, you can even say it like this, right, then, well, let's say 5 billion, be sure to look at it. Comfort of work within ERP is very important. The same servers, the same as, say, for UPP, will not work. So modernization is still needed. Therefore, there should be a partner who will come and tell the system administrator, right, how it should be. Someone who can optimize, if necessary, the work of, say, PostgreSQL, right, with Linux, so that all DBMS queries are optimal. Someone who can optimize 1C code, who specializes in this performance optimization, right, and someone who understands the methodology. Because it often happens that business requests various customizations, which can then lead to performance problems. We cover all these tasks comprehensively, all four pillars, so that the system works stably and quickly. And we do this long before the launch, so that you don't even notice that something has changed in the area of performance optimization. In general, this is such a project. Consider this when requesting a commercial offer, what they send you, ask questions, even if you don't understand something that seems obvious, because it is important so that you have less stress later and the launch is successful. What else is important? A partner who has a project methodology, that is, he can provide all sorts of charters, templates of project documents, how he does it, what he describes. Meet, ask, let them show, send some document templates. Like, this is all important. That is, so that you are convinced, because at the top level, the prices will have huge spreads, you will have to delve at least to the level of stage minus one, that is, to the blocks of work types. It is important, accordingly, that the contractor has systems for managing the project. That is, both task control, and documentation control, and service desk systems, so that the launch goes smoothly, right. Look at how much, well, let's say, so that he is not, right, the cobbler without shoes telling how to live correctly, and he himself has a mess inside. Well, accordingly, all his standards can be easily checked by simply asking the question: "Guys, show me how you manage the project, what do you have with the system, document templates, and what will you surprise us with?" You can say it like that. Ah, well, and let's talk about the next steps, right, that is, what's next? What is our approach? We actually invest a lot in pre-sales in express analysis. Why? Well, we made a decision for ourselves that we immediately develop a detailed plan. Someone says: "Guys, buy an assessment from us, we'll study you." as it were, right, after that we'll give you a roadmap. That's okay when it's a large business, but in general, no one wants to invest time now, right, money, as it were, right, from each contractor. Everyone wants an assessment. There are very good stages of express analysis here, when you can tell us about your current situation, about your current processes, and we, accordingly, will create this digital transformation architecture for you at a high level, right, a roadmap. how best to do it, taking into account your budget, budget specifics, deadlines. Well, and, in fact, the detailed work plan itself, which would take into account the transfer of all your know-how, the necessary set of documents, the necessary volume of support, performance, and so on. That is, this is a very detailed plan that will immerse you in this world of 1C, related to ERP implementation. A small survey now my colleagues will launch. For those interested, right, free express analysis or want to get a presentation, just some consultation, right, get, maybe we didn't answer some questions today, and we will gladly call you offline, right, and answer all questions, provide information. Let's just wait a minute and move on. So, while the counter is ticking, what's next? Next, actually, it will be surveys and questions, we'll go look now. We didn't quite make it. A little bit, by 20 minutes. That's it. But I also, actually, accelerated a lot. Well, of course, if you delve into the details, then everything is much more complicated. And many different questions arise. Therefore, yes, offline, I think we'll talk more, discuss all these questions. Let's go to questions. Yes, let's go to questions. Question from Elena. Management and accounting in ERP, features and options. So, well, let's figure it out. Now it will be very complex to answer. That is, there is ERP, there is ERP-Holding. Also important things, right, to consider. ERP is consulting. Well, like, there are separate charts of accounts, there is simple budgeting functionality, but in principle, you can also make plans, and all sorts of analysis of actuals. The specificity is mainly how they choose. That is, if it's ERP, then the focus is more on accounting. If you need extended treasury, extended budgeting, management with all sorts of consolidations, eliminations, right, various parallel blocks, some fixed assets, reserves, and financial instruments, then you go towards ERP-Holding, right, that is, full functionality. Like, the peculiarity of working in ERP is very simple, that is, people align all their accounting policies, essentially in regulatory and operational accounting, they maintain exactly what they need for management accounting. ERPs that do not have a large management specificity, and they are quite satisfied with tabular simple transformation reporting, which they collect from a single database, right, from ERP, from operational accounting data. Those who have slightly larger enterprises, VGO, more complex processes, these various financial controls, extended treasuries, management with separate charts of accounts, or this business planning, right, various forms. Then people go towards holding management, there, accordingly, the functionality is greater and various approvals, and so on. Well, I think I've answered. If there are any more questions, we'll answer them offline. Is it possible to combine management accounting with accounting plus tax on the basis of ERP? What problems can arise? Hmm, well, we generally talked about it, ah, while it was going on. Listen, well, you see, here it's more about problems. Usually, the finance director can't agree with the chief accountant. That's probably how I would put it. Because, well, probably in simple enterprises there are no problems. That is, there are none, no problems arise. Like, if I tell you, for example, that you set yourself the goal of management reporting by the fifth of the month with your closing schedule, right, and you, for example, use, I don't know, fast close with period fixation, right, that is, when by the fifth of the month a snapshot of data is already fixed, after which you open RSBU, accounting makes changes to the previous period, it falls into the first day of the open period, right? That is, when the data in the past does not change, oops, this is already ERP. That is, this is where complex methodology begins, as it were, when some of your own exchange rate differences appear, when exchange rates appear, including currency exchange rates, when various reserve accounting appears, or, for example, the fixed assets block is fully maintained in parallel accounting, right, with different useful lives. You have complex intra-group turnovers with markup elimination. If you have some of these words, then here, as it were, on the basis of standard ERP, you will hit a wall because you will lack this functionality, because you will not be able to implement it in operational accounting, but it is needed for management. Well, and, accordingly, you will not be able to shorten the closing periods to isolate this contour separately. That's it. But generally, the specificity can also be if you have some international companies that you also want to consolidate within ERP. Here, too, ERP Holding Management comes into play, which will help with this. ERP will be a problem. Oh, what an interesting question. Approaches, methods for calculating the economic effect of transitioning to ERP. Ah, let's, ah, figure it out, right. Ah, first, well, that is, ah, there is a recent article I wrote for T Advisors, right, specifically about transition specifics, typical mistakes as a transformation method. That is, there are projects of the year, I collected statistics from these projects of the year, which clients signed. That is, what is the economic effect for these enterprises as a result of the transition, right, there are general figures. I actually considered how these figures are achieved, but in general, everything starts with the fact that you need to measure the current, because, well, most often those who ask the question, what is the economic effect, you first need to look at the current figures, at the current analytics, understand the current problem. That is, how we first delved into it, turned this story into numbers, identified the problems. After that, you can offer optimization tools, that is, calculate this economic effect. What usually happens? Yes. Let me try to explain it this way. Someone says: "We have stagnation in profit, or some decrease, or, I don't know, we are not meeting the plan," you start to delve into the details of business processes, you see that they lack information about where all these expenses came from. It starts. Let's implement the breakdown of production costs. Hopp, we broke it down to micro-parts, right? That is, where all the money went, let's call it that, right? Or someone says: "We have a fixed salary payment system in production, and we can't implement piecework because, well, there is no system, right, for standardization, someone tries to do it on paper." You come and say: "Okay, let's make norms." Stages of extended production process management. Let's create an internal production timesheet, on the basis of which, right, we will increase production efficiency, right, accordingly, thereby reducing costs and various defects. Hopp, you already have a measurable indicator. 5,000 employees worked, we paid them this much. Now, hopp, we increased production efficiency. Supply processes, right, this is our, if you saw various statistics, analytics, right, then the most common problem is overstocking the warehouse. That is, when we have a lot of illiquid assets, we buy in reserve, because we don't have close interaction, right, this end-to-end planning. That is, we don't understand who sells what, who produces, how much needs to be bought. And we start, as it were, stocking warehouses in reserve. What if there are sanctions, we won't make it in time. Here you start to build more extended production chains to understand by what deadlines you need to buy something. Extended workplaces appear, there are already, accordingly, clear plans always in an up-to-date form, right, and you can adjust your supply system accordingly. To identify these economic effects, in short, you need to conduct an audit of current processes, understand where the problems are, and then the guys will help you determine the economic effect, by what means you can improve. Well, and you will turn this into numbers during the project. So, how much, in what is the difference between 1C Corp and ERP? Very simple. Corp is a so-called bundle, which includes, actually, four, well, let's call it that, right, there, corp, corporation, that is, it's just a bundle of existing software products, where you can have ERP, holding management, ZUP, document management. And, like, there is no significant difference in functionality. It's just a package, a software purchase, with which you get a small discount by buying more solutions at once. That's it. Well, I hope 1C Corp is about that, and not about accounting. About corporation, apparently, right, the speech. Yes, it's just that one of the corps is called accounting, so it's also included in the package, right. A package with packages. In general, it seems we have answered the main questions, colleagues. If there are any more, you can write to us by email, right, or, like, right, contact us, leave a request, accordingly, some additional consultations, questions, right, including on methods of calculating economic effect or some very deep specifics of your enterprise. The guys will tell you at an offline meeting, just share with them the current problems you have, and they will tell you how other clients have solved them. And in general, right, for now, they will tell you about ERP, how it will help you in your future work. We are finishing today. That's it. Thank you to everyone who listened to us, who connected today. We will be glad to see you offline, and also at the upcoming ERP forum, which will be held on November 20th. Come, register. Thank you all. Have a good evening. Thank you. Goodbye. We hope everything was useful and interesting. Goodbye.