Employees do not want new software - go on occasion or bend their line?

Software leapfrog will soon become a very common disease of companies. To change one software for another because of every little thing, to jump from technology to technology, to experiment in a living business is becoming the norm. At the same time, a real civil war begins in the office: a resistance movement is being introduced, partisans are conducting subversive work against the new system, spies are promoting a brave new world with new software, management from the armored car of the  corporate portal broadcasts about peace, work, KPI. A revolution usually ends with the complete failure of one of the parties.

We know almost everything about implementation, so we’ll try to figure out how to turn a revolution into evolution and make implementation as useful and painless as possible. Well, or at least tell you what you can get into the process of.

Ideal visualization of the adoption of new software by employees. Source -

Yandex.Pictures Foreign consultants would start this article like this: “If you offer your employees high-quality software that can improve their work, have a qualitative impact on performance, the adoption of a new program or system will occur naturally way. " But we are with you in Russia, so the question of suspicious and warlike employees is very relevant. A natural transition will not work, even with minimal software such as a corporate messenger or softphone.

Where does the problem grow from?

Today, each company has a whole software zoo (we take the general case, because the number of software in IT companies is more than double or triple, and adaptation problems overlap partially and are very specific): project management systems, CRM / ERP, email clients, instant messengers, corporate portal, etc. And this is not counting the fact that there are companies in which even the transition from browser to browser is carried out by the whole team without exception (and there are also teams that are completely sitting on Internet Explorer Edge). In the general case, there are several situations for which our article may be useful:

• the process of primary automation of a certain group of tasks takes place: the first CRM / ERP is introduced, a corporate portal is opened, a system for technical support is installed, and so on .;
  
• there is a replacement of one software for another for some reason: obsolescence, new requirements, scaling, change of activity, etc .;
  
• modules of the existing system are being expanded for development and growth (for example, the company opened production and decided to switch from RegionSoft CRM Professional to RegionSoft CRM Enterprise Plus with maximum functionality);
  
• There is a serious interface and functional software update.
  

Of course, the first two cases are much more acute and typical in their manifestations, pay special attention to them.

So, before you start working with the team (who already suspected that it was good reason for change, and there will be changes soon), try to understand what are the real reasons for changing the software and do you agree that the changes so necessary.

• It’s difficult to work in the old program: it is expensive, inconvenient, non-functional, has ceased to meet your requirements, is not suitable for your scale, etc. This is an objective necessity.
  
• The vendor stopped supporting the system, or support and refinement turned into an endless series of approvals and pulling money. If your costs have increased significantly, and in the future they promise to increase yet - there is nothing to wait, you need to cut it. Yes, the new system will also cost money, but in the end, optimization will cost less than such support.
  
• Change of software - a whim of one person or group of employees. For example, CTO wants a rollback and is lobbying for the introduction of a new, more expensive system - this happens in large companies. Another example: the project manager advocates changing Asana to Basecamp, then Basecamp to Jira, complex Jira to Wrike. Often, the only motive for such migrations is to show their vigorous work and maintain their position. In such cases, it is necessary to determine the degree of necessity, motives and validity and, as a rule, deny changes in a willful decision.
  

We are talking about the reasons for transitions from one software to another, and not about primary automation - just because automation is a priori necessary. If something is done manually and routinely in your company, but can be automated, you simply lose time, money and, most likely, valuable corporate data. Automate it!

How can I go: a great leap or a crouching tiger?

In world practice, there are three main strategies for switching to new software, adapting to it - and they seem very suitable for us, so we will not reinvent the wheel.

Big bang

Acceptance by the Big Bang method is the most tough transition, when you set the exact date and make a sharp migration, disabling the old software by 100%.

Pros

+ All work in one system, no need to synchronize data, employees do not need to monitor two interfaces at once.
+ Simplicity for the administrator - one migration, one task, support of one system.
+ All possible changes occur at one point in time and are noticeable almost immediately - there is no need to isolate what and in what proportion influenced productivity, speed of development, sales, etc.

Minuses

- Successfully works only with simple software: chats, corporate portal, instant messengers. Even email can already fail, not to mention project management systems, CRM / ERP, and other serious systems.
- “Explosive” migration from a large system to another will inevitably cause chaos.

The most important thing for this type of transition to a new work environment is training.

Parallel running

Parallel adaptation to software is a softer and more universal way of transition, in which a time period is set during which both systems will operate simultaneously.

Pros

+ Users have enough time to get used to the new software, quickly working in the old one, to find parallels, to delve into the new logic of interaction with the interface.
+ In case of sudden problems, employees continue to work in the old system.
+ User training is less rigorous and generally cheaper.
+ There is practically no negative reaction of employees - after all, they were not deprived of the usual tool or way of business (if automation occurs for the first time).

Minuses

- Administration problems: support for both systems, data synchronization, security management in two applications at once.
- The transition process is endlessly stretched - employees realize that they have almost an eternity in stock, and you can extend the use of the familiar interface a little more.
- User confusion - two interfaces are confusing and cause errors in work and data.
- Money. You pay for both systems.

Phased adaptation

Step-by-step adaptation is the mildest way to switch to new software. The transition is carried out functionally, in the agreed time periods and by departments (for example, from June 1 we only introduce new customers to the new CRM system, from June 20 we carry out transactions in the new system, we transfer calendars and cases until August 1, and we complete by September 30 migration is a very crude description, but generally clear).

Pros

+ Organized transition, distributed load on administrators and internal experts.
+ More thoughtful and in-depth training.
+ There is no resistance to changes, because they occur as gently as possible.

Cons - about the same as a parallel transition.

So now, just a phased transition?

The logical question, agree. Why get some extra trouble when you can make a schedule and act according to a clear plan? In fact, not everything is so simple.

• Software complexity: if we are talking about complex software (for example, a CRM system ), then phase adaptation is more suitable. If the software is simple (messenger, corporate portal), then the model is suitable when you announce the date and chop off the old software on the appointed day (if you are lucky, the employees will be able to pull out all the information they need, and if you do not count on luck, then you need to provide automated import necessary data from the old system to the new, if there is technical capability).
  
• Degree of risk for the company: the riskier the implementation, the slower it should be. On the other hand, delaying is also a risk: for example, you switch from one CRM system to another, and during the transition period you are forced to pay for both, thereby increasing the cost and cost of introducing a new system, which means that the payback period is stretched.
  
• Number of employees: the big bang is definitely not suitable if it is necessary to scale and configure many user profiles. Although there are times when an ultra-fast implementation for a large company is good. This option may be suitable for systems used by many employees, but they may not have requirements, since customization is not supposed. But again, this is a big bang for end users and a huge phased work for the same IT service (for example, billing or a bandwidth system).
  
• Features of the implementation of the selected software (revision, etc.). Sometimes the implementation is initially phased - with the collection of requirements, refinement, training, etc. For example, a CRM system is always being implemented gradually, and if someone promises you to “implement and configure in 3 days or even 3 hours”, remember this article and bypass such services as follows: installation ≠ implementation.
  

Again, even knowing the listed parameters, one cannot definitely take one path or another. Evaluate your corporate environment - this will help to simultaneously understand the balance of power and determine which model (or a combination of some of their elements) is suitable for you.

Agents of Influence: Revolution or Evolution

The first thing you should pay attention to is employees who will be hurt by the introduction of new software. Actually, the problem that we are now considering is a purely human factor, therefore, an analysis of the impact on employees cannot be avoided. We have already mentioned some of them above.

• Company executives determine how the new software will be generally adopted. And this is not the place for advertising speeches and fiery speeches - it is important to show exactly the need for changes, to convey the idea that this is just a choice of a cooler and more convenient tool, the same as replacing an old laptop. The biggest mistake made by management in such a situation is to wash their hands and eliminate themselves: if the bosses don’t need company automation, why should employees be interested in it? Be in the process.
  
• Heads of departments (project managers) are an intermediate link, which must be involved in all processes, manage dissatisfaction, show will and work out every objection of colleagues, conduct quality and in-depth training.
  
• An IT service (or system administrators) - at first glance, these are your early birds, the most adaptable and adaptive, but ... no. Often, especially in small and medium-sized companies, system administrators oppose any changes (enhancements) to the IT infrastructure, and this is not due to any technical justification, but to laziness and unwillingness to work. And which of us was not looking for ways to slope from the work? But let this not be to the detriment of the whole company.
  
• End users, as a rule, want to work well and conveniently on the one hand, and, like any living people, they are afraid of changes. The main argument for them is honest and simple: why are we introducing / changing, what are the boundaries of control, how will the work be assessed, what will change and what are the risks (by the way, the risks should be appreciated by everyone - even though we are vendors of a CRM system , we don’t dare say that everything always goes smoothly: there are risks in any process within the business).
  
• “Authorities” within the company are partisans who can influence other employees. This is not necessarily a person with a high position or a lot of experience - in the case of working with the software, the “authority” may turn out to be an advanced know-it-all who, for example, reread Habr and starts to intimidate everyone with how things will turn out bad. It may not even have a purpose to ruin the process of implementation or transition, - just show off and the spirit of resistance - and employees will believe him. It is necessary to work with such employees: to clarify, to ask, in especially severe cases, to hint at the consequences.
  

There is a universal recipe for checking whether users are really afraid of something or they have group paranoia headed by a savvy leader. Ask them about the reasons for dissatisfaction, about fears - if this is not a personal experience or opinion, the arguments will sprinkle on 3-4 clarifying questions.

Two important factors for successfully overcoming the “resistance movement”.

1. Provide training: vendor and internal. Make sure that the employees really understood, learned everything and are ready to start working regardless of the level of training. A mandatory attribute of training is printed and electronic instructions (regulations) and the most complete documentation on the system (self-respecting vendors release it together with software and provide it for free).
   
2. Look for supporters and choose influencers. Internal experts and early followers are your support, which will both educate and dispel doubts. As a rule, employees themselves are pleased to help colleagues, introduce them to new software. Your task is to temporarily unload them from work or to adequately reward them for a new load.
   

What should I look for?

1. How advanced are those employees who are affected by the change? (Relatively speaking, if tomorrow they will invent a new accounting program, God forbid you pop into accounting with the ladies over 50 and offer the transition from 1C - you won’t get out alive).
   
2. How much will work processes be affected? It’s one thing to change the messenger in a company of 100 people, it’s another to introduce a new CRM system that works at the core of the company’s key processes (and it’s not only sales, for example, the introduction of RegionSoft CRM in senior editions affects both production and the warehouse, and marketing, and top managers who together with the team will build automated business processes).
   
3. Is training provided and at what level?
   

The only logical transition in the corporate thinking system

What will save the transition / implementation of new software?

Before you tell me what key points will help you move comfortably to the new software, we will focus your attention on one point. There is something that you definitely don’t need to do - you don’t have to put pressure on employees and “motivate” them by deprivation, administrative and disciplinary sanctions. The process will not go better from this, but the attitude of employees will deteriorate: if they push it through, it means that there will be control; times forced, then do not respect our interest; since they are forcibly imposed, it means that they do not trust us and our work. Therefore, we do everything in a disciplined, clear, competent, but without pressure and excessive forcing.

You must have a detailed action plan.

That's all the rest may not be, but the plan should be. Moreover, the plan is correctable, updated, clear and inevitable, while being available for discussion and transparent to all interested employees. It is impossible to report directly that From 8 a.m. to 10 a feat, and at 16:00 a war with England, it is important to see the whole plan in perspective.

The plan must necessarily reflect the requirements of employees who will be the end users - so each employee will find out exactly what the desired feature and at what time he can definitely use. At the same time, the plan of transition or implementation is not some kind of unchanging monolith, it is necessary to leave the possibility of finalizing the plan and changing its attributes (but not in the form of an endless stream of edits and new “Wishlist” and not in the form of a constant shift of terms).  

What should be in the plan?

1. Milestones of the transition (stages) - what needs to be done.
   
2. Detailed transition points for each stage - how it should be done.
   
3. Key points and reporting on them (reconciliation of hours) - how will be measured what has been done and who should be at the control point.
   
4. Those responsible are people who can be contacted and who can be asked.
   
5. Dates - the beginning and end of each stage and the whole process.
   
6. Affected processes - what changes will occur in business processes, what needs to be changed along with the implementation / transition.
   
7. Final assessment - a set of indicators, metrics or even subjective assessments that will help assess the implementation / transition.
   
8. Start of operation is the exact time when the whole company will join the updated automated process and will work in the new system.
   

We met presentations of implementers, in which the red line is the advice: to introduce force, ignore the reaction, do not talk with employees. We are against this approach, and here's why.

Take a look at the picture below:



A new mouse, a new keyboard, an apartment, a car, and even work are pleasant, joyful events, some of them even achievements. And the user goes to Yandex to find out how to get used to, adapt. How to enter a new apartment and understand that it is yours, first open the tap, drink tea, go to bed for the first time. How to get behind the wheel and make friends with a new car, yours, but so far so alien. New software at the workplace is no different from the described situations: the employee’s work will never be the same. Therefore, implement, adapt, grow with new effective software. And this is the situation about which we can say: hurry slowly.