1C Implementation Consultant: Why the Real Work Starts with a Conversation, Not the Software

From the outside, a 1C consultant looks like someone who shows up and configures software. In reality, most of the work happens before the Configurator is ever opened. I work at the intersection of development and implementation, and I see this every day: a project usually breaks not on the technical side, but at the stage where no contractor actually talked to the client about how things really work.

The first task is to understand, not to configure

Before proposing a solution, you need to study the client's business processes, get into the specifics of how they work, and untangle the hidden nuances the client themselves often doesn't even frame as a problem — just "that's how it's always been done here." That's the pre-project survey: interviews with the client, an analysis of existing information systems, agreeing on requirements.

It's easy to get this wrong in either direction. Skip this step and jump straight into configuring a standard setup, and the system will work perfectly — just not for the processes the client actually has. Get stuck in endless discovery without ever landing on a concrete document, and the project stalls before it starts, while the client's trust in the timeline erodes.

The technical spec isn't a formality

After the audit comes the technical specification, where tasks get recorded — both the ones tied directly to configuring 1C and the ones tied to changing the client's processes. It's a document that later protects both sides: the developer knows exactly what to build, and the client knows exactly what they'll get and when.

A separate part of my job is assigning tasks to developers for configuration changes based on that spec, testing the result, and delivering the final version to the client. In other words, a consultant doesn't just "know 1C in general" — they translate the client's business language into concrete development tasks, and then verify the development didn't drift from the original intent.

Implementation almost always means rethinking a habit, not just configuring software

One thing that's hard to explain to a client upfront: implementing a 1C solution almost always requires some rethinking of established practice, adapting it to what the system can do. You can endlessly customize a configuration to match "how we've always done it," but some changes are better made not in the code but in the accounting, warehouse, or sales team's actual workflow.

This is the most delicate part of the conversation, because suggesting the client change a process isn't the same as suggesting a customization. What matters here is not imposing anything, but showing: here's what the system does out of the box, here's what would need custom development and ongoing support, and here's what could be simplified by slightly adjusting the process itself — cheaper and more reliable in the long run.

Training isn't a one-off event — it's part of the implementation

You can fully automate a business, but populating the configuration with data and actually working in the system is the job of the client's employees, not the consultant. That's why training users isn't a final formality after project handoff — it's part of the same work as configuration: if people don't understand why the new data-entry process exists, they'll find a way around the system, and six months later someone will be manually cleaning up the reporting again.

Regulation sets the pace, not the consultant

A distinct feature of this job is that part of the agenda is set not by clients but by legislation. Changes in tax law, a rising VAT rate, new product labeling requirements — all of it turns into mandatory updates for thousands of companies at once, whether they're ready or not. The consultant's role here isn't to invent anything — it's to warn the client in time that postponing a configuration update costs more than doing it ahead of schedule.

What a business choosing a contractor should take from this

If you judge a 1C consultant by their approach rather than their résumé, a few things are worth watching for:

• Do they start by asking how things actually work at your company, or do they jump straight to a standard setup? The latter often means the company's real processes won't be accounted for.

• Is the outcome of the discovery phase recorded in a technical spec, or does everything rest on verbal agreements that are easy to interpret differently later?

• Do they plan employee training as part of the project, or as an option that gets cut to save money?

• Do they warn you in advance about legislative changes that will affect the system in the coming months, or do they only mention it after the update is already overdue?

Bottom line

About seventy percent of a 1C implementation consultant's work is conversation, analysis, and documentation — configuring the software is the smaller remaining part. A good result isn't one where the system technically works — it's one where it works the way the client's business actually operates, and where employees understand why it's there and how to use it.