Как составить программу внедрения - Исправление недочетов и поиск решений вместе с Examum.ru

Время на прочтение
15 мин

Количество просмотров 57K

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

Для того что бы не объяснять каждому новому ПМу как делать план в Project’e и какие работы и какую структуру туда закладывать, я решил сделать некий драфт плана, который показывал бы типовую структуру работ по проекту внедрения и доработки простой информационной системы, стоимостью приблизительно 5 миллионов рублей и сроком около полугода. Условно, заказчик хочет стартовать проект в мае, а завершить в октябре, при этом старт проекта для нас — начинается в апреле, с подготовки пилота и КП.

Описание проекта

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

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

Риски проекта

Поскольку никакого Rocket Science в проекте нет, его риски составляют около 10%. Заложить их можно по разному — добавить 10% к стоимости ресурсов (но это не учитывает сроки), планировать работы с учетом рисков накидывая 10% длительности к каждой сколько-либо рискованной (именно такой вариант использовал я), или сделать этап Contingency перед завершающим этапом (в моем случае он бы составлял 3 недели или ~1/10 от длительности проекта.

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

Команда проекта

Руководитель проекта — менеджер, с хорошей технической экспертизой и навыками бизнес- анализа. Хорошо разбирается в функциональности решения, понимает бизнес-задачу заказчика.
Аналитик — проводит встречи по анализу, занимается разработкой проектной документации (протоколы встреч, описание функциональных требований, спецификаций, инструкций и т.д.)
Специалист по внедрению — отвечает за внедрение решения, организацию инфраструктуры для серверов, а так же их связь с внешним миром. Т.е. настраивает ОС, БД, отвечает за трекер поддержки и т.д.

Ведущий разработчик — он же архитектор. Участвует в проработке архитектуры решения, оценке задач по разработке, обеспечивает наставничество команде разработки и помощь в решении сложных задач.
Разработчик — основной разработчик проекта,
Младший разработчик — джуниор на подхвате кода, решает задачи под контролем разработчика, параллельно учится.
Аккаунт — менеджер по работе с клиентами, отвечает за взаимодействие с клиентом, составление и подписание договоров, контроль удовлетворенности клиента и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
Куратор — высший менеджер компании исполнителя, обеспечивающий контроль и поддержку проекта. Может быть так же — руководитель портфеля проектов и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
Заказчик — все сотрудники заказчика, привлекаемые к проекту. В плане — не детализируемы, предполагается что заказчик сам решит, кого из своих специалистов привлекать к тем или иным активностям.

Конечно, нам нужно забить команду проекта на представлении «Лист ресурсов» — я просто указал роли, краткое наименование и внутренние ставки (они «средние по больнице» и не привязаны к конкретной компании), а так же указал свой базовый календарь (в общем, соответствующий производственному календарю на 2018 год). Если вы используете сервер проектов, в дальнейшем вы можете указать вместо роли — конкретных исполнителей, но на данном этапе — важны именно роли, для понимания необходимости сотрудников той или иной квалификации. Если вы готовите план проекта для представления заказчикам, есть смысл заменить внутренние ставки на внешние — и то и другое вы наверное уже знаете, а если нет — то это повод обратится к владельцам ресурсов, которые их откроют.

Минимум миниморум:

Конечно, роли могут быть другими — все зависит от компании (и методологии) в которой вы делаете проекты. Одним даром не нужен аналитик и внедренец, у них есть консультанты, другие делят аналитиков на бизнес и системных и добавляют техписателей, третьи используют стажерские программы с подключением сотрудников и т.д. У меня — один из множества вариантов команды, на листе ресурсов можно смело заменить сущности на свои и добавить новые.
Здесь, мы отмечаем заказчиков — зеленым цветом, а специалистов нашей компании, не подлежащих к расчету ФОТа — фиолетовым. Кроме того, что это наглядно, это так же удобно в дальнейшем, например если заказчик попросит сформировать график его привлечения к проекту — вы просто выгрузите план в Excel и отфильтруете по цвету.

Жизненный цикл проекта

В данном кейсе использован очень простой и распространённый жизненный цикл проекта — хорошо знакомый всем «Waterfall» где несколько фаз следуют друг за другом.

Некоторые части проекта все же сделаны итеративно — например разработка разбита на итерации, в конце каждой из которых — реализуется показ разработанного функционала заказчику.
Но тем не менее, такой жизненный цикл не предполагает каких либо серьезных изменений в ходе проекта, поэтому предполагается что скоуп проекта определен на этапе входа в проект, а ограничения по скоупу разработаны и включены в договор. Стоит так же отметить «Этап 0» — на котором происходит оценка скоупа и организация пилотного проекта (для некоторых компаний это нынче редкость) — здесь предполагается что руководитель проекта выступает так же неким руководителем пресейла, в котором он описывает и оценивает функционал, а так же неким руководителем «пилотного» проекта — цель которого, познакомить заказчика с функционалом системы, показать ему интерфейс и преимущества на берегу, что бы заинтересовать его. Пилотный проект назвать проектом можно лишь условно — естественно, это просто стандартная заготовка системы минимально дорабатываемая под нужды конкретного заказчика. Например, виртуальная машина со стабильной версией системы, в которой может быть быстро реализована пара простых, но реальных процессов заказчика, и, например, быстро настроена связь с одной из используемых им систем (на основе уже существующего драйвера, или коннектера, требующего лишь простой настройки).

Так же для экономии места на экране я убрал отображение поля «Режим задачи» — на всех задачах он автоматический, ручного нигде нет.

Общий обзор этапов, их сроков и стоимости:

Итак, у нас есть 8 этапов (включая этап 0) и проект, который начинается 2 апреля, завершается 5 октября. Заказчику — можно вовсе не показывать этап 0, и конечно, не стоит его учитывать если вы не считаете ФОТ пресейлов и пилотов (но это для первый звоночек того, что вам есть над чем поработать, так как такой ФОТ считать нужно обязательно).

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

Этап 0 — подготовка проекта

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

Для организации пилота, от заказчика потребуется пара описаний его процессов, а так же пара пожеланий, которые он хочет видеть в системе — например, он хочет загрузить какой либо список из своей уже существующей стандартной БД.

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

При средних ставках внедренца и ПМа такой пилот будет стоить нам 59 400 рублей + еще 10800 рублей на его сопровождение, ведь у Заказчика появятся вопросы про его развертывание и использование. Ну как, вы все еще не хотите считать затраты на нулевом этапе?

Далее, если заказчику понравился пилот, мы приступаем к анализу скоупа проекта и его оценке. Предполагается, что проект типовой и все методы оценки уже разработаны и опробованы в вашей компании — если это не так, то вас ждет увлекательный аттракцион по сравнению стоимости работы написания ТЗ со стоимостью разработки функционала, покрывающего то, или иное требование (но это тема отдельной статьи).

Предположим, процесс описания скоупа и оценки у вас поставлен на поток, и после оценки куратор проекта одобряет ее (и накидывает % на торг и внепроектные риски) после чего КП отправляется на согласование заказчику. Здесь указанных 7 рабочих дней может быть явно мало, поэтому эта работа указана отдельно, и именно от нее зависит веха «КП Утверждено».

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

Этап 1 — сбор требований

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

В некоторых проектах есть смысл показать разработанный Project Charter, в некоторых проектах вместе с договором подписывается официальный устав, но независимо от этого кикофф нужен — для того, что бы ясно объяснить цели и сроки проекта команде (или командам) и познакомить всех друг с другом, договорится о взаимодействии. В общем, проведение Kick-off — это тоже тема отдельной статьи.

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

А вот кстати, и график встреч — для нашего простого проекта мы предусмотрели 6 встреч, на которых участвуют разные специалисты и которые стоят для нас по разному. Предполагается, что график мы заранее согласовали с заказчиками (или спонсорами), что бы бизнес-пользователи и вообще все заинтересованные лица, не ушли в отпуска или не были заняты на других активностях. Конечно, если вы работаете над внешним проектом, есть смысл включить план проекта в договор — в этом случае никто не сможет обвинить вас в срыве сроков, если заказчик по каким то причинам не сможет присутствовать на встречах.

Рассмотрим несколько встреч на примере:

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

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

Естественно, это идеальный вариант, который работает только при наличии 2 очень сильных и мотивированных проектных команд.

В реальной жизни — отсидеть на встрече 4 часа и за 4 часа составить приличный протокол с описанием требований и договоренностей (или отревьювить его) — и так 6 дней подряд — довольно тяжело. Не говоря о том, что встреча может быть и более 4 часов (кстати, в этом случае эффективность встречи резко падает и протокол может быть и не согласован). Если сроки (и заказчик) позволяют — заложите 1 встречу в 2 дня, и возьмите запас недельку — для проведения дополнительных встреч и ревью протоколов. Если вы на 100% не уверены в заказчике и команде — никогда не ставьте на неделе более 3 встреч. Ну и конечно, все зависит от региона присутствия — если вы делаете проект в своем городе, или хотя бы в своей области — тут торопится смысла нет. Если же ваш заказчик из Нового Уренгоя, а вы — из Самары — увы, придется выложится на встречах по полной — мариновать команду без работы в другом городе нет никакого смысла. Так же, обязательно пропишите участие заказчика во встречах отдельной строкой — и вставьте это в договор.

Этап 2 — Архитектура и дизайн

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

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

Есть ли смысл детализировать эти 5 дней в задачи и отражать их в плане проекта? На мой взгляд нет, логичнее сделать это в Jira/Redmine, а заказчику/спонсору показать такой план.
У меня предусмотрено 2 итерации согласования — это совершенно разумно, но требует от заказчика определенной ответственности — на берегу стоит объяснить, что все замечания к ТЗ Заказчик выставляет в одной итерации, а во второй — только проверяет их исправление, а новые замечания — не ставятся. Если заказчик настаивает на третей итерации замечаний — что ж, хозяин барин, вставляем и третью (и четвертую, и пятую…) не забыв прописать затраты и объяснить заказчику насколько вырастет стоимость проекта. Презентовать ТЗ первый раз разумно вдвоем с аналитиком, а вот вычитывать его необходимо всей команде — на сколько либо больших проектах это весьма емкий документ, который является условием для завершения фазы проекта (а следовательно подписания актов и оплаты), и случайные ошибки в нем не допустимы. Если у вас в компании есть свободные ресурсы, например аналитики, логично подключить их к чтению ТЗ в качестве свежего взгляда — ТЗ от этого хуже не станет, а проект не подорожает на сколько бы существенно.

Этап 3 — Разработка

Итак, техническое задание подписано, и казалось бы можно приступать к разработке.
Первое, о чем хочется сказать — это предупредить о недопустимости начала разработки, без утвержденного ТЗ. Это ведет просто к тому, что одну и ту же работу приходится делать 2 раза. Конечно, если вы работает по Agile, и у вас четких требований нет, а есть заказчик платит по схеме Time&Materials, тогда смело игнорируйте это требование. Если же скоуп проекта у вас утвержден, оплата FixPrice и вы не закладывали бюджет и сроки на переделку задач, то не позволяйте разработчикам сделать ни единого коммита, без подписанного ТЗ.

Второе — конечно подразумевается, что инфраструктура для разработки развернута, а процессы отлажены. Нерадивые спонсоры и кураторы проектов, стремятся включить в бюджет проектов такие расходы — переход на использование CI, развертывание Jira/Redmine, переход на новую версию ПО и библиотек, БД и т.д. и т.п. Задача ПМа здесь — защитить свой проект (и его бюджет) от такого, аргументируя что такие вещи должны быть вынесены в отдельные проекты с отдельными бюджетами.

Если вы работает по Waterfall — делать разработку стоит итерационно — т.е. разбить весь скоуп на части и показывать заказчику/спонсору по мере наработок. Пускай в софте еще будут баги, пускай нет данных, пусть формы не доделаны — лучше потратить бюджет и время на написание сценариев показа и дополнительные тесты, чем пропасть на месяц с глаз заказчика и появится с готовым продуктом. Фидбек заказчика на этапе завершения итерации разработки так же полезен, но это не значит что его надо бездумно пихать в скоуп — оцените его замечания. Если он предлагает что то несущественное — например, сменить цвет или размер поля на форме — покажите что вы лояльны и приветливо согласитесь. Если заказчик предлагает откровенно сложный функционал — откажитесь, аргументировав отсутствием в скоупе, а если заказчик настаивает — запускайте свою машину changemanagment’а (конечно, она у вас есть). Бывает, что заказчик предлагает казалось бы что то не существенное, например поменять формат телефонного номера, но это может сказаться на всей системе. В этом случае, посоветуйтесь с ведущим разработчиком/архитектором, возьмите его оценку под этой фичей, если она небольшая — можно пойти навстречу заказчику для повышения лояльности (но стоит помнить о риске ошибки оценки).

Но все это еще впереди, а пока, вам нужно будет декомпозировать задачи из ТЗ в задачи в трекере задач. Здесь подробного универсального рецепта нет, но в общем случае — создать задачи по каждому функциональному требованию, и в его рамках создайте подзадачи. Далее, используя методы оценок (например покер планирования), вы с проектной задачей оцените трудоемкость задач. Не забудьте расставить приоритеты задач, в соответствии с итерациями (можете прикрутить к описанию задач номера спринтов, и планировать исходя из производительности команды). В плане проекта всегда разумно указать, что является результатом той или иной итерации (например разработаны экранные формы, интеграция, аналитика или что то еще) — что бы заказчик знал, что он получает на показах и мог отслеживать, идете ли вы по плану, или задерживаетесь. Постарайтесь разбить итерации исходя из вашего опыта, но в любом случае — не пропадайте надолго, и ведите протоколы показа, куда заносите замечания от заказчиков, с вашими решениями по ним — это прикроет вас, в случае конфликта относительно скоупа проекта — иначе говоря, поможет избежать ситуации на сдаче-приемке — «Не подпишем, мы ведь говорили, что окошко надо было делать синим…».

Этап 4 — Тестирование

Итак, все задачи в Jira закрыты, все протоколы согласованы и теперь мы вступаем в этап тестирования продукта, разрабатываемого в рамках проекта.
Перед тем как тестировать — вам конечно понадобится тест-план и тест-кейсы, с оценкой их прохождения.

Обратите внимание на задачу 110 (исправление дефектов) — она параллельна 109 (поиску дефектов) с задержкой в день. Т.е. предполагается, что тестировщик, проходя по тест-кейсам, описывает дефекты в системе задач, а разработчики правят их не отходя от кассы. Такой подход разумен и используется, но есть и другое решение — приступать к починке только когда тестирование будет завершено. Какой из этих подходов подойдет именно вам — знает ваш руководитель разработки.

Не забывайте, что заказчик тоже захочет протестировать систему — на этот случай вы предоставите ему документ который называется «ПМИ» — или программа и методика испытаний. Сделать его логично на основе разработанных тест-кейсов, убрав всю внутреннюю кухню и оставив только нужные заказчику вещи (в т.ч. нефункциональное тестирование).

ПМИ должен быть прочитан и утвержден заказчиком и именно по результатам прохождения ПМИ, заказчик будет принимать итоговое решение о переводе системы в промышленную эксплуатацию.
У меня в проекте — согласование ПМИ не включено, т.к. на моей практике, заказчики редко вчитываются в ПМИ и тест-кейсы, ибо слабо понимают о каком конкретно функционале идет речь и чем в одном случае чек-бокс отличается от радиобаттона в другом случае (это шутка, такое вообще в ПМИ писать не надо). Поэтому при разработке документа, особое внимание следует уделить списку кейсов, о прохождении которых пойдет речь, и конечно, проследить что бы они были нормально проработаны внутри.

Пройти ПМИ должны не только тестировщики, но и ПМ и аналитики, и желательно внедрение — сдавать систему придется всем вместе, и иметь представление о том, как работает функционал — очень полезно, и конечно. повышается шанс найти неочевидные дефекты.

Этап 5 — Внедрение

Ура! Мы добрались! Система на тестовых серверах работает как часы, команда QA отсыпается и уходит в отгулы, и пришел звездный час команды внедрения. Начинается он с развертывания окружения — и тут же у меня в плане заложен некий запас по времени, т.к. я подразумеваю что окружение развёртывали уже минимум 100 раз и в худшем случае на вашей корпоративной вике есть подробная инструкция по развертыванию, а в лучшем — внедренец сам ее писал. Главное, помните — после развертывания полезно протестировать все, что вы можете протестировать по заранее разработанному смоук-тесту, конечно же он остался у вас с фазы тестирования.
Теперь — о главном, ведь если дьявол и кроется где то, то это именно в интеграции и миграции данных. Сколько красивых диаграмм Ганта было погублено тем, что интеграция не была оттестирована тщательно и тем, что данные заказчика находились в ужасном состоянии, ненормализованные, выходящие за все грани разумного (и пределы полей), отличные от того, что написано в ТЗ.

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

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

На прохождение ПМИ — планируйте от 25% времени ПМа и выше, в зависимости от вашего опыта и годности аналитика, который участвует в проекте — в идеале испытания должны проходить как по маслу, ну и во всяком случае в этом должен быть уверен заказчик по крайней мере до начала испытаний.

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

Этап 6 — Поддержка

Или, как ее называют — сопровождение ОПЭ (т.к. с гарантийной или технической поддержкой это общего почти не имеет). Итак, вся пицца съедена, бессонные ночи закончены, и ваш проект перешел в промышленную эксплуатацию. Это значит что у заказчика нет (или он просто не сумел найти) критичных замечаний к системе, разработанной в ходе вашего проекта, и дает пользователям команду работать в ней, как в основной системе (или как в клоне боевой системы, такое тоже бывает).

Теперь, ваша задача продержаться определенный период (от 5 дней до 4 месяцев) и убедится что система работает правильно. Выбор сроков зависит от назначения системы — иногда хватает и недели работы в новой системе, иногда нужно проработать в ней месяц или два, а то еще и квартал закрыть. Планируйте на это время людей, что бы они могли оперативно разобраться с возникшими у заказчика вопросами, но учтите, что вопросов может быть (должно быть!) немного — поэтому логично запланировать так же внутренние проектные активности — архивирование документации, приведение в порядок вики и трекера задач, подготовку ретро и т.д.

Не забывайте, что все проблемы, возникшие в ходе ОПЭ, надо фиксировать в специальном журнале (а в идеале — в трекере задач) и ежедневно отслеживать их статус совместно с заказчиком.

По окончании этапа можете так же запланировать одну встречу команды с заказчиком, где вы торжественно объявите о закрытии проекта и продолжении сотрудничества и подведете итоги. Если только ваш заказчик не в Новом Уренгое.

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

Предложения по этому — я выслушаю в комментариях, и обязательно опубликую mpp в месте, где его можно будет легко и безопасно забрать.

Источник

Библиографическое описание:

Вакорин, М. П. Разработка проекта по внедрению программного обеспечения в деятельность организации / М. П. Вакорин, А. И. Корнев. — Текст : непосредственный // Молодой ученый. — 2023. — № 10 (457). — С. 4-6. — URL: https://moluch.ru/archive/457/100713/ (дата обращения: 27.05.2023).

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

Ключевые слова:

внедрение, программное обеспечение, управление проектами, проект.

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

Независимо от размера компании, внедрение ПО — это сложная задача, требующая тщательного планирования и исполнения. Даже самое лучшее программное обеспечение будет бесполезным без надлежащего тестирования, оценки и управления процесса, поэтому очень важно иметь тщательный план до его начала.

Стоит прояснить, что внедрение ПО — это процесс принятия и интеграции программного приложения в системы и рабочие процессы вашей компании. Это может быть как простое программное обеспечение для работы с документами, например, «МойОфис», так и программное обеспечение, необходимое для складского учета или для цепочки поставок. Процесс внедрения может также применяться к обновлениям ПО или значительным модернизациям его функционала.

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

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

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

Рис. 1. 6 шагов для успешного внедрения ПО

Успешное внедрение ПО начинается с четкого определения необходимых изменений и качества процессов. Выделяют шесть шагов (рис. 1), которые необходимо выполнить, чтобы ваш проект внедрения ПО прошел гладко:

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

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

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

Проверка нового ПО в тестовой среде.
Для успешного внедрения ПО в вашу систему вам необходимо провести тестирование, чтобы убедиться, что оно совместимо с вашими текущими системами и работает так, как задумано. Чем больше испытаний вы проведете, тем больше шансов на успех внедрения.
Тестовая среда — это виртуальное пространство, работающее точно так же, как ваша текущая система, но полностью отделенное от нее, чтобы ее действия не влияли на работу предприятия. Эта среда тестирования позволяет вам создавать, запускать и тестировать новое ПО, чтобы убедиться в его совместимости и выявить ошибки или любые функции, которые работают неправильно.
Создание тестовой среды требует дополнительного времени, но она необходима для того, чтобы защитить вашу действующую систему от сбоев. Иногда может возникнуть желание развернуть простую часть ПО, не опробовав ее сначала в тестовой среде. Тем не менее, даже простое программное обеспечение может вывести из строя ваши текущие системы в случае серьезной несовместимости, поэтому не стоит рисковать.
Создание программы адаптации и обучения сотрудников.
Внедрение программного обеспечения часто рассматривается только с технической стороны, однако и подготовка вашей команды является важной частью процесса. Параллельно с внедрением создавайте программы обучения и адаптации сотрудников, чтобы избежать простоев после того, как ПО будет готово к использованию.
Проведите тестирование для каждой команды, чтобы убедиться, что они знают, как правильно использовать новое ПО для своих конкретных задач.
Установка и интеграция нового ПО.
Теперь пришло время выполнить работы по установке и интеграции.
Именно на данном этапе ваши сотрудники начнут использовать новое программное обеспечение. Если развертывание требует отключения существующих систем, разверните новое программное обеспечение в нерабочее время, когда в систему входит наименьшее количество сотрудников, и предупредите сотрудников заранее.
Если ваше программное обеспечение требует создания новых учетных записей или входа в систему, обязательно разошлите инструкции по созданию учетных записей и входу в систему непосредственно перед запуском или одновременно с ним. Кроме того, полезно разослать напоминания хотя бы за несколько дней до запуска, чтобы исключить любые неожиданности.
Сбор обратной связи.
Важно разработать процесс обратной связи как часть процесса внедрения, чтобы можно было выявить любые сбои, ошибки и другие проблемы после запуска ПО в эксплуатацию. Ранняя обратная связь позволит вам решить проблемы до того, как они получат широкое распространение, поэтому начинайте запрашивать ее, пока сотрудники обучаются работе с ПО.
Процесс получения отзывов от каждого сотрудника, использующего ваше новое ПО, может показаться сложной задачей, но для выявления общих проблем обычно достаточно короткого опроса по электронной почте. Вы можете запросить обратную связь по отделам или на индивидуальной основе.
Независимо от метода, который вы используете для сбора отзывов, ваша команда по внедрению должна иметь открытую линию связи с сотрудниками для оказания поддержки и решения любых возникающих вопросов.

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

Литература:

Нетесова, О. Ю. Информационные системы и технологии в экономике: учебное пособие для вузов / О. Ю. Нетесова. — 4-е изд., испр. и доп. — Москва: Издательство Юрайт, 2023. — 178 с. — (Высшее образование). — ISBN 978–5–534–15926–4. — Текст: электронный // Образовательная платформа Юрайт [сайт]. — URL: https://urait.ru/bcode/510292 (дата обращения: 10.03.2023).
Производственный менеджмент. Теория и практика в 2 ч. Часть 1: учебник для вузов / И. Н. Иванов [и др.]; под редакцией И. Н. Иванова. — 2-е изд. — Москва: Издательство Юрайт, 2023. — 376 с. — (Высшее образование). — ISBN 978–5–534–15029–2. — Текст: электронный // Образовательная платформа Юрайт [сайт]. — URL: https://urait.ru/bcode/514463 (дата обращения: 12.03.2023).
Walker, Royce Software Project Management: A Unified Framework / Royce Walker. — 1st Edition. — Addison-Wesley Professional, 1998. — 438 c. — Текст: непосредственный.

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

внедрение, программное обеспечение, управление проектами, проект

Похожие статьи

Внедрение специализированного программного обеспечения…

Разработка информационной системы корпоративного…

В связи с этим создание и проектирование информационных систем тестирования является

Любая информационная система представляет собой программный продукт, реализующий

Фактически эти процессы — программное обеспечение, которое установлено на разных

Внедрение автоматизированных и самодостаточных информационных систем, особенно в…

Клиентский опыт (Customer Experience) как инструмент обратной…

Внедрение системы CRM в деятельность банка, по мнению Никоновой О. Е. и Алиакберовой Л. З., позволяет [3]

Внедрение показателей удовлетворенности в систему KPI компании. 6. Обратная связь с клиентами.

Основным преимуществом новых программных продуктов, используемых в «офисе

CRM система как необходимый компонент успешного бизнеса.

Методика Scrum: опыт и внедрение в крупных компаниях

Ключевые слова: scrum, управление проектами, система, методология, управленческие

Scrum выстраивает последовательность работы сотрудников в команде при разработке и внедрении проектов.

К тому же в данном контексте владелец продукта обязан (так же, как и Scrum-мастер)

Работа в команде — это один самых эффективных методов мотивации персонала.

Анализ «Технологии быстрых результатов» в управлении…

…внедрением финансово-экономических программных продуктов фирмы «1С» / А. С. Семин.

большое количество программных продуктов системы «1С:Предприятие 8» (ППC 1С).

Любое внедрение программных продуктов должно в максимально быстрые сроки

Стоимость команды внедрения уменьшается — нет необходимости в дорогостоящих РП.

Программное обеспечение для управления трансформацией…

Методологии внедрения мобильного приложения для…

…внедрения мобильного приложения для интеграции с Helpdesk системой ИТ-предприятия.

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

Анализ внедрения программного средства в ООО…

Компания “Информсервис” занимается реализацией Справочно-правовой системы (СПС) “КонсультантПлюс”.

Были выделены 5 уровней спроса на комплекты программного средства

Рисунок 1 – Количество продаж программного продукта.

К вопросу об использовании программных продуктов с открытым…

Внедрение в нашей стране решений на базе Open Source [1] в разные структуры, очевидно, должно начаться

Moodle [3]— среда дистанционного обучения с открытым исходным кодом.

Над системой уже более 10 лет работает международная команда разработчиков, под

Система широко известна в мире, имеет более 60 тысяч инсталляций более чем в 100 странах…

Источник

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

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

Итак, с чего начинается внедрение? С новых серверов и нового ПО? Нет, до этого еще надо дожить. Любое внедрение начинается с вещей гораздо менее интересных. Пройдем по основным этапам.

Постановка задачи.

Как обычно происходит, вызывает вас утром шеф и говорит: «Знаешь, я подумал — нам надо сделать свою электронную почту» или «Тут отдел продаж жалуется, тормозит у них, надо что-то сделать». Очень редко, когда руководство ставит конкретную задачу, в большинстве случаев перед администратором ставится проблема либо пожелание — выбор решения, его реализация и ответственность за это полностью ложится на его плечи.

«Ну что, сделаешь?» — спрашивает шеф, не спешите бить себя пяткой в грудь и уверять что для вас это раз плюнуть, сейчас проверяют не ваши знания и квалификацию, а вашу способность предложить для предприятия оптимальный вариант. На этом этапе вы должны выяснить, какие именно функции нужно реализовать и в каком объеме, а также какой экономический эффект ожидается от данного внедрения и какой его предполагаемый бюджет.

Не бойтесь и не стесняйтесь говорить о возможных трудностях и проблемах, либо о дополнительных затратах. Этим вы покажете себя как грамотного специалиста, думающего в первую очередь о потребностях предприятия. Если же руководство требует «как-нибудь, чтоб работало» реализовать его запросы на текущем и явно не подходящем оборудовании, то стоит задуматься о смене работы.

Если для внедрения требуется новое оборудование, так и скажите об этом. На недоуменный вопрос: «Мы же полгода назад купили новый сервер, ты сам выбирал», поясните, что тогда не стояло таких задач, а покупать сервер «на вырост» — это деньги на ветер, т.к. оплаченная вычислительная мощность не будет использоваться.

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

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

Формализация требований.

Имея на руках список требований можно переходить к их формализации. Ничего сложного и страшного в этом слове нет, просто вы должны «перевести» поставленную задачу с обычного языка на технический. Фактически вам надо составить техническое описание будущей системы. Какие функции и компоненты требуются, какая должна быть нагрузочная способность, требования к доступности и отказоустойчивости.

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

Еще один очень важный момент, про который многие забывают, это список показателей и критериев, по которым следует проводить оценку эффективности системы. Очень хорошо если это будут не «попугаи» бенчмарка, а некий набор показателей, применимый к повседневной деятельности предприятия. Если возможно, выполните нагрузочное тестирование. Если стоит выбор между синтетическими тестами и тестированием на реальных приложениях — выберите последнее. Составьте набор тестов с использованием реальных приложений и учитывающий круг повседневных задач. Также обязательно проведите тестирование существующей системы, чтобы потом была возможность сравнить. Помните, что руководству гораздо интереснее насколько быстрее формируются отчеты и т.п., чем сколько «попугаев» получила система в каком либо бенчмарке.

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

Выработка решения

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

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

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

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

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

Мы крайне не советуем браться за внедрение без практического опыта работы с внедряемым программным продуктом, даже имея под рукой многократно проверенный мануал. В случае какой либо нештатной ситуации что вы будете делать? Спрашивать совета на форумах? А время идет, сроки поджимают.

Внедрение

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

Подобный подход позволяет в любой момент времени показать руководству как идет внедрение, а также вырабатывает самодисциплину и ответственный подход к поставленным задачам. Работы без плана обычно сводятся к тому, что 80% времени занимаются ерундой, а в оставшиеся 20% аврально внедряют, буквально бегая по потолку. Любая задержка, такая как брак оборудования или затягивание сроков третьей стороной, может оказаться для проекта фатальной. Поэтому составьте план и заставьте сами себя его придерживаться, вы увидите, успех не заставит себя долго ждать.

Сдача проекта

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

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

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

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

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

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

Источник

The business landscape nowadays is ultracompetitive, and for small businesses to survive and flourish, they need the right software systems to optimize their workflows, increase team productivity, and bring in more revenue.

Software implementation, however, is no walk in the park. Finding the perfect software platform for your specific business needs requires time and attention — and, in many cases, a significant financial investment.

And then, there’s the human side of the equation. People are creatures of habit, and habits, once ingrained, are extremely difficult to change.

Your employees may already be used to doing things a certain way. If their way works for them just fine, upending their processes may result in their resisting the change, to the detriment of the entire organization.

The solution? Have a system implementation plan in place before embarking on the journey of adopting new software.

Why do you need a software implementation plan?

New software adoption requires serious work, which is why you want to squeeze the most value out of your new system. You want a measurable return for each dollar you spend. That said, a well-thought-out software implementation process will help you succeed.

To further illustrate the value of a solid plan, let’s identify some of the common reasons why software adoptions fail.

Hastily made decisions

Implement a new software system for the right reasons, and not because everyone in your industry has started using this shiny new software. What works for them may not work for you. Do your due diligence and listen to feedback, so you don’t end up with buyer’s remorse.

Involvement of the wrong people in the implementation phase

You don’t want just anyone in your corner during the implementation. You want relevant and capable stakeholders providing their input, assisting with the project plan, and advocating the use of the software.

Improperly configured system

You’ll have to customize or integrate some systems with existing tools to fully maximize them. Be aware of all the options available to you.

Employees not appreciating benefits of the software

If the software’s end users don’t understand what they’re getting out of the new platform, they won’t be keen to adopt it. Chances are they’ll even see it as a hindrance to productivity, instead of a tool they can wield to their advantage. Ensure that the software’s benefits are thoroughly communicated to lessen, if not totally eliminate, friction.

Inadequate software training

Most software vendors provide training, so take advantage of their onboarding programs to train your employees on how to use the new platform.

5 steps to create a successful software implementation plan

In most cases, adopting new software is a big deal. Botch the implementation process, and you’re likely to experience operational downtime and revenue loss.

Conversely, if you do your homework and make the necessary preparations, your organization can enjoy numerous benefits including across-the-board process efficiency, improved visibility, cost savings, and accelerated growth.

Below is a five-step process you can take to make the most of your new software system.

1. Build a business case

No matter the size of your business, software implementation is not something you do just because.

While small businesses are nimbler than their larger counterparts, mistakes can be costly and can cripple any company, especially those on a shoestring budget.

On the other end of the spectrum, larger organizations have difficulty rolling out new software or upgrading existing ones because of the growing complexity of the decision-making process. According to a survey by McKinsey, 72% of senior executives think bad strategic decisions were “about as frequent as good ones or were the prevailing norm in their organization.”

These two scenarios underscore the significance of an airtight business case in any software implementation plan. Moreover, involving your staff early in the process will minimize resistance to change.

So how do you go about making your case?

Highlight the pain points: What challenges is your company facing? What aspects need improvement? The best way to find out is to ask your employees and other relevant stakeholders. If organizational efficiency is at an all-time low, resulting in the company losing money, focus on that. The key is to align business objectives with your goals.
Provide a solution: Outline in detail how a new, say, project management software system can improve team efficiency and productivity, and why it’s critical to addressing the pain points you raised.
Analyze the cost vs. benefits: The main reason you need a strong business case is to justify the software investment. Break down both tangible and intangible costs, as well as the tangible and intangible gains the company is poised to achieve with a successful rollout.
Present a timeline: Set time expectations, specifically how long it takes to evaluate software, implement a new system, and realize ROI (return on investment).
State how you plan to manage change: Research by McKinsey found that 70% of organizational transformation programs fail, so why should executives back your project proposal when it’s less risky to simply turn it down? Number one, by emphasizing the cost of not addressing the company’s nagging pain points. Number two, by making them understand that you know the risks and the steps you plan to undertake to steer clear of the same mistakes other companies have made.

2. Choose a trustworthy vendor partner

Once you have the go-ahead, next on the agenda is finding the most suitable software vendor. This isn’t necessarily easy, considering all the hype surrounding software.

To simplify the selection process, here are a few questions you should be asking:

What exactly do you need, e.g., criteria such as price, features, cloud-based vs. on-premise vs. hybrid, etc.?
Has the provider been in business long enough? What are their credentials?
What are their customers saying about them?
Is the software scalable?
Are there any hidden costs?
Can the software integrate with the systems already in place in your company?
Does the vendor provide software training?
Is after-sales support included in the implementation cost?
Are upgrades and updates cloud-based?

In the case of bespoke software acquisition, keep in mind that developers will deliver exactly what you request of them, which means it’s not enough that you know what you want. You should also be able to articulate it in the most granular way possible.

3. Prevent scope creep

The bells and whistles different software systems provide can set you off track if you’re not careful. Just like in a candy store, the software market offers a whole laundry list of options and customizations.

This is why preparing a needs document that outlines all the features and functionalities of the system you’re looking for is critical when evaluating software. It puts you back on the right path when you start to veer off course.

The needs document should also give vendors a clear picture of your specific needs as an organization.

Scope creep happens the moment you decide to set up the software’s every available functionality or customize every capability all at once. It’s a nice trap to fall into, but it’s still a trap, one that results in:

The implementation process dragging out
Costs increasing exponentially
Stakeholders losing interest

Projects, including software implementation, rarely turn out exactly as expected on day one. Changes during the project life cycle are a natural occurrence, but to prevent scope creep, a certain level of control has to be exercised.

Therefore, it’s vital that your implementation team (more on this below) applies project management best practices and that members work together to maximize software usage for their respective departments.

No matter the size of your team, a collaborative project management tool will allow you to flesh out your software implementation process plan. Some well-regarded options include:

Asana for worker-centric features, such as workload monitoring and built-in project templates, and a user-friendly interface
Basecamp for document storage, task prioritization, and scheduler features
monday.com for customizable budget dashboards and multiple widget types, including calendar and task progress
Wrike for project tracking features such as Gantt charts and kanban boards

4. Assemble the right team

The team you put together is crucial to your software implementation success. Its size can range from as few as two to as many as needed.

In general, the more departments needing the software, the bigger the size of the team. Each department’s representative functions as the champion of the new software who will answer questions and help train colleagues.

Your software implementation team may include the following:

Project owner: Usually the head of the business or department implementing the new software system, may also be a team of executives instead of just one person for larger organizations
Project manager: Responsible for organizing the implementation process, including working out the budget
System administrator: Oversees the system’s setup and technical administration
Superstar end user: The go-to person who serves as the communication liaison between end users and the project team
Members from core departments: The software’s champions from the different departments in your organization

Keep in mind that the type of people you assign to your implementation team reflects how committed you are to the success of the initiative. So include only those who are highly talented, team smart, and equally committed to the project’s success.

5. Drive user adoption

The last thing you want is a software system gathering dust because no one wants to use it.

Then again, if you’re the boss, you can simply instruct your employees to adopt the new system whether they like it or not, right? You’re free to do exactly just that. However, expect employee dissatisfaction and pushback.

Here are some tips to increase the odds of employees actually using the new software:

Prepare your teams for the switch as early as possible: The earlier you let employees know of the change, the more accepting they will be.
Assign a change manager: Someone has to spearhead the change, and employees must be clear on whom to approach for questions, training, feedback, and other information.
Communicate the software’s benefits: When stakeholders understand the good the software will do for them, adoption rates are more likely to increase.
Ensure that training is sufficient: For teams to use the software, they have to know how it operates.
Provide ongoing support: Expect issues to arise, especially during the early stages of the adoption, so a helpdesk or tech support team is essential during this crucial phase.

Get the most value out of software

Implementing new software is a serious undertaking. A software implementation plan is your best friend to ensure it’s pulled off without a hitch.

The steps and ideas we’ve outlined above should steer you towards the path of successful implementation and smooth transition.

Источник

Как поставить цели для CRM, собрать проектную команду, выбрать интегратора, провести аудит и убедиться, что в компании всё готово к процессу внедрения.

Для CRM поговорка «Хорошее начало – половина дела» – не просто красивые слова, это в буквальном смысле так. Внедрение системы – большой, комплексный процесс, успех которого во многом зависит от подготовительной работы. Мы уже рассказывали о том, как происходит внедрение в целом, поэтому сегодня подробнее остановимся на том, что предшествует непосредственному развёртыванию программы. Не пугайтесь количества пунктов: слона надо есть по частям, поэтому мы разбили процесс на составляющие – как раз на один-два укуса.

1. Поставить цели и задачи

Самый первый шаг – определить для себя, какие цели вы ставите перед CRM, и какие задачи она должна решить, чтобы их выполнить. И тут «Увеличить прибыль компании» как цель не подойдёт.

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

Только имея чёткие и реалистичные цели, вы сможете понять,

действительно ли вам нужна CRM;
рассчитывать на то, что интеграторы и сама система смогут реализовать ваш запрос;
увидеть, было ли внедрение успешным, и каковы его результаты.

Но как поставить правильную цель? Вот список вопросов, которые стоит задать себе, чтобы понять, для чего CRM нужна именно вашей компании:

1. Что в компании требует улучшения? Какие аспекты я хочу изменить?

2. По какой причине нам нужна CRM?

3. Какие проблемы компании система должна решить прямо сейчас?

4. Какие функции и инструменты я хотел бы видеть в CRM?

5. Кто из персонала будет (и не будет) пользоваться системой?

6. Готовы ли сотрудники к внедрению CRM?

7. Каких результатов я ожидаю от системы через месяц? Через полгода? Через год?

К этому брейнсторму можно и нужно привлечь ключевых сотрудников. Как в случае с любым мозговым штурмом, пишите все пожелания к CRM, которые придут в голову, даже нестандартные: так рождаются прорывные идеи. Затем проанализируйте список и выберите пункты, которые закроют застарелые «боли» компании, а также те, что касаются автоматизации процессов. Это база, на которой будут строиться ваши цели и задачи.

Чёткие цели могут выглядеть так: «Увеличить ежемесячную выручку на 20%», «Повысить процент выполнения плана в отделе продаж до 70%», «Повысить конвертацию тёплых лидов на 30%».

Да, некоторые вещи трудно выразить в цифрах, например, «Выйти на новый рынок» или «Сделать работу сотрудников прозрачной». Но в целом чем яснее цель, тем больше шансов, что она будет достигнута.

В дальнейшем обсудите ваш список идей и пожеланий с интегратором CRM. Это один из пунктов, на основе которых он будет рекомендовать систему и/или её кастомизацию. Специалисты интегратора помогут откорректировать цели, чтобы они были реалистичными и точными, и подскажет, какие задачи можно решить сразу, на базовых настройках программы.

2. Выбрать правильное время для начала внедрения

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

3. Зафиксировать показатели

Чтобы понять, насколько успешно прошло внедрение, и какие результаты принесла CRM, необходимо оценить и зафиксировать показатели, которые были до появления системы. Речь идёт о таких ключевых моментах, как время на подготовку коммерческого предложения для клиентов; число звонков, которые совершают менеджеры ежедневно; количество лидов; объём продаж и т.д.

4. Выбрать вариант внедрения и интегратора

Внедрять систему можно и самостоятельно. Но в этом случае будьте готовы выделить сотрудника или даже команду, которая:

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

Для человека без опыта вникнуть во все эти вопросы будет сложно. Даже если у вас в штате есть люди, которые имеют достаточно знаний и навыков, скорее всего, внедрение CRM займёт гораздо больше времени и сил, чем при привлечении команды специалистов.

И не факт, что процесс пройдёт успешно. Наверно, практически все интеграторы сталкивались с ситуацией, когда их приглашали «доработать» самостоятельно внедрённую систему. Зачастую это означает, что приходится вносить не только серьёзные изменения в сам процесс работы с CRM, но и менять её саму.

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

5. Собрать команду CRM

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

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

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

Затем вам необходимо собрать проектную команду и назначить руководителя. Эти люди помогут сформировать цели внедрения и требования к CRM, обеспечить принятие системы в коллективе, будут взаимодействовать с интегратором и в целом станут локомотивом для перемен.

В состав команды обязательно должны входить:

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

Ответственным может быть коммерческий директор или директор по развитию, руководитель отдела продаж – то есть человек, имеющий большое влияние в организации, понимающий значение CRM и заинтересованный в её успешном внедрении.

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

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

Первое: к работе с интегратором нужно подключить и рядовых менеджеров – именно они знают все тонкости работы с клиентами; видят изнутри, как построены процессы. Руководитель, особенно если это не непосредственный начальник отдела, может описать процесс так, как он его представляет или хочет видеть, а не так, как он происходит на самом деле.

Второе: назначая ответственных и ключевых пользователей, имейте в виду не только их роль и влияние, но и их «подкованность» в работе с современными технологиями. Как правило, успех внедрения и принятия CRM увеличивается с уменьшением возраста. Младшее поколение уже не помнит ни дня без гаджетов, социальных сетей и постоянного доступа в интернет: ему освоить (и продвигать) новую программу будет проще, чем опытному «продажнику», который на «вы» с компьютером.

6. Провести аудит компании

Здесь аудит – это анализ структуры организации и её бизнес-процессов, с целью выявить её слабые места и найти способы их преодоления с помощью CRM, а также унифицировать и перенести эти процессы в систему.

Этот этап лучше провести совместно с интегратором. Проводя аудит самостоятельно, вы рискуете проглядеть важные моменты – либо проблемы, либо возможности для повышения производительности. Бизнес-аналитики партнёра смогут посмотреть на компанию со стороны и увидеть какие-то болевые точки, избыточность или недоработки, которые изнутри уже не заметны. Например, где теряются заявки, на какие дела тратится слишком много времени, что стоит автоматизировать в первую очередь, какие процессы можно улучшить, чтобы сделать бизнес более эффективным, и т.д.

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

Если он будет действовать самостоятельно, то постарается дать CRM максимальный функционал, чтобы вы получили все инструменты, функции и элементы, которые потенциально могут понадобиться вашей компании. В итоге вы рискуете получить слишком сложную систему: сотрудникам будет сложнее изучать программу и работать с нею, а многие «фишки» (за которые вы заплатили!) просто не будут востребованы.

Для проведения аудита интегратор будет задавать множество вопросов об организации и её работе. На этой базе в дальнейшем будут прописываться коммуникационные и бизнес-процессы: кто, когда и как выполняет те или иные действия и операции, в какие сроки и по каким этапам. Будут выстраиваться воронки продаж: их этапы, поля, схема движения лидов и взаимосвязи между воронками. И отбираться действия для автоматизации в CRM.

7. Определить количество пользователей

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

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

8. Проверить аппаратное и программное обеспечение

Убедитесь, что ваше аппаратное и программное обеспечение соответствует требованиям выбранной CRM. Устаревшее оборудование может привести к ошибкам и медленной работе системы: это никак не поспособствует её принятию в коллективе. Пользователи обычно не винят свои компьютеры – они винят CRM.

9. Проанализировать уже установленное ПО

Анализ уже существующего в компании ПО поможет понять, от каких программ можно отказаться после внедрения CRM, и с какими из них систему нужно интегрировать.

10. Выбрать CRM-систему

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

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

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

11. Определить бюджет и сроки проекта

Теперь, когда определены цели, выбран интегратор и CRM, а пользователи посчитаны, нужно точно определить бюджет на развёртывание системы. Стоимость работы интегратора зависит и от его практики, и от самой CRM, и от масштабов компании-заказчика, и от пакета услуг.

От этого же зависят и сроки. Невозможно внедрить большую, сложную систему с обширным функционалом за одну неделю. Если вы ограничены во времени, стоит расставить приоритеты и раздробить процесс на составляющие: сперва внедрять самые важные инструменты (и обучать им сотрудников), затем менее востребованные. Принцип «одна неделя – одна функция» позволит сотрудникам быстрее начать работу в новой системе и плавно входить в курс других возможностей.

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

12. Определиться с техническим заданием

Собрав все сведения на предыдущем этапе, интегратор пропишет альфа-версию технического задания и согласует его с вами. В ТЗ прописываются все основные требования к CRM, сроки и бюджет, перечень работ, послепродажное обслуживание и т.д.

Но если у вас большая компания, и внедрение растянется на долгий срок, разумно использовать гибкий (Agile) подход, когда технического задания, по сути, не существует, и список ближайших работ формируется и согласовывается каждые 2-3 недели. Это позволит вносить нужные коррективы по мере изменения дел, рынка и т.д. Ситуация, как мы знаем, может меняться очень быстро, и идеи, которые были востребованы полгода назад, сейчас уже могут быть нерелевантны.

13. Подготовить данные для переноса в новую CRM-систему

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

Перед подготовкой задайте себе несколько вопросов:

1. Какие именно данные нужно перенести в CRM?

2. Где сейчас хранятся данные (в другой системе, в таблице Excel, в бумажных блокнотах менеджеров)?

3. Какой «возраст» клиентов релевантен для вас (то есть, например, стоит ли вносить в систему информацию о клиентах, с которыми последний раз взаимодействовали год, два, три назад)?

4. Насколько актуальна имеющаяся информация (меняются номера телефонов, сотрудники, адреса почты и т.д. – когда последний раз вы связывались по этим контактам с этими людьми)?

5. Что делать с дублированной информацией?

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

14. Верно оценить сложность системы

Не стоит недооценивать сложность любого программного продукта. Даже если вы внедряете «простую» CRM, убедитесь, что у пользователей есть достаточно времени и обучающих материалов, чтобы разобраться с её функциями и понять, как использовать систему в полной мере.

Успешного внедрения!

Источник