Site integration with 1C - risks and a bit of reality

Fail ends from 30% to 50% of attempts to introduce a full-time integration of the site with 1C. My colleagues told me that I have a 75% business plan. That is, in three cases out of four, you will have to twist something with a file, and in one case you will have to evacuate or resuscitate in general. And what would it be, after all ...

... Top manufacturers of modern domestic control systems unanimously declare that they can integrate with 1C. Naturally, this applies for the most part to typical configurations - you just can’t foresee everything, yeah. And marketing forces us to say that “this is easy!”. A slogan that will probably never die.

Consider the integration process in terms of client-performer. Scenario sales can turn into real ad because of a couple of awkward movements of the manager.
')


So get acquainted with the bitter experience and share our:

Pre-sale phase:

Dialogue analysis:

Manager - already grated roll and ask the right questions. But in the pre-sale phase, such details are usually unknown to the customer, and finding them out is long and dreary. It is easier to choose the contractor who will not ask such questions. The attempt of the project manager to transfer the integration to further stages contributes to the fact that the presale phase passes more smoothly.

But in practice, this can lead to big problems after the launch of the system, when it turns out that the structure of the product catalog in 1C and its structure on the site are fundamentally different. The information that someone writes 1C is a very alarming signal, as well as the fact that the client plans to change the 1C version.

As a rule, this ensures that full-time integration is not enough.

Phase of approval of technical specifications:

Dialogue analysis:

Failure to provide unloading or access to 1C, unfortunately, is a frequent problem. At the same stage of work, I would recommend to begin interaction with the customer's programmer (various kinds of surprises are quite possible). Sometimes it is the cheapest and real option.

Agree with the customer to arrange for you to negotiate with the programmer, make sure that the programmer either gives you access to the upload, or 100% agreed to provide the upload and settings to suit your requirements. Fix the arrangements in writing.

Development Phase:

Dialogue analysis:

Almost guaranteed file. Programmers need to design the directory structure, but if unloading from the database will be fundamentally different - this must be taken into account in advance. Perhaps everything could have been saved here, but ...

Project Phase:

Analysis of the situation:

Well, everything happened. Now the project manager will try to "steer" a remote programmer who does not stand in his command, and whom he did not hire. It all depends on what kind of self-importance the programmer has on the client side ... And don’t let it be> 9000 :-)

Project acceptance phase:

And - further developments:



Dialogue analysis:

If you put pressure on the customer’s programmer, you can find out that he either didn’t figure out the specification, or tried, but he didn’t succeed, or he has already built up some sort of his own govnokod or some kind of his own “universal” format that he doesn’t want to back down from . A special tin starts if your client pays his 1C-nickname an hourly rate, and 1C-nick claims that his work will take a week because of your “unreasonable” demands (or the uniqueness of “our base”).

A week later:

Dialogue analysis:

For brevity, only the strongest moves of the PM are shown. In fact, you can fuck much longer. You can taxi, but about getting into the budget and time limit - this is no longer a question. The client is to blame (it is formalized in the contract that the unloading will be provided in the required format ), but this is unimportant, since the goal of the PM is to launch the project and not to prove “guilty”.

The main thing is not to talk like "you were professionals, you should have foreseen." You have foreseen and decided to continue the integration, having an open risk. And the risk, alas, worked.

It is treated, as a rule, by an increase in the price of 2-3-4 person-days by the programmers of the studio, and another 8-16 hours of nerve negotiations by the project manager and the client. Actually, hence the difference in price - $ N for full-time integration, $ MMM - for non-standard.

Nerve cells are not restored.

Total, about this alignment, on the main risks:

Risk / situation	Effects	Counteraction
Unloading requested at the stage preseil.	The client will look for someone easier. Too much time will be spent on presale, and the project will fail.	Move the integration to a separate stage. Give a "fork" for the best and worst cases. Inform the customer about the possible risks.
Unloading is not provided at the stage of preparation of the TZ.	Incorrectly designed directory structure. Disruption of time and budget.	Insist on providing unloading. Move integration into a separate stage. Inform the customer about the possible risks.
Integration rendered in a separate stage.	We'll have to redo the entire directory structure.	Get the upload before the start of the design.
1C has been modified by a third-party developer, has an outdated version, or a poorly structured directory.	The inability to perform full-time integration. Long negotiations with the programmer of the customer, loss of time.	Insist on compliance with the signed requirements. Perform customization of unloading on the client side on your own.
Perform 1C settings on the client side on their own.	Unpredictable complexity and possible difficulties with atypical configuration. The risk of "digging" in the project. The risk of getting a load on site maintenance is free advice on 1C or getting to fix some glitches in 1C, which “was not up to you”.	Insist on compliance with signed unloading requirements. Instruct setting 1C to a reliable third party (to which, in which case, all claims will be made). Nominate with the customer.
The studio insists on following the protocol.	The risk of breaking the relationship due to the inability of the client to implement the requirements independently. Delaying the delivery of the project.	Move integration with 1C on a separate phase. Perform 1C settings by yourself. Accept data in the format in which the client is able to provide it.
The programmer on the customer side is out of control.	Long, difficult negotiations. Breaking deadlines.	Organize daily trilateral calls with the customer, its programmer and the studio. Solve the problem at a higher level (escalate).
The studio caved in and agreed to change the protocol requirements to fit any format.	Alteration of the directory structure, time-consuming integration programming “for free”, deadlines.	Lay on the integration - a lot of money. Remember the experience and no longer come across.