ソフトウェアのリープフロッグは、間もなく企業にとって非常に一般的な病気になるでしょう。些細なことでソフトウェアを別のソフトウェアに変更したり、テクノロジーからテクノロジーに飛び移ったり、実際のビジネスを実験したりすることが標準になりつつあります。同時に、本当の内戦がオフィスで始まります。導入に対する抵抗運動が形成され、パルチザンが新しいシステムに対して破壊活動を行い、スパイが新しいソフトウェアで素晴らしい新世界を促進し、装甲車からの管理が行われます。企業ポータルでは、平和、労働、KPI について放送しています。革命は通常、一方の側の完全な失敗に終わります。
私たちは実装についてほぼすべてを知っているので、革命を進化に変え、実装をできるだけ便利かつ苦痛なく行う方法を考えてみましょう。少なくとも、その過程で何が起こるかについては説明します。
新しいソフトウェアに対する従業員の受け入れ状況を理想的に視覚化します。出典 - Yandex.Images
外国のコンサルタントは、この記事を次のように始めるでしょう。「従業員の仕事を改善し、パフォーマンスに定性的な影響を与える高品質のソフトウェアを提供すれば、新しいプログラムやシステムの採用は自然に起こるでしょう。」しかし、私たちはロシアにいるので、不審で好戦的な従業員の問題は非常に重要です。企業メッセンジャーやソフトフォンなどの最小限のソフトウェアを使用した場合でも、自然な移行は機能しません。
Откуда растут ноги у проблемы?
Сегодня в каждой компании установлен целый зоопарк ПО (мы берём общий случай, потому что в ИТ-компаниях количество софта больше вдвое или втрое, а проблемы адаптации пересекаются частично и весьма специфичны): системы управления проектами, CRM/ERP, почтовые клиенты, мессенджеры, корпоративный портал и т.д. И это не считая того, что бывают компании, в которых даже переход с браузера на браузер осуществляется всей командой без исключения (а ещё есть команды, полностью сидящие на Internet Explorer Edge). В общем случае есть несколько ситуаций, для которых может оказаться полезной наша статья:
- いくつかのタスク グループの一次自動化プロセスがあります。最初の CRM/ERP の導入、企業ポータルの開設、テクニカル サポート システムのインストールなどです。
- происходит замена одного ПО на другое по каким-то причинам: устаревание, новые требования, масштабирование, смена деятельности и т.д.;
- происходит наращивание модулей существующей системы для целей развития и роста (например, компания открыла производство и решила перейти с на с максимальной функциональностью);
- происходит серьёзное интерфейсное и функциональное обновление ПО.
もちろん、最初の 2 つのケースはより急性で典型的な症状なので、特に注意してください。
したがって、チーム (すぐに変更が行われることをすでに疑っている) と作業を開始する前に、ソフトウェアを変更する本当の理由は何なのか、また変更がそれほど必要であることに同意するかどうかを理解するように努めてください。
- В старой программе сложно работать: она дорогая, неудобная, нефункциональная, перестала соответствовать вашим требованиям, не подходит для вашего масштаба и т.д. Это объективная необходимость.
- ベンダーがシステムのサポートを停止したか、サポートと変更が際限なく承認と資金の流出を繰り返すことになりました。コストが大幅に増加し、将来さらに増加することが約束されている場合は、待つ必要はなく、削減する必要があります。確かに、新しいシステムにも費用がかかりますが、最終的には最適化の方がそのようなサポートよりも費用は安くなります。
- Смена ПО — прихоть одного человека или группы сотрудников. Например, CTO хочет откат и лоббирует внедрение новой, более дорогой системы, — такое бывает в больших компаниях. Другой пример: проектный менеджер ратует за смену Asana на Basecamp, потом Basecamp на Jira, сложной Jira на Wrike. Нередко единственный мотив таких миграций — показать свою бурную работу и сохранить должность. В таких случаях нужно определять степень необходимости, мотивы и обоснованность и, как правило, волевым решением отказывать в изменениях.
Мы говорим о причинах именно переходов с одного ПО на другое, а не о первичной автоматизации — только потому что автоматизация априори необходима. Если в вашей компании что-то делается вручную и рутинно, но может быть автоматизировано, вы просто теряете время, деньги и, скорее всего, ценные корпоративные данные. Автоматизируйте это!
Как можно перейти: великий скачок или крадущийся тигр?
В мировой практике существуют три основных стратегии перехода на новое ПО, адаптации к нему — и они нам кажутся весьма годными, поэтому не будем изобретать велосипед.
ビッグ・バン
Принятие методом «Большого взрыва» — максимально жёсткий переход, когда вы устанавливаете точную дату и осуществляете резкую миграцию, отключая старое ПО на все 100%.
プロたち
+ Все работают в одной системе, не нужно синхронизировать данные, сотрудникам не нужно следить сразу за двумя интерфейсами.
+ Простота для администратора — одна миграция, одни задачи, поддержа одной системы.
+ Все возможные изменения наступают в один момент времени и заметны почти сразу — нет необходимости вычленять, что и в какой доле повлияло на продуктивность, скорость разработки, продажи и т.д.
コンズ
— Успешно работает только с простым программным обеспечением: чаты, корпоративный портал, мессенджеры. Даже электронная почта уже может дать сбои, не говоря уж о системах управления проектами, CRM/ERP и прочих серьёзных системах.
— «Взрывная» миграция с крупной системы на другую неизбежно вызовет хаос.
Самое важное для такого типа перехода в новую рабочую среду — это обучение.
Parallel Running
Параллельная адаптация к ПО — более мягкий и наиболее универсальный способ перехода, при котором задаётся временной промежуток, в течение которого будут одновременно функционировать обе системы.
プロたち
+ Пользователи имеют достаточно времени, чтобы привыкнуть к новому ПО, оперативно работая в старом, отыскать параллели, вникнуть в новую логику взаимодействия с интерфейсом.
+ В случае внезапных проблем сотрудники продолжают работать в старой системе.
+ Обучение пользователей менее жёсткое и в целом обходится дешевле.
+ Негативная реакция сотрудников практически отсутствует — ведь их не лишили привычного инструмента или уклада дел (если автоматизация происходит впервые).
コンズ
— 管理上の問題: 両方のシステムのサポート、データ同期、2 つのアプリケーションの同時セキュリティ管理。
— 移行プロセスは際限なく続きます。従業員は、自分の残り時間はほぼ永遠であることに気づき、使い慣れたインターフェイスの使用をもう少し延長できるようになります。
- ユーザーの混乱 - 2 つのインターフェイスは混乱を招き、操作エラーやデータ エラーを引き起こします。
- お金。両方のシステムの料金を支払います。
Phased Adoption
段階的な適応は、新しいソフトウェアに切り替えるための最も柔軟なオプションです。移行は、指定された期間内に部門ごとに機能的に実行されます (たとえば、1 月 20 日からは新しい顧客のみを新しい CRM システムに追加し、1 月 30 日からは新しいシステムで取引を実行し、XNUMX 月 XNUMX 日まではカレンダーを移行します) 「XNUMX 月 XNUMX 日までに移行を完了する」という説明は非常に大まかですが、一般的には明確です)。
プロたち
+ Организованный переход, распределённая нагрузка на администраторов и внутренних экспертов.
+ より思慮深く、より深い学習。
+ 変化はできるだけ穏やかに起こるため、変化に対する抵抗はありません。
コンズ - 平行遷移の場合とほぼ同じです。
では、今は段階的に移行するだけでしょうか？
論理的な質問には、あなたも同意するでしょう。スケジュールを立て、明確な計画に従って行動できるのに、なぜ余計な手間がかかるのでしょうか。実際、すべてがそれほど単純なわけではありません。
- ソフトウェアの複雑さ: 複雑なソフトウェアについて話している場合 (たとえば、 ), то больше подойдёт фазовая адаптация. Если ПО простое (мессенджер, корпоративный портал), то подойдёт модель, когда вы объявили о дате и отрубаете старое ПО в назначенный день (если повезет, сотрудники успеют вытащить всю необходимую им информацию, а если не рассчитывать на везение, то необходимо предусмотреть автоматизированный импорт необходимых данных из старой системы в новую, при наличии технической возможности).
- Степень риска для компании: чем рисковее внедрение, тем медленнее оно должно быть. С другой стороны, затягивание — тоже риск: например, вы переходите с одной CRM-системы на другую, и в период перехода вынуждены платить за обе, тем самым растут затраты и стоимость внедрения новой системы, а значит, растягивается период окупаемости.
- Численность сотрудников: большой взрыв точно не подойдёт в случае необходимости масштабирования и настройки множества пользовательских профилей. Хотя бывают случаи, когда ультра быстрое внедрение для большой компании — благо. Такой вариант может подойти для систем, которыми пользуются многие сотрудники, но при этом не могут иметь требования, поскольку не предполагается кастомизация. Но опять же, это big bang для конечных пользователей и огромная поэтапная работа для той же ИТ-службы (например, биллинг или пропускная система).
- Особенности внедрения выбранного ПО (доработка и т.д.). Иногда внедрение изначально поэтапное — со сбором требований, доработкой, обучением и т.д. Например, внедряется всегда поступательно и если вам кто-то обещает «внедрить и настроить за 3 дня или даже 3 часа» — вспомните эту статью и обойдите такие услуги стороной: установка ≠ внедрение.
Опять же, даже зная перечисленные параметры, нельзя однозначно становиться на тот или иной путь. Оцените ваше корпоративное окружение — это поможет одновременно понять расклад сил и определить, какая модель (или сочетание некоторых их элементов) вам подойдёт.
Агенты влияния: революция или эволюция
Первое, на что стоит обратить внимание, это сотрудники, которых заденет внедрение нового ПО. Собственно, проблема, которую мы с вами сейчас рассматриваем, чистой воды человеческий фактор, поэтому анализа влияния на сотрудников не избежать. Некоторых из них мы уже упомянули выше.
- 企業のリーダーは、新しいソフトウェアが一般にどのように受け入れられるかを決定します。そして、ここはプロモーションや激しいスピーチをする場所ではありません。変化の必要性を正確に示し、これは古いラップトップを交換するのと同じように、よりクールで便利なツールを選択しているだけであるという考えを伝えることが重要です。このような状況における経営者の最大の間違いは、自ら手を洗って身を引くことです。経営者が会社の自動化を必要としないのであれば、なぜ従業員が自動化に関心を持つ必要があるのでしょうか。プロセスに参加してください。
- Руководители отделов (менеджеры проектов) — промежуточное звено, которое обязательно должно участвовать во всех процессах, управлять недовольством, проявить волю и отработать каждое возражение коллег, провести качественное и глубокое обучение.
- ИТ-служба (или системные администраторы) — на первый взгляд, это ваши early birds, самые адаптируемые и адаптирующие, но… нет. Нередко, особенно в малых и средних компаниях, сисадмины выступают против каких-либо изменений (усилений) ИТ-инфраструктуры, и связано это не с какой-то технической обоснованностью, а с ленью и нежеланием работать. А кто из нас не искал путей откосить от выполнения работы? Но пусть это будет не во вред всей компании.
- Конечные пользователи, как правило, хотят работать хорошо и удобно с одной стороны и, как и любые живые люди, боятся изменений. Основная аргументация для них честная и простая: зачем внедряем/меняем, какие границы у контроля, как будет оцениваться работа, что изменится и в чём риски (кстати, риски стоит оценить всем — мы хоть и вендоры ただし、すべてが常にスムーズに進むとは言いません。ビジネス内のどのプロセスにもリスクは存在します)。
- 社内の「権威」とは、他の従業員に影響を与えることができる党派的な存在です。これは、必ずしも高い地位や豊富な経験を持つ人物である必要はありません。ソフトウェアを扱う場合、「権威」は、たとえば、Habr を再読して威圧し始める高度な知識人である可能性があります。すべてがどれほど悪化するかについてみんな。彼には導入や移行のプロセスを台無しにするという目標さえなく、単なる見栄と抵抗の精神があるだけかもしれないが、従業員は彼の言うことを信じるだろう。そのような従業員と協力する必要があります。説明し、質問し、特に難しい場合には結果をほのめかす必要があります。
ユーザーが本当に何かを恐れているかどうか、または賢明なリーダーが率いる集団被害妄想に陥っているかどうかを確認するための普遍的なレシピがあります。不満の理由や懸念事項について尋ねます。これが個人的な経験や意見ではない場合、3 ～ 4 つの明確な質問の後に議論が殺到し始めます。
Два важных фактора успешного преодоления «движения сопротивления».
- Проводите обучение: вендорское и внутреннее. Убедитесь в том, что сотрудники действительно всё поняли, усвоили и вне зависимости от уровня подготовки готовы начать работать. Обязательный атрибут обучения — печатные и электронные инструкции (регламенты) и максимально полная документация по системе (уважающие себя вендоры выпускают её вместе с ПО и предоставляют бесплатно).
- サポーターを探してインフルエンサーを選びましょう。社内の専門家と早期導入者がサポート システムとなり、教育と疑問の払拭を行います。原則として、従業員自身も喜んで同僚を助け、新しいソフトウェアを紹介します。あなたの仕事は、彼らを一時的に仕事から解放するか、新しい仕事量に対して適切なボーナスを与えることです。
何に注意を払う必要がありますか？
- 従業員は変更の影響をどの程度受けていますか? (相対的に言えば、明日彼らが新しい会計プログラムを発明したとしても、50 歳以上の女性がいる会計部門に鼻を突っ込み、1C からの移行を提案することを神は禁じます。あなたは生きて帰れないでしょう)。
- Насколько сильно будут затронуты рабочие процессы? Одно дело поменять мессенджер в компании из 100 человек, другое — внедрить новую CRM-систему, на работе в которой завязаны ключевые процессы в компании (и это не только продажи, например, в старших редакциях затрагивает и производство, и склад, и маркетинг, и топ-менеджеров, которые вместе с командой будут выстраивать автоматизированные бизнес-процессы).
- トレーニングは提供されましたか?またそのレベルは何ですか?
企業の思考体系における唯一の論理的移行
Что спасёт переход/внедрение нового ПО?
Прежде чем рассказать, какие ключевые моменты помогут вам комфортно переехать на новый софт, заострим ваше внимание на одном моменте. Есть то, что делать точно не надо — не надо давить на сотрудников и «мотивировать» их депремированием, административными и дисциплинарными взысканиями. Процесс от этого лучше не пойдёт, а вот отношение сотрудников ухудшится: раз продавливают, значит, будет контроль; раз заставляют, значит, не уважают наш интерес; раз насильно навязывают, значит, нам и нашей работе не доверяют. Поэтому всё делаем дисциплинированно, чётко, грамотно, но без давления и излишнего форсирования.
詳細な行動計画を立てる必要がある
Вот всего остального может не быть, а план быть должен. Причём план корректируемый, обновляемый, чёткий и неотвратимый, при этом доступный для обсуждения и прозрачный для всех заинтересованных сотрудников. Нельзя директивно сообщать о том, что С 8 утра до 10 — подвиг, а в 16:00 война с Англией, важно видеть весь план в перспективе.
В плане обязательно должны быть отражены требования сотрудников, которые будут являться конечными пользователями — так каждый сотрудник узнает, какую именно желаемую фичу и в какое время он точно сможет использовать. При этом план перехода или внедрения это не какой-то неизменяемый монолит, необходимо оставлять возможность доработки плана и изменения его атрибутов (но не в виде бесконечного потока правок и новых «хотелок» и не в виде постоянного смещения сроков).
Что должно быть в плане?
- 移行の主なマイルストーン (段階) - 何を行う必要があるか。
- 各段階の詳細な移行ポイント - それをどのように行うべきか。
- 重要なポイントとそれに関する報告（時間の調整） - 行われたことをどのように測定するか、誰が管理点に立つべきか。
- Ответственные — люди, к которым можно обратиться и с которых можно спросить.
- Сроки — начало и конец каждого этапа и всего процесса в целом.
- 影響を受けるプロセス - ビジネス プロセスでどのような変更が発生するか、実装/移行に伴って何を変更する必要があるか。
- 最終的な評価は、発生した実装/移行の評価に役立つ一連の指標、指標、さらには主観的な評価です。
- 運用の開始日は、全社が更新された自動化プロセスに参加し、新しいシステムで作業する正確な日付です。
私たちは、赤線がアドバイスである実装者のプレゼンテーションに遭遇しました。つまり、強制的に実装する、反応を無視する、従業員と話をしない。私たちはこのアプローチに反対しています。その理由は次のとおりです。
Посмотрите на картинку ниже:
Новая мышка, новая клавиатура, квартира, машина и даже работа — это приятные, радостные события, некоторые из них даже достижения. И пользователь идёт в Яндекс, чтобы узнать, как привыкнуть, адаптироваться. Как войти в новую квартиру и понять, что это твоё, впервые открыть кран, выпить чай, впервые лечь спать. Как сесть за руль и подружиться с новой машиной, твоей, но пока такой чужой. Новое ПО на рабочем месте ничем не отличается от описанных ситуаций: работа сотрудника никогда не станет прежней. Поэтому внедряйте, адаптируйте, растите с новым эффективным ПО. И это та ситуация, про которую можно сказать: поспешайте медленно.
出所： habr.com