Внедрение IT продукта. Почему пользователи саботируют внедрение новой системы?

Введение

Внедрение новой программы в бизнес-процессы компании - это всегда непростой процесс. Существует множество очевидных и не совсем очевидных факторов, почему программа может не прижиться в компании.

В этой статье мы поговорим об основных проблемах внедрения программного продукта и как минимизировать риск того, чтобы все затраченные усилия не прошли даром.

Ключевые причины проблем при внедрении новой программы

Есть несколько точек в проекте, откуда могут прилететь проблемы. Мы будем отталкиваться именно от субъектов, кто может чинить препятствия на пути к внедрению программы в работу.

Пользователь системы

Именно пользователи будут работать с программой. Именно ни на своей шкуре почувствуют все-все ее проблемы и неудобства.

Крайне важно, чтобы именно пользователь в первую очередь принял программу.

Для этого она должна давать ему наиболее удобный способ работы. Если есть более удобный способ работы по старинке (например, через эл почту), то люди будут просто работать в обход системы.
Т.е. формально они вроде как работают в ней, но только для галочки, для выполнения служебных обязанностей. А реальное выполнение будет идти вне системы.

Даже, если все крайне удобно и эффективно работает, некоторым пользователям все равно будет невыгодно внедрение системы, которая делает процессы прозрачными. Ведь в этом случае их "увидят". Когда хаос в процессах, очень сложно понять, кто реально, что делает. Все строится на заверениях, и многих это устраивает (особенно особо хитрых сотрудников).

Если человек саботирует внедрение системы без видимых причин, то стоит задуматься какие цели он преследует, и нужен ли такой человек в компании.

Разработчик системы (или программисты на сопровождении)

Если вы - человек от бизнеса, то рассматривайте лучше программистов как руки, а не как мозги (хотя мы, разработчики, обычно себя воспринимаем именно как мозги).
Большинство программистов - умные рациональные люди. Но зачастую они умны по-своему, в техническом плане, но не в бизнес-плане. И это нормально, это нужно просто принять.

Программист, который хорошо создает функционал и глубоко понимает бизнес-процессы - на вес золота.

Сразу важно понимать, что нельзя отдавать на откуп программистам построение бизнес-процессов.

Они должны реализовать задумки, но никак не придумывать их за владельца продукта, бизнес-аналитиков и т.д. Посредственный будет бизнес-результат, если все продумывает внешний программист, который совсем недавно вообще не представлял ваших бизнес-процессов.

Если многие решения по процессам навязаны (или полностью созданы) внешним разработчиком - ничего хорошего скорее всего не будет. Думаю, именно поэтому очень многие коробочные продукты зачастую не соответствуют реальным потребностям бизнеса. В них есть 100500 функций, но какие-то простые важные потребности конкретного бизнеса не закрыты.

Вторая проблема, которая может идти от стороны разработки - медленное следование за потребностями проекта

Если новые хотелки медленно закрываются, и разработка не поспевает за изменениями бизнес-процессов, то пользователям придается адаптироваться к обходным путям работы.

Крайне важно быстро внедрять пожелания, идеи по системе. Все это должно развиваться ступенчато и на основе ПОТРЕБНОСТЕЙ бизнеса, а не основе того, что тогда-то выйдет новая версия коробочного продукта.

Руководство

Руководство может жить в отрыве от масс (пользователей), не понимать их потребностей, но при этом именно они принимают конечные решения.

Если генеральный директор проявляет излишнюю активность, мешая по сути владельцу продукта его развивать, то может получиться так, что программу сделали по пожеланиям директора, но всех других она не устраивает (просто начинают работать в обход ее или используют только, когда совсем нельзя обойти).

Руководство должно доверять владельцу продукта (о нем ниже), который формирует видение по программе, ее развитию.

Владелец продукта

Это главный человек для программы. Именно он является главным идейным ядром внедрения этой программы.

Сильный владелец продукта - 80% успеха его внедрения. При слабом владельце продукта никакие другие хорошие факторы не спасут проект.

Именно владелец продукта определяет вектор развития продукта, взаимодействует с заинтересованными лицами по программе. Ключевая компетенция владельца продукта - бизнес-аналитика. Он должен глубоко понимать процессы компании, выгоду от внедрения программы, и как эта программа повлияет на будущее развитие компании в целом.

Про владельца продукта мы написали большую статью руководство

Внутренний системщик

Это может быть внутренний сис.админ, или технический директор. Если компания небольшая, то один человек может отвечать за всю техническую часть компании.

Этот человек может противиться внедрению новой системы:

это выходит за зоны его компетенции (например, другие технологий, стек). А ему хотелось, чтобы было все родное, знакомое. Чисто по-человечески, понять его можно. Я сам крайне не люблю моменты, когда в проект добавляется неведомая штука, которую непонятно кто будет поддерживать в случае проблем.
потеря монополии на техническую часть. По сути в его вотчину врывается новый подрядчик, и уменьшает зависимость компании от его влияния.
дополнительные ненужные движения (обучение, решение вопросов стыковки и т.д.). Если технарь не понимает, откуда он получает свою зарплату (что платит, не компания, а ее клиент ему по сути через компанию), то он будет задаваться вопросом "А зачем это все надо? И так все работает хорошо". Т.е. у системщика не стоит задача развития бизнес-процессов, улучшения их характеристик, а значит он может воспринимать это, как причуду руководства (они же так ничего не понимают, просто начитались всякой ерунды).

В общем, надо учитывать, что системщик может ставить палки в колеса и лучше его по максимуму изолировать от нового проекта. Если же новый подрядчик будет напрямую зависеть от системщика, то скорее всего проект не внедрится, а системщик свалит это все на плохого внешнего подрядчика.

Текущая бизнес-ситуация (конечный клиент)

Внедрение программы - это довольно дорогой, длительный процесс. На мой взгляд, эти игры не для компаний, у которых одна задача - выжить. В этом случае наоборот нужно убирать все издержки, сокращать штат до минимума, процессы делать максимально простыми, и все усилия тратить на продажи.

Внедрение программы - это больше про рост, про долгосрочное масштабирование. Программа может рассматриваться как экзоскелет для бизнеса. Если вы малый ребенок (хаос, нет бизнес-процессов) - то программа вам только усложнит жизнь. Если вы уже взрослый человек (отточенные процессы), то программа-экзоскелет усилит ваши возможности, позволит делать все быстрее и в большем масштабе.

В общем тезис простой: если все плохо, то программа только усугубит ситуацию. Если есть планы расти, то программа закладывает фундамент роста.

Что мы можем ответить на это в рамках платформы Falcon Space?

Мы создаем платформу с прицелом непрерывное развитие проекта.

Что считаю важным для любого активного проекта:

Быстрое следование за изменениями в бизнесе компании. Система должна довольно быстро реагировать в плане изменений по пожеланиям пользователей и отвечать потребностям бизнеса.
Система должна быть достаточно гибкой. Не должно быть такого, что нельзя изменить что-то кардинально важное (я сейчас не про стилистику, а именно бизнес-процессы, новые кабинеты, новые объекты для учета и т.д.).
Стоимость поддержки не должна быть космической. Если изменение системы приводит к непомерной стоимости поддержки, то вероятно она не будет в итоге развиваться по экономическим соображениям. В идеале, на стороне заказчика должен быть человек, знающий базовый SQL и чуть HTML, который сам сможет делать изменения в системе без необходимости внешнего поставщика.

Наша платформа подразумевает узкий стек - SQL и Bootstrap4 (стилизация HTML). Это дает требуемый уровень гибкости и экономности поддержки (нужен по сути 1 человек на поддержку такой системы).
Есть готовые решения на базе платформы, но их надо рассматривать как стартовую точку для развития своего проекта, а не продукт, высеченный на камне (какая-то сложная метафора получилось).

Кратко пройдемся по тем же субъектам:

Пользователь - в рамках проекта доработок можно создавать общий чат с пользователями и собирать их пожелания и оперативно внедрять те, которые посчитает важными владелец продукта.
Если пользователь видит, что его изменения появляются в системе, он будет считать ее своей. Он тоже приложил руку к ее изменению. В итоге он не только будет в ней работать, но и считать себя частью процесса ее становления.
Разработчик системы - обычно это 1-2 человека из нашей команды. Для них мы создаем инструменты, упрощающие и ускоряющие разработку (например, автогенерация таблиц, форм для некоего объекта в базе данных).
Руководство - для руководства важно все знать. Обеспечить максимальную прозрачность. Если все ведется через систему, то можно знать кто когда что делал, где были задержки, где у нас проблемы и т.д.
Ключевое - информация должна накапливаться в системе. А дальше дело техники - создать некую панель супервизора, где можно выводить различные минитаблицы, графики по ключевым объектам бизнес-системы.
Ключевая задача руководства - принимать правильные решения. Наличие качественной оперативной информации - основной фактор для принятия хороший решений.
Владелец продукта. Платформа и команда разработки - это пластилин и руки, которые могут сделать почти что угодно. Ваша главная задача - точно сформулировать, что вы хотите реализовать, а также своевременно детализировать новые потребности бизнеса до команды разработки.
Внутренний системщик. Если человек знает SQL, то он вполне может за 1-2 недели изучить ключевые практики разработки на базе нашей платформы. Таким образом, он может увеличить свою ценность для компании, а также снизить зависимость компании от внешнего поставщика услуг разработки (что делает его, системщика, еще более ценным для компании).
Клиент компании. У клиента может быть удобный функциональный кабинет, где видные его заказы, история по ним, некая статистика, баллы, акции, рефералы и т.д. Т.е. клиент получает некой доп сервис, цифровое лицо компании, через которое он взаимодействует с ней. Косвенной выгодой для клиента компании может быть уменьшение простоев в обработке заказов, более доступная и актуальная информация.

Описание платформы можно найти на главной странице нашего сайта

Заключение

В статье рассмотрели ключевые проблемы внедрения новой программы в существующую компанию. Учитывая указанные факторы, можно снизить риски провала внедрения IT проекта, что позволит планировать рост компании в обозримом будущем.

Источник: https://falconspace.ru/blog/vnedrenie-programmnogo-produkta-v-rabotu---pochemu-polzovateli-sabotiruyut-vnedrenie-novoy-sistemy