The introduction of the software product. Features of the business consultant. Part I

Labor is the father of pleasure.

Stendal.

Today I continue to talk about the work of a business consultant with small and medium businesses. Let me remind you that I have already told you how to get acquainted with a client, how to show yourself from the best side and convince the head of the company that you need to provide you with a choice of software product, as well as how to gather information that is necessary for the correct choice.
In addition, I explained in detail how to present your chosen solution. In the article “We are presenting a software product. How to convince the client of your choice ” we discussed the various nuances of this stage of work. And now, as I promised, let's talk about the next stage, about implementation.

The introduction of a software product from the point of view of a business consultant.

Before talking about some actions, I want to remind you a very important point. You are not a software vendor. You are a business consultant. And because your main goal - is to solve the tasks, and not to sell any software ...
')
Once again: the main thing is to solve the business problem!

You have no interest in selling a product. Moreover, you do not sell it in principle. The customer buys your chosen software not from you, but from the developer. Therefore, if the new software will simply perform the same functions as the old one, you have not completed your task.

You are implementing such software that will:

• Effectively solve the tasks that the client has set for you.
• It will help you find a solution to the problems that have arisen in the business.
• And also, naturally

will solve all the problems that were solved by the old software.

It is this software that you should have chosen at the previous stage of work, and then successfully presented to the client.
Moreover, when you communicate with a client, I do not advise at all to focus on the fact that you are implementing some specific software. Of course, you do this work and, of course, talk about it, including with the client. But it is necessary to constantly remember and voice (including in terms of work) that you do not just implement software, you solve certain tasks.

For example:

The task was set before you: to introduce accounting for acquiring operations. When using current software, such accounting is either not kept at all or is conducted incorrectly.

You know that this task can be effectively solved if you implement 1C Trade Management 11. Moreover, this component will also work effectively with the tasks that the current software product solves. As a result, you are proposing the implementation of 1C Trade Management 11. But in the work plan, you describe these processes as “Introduction of accounting for acquiring transactions”. Because the solution to this problem is your goal. Both you and your client must constantly remember this.

Why is this so important? Proper goal setting helps the proper implementation of the project. Here is how a typical software deployment process usually looks like in most cases:

1. Got a list of tasks that need to be implemented.
2. We finished the software with the wishes of the client.
3. Installed everywhere the program, set up.
4. Conducted a short training.
5. Left a manual written in technical language and understandable, most often, only to the system administrator.

It is this version of work that I personally observed more than once while working at 1C partner companies. In addition, many of my business clients, faced with the introduction of various software products, also talked about this option. The maximum of the formal approach is the minimum of effectiveness.

What is the result? The software has been implemented, the training has been completed, the acts of completed work have been signed, bills have been paid. Formally, the work was done, and the developers complete the collaboration. At the same time, it is profitable for implementers to close the project as soon as possible and receive payment. It is beneficial for the client’s employees to finish their work as soon as possible and calmly switch back to the old familiar version of the program. The only one who suffers is the owner of the company. He lost money, but earned nothing.

Why it happens?

The developers are not interested in further cooperation with the client, but because the training is done only formally.
The software really does not satisfy all the needs of the company, but it was possible to understand it only after implementation. And, as you know, for the revision after signing the certificate of completion, payment is made separately.

Employees did not see for themselves any benefits from the introduction of a new software product, while constantly experiencing difficulties in performing the usual operations in the new system, as a result they sabotaged further work with the new program.
You can continue to list the reasons why a particular product was unclaimed. In fact, there is one reason:
The people who were involved in the implementation were not interested in solving certain business problems of the client.

The business tasks of the developers, of course, implemented in full. And how the company will continue to work with their software, in most cases, they are no longer interested.

Another thing - the work of a business consultant. Here the goals of the consultant and the client completely coincide, since you are engaged in solving the customer’s problem, and not just in software implementation. Therefore, the business consultant doesn’t approach the implementation process a bit differently than the developers.

What is implementation?

Software implementation is the process of setting up software under certain conditions of use, as well as training users to work with the software product.

( Wikipedia )

Formally, this definition is correct, and I think any IT specialist will agree with him. But for a business consultant, first of all, the result is important. Therefore, if, for example, the software is installed, and users can fully work with it without training, from my point of view, the task is also considered completed. Those. implementation took place, despite the fact that one of the stages was not implemented. On the other hand, if the solution of the task requires some additional actions, it means that they will also need to be performed.

The introduction of the software product took place in the event that the software product performs the task, and the company's employees have completely switched to working with the new product.

So, the overall goal is clear. This is a business problem solution. And then I propose to forget about this goal for a while and concentrate on each of the stages of work.

In Japan, since ancient times, Yumi longbow shooting has been taught. The teachers of one of the classical schools claim:
In order to achieve a goal, it is necessary to concentrate not on the goal itself, but on the process, on your every action.
I believe that the same principle works when introducing software. You once marked the goal, and then concentrate on the actions at each of the stages of work. And if you correctly perform each of the actions, you will surely reach the goal. Focus mostly not on what you are trying to implement, but on how you do it. Carefully treat each process, create all conditions for its implementation. And then you can really get to the goal.

Errors in the implementation.

Why did I dwell on these concepts in such detail — correct goal setting and concentration on processes? I saw a lot of mistakes in the construction of the implementation process, and errors that led to sad consequences. I want to warn you of some of these mistakes, the most important and common ones.

Avoid rushing. Even if the client is trying to push and rush. Never assume strict obligations on the timing at the beginning of the project as a whole. Very often in the implementation process, the need for some additional actions and modifications in the program is revealed. In addition, the appetite comes with eating, and quite often in the process of work, the client himself begins to set additional tasks. If you are limited to a strict time frame, it can lead to haste. As a result - to a large number of errors and flaws.

The goal must be marked “in general”. You do not need to drive yourself into some kind of rigid framework, you do not need to strictly indicate the list of improvements from and to. You are a business consultant, your task is to solve problems in business. Software is only one of the tools needed to achieve a goal. At the same time, you still know the work of this particular business rather weakly; you have not yet had time to go into all the nuances. Therefore, already in the process of introducing a software product, you yourself can understand that you need to implement additional solutions or plans to implement them a little differently. In general, keep the maximum space for maneuver.

In order to avoid the listed errors, you definitely need to convey to the client a simple idea:
Here and now you are doing a unique job, in a unique environment with a unique result. Therefore, it is simply impossible to accurately predict all the nuances!


You have never worked with this company before, and therefore you cannot predict all the nuances.
Company employees in most cases also had never before been trained to work with this software.
And no one has ever used the results of the work you are going to do. Of course, you know how to work with small and medium businesses, you have experience in the successful implementation of other projects. You also know the proposed software product and, most likely, you can boast of successful implementation experience.

But all this was for other clients who have other needs, features of building a business, other people work for them, etc. And here and now an individual project is being implemented. Therefore, it is impossible to predict exactly what you will reach the final with the client, and how long the work will take.

Depending on the complexity and volume of the work to be done, I often refer to some approximate dates. It can be 2 - 4 months or from six months to 1.5 years. Yes, I do not know the exact timing of the project, as I can not say in advance exactly how the result of my work will look like. But I know the most important thing - this is the main goal, as well as exactly how to implement each stage of work.
Those. I use the very principle that I already mentioned in connection with the Japanese archery of Yumi: focus on each action, at each stage, perform each action qualitatively. And then you will definitely come to the goal!
Where does the introduction begin?

Before starting the work itself, it is very important to convey to the client the philosophy that I mentioned above. You can use different words for this, emphasize those points that, in your opinion, will be better accepted by your client. In some specific moments, you can even take on quite tough obligations. But this is particular. And, in general, the client must understand: the work may last long enough, and there may be some changes in the process. This is a normal workflow, everything goes according to plan, and the necessary result will be sure. If all of you have correctly communicated to the client, then in the future there will not be any negative or complaints regarding the timing or some stages of the program’s implementation. He is warned about all the nuances of work.

It is also very important to remember that your client is not an IT specialist, not a software vendor, not a consultant or an implementer. Moreover, most likely, for him the introduction of a software product is an unfamiliar or unfamiliar process.

Your client knows his job well, in this he is an expert. And most of your explanations, technical terminology and a list of necessary steps for it are still not clear. And therefore not needed. Explain the goals, explain what problem you solve as a result. And about the process itself you need to talk as little as possible and focus on, first of all, on those actions for the implementation of which will require the participation of the client.

In addition, remember that the introduction of a new software product, most likely, in his company was carried out for a long time. Small and medium businesses very often use the same software 7 - 10 years. So, by the time you started your work, the company’s employees either forgot how to implement the programs or never participated in this process. Therefore, you need to understand that you may face fears, rejection, and other difficulties.

I will give an example. Once, I myself was too deep into technical nuances and tried to explain how, say, MailChimp differs from the 1C mailing. I talked about the API, about statistics, about the number of failures, as well as about other technical parameters. In this case, the client, in fact, needed completely different data. It was enough for him to demonstrate an example of a letter and show an example of statistics so that we would understand each other and the client would understand the benefits for himself.

Speak to the client from his point of view and in his language!

If you do not overload your explanations with unnecessary terms, but explain to the client what he really needs to know, and explain it to him in simple and understandable language, believe me, you will achieve more than with a long lecture saturated with technical characteristics.

Also, do not try to impress the client with the help of beautiful terminology. If you really know the subject, you will be able to explain all the nuances in a simple and understandable language. Remember that your client is also an expert in a certain area, also communicates periodically with non-specialists, explaining some nuances to them. And he also understands this simple truth.

At the management level, it is usually enough to inform: yes, this product will be able to solve the problem. And decide it effectively.
And when you communicate with an employee who, for example, will be responsible for unloading and sending mail in the same MailChimp, he not only can, but also needs to clarify where to look at what data, where the statistics are, and how it all is works.

I will write about my approach to the implementation process in the next article.