“Bad habits” of Russian IT customers
Customers in Europe and Russia
So, what is the portrait of the average large customer “not from the Russian Federation” – for example, from Europe or the USA.
The majority (approximately 90%) are private businesses whose main goal is to make a profit. Those companies that work under government orders, basically, have nothing in common with the classic Russian government order: they are much smaller than our state corporations, for example, Rostec or Rostelecom, and simply fulfill orders from the state or work under a grant support scheme. Accordingly, owners carefully calculate not only the cost of implementing IT solutions, but also ownership, and save their budget.
Accordingly, most often Western customers take the “box” and adjust their processes to it, if required. “Custom” is rarely ordered, unless it is initially a custom development. The vendor is selected based on functionality, reliability, number of implementations, etc.
In Russia it’s exactly the opposite: a customer who buys a “box” is a rarity, directly proportional to how Europeans buy “custom”. Due to the chaotic nature of processes, adjusting processes to the system is unrealistic. And here, at the stage of drawing up technical specifications and working on the project, the most “interesting” begins.
What not to do if you are a customer
Below are typical behavior patterns. I just want to add – “try not to do that!”
1. Transferring junk from the old system
The customer asks to transfer old features and functionality, most often without even analyzing whether they are used or not. Those. from the old system that they want to replace, they are trying to drag all the ballast, which, in theory, just needs to be gotten rid of. Considering that some systems have been in operation for five years or more, imagine how much unnecessary stuff has accumulated there.
2. Saving unnecessary paid software
An almost similar situation – they want to keep the plugins, paid extensions, etc. that were purchased for the previous system. And, again, it does not affect how often they are used, how convenient they are and whether they can be done differently, etc. They just want to maintain the budget because – what? – that’s right, the previous development was also custom.
Points 1 and 2 are, in general, solvable. Yes, this leads to long, difficult negotiations, but, as a rule, it is possible to convince people to keep only what is really needed.
3. Edits for the sake of edits, scattered requirements
For some reason, many companies believe that if an employee has not contributed or provided valuable comments, then he is not effective and is wasting his place in the work group. Therefore, one of the bad “advices” is to collect comments from everyone, regardless of whether they understand the topic or not, and add everything to the technical specifications. It doesn’t need to be like that.
4. The customer is trying to combine all the features from different vendors into one product
The worst option. That is, the company spends some time exploring the market and notes the features it likes (spoiler – which may not fit together in any way). As a result, instead of technical specifications, we get Frankenstein, which no experienced vendor wants to take on. If such a thing does exist, then, as a rule, the project simply gets bogged down in a huge number of endless improvements, edits and alterations, because everything does not work as we would like.
We have an example where a customer has been collecting requirements from different vendors for 4 years. They spent a lot of money on this market research, but, judging by another questionnaire, they still have not come to any decision. Let me remind you – 4 years.
Another example: the Galaktika company followed approximately this path: they themselves, as a vendor, began to implement a Frankenstein solution at Yukos. And under active continuous customization, they ended as a business and were unable to develop into something more, although at that time they were the market leader.
Usually, such situations are visible, and we try not to participate in them.
5. Maximum – in-house development, minimum of external solutions.
Example – Sberbank, VTB, Yandex, Russian Post, RSHB, etc. Those. These are large corporations with large budgets that have the opportunity to develop their own development and try to compete with vendors and integrators. But the problem is that, as a rule, the resulting product either does not reach sale or does not find a user, because companies don’t specialize in this. At the same time, huge corporations hinder the development of the market, because they either buy up potential competitors (but this is a global experience, ours are no exception), or develop an irrelevant product, vacuum the labor market, etc.
I am inclined to believe that all of the above is a consequence of a special stage of the market and its segments. State corporations accumulate huge budgets, the attitude towards which differs from private companies. There are many reasons and they, in general, are not about corruption, but about organizational problems and peculiarities of legislation.
Any modification for the customer means additional costs for a specialist who must appear on staff or be hired and will support and develop a separate product track. At the same time, clients often want to develop a custom feature, but transfer the cost of development to the vendor, because he will then “sell” it.
The vendor, in turn, when releasing any release, must take into account compatibility with custom. Accordingly, he can implement features only in the product, and not with a specific customer. At the same time, if the vendor does not conduct a demand analysis, he may find himself in a situation where this feature then turns out to be unnecessary for any customer or is very rarely used. And this turns into 2 problems:
1. He can’t sell it to anyone else.
2. Forced to spend money on supporting this feature, because… if at least one customer is already using it, then development, technical support, bug fixing, testing, debugging for new releases, etc. are needed.
An alternative is to separate individual blocks into independent plugins, which are modified and purchased separately. To create your own plugin marketplace, the vendor must grow up to it.
There is only one conclusion – select customers as carefully as they select a vendor. And wait – the market will change gradually, synchronously with maturity and greater commercialization (spoiler: no).
