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

Software leapfrog will soon become a very common disease of companies. Changing one software for 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 movement of resistance to implementation is formed, partisans carry out subversive work against the new system, spies promote a new wonderful world with new software, the management from the armored car of the corporate portal broadcasts about peace, labor, KPI. A revolution usually ends in the complete failure of one of the parties.

We know almost everything about implementation, so let's try to figure out how to turn a revolution into an evolution and make implementation as useful and painless as possible. Well, or at least tell you what you can get yourself into in the process.

Ideal visualization of acceptance of new software by employees.Source — Yandex.Images

Foreign consultants would begin this article something like this: “If you offer your employees 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 in Russia, so the issue of suspicious and belligerent employees is very relevant. A natural transition will not work, even with minimal software such as a corporate messenger or softphone.

Where do the legs of the problem grow from?

Today, every company has a whole zoo of software installed (we take the general case, because in IT companies the amount of software 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 that's not counting the fact that there are companies in which even the transition from browser to browser is carried out by the entire team without exception (and there are also teams that are completely sitting 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 some group of tasks: the first CRM / ERP is being implemented, a corporate portal is opening, a system for technical support is being installed, etc.;
• there is a replacement of one software for another for some reason: obsolescence, new requirements, scaling, change of activity, etc.;
• there is an increase in the modules of the existing system for the purposes of development and growth (for example, the company opened production and decided to switch from RegionSoft CRM Professional on RegionSoft CRM Enterprise Plus with maximum functionality)
• there is a serious interface and functional update of the software.

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 (which has already suspected that fsss is not without reason, and there will be changes soon), try to understand what the real reasons for changing the software are and whether you agree that the changes are so necessary.

• The old program is difficult to work with: it is expensive, inconvenient, non-functional, no longer meets your requirements, does not fit 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 even more, there is nothing to wait for, you need to cut. Yes, the new system will also cost money, but in the end, optimization will cost less than such support.
• Software change is a whim of one person or group of employees. For example, the CTO wants a rollback and lobbies for the introduction of a new, more expensive system - this happens in large companies. Another example: a 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 hectic work and keep the position. In such cases, it is necessary to determine the degree of necessity, motives and justification and, as a rule, a strong-willed decision to refuse changes.

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

How can one cross: the great leap or the crouching tiger?

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

Big Bang

Big bang adoption is the most brutal transition where you set a firm date and do a drastic migration, shutting down old software 100%.

pros

+ Everyone works 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, maintaining 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 affected productivity, development speed, sales, etc.

Cons

- It works successfully only with simple software: chats, corporate portal, instant messengers. Even e-mail 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 learning.

Parallel Running

Parallel adaptation to software is a softer and most versatile 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 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 rigid and generally cheaper.
+ The negative reaction of employees is practically absent - after all, they were not deprived of their usual tool or way of doing things (if automation is happening for the first time).

Cons

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

Phased Adoption

Phased adaptation is the softest option for switching to new software. The transition is carried out functionally, within the agreed time periods and by departments (for example, from June 1, we add new clients only to the new CRM system, from June 20 we conduct transactions in the new system, transfer calendars and cases until August 1, and by September 30 we complete migration is a very rough description, but generally visual).

pros

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

Cons - about the same as for a parallel transition.

So now, just a phased transition?

Logical question, you see. Why get some extra hassle when you can make a schedule and act according to a clear plan? In fact, not everything is so clear.

• Software complexity: when it comes to complex software (for example, 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 cut off the old software on the appointed day (if you're lucky, employees will have time to pull out all the information they need, and if you don't count on luck, then you need to provide for automated import necessary data from the old system to the new one, if technically possible).
• Degree of risk for the company: the riskier the implementation, the slower it should be. On the other hand, delay is also a risk: for example, you are switching 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 implementing a new system, which means that the payback period is extended.
• Headcount: A big bang is definitely not the way to go if you need to scale and set up multiple user profiles. Although there are times when ultra-fast implementation for a large company is a boon. This option may be suitable for systems that many employees use, but may not have requirements, since customization is not expected. But then 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 access control).
• 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, CRM system is always being 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: installation ≠ implementation.

Again, even knowing the listed parameters, one cannot unambiguously take one path or another. Assessing your corporate environment can help you both understand the balance of power and determine which model (or a combination of some of their elements) is right for you.

Agents of influence: revolution or evolution

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

• Company leaders determine how the new software will be generally accepted. And here there is no 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 of management in such a situation is to wash their hands and withdraw: if the authorities do not need company automation, why should employees be interested in it? Be in the process.
• Heads of departments (project managers) are an intermediate link that must necessarily participate in all processes, manage dissatisfaction, 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 oppose any changes (strengthening) of the IT infrastructure, and this is due not to some kind of technical validity, but to laziness and unwillingness to work. And who among us hasn't looked for ways to get away from doing work? But let it not be to the detriment of the whole company.
• End users, as a rule, want to work well and comfortably on the one hand and, like any living people, are afraid of change. The main argument for them is honest and simple: why are we implementing / changing, what are the limits of control, how will the work be evaluated, what will change and what are the risks (by the way, risks should be assessed by everyone - even though we are vendors CRM systems, but we do not dare to say that everything always goes smoothly: there are risks in any process within a business).
• "Authorities" within the company are partisans who can influence other employees. This is not necessarily a person with a high position or great experience - in the case of working with “authority” software, it may turn out to be an advanced know-it-all who, for example, re-read Habr and starts to intimidate everyone with how bad everything will become. He may not even have a goal to disrupt the implementation or transition process - just show-offs and a spirit of resistance - and employees will believe him. You need to work with such employees: explain, ask, in especially difficult cases, hint at the consequences.

There is a universal recipe for how to check whether users are really afraid of something or they 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 fall on 3-4 clarifying questions.

Two important factors for successfully overcoming the "resistance movement".

1. Provide training: vendor and internal. Make sure that employees really understand everything, have learned it and, regardless of the level of training, are ready to start working. A mandatory attribute of training is printed and electronic instructions (regulations) and the most complete documentation on the system (self-respecting vendors release it along with the software and provide it for free).
2. Look for supporters and choose influencers. Inner experts and early adopters are your backbone to 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 adequately reward them for a new load.

What should pay attention to?

1. How advanced are those employees who will be affected by the changes? (Relatively speaking, if a new accounting program is invented tomorrow, God forbid you poke your head into the accounting department with ladies over 50 and offer a transition from 1C - you won’t get out alive).
2. How much will work processes be affected? It's one thing to change a messenger in a company of 100 people, it's another thing to implement a new CRM system, in which key processes in the company are tied (and this is not only sales, for example, implementation of RegionSoft CRM in senior editions, it affects production, warehouse, marketing, and top managers who, together with the team, will build automated business processes).
3. Has training been provided and at what level?

The only logical transition in the system of corporate thinking

What will save the transition / implementation of new software?

Before we tell you what key points will help you move comfortably to new software, let's focus on one point. There is something that you definitely don’t need to do - you don’t need to put pressure on employees and “motivate” them with bonus deductions, administrative and disciplinary sanctions. The process will not go better from this, but the attitude of employees will worsen: if they push through, then there will be control; if they force it, it means that they do not respect our interest; since they forcefully impose it, it means that they do not trust us and our work. Therefore, we do everything in a disciplined, clear, competent way, but without pressure and excessive forcing.

You must have a detailed action plan

Everything else may not be, but there should be a plan. Moreover, the plan is correctable, updated, clear and inevitable, at the same time accessible for discussion and transparent for all interested employees. It is impossible to directively report that from 8 am to 10 am is a feat, and at 16 pm there is a war with England, it is important to see the whole plan in perspective.

The plan must necessarily reflect the requirements of the employees who will be the end users - so each employee will know exactly which feature they want and at what time they will definitely 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 “wishlists” and not in the form of a permanent shift in deadlines).  

What should be in the plan?

1. Key milestones of the transition (stages) - what should be done.
2. Detailed transition points for each stage - how it should be done.
3. Keypoints and reporting on them (reconciliation of hours) - how what is done will be measured and who should be at the control point.
4. Responsible - people who can be contacted and from whom you can ask.
5. Deadlines are 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. The final assessment is a set of indicators, metrics, or even subjective assessments that will help evaluate the implementation/transition that has taken place.
8. The start of operation is the exact date when the entire company will join the updated automated process and will work in the new system.

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

Look at the picture below:

A new mouse, a new keyboard, an apartment, a car, and even a job are pleasant, joyful events, some of them even achievements. And the user goes to Yandex to learn how to get used to it, to adapt. How to enter a new apartment and understand that it 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 so far such a stranger. The 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 the situation about which you can say: hurry slowly.

Source: habr.com