Как правильно внедрять программу

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

Хочется уже запустить ее в работу. Как же сделать это просто, быстро и без серьезных проблем?

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

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

Как описывать и внедрять бизнес-процессы в компании?

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

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

Рассмотрим примеры спонтанного внедрения из нашей практики.

1. В теплосети одного города на Урале пробовали собственными силами запустить программу «1С:Управление теплосетью 2» (УТ2), просто установив программу и купив учебные курсы. О проектах внедрения заказчик не слышал в принципе. «Мы купили программу, а что бы она заработала – нужно ещё заплатить?!». Это всё равно, что купить небольшой самолёт и удивляться, что летать не получается. Хотя все мы знаем, что для полета нужно заплатить за лицензию пилота и оборудовать аэродром. В этом случае внедрение не происходит вовсе, и программа не запускается.
2. Другой пример, в одной из из теплосетей Сибири. Третий год коллеги пытаются запустить программу УТ2 собственными силами, обращаясь к нам только за небольшими доработками. Но программа все никак не перейдет в промышленную эксплуатацию. Что же там происходит? Правильно — спонтанное внедрение. Установили программу. Посадили штатного программиста – внедряй, ты же программист!

За что мы тебе деньги платим? Цель – чтобы всё работало. Срок – в ближайшее время! Тут мы имеем дело с неопределенными целями проекта, размытой проектной командой и отсутствием сроков.
Проектное внедрение по договору с компетентным подрядчиком решает перечисленные проблемы. Цели внедрения, сроки и бюджет определяются в момент заключения договора, заказчику есть с кого спросить. А подрядчик заинтересован в том, чтобы проект был успешным еще больше, чем заказчик, иначе он просто ничего не заработает. Поэтому всегда начинает внедрение с приказа, определяющего проектную команду, и заранее обсуждает премирование сотрудников заказчика по результатам проекта.

3 лучших способа контролировать выполнение задач сотрудниками

Рассмотрим пример успешного проектного внедрения.

Первое внедрение программы УТ2 было осуществлено в теплосети города-милионника. Проект длился 4 месяца и окончился к концу 2018 года. Работы выполнялись смешанной проектной командой. Руководителя проекта выделила фирма-партнёр 1С. А основную работу выполняли пятеро специалистов ИТ-службы заказчика, имевшие опыт подобных проектов.

Конечно, не все теплосети могут себе позволить собственную команду ИТ-специалистов. В небольших ресурсоснабжающих предприятиях IT-отдел представлен одним сисадмином. Он и программист, и заправщик принтеров, и специалист техподдержки, и методолог. Он же Гога, он же Гоша. Тут уже никак не обойтись без договора на внедрение с компетентной фирмой.

Лучше всего привлечь разработчика отраслевого решения.

Устав проекта и приказ о внедрении программы .

Итак, мы поняли, чем проект отличается от «занятий внедрением». Четкие цели, границы проекта, определение требований, сроков и бюджета проекта. Описание проекта заносится в его устав. Типовой устав проекта внедрения содержит следующие разделы:

• Обоснование проекта
• Содержание проекта, его цели
• Сроки и бюджет проекта
• Организация проекта, план коммуникаций
• Границы и допущения проекта
• Риски проекта

Календарно-сетевой график проекта.

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

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

Например, один из заказчиков приобрел программу УТ2 еще в 2018 году. На наши вопросы, как идут дела, отвечают: «Мы вовсю внедряем, приказ был. Но пока работаем на старой программе». Программа имеется и директор приказал ее внедрить, определил срок, и сами сотрудники очень хотят. Но у «выделенных» специалистов нет времени на новую программу.

Ручная работа съедает всё время.

В случае, если Заказчик заключает с нашей компанией договор на внедрение, процесс идет строго в соответствии с календарно-сетевым графиком проекта (КСГ).

Руководитель проекта со стороны компании Софт-портал планирует работы и следит за выполнением работ, причём следит не только за своими коллегами. Этот же руководитель контролирует команду заказчика, следит за правильностью ввода данных и проверки результатов. Документирует запросы на изменения и работает с отклонениями.

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

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

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

Источник: soft-portal.ru

Как внедрить ПО в компанию без проблем и потерь

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

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

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

Методология

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

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

Начинаем тестирование

Залог успешного тестирования — в трех составляющих: время, ответственность и участники.

• Время. Тестирование должно быть ограничено по времени. Ключевая задача — провести оценку и получить на выходе эффективный инструмент, помогающий в ежедневной работе. Установите временные рамки тестирования заранее: оцените, сколько дней, часов или недель вам потребуется, чтобы полностью разобраться в инструменте (или инструментах, если выбираете между несколькими поставщиками) и принять решение.
• Ответственность. Важно выбрать ответственного за тестирование. Если речь идет о системах автоматизации перевода, в этой роли обычно выступают руководители отдела перевода. Автоматизация подразумевает внедрение инструментов контроля качества и аналитики, помогает оценить нагрузку сотрудников, чтобы оптимизировать модели работы. Кому, как не руководителю, нужны эти данные? Но и другие сотрудники, в зависимости от степени заинтересованности, могут успешно руководить тестированием и аккумулировать результаты.Если не выбрать руководителя тестирования на вашей стороне, то будет невероятно трудно оценить результаты использования, провести анкетирование, запустить процесс, организовать обучение, а впоследствии собрать результаты для анализа.
• Участники. А вот от пользователей (сотрудников отдела или его части) требуется детальная оценка функционала, интерфейса и удобства. Особенное внимание следует уделить сотрудникам, которые работали с похожими программными решениями. Если их много — обучение пройдет значительно проще. Согласно статистике работы пользователей в Smartcat, специалисты, которые уже работали с подобными решениями, проще осваивают новые программы. И результаты такие сотрудники показывают быстрее. Тем не менее, мы в любом случае проводим обучение: формируем несколько групп, организуем разноуровневые консультации при внедрении и после него (если требуется). Такая система уже показала эффективность в крупных компаниях: Сбербанк, «Евразийский банк» и другие. Также данные сотрудники могут быть компетентами на тестировании, к их мнению стоит прислушаться. Как правило, их оценка будет носить объективный, предметный характер. Крайне важно, чтобы руководитель проекта включил тестирование и заполнение опросников по его итогам в функциональные обязанности своего отдела. Кажется, что на этом по участникам все. Но это должны быть не только пользователи программы, но и сотрудники других отделов. Обязательно подключите другие департаменты как можно раньше. Как минимум, ИТ-отдел и команду юристов: у них может быть свой список требований. Например, они порекомендуют, какой вариант установки выбрать — серверное решение, облачную модель или, скажем, «частное облако» (установка решения на изолированной физической или виртуальной машине с собственной базой данных в дата-центре). Повторюсь, подключайте коллег как можно раньше — объясняйте важность, используйте административный ресурс, возьмите в заложники любимый кактус. Тестировать облачную версию решения, а устанавливать серверную неправильно: разворачивать демостенд нужно в том виде, в котором он будет работать после покупки. Иначе последствия будут плачевными: при масштабировании проекта на всю организацию вылезут проблемы и ошибки — перегрузка серверов, недоступность облачных решений в закрытой сети и т.д.

Этапы тестирования

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

1. Интервью с участниками процесса. Оно проводится, чтобы подготовиться к обучению, выбрать версию установки и определиться с предварительными требованиями по доработке основного функционала. Устно или письменно.
2. Составление документа для оценки решения — функциональная матрица или техническое задание. Обычно этот документ состоит из нескольких частей: интерфейс, функциональные особенности, адаптация и т.д.
3. Согласование схемы внедрения. Выбираете платформу (облако, сервер, десктопная версия), подписываете договор тестирования и, если необходимо, NDA.
4. Установка решения. Этим может заняться ваш ИТ-отдел или вендор ПО. Например, в Smartcat специалисты проконсультируют по всем вопросам и помогут при установке.
5. Обучение. Как мы уже говорили, может проходить в несколько этапов и зависит от глубины познаний сотрудников и их количества.
6. Собственно тестирование.
7. Подведение итогов тестирования. Оцениваете результаты и впечатления участников.
8. Экономическое обоснование эффективности внедрения решения. Описываете финансовые выгоды от внедрения программы.

Да, процесс тестирования комплексный и может потребовать времени. Но в результате это поможет сократить затраты, автоматизировать работу сотрудников и повысить эффективность отдела. При выборе поставщика выясните, у кого есть ресурсы на плотное участие в процессе: от составления ТЗ до технической поддержки каждого пользователя в режиме 24/7.

Источник: ru.smartcat.com

2 подхода к внедрению программных продуктов

Господи, дай мне терпение принять то, что я не в силах изменить,
Дай мне силы изменить то, что возможно,
И дай мне мудрость научиться отличать первое от второго.
(богослов Рейнольд Нибур (Dr. Rheinhold Niebur)

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

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

Андрей Арбузов
Генеральный директор Консалтинговая компания Эрбика
Подход
«От программы»

Подрядчик рассказывает Заказчику о возможностях и удобствах программного продукта. Главное меню, формы, отчеты. «Смотрите какая хорошая программа». Да, программа хорошая, но подходит ли она бизнесу?

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

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

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

А вопросов возникает масса. Как построить проект внедрения, с чего начать? Какие функции программы задействовать? С какой детализацией описывать? Что автоматизировать, а что лучше оставить в Excel? Как распределить функции между сотрудниками?

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

Организационная часть проекта лежит на Заказчике, управляет проектом Заказчик, за результаты проекта отвечает Заказчик.

Подрядчик всегда вправе спросить «К программе претензии есть?»

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

• Требует от сотрудников Заказчика высокую квалификацию по организации проекта.
• Бизнес «прогибается» под программу.
• Риски проекта полностью ложатся на Заказчика

Подход
«От бизнеса»

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

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

Проект имеет статус «Изменение бизнеса с помощью программы», а не «внедрение программы»,

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

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

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

Источник: erbica.ru