2023/07/05 11:06:22

Внедрение 1C:ERP — взгляд со стороны подрядчика и клиента

Внедрение новой информационной системы, как правило, не проходит гладко. Любой проект требует вовлечения всей компании и больших изменений, в которых сотрудники видят скорее создание проблем, чем их решение. Как следствие, в адрес группы внедрения поступает большой поток негативной обратной связи, в котором непросто распознать истинные мотивы сотрудников и целесообразность действий внедренцев. Слова о том, что подрядчик «не понимает, как мы работаем, он сломает все наши процессы», могут говорить как о неготовности специалиста принять изменения и перестроиться на новый процесс, так и о действительном непонимании процессов предприятия со стороны интегратора. ИТ-компания SimbirSoft имеет опыт работы в таких ситуациях с обеих сторон баррикад — у них работают и специалисты, которые внедряли ERP, будучи ответственными сотрудниками на производстве, и непосредственно специалисты-интеграторы. В этой статье Светлана Кузнецова поделится видением процесса внедрения 1С:ERP с двух сторон, а также примерами и лайфхаками коллег, как те или иные моменты можно сделать более эффективными.

Содержание

Светлана Кузнецова
Опыт работы в ИТ около 15 лет, Master of Business Administration, руководитель направления web и 1C-разработки, спикер конференций и автор статей.


Каждое внедрение информационной системы (далее — ИС) включает следующие этапы:

  • Обследование
  • Проектирование/моделирование
  • Написание технического задания
  • Разработка
  • Внедрение/запуск
  • Сопровождение

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

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

Этап обследования

Цель и участники

Цель этапа — собрать информацию о целях и границах проекта, структуре организации, существующих потоках данных между подразделениями и системами, процессах в организации и их недостатках, а также сформировать предложение по оптимизации, просчитать стоимость и сроки внедрения ИС. Как DevOps-сервис помогает «разгрузить» высоконагруженные системы BPMSoft

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

Участники со стороны интегратора:

Участники со стороны заказчика:

  • Руководитель проекта
  • Специалисты — «носители знаний», которые вживую знают описываемый процесс и могут во время интервью дать ценные советы, чего им не хватает в работе, как оптимизировать и упростить процесс.

Кроме полезных процессов, на этом же этапе обнаруживаются:

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

Особенности

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

Image:Frame_8220(2).jpg

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

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

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

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

Также на этапе обследования описывается структура предприятия и ролевая модель.

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

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

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

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

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

Итоги

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

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

  • Характеристика объекта автоматизации:
    • описание организационной структуры
    • описание основных бизнес-функций каждой организационной единицы объекта с указанием количественных качественных характеристик
    • описание информационных потоков внутри объекта
    • описание внешних взаимодействий объекта
    • описание бизнес-процессов

  • Описание существующей информационной системы:

    • текущее состояние IT-инфраструктуры:

    • логическая структура системы:

      • функции подсистем
      • внутренние и внешние связи
      • используемые архитектурные и технологические решения
      • связи между подсистемами — какие данные по ним передаются и какие протоколы взаимодействия используются

    • текущие и планируемые объемы данных в системе
    • структура базы данных
    • интерфейсы внешних взаимодействий

  • Описание недостатков существующей системы:

    • видимые и скрытые недостатки
    • текущие и те, которые могут возникнуть с развитием бизнеса

  • Обоснование необходимости разработки или модификации системы

    • заключение о качестве существующей системы, целесообразности ее модификации или замены

  • Предложения:

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

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

Этап проектирования/моделирования

Цель и участники

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

Цель этапа — отразить бизнес-процессы заказчика и зафиксировать функциональные разрывы, для устранения которых потребуются доработки.

На этапе моделирования определяются:

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

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

Участники этапа со стороны интегратора:

  • Руководитель проекта
  • Аналитик
  • Архитектор

Участники этапа со стороны заказчика:

  • Руководитель проекта
  • Сотрудники — «носители знаний», отвечающие за функциональные модули

Особенности

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

  • Примечание. Всё, что можно реализовать с помощью типовых программных продуктов , важно описать в модели. Функциональность, которую невозможно разработать таким способом, описывается в качестве ФТ. На их основании составляется ТЗ и выполняется последующая доработка системы.


После составления детально описанного реестра бизнес-процессов с точками разрыва проводится их категоризация на:

  1. Критично важные — без них нельзя запускать проект.
  2. Средней важности — проект можно запустить, но эти точки разрыва нужно устранить в течение 1-3 месяцев после запуска проекта.
  3. Маловажные точки разрыва — их можно устранить в течение 6-12 месяцев после запуска системы в эксплуатацию

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

Также на этом этапе разрабатывается нормативно-справочная информация (далее — НСИ). В процессе подготовки НСИ необходимо определить структуры справочников, элементы и особенности их заполнения, а затем всё это согласовать с заказчиком.

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

Итоги

Результаты этапа моделирования:

  • Детализированный и категоризированный реестр бизнес-процессов с точками разрывов.
  • Регламенты работы в системе, согласованные с пользователями.
  • Установленные границы автоматизации проекта.

Этап написания технического задания

Цель и участники

На основе данных, полученных на предыдущих этапах (реестр бизнес-процессов и функциональные требования), составляется детализированное техническое задание.

Участники со стороны интегратора:

  • Руководитель проекта
  • Функциональный и технический архитекторы
  • 1С-аналитики

Участники со стороны заказчика:

  • Руководитель проекта
  • Ключевые пользователи
  • Руководители подразделений, чьих бизнес-процессов коснется результат внедрения
  • Исполнительные лица, ответственные за внедрение

Особенности

ТЗ состоит из версий, оглавления, описания бизнес-процессов (включая схемы в нотациях — IDEF0, BPMN, EPC или др), требований к интерфейсу, блоков для разработчика с уточнениями применяемых типов данных, документов и справочников, а также правил сдачи — как и на каких контрольных примерах будет проводится приемка разработанного блока.

Итоги

Перед стартом разработки должны быть готовы следующие документы:

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

Все эти документы составляют основу проекта по внедрению :ERP и являются важными составляющими процесса внедрения системы.

Этап разработки

Цель и участники

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

Участники со стороны интегратора:

  • Руководитель проекта
  • Технический и функциональный архитектор
  • 1С-аналитики
  • 1С-разработчики
  • Администратор базы данных (если такого специалиста нет у клиента)

Участники со стороны клиента:

  • Руководитель проекта
  • Администратор базы данных
  • Руководители и конечные пользователи подразделений заказчика

Особенности

Коммуникации между командой программистов и аналитиков важны на всем этапе разработки по нескольким причинам:

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

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

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

Операция Возможные проблемы Действия в случае возникновения проблемы Время на операцию Сценарий проверки корректности выполнения
1. Информировать пользователей о закрытии системы на редактирование. Канал информирования: корпоративная почта и личное оповещение сотрудников руководителями подразделений. Информирование произвести за сутки и за час до закрытия. Текст сообщения `...` - -Собрать подтверждение от руководителей подразделений о том, что сотрудники подразделения проинформированы
2. Закрыть доступ на редактирование в рабочей системе - -
3. Развернуть новую рабочую систему по адресу `…` Не пройдены сценарии проверкиОткат изменений. Информирование пользователей. Возврат ИС на проверку и корректировку. ИС открывается по адресу…Сценарии проверки с соответствующими ролями (ссылка на документ)

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

Итоги

Результаты этапа:

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

Этап внедрения / запуска

Цель и участники

Цель этапа — ввести систему сначала в опытную, а потом в промышленную эксплуатацию.

Image:Frame_8220(1).png

Участники этапа со стороны интегратора:

  • Руководитель проекта
  • Консультанты по всем блокам
  • Аналитики
  • Системные администраторы (DevOps-инженеры)

Участники этапа со стороны заказчика:

  • Руководитель проекта
  • Исполнительные лица, ответственные за внедрение системы :ERP в организации
  • Администратор базы данных
  • Конечные пользователи

Конечные пользователи — это пользователи 1С:ERP, которые работают непосредственно с системой на ежедневной основе. Это могут быть менеджеры, бухгалтеры, продавцы и другие сотрудники, зависит от конкретной организации.

Особенности

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

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

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

Итоги

После запуска ИС в промышленную эксплуатацию необходимо иметь:

  • Задокументированные и утвержденные заказчиком результаты тестирования. Работоспособность системы необходимо проверить в реальных условиях и убедиться в ее соответствии заданным требованиям, которые были составлены еще на этапе ТЗ.
  • Актуализированная и собранная в одном месте документация.
  • Пользователи системы проходят обучение и внедряют полученные навыки в свою работу.
  • Разработанный план мероприятий по поддержке и сопровождению ИС после запуск.

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

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

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

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

Участники этапа:

  • Специалисты заказчика
  • Специалисты компании-интегратора
  • Смешанная команда

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

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

Резюме

Перед стартом процесса внедрения :ERP на предприятии рекомендуем учесть следующие моменты:

1. Обосновать необходимость и быть готовыми к внедрению системы. Перед принятием решения о внедрении 1С:ERP необходимо исследовать работу предприятия, выявить недостатки или узкие места в производственных процессах, которые можно устранить с помощью этой ИС.

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

3. Сформировать профессиональную опытную команду проекта из состава предприятия и компании-интегратора.

4. Правильно выполнить все вышеизложенные этапы: обследование, проектирование, написание ТЗ, разработка, запуск в эксплуатацию. Иметь под рукой всю актуальную информацию.

5. Запустить команду поддержки и организовать сопровождение на протяжении всей жизни системы.

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

Если остались вопросы, напишите нам.