Employees do not want a new software - go on about or bend your line?

Software leapfrog will soon become a very common disease of companies. Changing one software to another because of every little thing, jumping from technology to technology, experimenting on a live business is becoming the norm. At the same time, a real civil war begins in the office: a resistance movement is being formed, the guerrillas conduct subversive work against the new system, spies propagate a new brave world with new software, the leadership from the armored car of the corporate portal broadcasts about peace, labor, KPI. Revolution usually ends in complete failure of one of the parties.

We know about the introduction of almost everything, so let's try to figure out how to turn the revolution into evolution and make the introduction of the most useful and painless. Well, or at least tell you what you can plunge into the process.


Perfect visualization of the adoption of new software by employees. Source - Yandeks.Kartinki

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.” But we are with you in Russia, so the question of suspicious and militant employees is highly relevant. A natural transition will not work, even with minimal software such as a corporate messenger or softphone.
')

Where do the legs grow from the problem?

Today, every company has a whole software zoo (we take the general case, because IT companies have twice or three times the amount of software, and adaptation problems overlap partially and 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 the browser to the browser is carried out by the whole team without exception (and there are still teams sitting completely on Internet Explorer Edge). In general, there are several situations for which our article may be useful:

• there is a process of primary automation of a group of tasks: the first CRM / ERP is being introduced, a corporate portal is being opened, a system for technical support is being installed, and so on;
  
• one software is replaced by another for some reason: obsolescence, new requirements, scaling, changing activities, etc .;
  
• there is an expansion of the existing system modules 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 has already suspected that it is not accidental, and soon there will be changes), try to understand what the real reasons for the software change are and whether you agree with the changes so necessary.

• In the old program it is difficult to work: it is expensive, inconvenient, non-functional, has ceased to meet your requirements, is not suitable for your scale, etc. This is an objective necessity.
  
• Vendor ceased to maintain the system, or support and refinement turned into an endless series of approvals and money pulling. If your costs have increased significantly, and in the future they promise to increase more - there is nothing to wait for, you need to cut it. Yes, the new system will also cost money, but ultimately the optimization will be cheaper than such support.
  
• Software change - the whim of one person or group of employees. For example, the CTO wants to roll back and lobby for the introduction of a new, more expensive system - this happens in large companies. Another example: a project manager is fighting to change Asana to Basecamp, then Basecamp to Jira, difficult Jira to Wrike. Often, the only motive for such migrations is to show their stormy work and save their position. In such cases, it is necessary to determine the degree of necessity, motives and validity and, as a rule, by a strong-willed decision to refuse changes.
  

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

How can you 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 to be very suitable for us, so we will not reinvent the wheel.

Big bang

Accepting the “Big Bang” method is the toughest transition possible when you set the exact date and perform a sharp migration, disabling the old software at 100%.

pros

+ All work in one system, no need to synchronize data, employees do not need to monitor the two interfaces at once.
+ Simplicity for the administrator - one migration, one tasks, supporting one system.
+ All possible changes occur at the same 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: chat rooms, corporate portal, instant messengers. Even e-mail can already fail, not to mention the 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 working environment is training.

Parallel Running

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

pros

+ Users have enough time to get used to the new software, quickly working in the old, to find parallels, to penetrate 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 stringent and generally less expensive.
+ The negative reaction of employees is practically absent - after all, they have not been deprived of the usual tool or way of business (if automation occurs for the first time).

Minuses

- Problems of administration: support for both systems, data synchronization, security management in two applications at once.
- Infinitely stretching the transition process - employees realize that they have almost an eternity left, and you can extend the use of the familiar interface a little more.
- Confusion of users - two interfaces are confusing and cause errors in work and data.
- Money. You pay for both systems.

Phased adoption

Phased adaptation - the softest version of the transition to new software. The transition is carried out functionally, at specified time periods and by subdivisions (for example, from June 1 we bring new customers only to the new CRM system, from June 20 we conduct transactions in the new system, until August 1 we transfer calendars and cases, and by September 30 we complete Migration is a very rude description, but generally visual).

pros

+ Organized transition, distributed load on administrators and internal experts.
+ More thoughtful and deep learning.
+ There is no resistance to change, because they occur as gently as possible.

Cons - about the same as the parallel transition.

So now, just a phased transition?

A logical question, agree. Why get some extra hassle when you can make a schedule and act on a clear plan? In fact, not so simple.

• Software complexity: if we are talking about complex software (for example, a CRM system ), then phase adaptation is more appropriate. If the software is simple (messenger, corporate portal), then the model will do when you announced the date and cut off the old software on the appointed day (if lucky, the staff will have time to pull out all the information they need, and if you don’t count on luck, then you need to provide automated imports required data from the old system to the new one, if technically possible).
  
• The 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 move from one CRM system to another, and during the transition period you have to pay for both, thereby increasing costs and the cost of introducing a new system, which means the payback period is stretched.
  
• The number of employees: a big bang just does not fit in the case of the need to scale and configure multiple user profiles. Although there are times when ultra fast adoption for a large company is a blessing. This option may be suitable for systems that are used by many employees, but at the same time may not have requirements, since no customization is expected. But again, this is a big bang for end users and a huge step-by-step work for the same IT service (for example, billing or pass-through system).
  
• Features of the implementation of the selected software (refinement, etc.). Sometimes the implementation is initially phased - with the collection of requirements, refinement, training, etc. For example, a CRM system is always implemented progressively, and if someone promises you to “implement and configure in 3 days or even 3 hours,” remember this article and bypass such services with a side: installation ≠ implementation.
  

Again, even knowing the parameters listed, it is impossible to unambiguously take one or another path. Evaluate your corporate environment - it will help you at the same time understand the balance of power and determine which model (or a combination of some of their elements) will suit you.

Agents of influence: revolution or evolution

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

• Company executives determine how new software will be generally accepted. And this is not the place for advertising speeches and fiery speeches. It is important to show the need for change, to bring the idea that this is just a choice of a cooler and more convenient tool, just like replacing an old laptop. The biggest mistake of the leadership in such a situation is to wash their hands and separate themselves: if the bosses do not need automation of the company, why should the employees be interested in it? Be in progress.
  
• Heads of departments (project managers) - an intermediate link, which must necessarily participate in all processes, manage discontent, show will and work out every objection of colleagues, conduct high-quality and in-depth training.
  
• IT service (or system administrators) - at first glance, these are your early birds, the most adaptable and adaptable, but ... no. Often, especially in small and medium-sized companies, system administrators are opposed to any changes (gains) in the IT infrastructure, and this is not connected with any technical justification, but with laziness and unwillingness to work. And who among us was not looking for ways to hang out from doing the work? But let it be not 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, are afraid of change. The main argument for them is honest and simple: why do we introduce / change, what are the boundaries of control, how will work be evaluated, what will change and what are the risks (by the way, the risks should be assessed by everyone - although we are CRM system vendors, we don’t dare to 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 software, the “authority” may turn out to be an advanced know-it-all, who, for example, reread Habra and start to intimidate everyone with how everything will turn out bad. He may not even have a goal to ruin the process of implementation or transition - just show-off and the spirit of resistance - and the staff will believe him. It is necessary to work with such employees: explain, ask, in especially difficult cases, hint at the consequences.
  

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

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

1. Conduct training: vendor and internal. Make sure that the staff really understood everything, learned and, regardless of the level of training, are ready to start working. Mandatory attribute of training is printed and electronic instructions (regulations) and the most complete system documentation (self-respecting vendors release it along with software and provide it for free).
   
2. Look for supporters and choose infuenserov. 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, to introduce them to the new software. Your task is to temporarily unload them from work or reward them adequately for the new load.
   

What you need to pay attention to?

1. How advanced are those employees who will be affected by the changes? (Relatively speaking, if tomorrow a new accounting program is invented, God forbid you stick in the accounting department with the ladies for 50 and suggest a transition from 1C - you won’t go out alive).
   
2. How much will workflow be affected? It’s one thing to change an instant messenger in a company of 100 people, another is to introduce a new CRM system in which key processes in the company are tied up (and this is not just sales, for example, the introduction of RegionSoft CRM in older editions affects both production and warehouse and marketing, and top managers, who together with the team will build automated business processes).
   
3. Has training been conducted and at what level?
   

The only logical transition in the system of corporate thinking

What will save the transition / introduction of new software?

Before we tell you what key points will help you comfortably move to a new software, we will focus your attention on one point. There is something that you don’t need to do - don’t put pressure on employees and “motivate” them with depremization, administrative and disciplinary actions. The process will not work better from this, but the attitude of the employees will deteriorate: being pushed, then there will be control; once forced, it means they do not respect our interest; if they forcefully impose, it means they do not trust us and our work. Therefore, we do everything in a disciplined, well-defined, competently, but without pressure and excessive forcing.

You must have a detailed action plan.

That all the rest may not be, and the plan should be. Moreover, the plan is adjustable, updated, clear and unavoidable, while being available for discussion and transparent to all interested employees. It is not directive to report that From 8 am to 10 is a feat, and at 4:00 pm 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 end users - so each employee will know exactly what desired feature and at what time he will be able to use it. At the same time, the transition or implementation plan is not some kind of immutable 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 “women” and not in the form of a permanent shift in terms).

What should be in the plan?

1. Milestones of the transition (stages) - what should be done.
   
2. Detailed points of transition for each stage - as 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. Responsible - people who can be contacted and with whom you can ask.
   
5. Terms - the beginning and end of each stage and the whole process as a whole.
   
6. Affected processes - what changes will occur in business processes, what needs to be changed along with the implementation / transition.
   
7. The final assessment is a set of indicators, metrics or even subjective assessments that will help assess the implementation of the transition / transition.
   
8. The 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 by force, to ignore the reaction, not to talk with the staff. We are against this approach, and here's why.

Look at the picture below:



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