ООО «ТЕЛЕСТОР»
ИНН:7811212947
erid:2SDnjchQtDg
ООО «ТЕЛЕСТОР»
ИНН:7811212947
erid:2SDnjchQtDg
Внедрение новой программы в бизнес-процессы компании - это всегда непростой процесс. Существует множество очевидных и не совсем очевидных факторов, почему программа может не прижиться в компании.
В этой статье мы поговорим об основных проблемах внедрения программного продукта и как минимизировать риск того, чтобы все затраченные усилия не прошли даром.
Есть несколько точек в проекте, откуда могут прилететь проблемы. Мы будем отталкиваться именно от субъектов, кто может чинить препятствия на пути к внедрению программы в работу.
Именно пользователи будут работать с программой. Именно ни на своей шкуре почувствуют все-все ее проблемы и неудобства.
Крайне важно, чтобы именно пользователь в первую очередь принял программу.
Для этого она должна давать ему наиболее удобный способ работы. Если есть более удобный способ работы по старинке (например, через эл почту), то люди будут просто работать в обход системы.
Т.е. формально они вроде как работают в ней, но только для галочки, для выполнения служебных обязанностей. А реальное выполнение будет идти вне системы.
Даже, если все крайне удобно и эффективно работает, некоторым пользователям все равно будет невыгодно внедрение системы, которая делает процессы прозрачными. Ведь в этом случае их "увидят". Когда хаос в процессах, очень сложно понять, кто реально, что делает. Все строится на заверениях, и многих это устраивает (особенно особо хитрых сотрудников).
Если человек саботирует внедрение системы без видимых причин, то стоит задуматься какие цели он преследует, и нужен ли такой человек в компании.
Если вы - человек от бизнеса, то рассматривайте лучше программистов как руки, а не как мозги (хотя мы, разработчики, обычно себя воспринимаем именно как мозги).
Большинство программистов - умные рациональные люди. Но зачастую они умны по-своему, в техническом плане, но не в бизнес-плане. И это нормально, это нужно просто принять.
Программист, который хорошо создает функционал и глубоко понимает бизнес-процессы - на вес золота.
Сразу важно понимать, что нельзя отдавать на откуп программистам построение бизнес-процессов.
Они должны реализовать задумки, но никак не придумывать их за владельца продукта, бизнес-аналитиков и т.д. Посредственный будет бизнес-результат, если все продумывает внешний программист, который совсем недавно вообще не представлял ваших бизнес-процессов.
Если многие решения по процессам навязаны (или полностью созданы) внешним разработчиком - ничего хорошего скорее всего не будет. Думаю, именно поэтому очень многие коробочные продукты зачастую не соответствуют реальным потребностям бизнеса. В них есть 100500 функций, но какие-то простые важные потребности конкретного бизнеса не закрыты.
Вторая проблема, которая может идти от стороны разработки - медленное следование за потребностями проекта
Если новые хотелки медленно закрываются, и разработка не поспевает за изменениями бизнес-процессов, то пользователям придается адаптироваться к обходным путям работы.
Крайне важно быстро внедрять пожелания, идеи по системе. Все это должно развиваться ступенчато и на основе ПОТРЕБНОСТЕЙ бизнеса, а не основе того, что тогда-то выйдет новая версия коробочного продукта.
Руководство может жить в отрыве от масс (пользователей), не понимать их потребностей, но при этом именно они принимают конечные решения.
Если генеральный директор проявляет излишнюю активность, мешая по сути владельцу продукта его развивать, то может получиться так, что программу сделали по пожеланиям директора, но всех других она не устраивает (просто начинают работать в обход ее или используют только, когда совсем нельзя обойти).
Руководство должно доверять владельцу продукта (о нем ниже), который формирует видение по программе, ее развитию.
Это главный человек для программы. Именно он является главным идейным ядром внедрения этой программы.
Сильный владелец продукта - 80% успеха его внедрения. При слабом владельце продукта никакие другие хорошие факторы не спасут проект.
Именно владелец продукта определяет вектор развития продукта, взаимодействует с заинтересованными лицами по программе. Ключевая компетенция владельца продукта - бизнес-аналитика. Он должен глубоко понимать процессы компании, выгоду от внедрения программы, и как эта программа повлияет на будущее развитие компании в целом.
Про владельца продукта мы написали большую статью руководство
Это может быть внутренний сис.админ, или технический директор. Если компания небольшая, то один человек может отвечать за всю техническую часть компании.
Этот человек может противиться внедрению новой системы:
В общем, надо учитывать, что системщик может ставить палки в колеса и лучше его по максимуму изолировать от нового проекта. Если же новый подрядчик будет напрямую зависеть от системщика, то скорее всего проект не внедрится, а системщик свалит это все на плохого внешнего подрядчика.
Внедрение программы - это довольно дорогой, длительный процесс. На мой взгляд, эти игры не для компаний, у которых одна задача - выжить. В этом случае наоборот нужно убирать все издержки, сокращать штат до минимума, процессы делать максимально простыми, и все усилия тратить на продажи.
Внедрение программы - это больше про рост, про долгосрочное масштабирование. Программа может рассматриваться как экзоскелет для бизнеса. Если вы малый ребенок (хаос, нет бизнес-процессов) - то программа вам только усложнит жизнь. Если вы уже взрослый человек (отточенные процессы), то программа-экзоскелет усилит ваши возможности, позволит делать все быстрее и в большем масштабе.
В общем тезис простой: если все плохо, то программа только усугубит ситуацию. Если есть планы расти, то программа закладывает фундамент роста.
Мы создаем платформу с прицелом непрерывное развитие проекта.
Что считаю важным для любого активного проекта:
Наша платформа подразумевает узкий стек - SQL и Bootstrap4 (стилизация HTML). Это дает требуемый уровень гибкости и экономности поддержки (нужен по сути 1 человек на поддержку такой системы).
Есть готовые решения на базе платформы, но их надо рассматривать как стартовую точку для развития своего проекта, а не продукт, высеченный на камне (какая-то сложная метафора получилось).
Кратко пройдемся по тем же субъектам:
Описание платформы можно найти на главной странице нашего сайта
В статье рассмотрели ключевые проблемы внедрения новой программы в существующую компанию. Учитывая указанные факторы, можно снизить риски провала внедрения IT проекта, что позволит планировать рост компании в обозримом будущем.