Контроль качества внедрения и внедренных ERP-систем

Подробности
Опубликовано: 20.07.2022 09:00
Автор: Степанов Дмитрий Юрьевич
Просмотров: 2162
Корпоративные информационные системы и учетная политика организации при применении автоматизированной формы ведения учета

Аннотация: в статье описывается процедура проведения контроля качества проекта внедрения ERP-систем, а также оценка качества уже имплементированных программных решений. Задается термин контроля качества, приводится характеристика параметров контроля согласно своду знаний по управлению проектами PMBoK и теории корпоративных информационных систем. Предлагается использование трех бальной шкалы оценки качества вида светофор. Дифференцируется процедура оценки качества внедренных ERP-систем для целей аудита, из-за наличия большого числа дефектов и при отсутствии проектной документации.
Скачать: PDF (статья), PDF (выпуск №19).
Ключевые слова: контроль качества ERP, ERP контроль, управление качеством 1С ERP, качество внедрения ERP, QA ERP, контроль внедрения ИС, контроль качества программного обеспечения, контроль качества программных продуктов, внедрение ERP проблемы, проблемы внедрения ERP систем, контроль качества внедрения SAP, контроль внедрения 1С, сложности внедрения ERP систем, риски внедрения ERP, сложности внедрения ИС, качество информационных систем, оценка качества информационных систем, управление качеством информационных систем.

Введение

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

Внедрения ERP-систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко-дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP-систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4].

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

Для начала давайте разберемся, что же собой представляет контроль качества. Согласно [5] контроль качества – это деятельность, которая реализуется для гарантированного подтверждения того, что производимые товары, услуги или процессы соответствуют установленным требованиям (стандартам). Здесь важно заметить, что процедура контроля качества подразумевает не столько исправление ошибок несоответствия, сколько их выявление. Обычно оценка дается по трех бальной шкале вида светофор: критические замечания помечаются красным, наличие существенных замечаний – желтым, а несущественные комментарии – зеленым, причем рекомендации даются практически во всех случаях.

В контексте реализации любого проекта вне зависимости от предметной области, фактическим регламентом большинства является свод знаний PMBoK, в то время как для внедрения ERP-систем требованиями выступают большинство подготавливаемых в ходе проекта документов. Понимание регламентирующих документов в контексте ERP-проектов может быть сформировано, используя теорию корпоративных информационных систем (далее – КИС) [6], для чего необходимо выделить два основных состояния системы: процесс внедрения (до продуктивного запуска) и ее регулярной промышленной эксплуатации (после запуска). В первом случае срабатывают все три группы уровней, характеризующие задачи: управление проектом и изменениями, а также содержанием (процессы, данные, приложения и техническая инфраструктура). Обычно уровень содержания обеспечивает контентную часть проекта, уровень проекта необходим для доставки содержания в срок, а уровень изменений включает перечень мероприятий для того, чтобы содержание прижилось в регулярной работе компании. Во втором случае речь идет исключительно о содержании и изменениях, в виду того, что управление проектом внедрения уже успешно реализовано.

1. Контроль качества внедрения ERP-системы

В своде знаний PMBoK выделяет 10-ть параметров проекта для контроля их выполнения:

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

последние 3-и из которых мы опускаем в виду нерелевантности процедуре контроля качества на стороне заказчика. Тогда контроль качества ERP-проекта внедрения будет заключаться в регулярном оценивание приведенных выше параметров с точки зрения их планирования, выполнения, мониторинга и корректировки в рамках классического PDCA-цикла.

Теперь обратимся к теории КИС, что позволит внести в процесс контроля качества специфику ERP-систем. Теория направлена в первую очередь на идентификацию и анализ рисков имплементации, а во вторую – на предложении способа его устранения или минимизации. Так, в рамках проекта должны быть определены активности и документы по устранению следующих групп рисков:

  • игнорирование объема проекта и его непрерывное изменение;
  • затягивание сроков согласования и выполнения критичных проектных задач и документов;
  • недоступность сотрудников заказчика;
  • завышенные ожидания конечных пользователей от ERP-системы,

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

2. Контроль качества внедренных ERP-проектов

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

  • контроль качества внедренной системы для целей аудита;
  • контроль по причине большого числа дефектов после запуска,

далее рассмотрим каждый из них более подробно.

2.1. Контроль качества внедренной ERP-системы для целей аудита

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

2.2. Контроль качества ERP-системы из-за дефектов после запуска

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

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

то речь идет о проблемах содержания внедренного продукта. Если же есть сомнения в следующих пунктах:

  • в уровне обучения сотрудников работе с ERP-системой;
  • в понимании сотрудниками порядка работы в ERP-системе;
  • степени фактического применения информационной системы в регулярных процессах, то следует более пристально рассмотреть процедуры управления изменениями в компании,

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

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

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

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

Оценка каждого из указанных пунктов ведется на основе все той же трехбальной шкалы оценивания. Тогда на выходе процедуры контроля качества помимо прочего готовится список возникших дефектов с указанием причины их возникновения: про-ектная/программная недоработка или неумелые действия пользователей системы.

2.3. Контроль качества при отсутствии проектной документации

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

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

Литература

  1. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
  2. Стеллман Э., Грин Д. Постигая Agile. Ценности, принципы, методологии. – М.: Манн, Иванов и Фербер, 2018. – 448 c.
  3. Ширенбек Х., Листер М., Кирмсе Ш. Руководство к своду знаний по управлению проектами. Руководство PMBoK. Шестое издание. – М.: Олимп-Бизнес, 2019. – 974 с.
  4. Олейник П.П. Корпоративные информационные системы: учебник для вузов. – СПб.: Питер, 2012. – 175 с.
  5. Калянов Г.Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. – М.: Горячая линия – Телеком, 2014. – 210 с.
  6. Stepanov D.Yu. The theory of corporate information systems // Lecture Notes in Electrical Engineering, vol. 986. Springer, Cham. https://doi.org/10.1007/978-3-031-22311-2_3.

Выходные данные статьи

Степанов Д.Ю. Контроль качества внедрения и внедренных ERP-систем // Корпоративные информационные системы. – 2022. – №3 (19) – С. 22-28. – URL: https://corpinfosys.ru/archive/issue-19/201-2022-19-erpqa.

Контроль качества внедрения и внедренных ERP-систем

Об авторе

Степанов Дмитрий Юрьевич Степанов Дмитрий Юрьевич – кандидат технических наук, доцент МИРЭА, принимал участие более чем в 10 проектах внедрения корпоративных информационных систем на базе SAP, Microsoft и Sage. Специализируется на управлении материальными потоками, сбытом и системой документов. Автор более 25 статей, в том числе публикации в журналах «Логистика сегодня», «Вопросы экономических наук», «САПер» и др. Электронный адрес автора: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Статьи выпуска №19

  1. Единый налоговый платеж и единый налоговый счет в 2023 году;
  2. Учет договоров с использованием HoneyCode (часть 2);
  3. Контроль качества внедрения и внедренных ERP-систем;
  4. Гибридные методы внедрения корпоративных ERP-систем;
  5. Формирование ресурсного плана в проектах внедрения ERP-систем.