Moving from SAP to 1C:ERP: a pre-project survey for a chemical concern

Moving from SAP to 1C means transferring processes built over years into a system with different logic, structure and capabilities. Preparing for such a move is a separate stage that determines how manageable the implementation itself will be. Using a project with a large chemical concern as an example, we explain how we conduct a pre-project survey and why a Business Requirement Review (BRR) is needed.

Project start

The Russian division of the chemical concern uses SAP as its accounting system, heavily customised for the company's processes. When the question of moving to a Russian solution arose, 1C:ERP was chosen: an integrated management system that brings finance, production, sales, procurement and warehouse together in a single environment.

The company turned to UCMS Group as a partner with a proven track record: we have been running payroll and HR administration for this client since 2020 and had already implemented 1C:ZUP and employee self-service portals.

Sergey Pulnikov, head of the consulting department at UCMS Group:
“Because we already had joint experience of implementing 1C, the client had seen how we work: we do not just launch the system and leave, we stay until employees are confident working in it.”

At the same time it was important not just to reproduce the old model but to make it manageable: so that when a new cost item appears or parameters change, there is no need to go into the code and everything can be reconfigured through reference books.

Read also:A case study on HR administration at the same company

Delivering the first stage: from analysing the client's processes to designing the system in 1C:ERP

Every implementation at UCMS Group starts with a pre-project survey and the preparation of a BRR: a description of the client's business processes. It is not a dry technical specification but a document written in plain language that an accountant, a procurement specialist, a department head and a developer can all read, understand and approve. The BRR helps align expectations between the client and the provider and reduces the risk of unnecessary customisations and misunderstandings during implementation.

For a large project like this one, we prepare a separate BRR for each block: finance, warehouse, procurement, credit management and so on. Methodologists, analysts and developers work on each one, which makes it possible to validate every decision both from the business logic side and from the implementation side.

Stages of the pre-project survey

• Studying the documentation.The client provided a large body of internal materials: departmental requirements, instructions and regulations. We analysed them and mapped them onto processes in 1C:ERP.
• Interviews with employees.In parallel we held meetings with representatives of each department - the direct users of the system. This helped clarify the real working scenarios that had not been documented.
• Modelling in 1C:ERP.For each process the implementation team modelled the solution in a demo database: what is covered by standard functionality and what is not. Where standard functionality was insufficient, developers were brought in to discuss possible customisations.
• Writing and approving the BRR.For each area we produced a BRR, which was approved and refined with each department in several rounds.

Sergey Pulnikov, head of the consulting department at UCMS Group:
“First you immerse yourself in the company's processes and almost become its employee. Then you take each process and try to map it onto 1C logic: some things are covered by standard functionality, and for others you realise customisation is needed. It is a huge amount of very interesting analytical work.”

Project architecture

In this project we tried to rely on the standard functionality of 1C:ERP as much as possible: it makes the system easier to maintain and safer to update. Where standard blocks were insufficient, we customised them or designed them from scratch.

Examples of customising standard blocks

• Warehouse.We added a stock blocking mechanism: goods are moved to a block with a reason and become unavailable for movement in the system. We also developed documents that allow the shelf life of a batch to be changed and goods to be repacked without creating a new item in the reference book (as happens in standard functionality).
• Treasury.We designed a report on foreign currency cash balances as at a given date: with detail by bank account, amounts shown in the account currency and the ability to view all accounts at once or select a specific one. We also built into the interface the ability to force re-post documents for a selected group of accounts.
• Sales.We improved sales plan analytics and developed a report for analysing customer orders that lets employees in different departments get data using individual filters.

We added to the standard retro-bonus functionality a link to the counterparty's line of business and region, the ability to accrue daily and to set the bonus as a fixed amount. We developed an additional document to automatically reflect the retro-bonus reserve in statutory accounting.

• The four-eyes principle.. For a number of operations in several blocks we configured a mandatory control check: an action takes effect only after confirmation by a second responsible employee.

What we designed from scratch

• Credit management.The system shows up-to-date counterparty data: credit limits, rating and payment history. The rating is updated automatically, for example it goes down when a payment is overdue. This makes it possible to manage restrictions promptly: block individual orders or counterparties. We also developed an extended status model, because the standard 1C:ERP statuses did not reflect the real decision-making chain.
• Third-party procurement.1C:ERP has no specialised block for third-party procurement. We developed this block with the ability to categorise purchases and use different approval routes. We designed a new document, the Purchase Request, with types and subtypes, each with its own fields, limits and approval routes. After approval the request is automatically converted into a supplier order (if the supplier is on the approved list and the amount does not exceed the established limit).

We also developed a report on remaining limits that shows how much of the contract limit has already been used. If the remaining limit is less than 20%, the figure is highlighted in red. Access to the report is granted via the access matrix, subject to restrictions.

We added an allowed deviation field to the contract card: a small excess over the limit within a given percentage goes through without additional approval. For example, contracts flagged as a framework agreement have a separate approval process with mandatory review by the procurement department manager.

A pre-project survey and the BRR determine how smoothly the move from SAP will go: when processes are recorded, decisions approved and every department understands how its part of the system will work, the implementation itself becomes predictable.

Telegram channel about accounting and HR outsourcing for those who want transparent, manageable business processes

We share case studies, explain legislative changes and show how automation and outsourcing help businesses grow.

Subscribe