Внедрение программного обеспечения — процесс настройки программного обеспечения под определенные условия использования, а также обучения пользователей работе с программным продуктом.
При внедрении программного обеспечения требуется действия в трех плоскостях работ:
Первая из них – это выделение критических, с точки зрения общего результата, процедур в деятельности организации. Это выполняется на этапе осознания клиентом целей.
Вторая плоскость работ – это составление Технического задания на внедрение, то есть составление плана того, как будет внедряться портал в конкретную организацию.
Третья – это собственно выполнение работ по внедрению портала.
Выявление критических процедур
Клиент иногда не может чётко и конкретно сказать какие проблемы он собирается решить с помощью корпоративного портала. Им озвучиваются неясные ожидания, пожелания, «хотелки». Помочь клиенту в определении таких критических точек необходимо на стадии составления брифа. Необходимо также выявить иерархию значимости этих проблем для конкретной организации и критерии того, что будет считаться решением проблемы.
Составление ТЗ и Проектной документации.
Цели этапа — дать понять как Заказчику, так и Исполнителю — где начинаются и где заканчиваются работы; что будет реализовано при внедрении, а что нет; каким образом будет осуществляться приемка и тестирование.
Внедрение
Третий этап — это собственно выполнение работ по внедрению по составленному ТЗ.
Примечание: В списке этапов внедрения нет описания юридических моментов взаимодействия между клиентом и студией: заключения договоров, актов приёмки/сдачи и прочих документов. Эти юридические аспекты в курсе не рассматриваются.
Типы клиентов
Понять с кем имеете дело |
Клиент — он разный, каждый раз другой. Сценарии взаимодействия с клиентом зависят от его внутреннего запроса. Во всех ситуациях, когда описывается какой-либо инструментарий или рекомендация, нужно понимать границы ее применения и сценарии использования. Можно выделить четыре основных типа клиента:
- Мы все знаем сами. Сделайте, то что вас просят. Это крупные компании с выстроенными бизнес-процессами, имеющими, подчас, не просто IT-отдел, но и целый департамент. В большинстве, такие компании уже имеют какую-либо вариацию корпоративного портала из-под другой платформы (часто самописную) и требуется перенос. Им не нужно постепенное внедрение битрикс корпортала в режиме внутреннего альфа-тестирования потребностей.Такие клиенты сами говорят, что нужно и какие инструменты будут даны пользователям, какие категорически заблокировать, а какие доработать или разработать с нуля. Можно запросто услышать безапелляционно высказанную фразу: «У нас Задачи не приживутся, их нужно отключить».Отбирать в таких случаях «хлеб» у отдела департамента аналитики, маркетинга, IT и прочих, чревато. Это может быть расценено, как попытка показать некомпетентность сотрудников по их профессиональным вопросам в глазах руководства. В лучшем случае, вас будут каждый раз останавливать, в худшем — прекратят с вами работать. К процессу выявления критических процедур, если он будет, вас просто не подпустят. Техническое обслуживание они проводят самостоятельно или аутсорсом без предоставления внешнего доступа.Только необходимость в серьезной доработке может вернуть их за стол переговоров с подрядчиком.
- Нам нужно сделать вот это и вот так. Ваши предложения — изложите, мы их рассмотрим. Это компания с выстроенными бизнес-процессами. Корпортал отсутствует или имеется в зачаточном состоянии в виде, например, файлохранилища. Корпортал рассматривают как инструмент для оптимизации взаимодействия и контроля.Ключевой момент в выстраивании работы с таким Заказчиком — понимание того, что, скорее всего, работать придется через буфер, «сломанный телефон» в чистом виде. Вы рассказываете (презентуете, выставляете КП и т.п.) некоему менеджеру, он слушает, понимает, насколько может понять, и делает, в свою очередь, презентацию перед руководством, принимающим решение.Результат непредсказуемый и плохо управляемый. Ключ к эффективному контакту с таким клиентом лежит в постепенном «втирании в доверие». Помочь менеджеру (ответственному лицу) в наглядном и простом представлении результатов и предложений для руководства. Успех проекта зависит от того, насколько успешным будет в результате менеджер, контактирующий с вами.
- Нам нужно прийти вот сюда, давайте вместе подумаем, в чем нам сможет помочь корпортал. Идеальный Заказчик. Цели и задачи или уже сформулированы, или Заказчик готов к их выработке в процессе работы.
- Ну, вы же специалисты. Сделайте, что там нужно и чтобы все хорошо работало. Вас спасет:
- выявление и документирование целей и задач;
- подробное ТЗ;
- разбивка проекта на логически завершенные блоки и временны́е этапы;
- компетенция аналитика, позволяющая сформулировать предложение на основе не только собранных исходных данных, но и анализа эффективности внедрения и формирования предложений по коррекции.
Цели и задачи
Внедрение преследует свои цели, которые решаются последовательным решением списка задач.
Цели и задачи
Внедрение преследует свои цели, которые решаются последовательным решением списка задач.
Цели
Цели внедрения — некий производственный результат, для достижения которого реализуется проект «Корпоративный портал».
Как правило, решаются цели оптимизации производственного процесса. Цели могут быть многоуровневые, разные по значимости, разные по сложности реализации. Чем подробнее описаны цели, тем осознаннее клиент (и внедренец) подходит к проекту «корпоративный портал». Цели достигаются (или не достигаются) и могут быть объективно измерены, а также обязательно привязаны ко времени.
Например, для отдела продаж: к 1 декабря увеличить количество обрабатываемых входящих заявок (фиксация лида, первичный ответ, формирование уточняющего запроса, постановка сопряженных задач и т.п.) с 15 до 25 штук на менеджера продаж в день.
Еще пример, сократить время интеграции нового сотрудника в структуру компании с 2 дней до 4 часов, исключить из процесса интеграции сопровождающего HR-сотрудника, разработать и внедрить с 1 декабря.
На самом деле это очень-очень сложно — формировать цели. В ряде случаев выявляется:
- недостаток исходных данных и аналитики по объекту оптимизации со стороны Заказчика,
- непонимание Заказчиком смысла процедуры постановки целей.
Если ваша студия именно разработчики, а не бизнес-консультанты по целеполаганию, то, возможно, есть смысл вообще отказаться от наличия такого раздела в ТЗ, чем писать в него то, что не является целями или они надуманы (просто для того, чтобы были). И тогда реализация проекта сведётся к решению задач без привязки к результатам. Заказчик в таких случаях полагает, что мечты сами превратятся в цели и будут достигнуты автоматически.
Желательно выстраивание иерархии целей:
- Базовые — цели, без реализации которых корпоративный портал нельзя считать внедрённым. То есть то, ради чего, собственно, внедрение и затевалось. По другому это можно назвать «порог успешности».
- Второстепенные — цели, достижение которых — это приятный «бонус».
- Первичные цели — цели, которые вам кажутся самыми легко достижимыми и способными показать сотрудникам эффективность проекта.
- Приоритетные по сроку — цели, достижение которых необходимо в первую очередь.
Примечание: Цели меняются. Заявленные базовые цели в процессе внедрения вполне могут измениться или отойти в разряд второстепенных и наоборот.
Первичные цели отличаются от Приоритетных по сроку. Первые направлены на «ВАУ-эффект» среди сотрудников компании, что должно возбудить и поддерживать интерес к порталу у сотрудников до тех пор, пока работа на портале не войдёт в привычку и корпоративную культуру. Вторые — это собственно производственные цели и должны дать эффект быстрой отдачи в производственном плане.
Базовые цели при этом вполне могут не попадать в Приоритетные по сроку. Как правило, это сложные цели автоматизации и оптимизации основной производственной деятельности компании, к которым нужно подойти особо внимательно.Примечание: Предложенный способ ранжирования — не единственный. Можно, например, выписать все цели списком, в соответствии с логикой внедрения и по срокам, и назначить каждой цели (задаче) свой вес. Получится своеобразный KPI среди задач.
Возможны другие способы ранжирования целей. В каждом конкретном случае нужно выбирать оптимальный для него способ.
Задачи
Задача — конкретные действия, которые нужно выполнить для достижения поставленной цели.
Задача отвечает на вопрос: что нужно сделать чтобы достичь цели. Задача конкретна и процедура ее формирования, в отличии от цели, чаще всего однозначно понимается и подрядчиком, и Заказчиком.
Примером задачи может быть освоение Живой ленты и сообщений, Календаря и других инструментов, решающих текущие, мелкие, но неудобные моменты в работе сотрудников. Например, создание Базы знаний или Бизнес-процесса по заказу меню из столовой на обед.
Возможен парадокс: правильно решенная задача может не привести к достижению цели. Если цель неправильно сформулирована.
Порог успешности, Критерии успешности
Порог успешности |
Порог успешности — минимально необходимый набор целей, достижение которых позволит говорить об успешном внедрении портала.
Порог успешности — понятие относительное, так как Базовые цели могут быть реализованы в разных объемах. Поэтому можно говорить о такой вещи, как критерии успешности.
Критерии успешности |
Критерии — критерии, которые будут характеризовать успешное внедрение.
Критерии успешности нужны для определения, когда можно считать цель достигнутой. Чем объёмнее, сложнее и труднее цель, тем больше всяких нюансов вылезает при её достижении. Например, в качестве цели высказано: «Перевести на инструмент Бизнес-процессы деятельность компании». Цель слишком общая, но она высказана клиентом.
Если студия-внедренец подпишется под ней без всяких оговорок, то её будет жалко: невозможно создать инструмент, удовлетворяющий любую потребность любой компании. И реализовать таким образом сформулированную цель крайне трудно.Внимание! Необходим конкретный список бизнес-процессов и логическая блок-схема, статусы перехода, права и роли участников на каждом шаге.