Do you need consulting for a 1C:ERP implementation?

At a certain point in its growth and development, a company needs clear methodologies for its business processes. For example, to make fast and sound decisions, a CEO needs to introduce management accounting: structure the process, build a system of positions, define responsibilities, and so on. This can be done in-house, but experimenting and losing time and money on it makes no sense — after a couple of such experiments, the company may have to close. The company usually has no suitable specialist on staff. It is more effective to turn to professionals who will get it right the first time.

Consulting firms develop policies, for example, an accounting policy or a budgeting methodology — in other words, how the company should operate. Systems integrators should then implement these policies in the software that is already in place or being implemented.

This approach has a major drawback: consulting firms do not know the system in which the methodologies they develop will be automated. An IT system often already has a built-in framework for the business process architecture.

For example, a company runs 1C:ERP Enterprise Management, and a separate consulting firm may develop a methodology that simply cannot be implemented in that IT system. The existing software then has to be rewritten and customized. You could invest RUB 1 billion (≈ $10 million) in it, and maybe in 10 years something will come of it — or maybe not.

The ideal option is when the systems integrator and the client work together to develop the methodology and the 1C:ERP modules. That way, the methodology can be tied to what actually exists.

You definitely need consulting if:

- you have no methodology for the company’s business processes

- you have no accounting policies for each department

- it all lives in employees’ heads rather than “on paper”

We provide this kind of consulting as part of turnkey end-to-end automation.

We design the business architecture, build process models, and, where possible, adjust flexible processes to optimize business processes as much as possible, keeping customizations to what is truly necessary. After all, every customization means millions spent on development, updates, and system support.

On our projects, 70% of the work is done by analysts and functional architects. This stage is the most difficult and time-consuming. Here is how it works:

We study the company’s source documents in detail

We examine all business processes. “Hidden” processes often come to light that were not obvious even to the business owner

We compile a register of all the company’s processes, documenting how things currently work at the client without reference to ERP or any other system. For example, it looks like this

eEPC diagram of business process 1.02 “Assembly (kitting) of fixed assets”

eEPC diagram of business process 1.03 “Commissioning of fixed assets and intangible assets/R&D”

At the modeling stage, we bring together two views: as-is and to-be

This stage is not easy for the client to accept either. After seeing the modeling demo, users often simply do not recognize their system and processes. They feel it will not work for them and that they need a custom program in which all processes follow the order established in the company.

That is understandable. Sometimes a company has to “die and be reborn.” It is frightening for employees, managers, and the CEO alike. No one likes changing established routines, let alone paying for it. But in reality it comes down to a choice: change yourself, or pay dozens of times more and spend several years on customizations.

Why do we always offer standard 1C:ERP functionality?

Because the fewer customizations there are, the smaller the project budget and the costs of support, updates, and so on. And we are talking about tens, and sometimes hundreds, of millions of rubles. So building the right processes turns out to be faster, cheaper, and more effective.

“Clients usually don’t come to us for consulting. They don’t really understand why it is needed or what value it brings. They simply need a modern enterprise management system — ideally fast, not too expensive, and tailored to their processes.

That is where we come in. Knowing the capabilities of the ERP system and the client’s industry specifics, we design the architecture of the new processes and prepare the changes that need to happen in the company (which employee in which department will perform which actions in the new system) so that standard functionality is used as much as possible. We find the balance of the project triangle: cost, quality, and time. Demonstrating the modeling results to users lets them see clearly why the processes in the new system are designed exactly this way.

Our analysts are meta-specialists: they not only know the software being implemented inside out, but are also consultant-level experts in business processes. A good specialist on our team usually knows two or three 1C:ERP modules (for example, 1C:ERP Production, Warehouse, IFRS) as both a business analyst and a systems analyst. Large projects require several analysts and functional architects.”

Anton Kulish, CEO of Tsifrovizatsiya Proizvodstva LLC (CIFP)

Consulting as the key stage of a 1C:ERP automation project

Imagine a client comes to an integrator with a request to automate production.

An experienced integrator first asks whether the company has a documented accounting methodology. No? Then that has to be done first.

You need to build the chains of actions that should take place in production:

• how processes should be reflected in the system,
• how they should be accounted for,
• how cost will be calculated in 1C:ERP,
• how costs will be allocated, and so on, for every process.

Sometimes this system exists in employees’ heads. Sometimes it does not exist even there. “Automate production” is taken to mean that the integrator should develop the methodology. The client assumes it is built into the system: “You’re automating, so figure out how we’re organized and tell us how it should be.”

So the integrator has to write the methodology. For example, an accounting policy has a section on how to account for fixed assets: they can be depreciated using the straight-line method or an accelerated method. And the client has to choose a specific one. And so on for every process.

Workwear, for example, can be written off at full cost immediately, or in parts. The cost can be spread over 10 years for a super-durable hard hat that lasts many years. Writing it off all at once causes too big a jump in production cost, making it inaccurate and uneven. But gloves that are used for a week can be written off immediately. Different options are possible here.

How do you automate budgeting? You can’t, without a methodology. There have to be reports with formulas, and the budgeting process must be documented: how budgets are approved, adjusted, and planned.

So consulting should answer exactly how these processes should run and set procedures for them.

The integrator’s job is to automate these processes in the chosen solution — roughly speaking, to “tick the boxes” where needed.

Experienced integrators take a comprehensive approach to a project (what we call “turnkey”). In such projects, the business analysis stage comes first. The integrator studies the existing business processes, how they are interconnected, where the bottlenecks are, and so on. The deeper and more detailed the business analysis, the more accurate the project timeline and cost the client will get. It is better not to rush here.

Based on the data gathered, the integrator begins its consulting work, which helps streamline processes and save significant money.

Of course, you can do without consulting. It saves time and, at first glance, money. Most integrators do exactly that. That is why you often see projects whose results don’t satisfy the client, or projects that simply stall.

We recommend not chasing short timelines and a low initial price. It is better to look closely at how the integrator works, ask questions, and discuss the details at kickoff meetings.

Why in-house consulting is not the best choice

External teams usually deliver projects more successfully, even though they know less about the company’s processes.

Why?

The key to project success is a project manager who knows the company’s business processes well, working with an external team.

An external team has a number of advantages that employees do not have.

1. A fresh look at processes. When you are on the inside, you cannot be objective. That is simply human psychology.
2. No personal constraints. There are no close, emotional relationships with employees. This makes it possible to say calmly and candidly what needs to change. Sometimes these are very serious matters, up to eliminating positions or sending people for training.
3. Broad exposure. An external team has experience from other projects and knows how similar successful companies are organized.
4. Expertise. Knowledge and experience from automating other companies help avoid pitfalls and suggest a more effective and faster path.

Why can’t a programmer implement an ERP system?

We often see a company buy a “box” (the software itself), hire a 1C specialist, and try to set up 1C:ERP that way. Even large companies make this mistake. One of our projects started exactly like this. At the assembly-line production site of one of the largest construction companies, a programmer installed 1C:ERP Enterprise Management 2.5, but he was unable to tie the system to real operations. He lacked the knowledge of an analyst and a functional architect. And that volume of work is too much for one person anyway. So he simply quit overnight.

A programmer can write a technical specification; he knows 1C:Enterprise 8.3 and, specifically, 1C:ERP Construction Company Management, and he knows the code. What more could you need? But he does not know this particular company: the nuances of its business or all of its business processes. In fact, he is not needed on the project at all for the first six months.

The implementation stage is preceded by a large body of consulting work. This means studying the company and its processes thoroughly: analyzing the real situation, modeling the desired result, agreeing it with users, and modeling customizations where necessary. Only then does the programmer get to work.

In other words, without upfront consulting, the project is doomed.

Our advice: never skip the business analysis and consulting stages. The more expert the analysts and architects, the better, faster, and cheaper the project will be.