<div><img src="https://mc.yandex.ru/watch/26690535" style="position:absolute; left:-9999px;" alt="" /></div>

Проблемы внедрения ERP (ч. 1)

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

В статье вы найдете ответы на следующие вопросы:

  • Бывает ли отсутствие проблем?
  • Проблемы целеполагания и аналитики
  • Проблемы проектирования ERP и их решения
  • Проблемы разработки ERP и их решения
  • Проблемы внедрения ERP

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

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

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

Этапы разработки и внедрения ERP:

  1. Определение целей создания системы. Понимание того, что именно автоматизируем. Проводится в ходе первой встречи.
  2. Бизнес-аналитика, выявление и фиксация бизнес-процессов. Это происходит в процессе проведения серии встреч: от общей встречи с руководителями до встреч с руководителями отделов и сотрудниками. По итогам встреч структурируются и фиксируются потребности бизнеса.
  3. Составление структуры проекта с использованием данных в MindMap (концепции в виде диаграммы), с которой будет работать система, и список потенциально необходимых интерфейсов.
  4. Составление прототипов интерфейсов, схематичного расположения структурных элементов.
  5. Составление дизайна интерфейсов, чтобы представить, как это будет выглядеть в готовой системе.
  6. Составление технического задания. Определение этапов и сроков проекта.
  7. Разработка системы. Это может проходить поэтапно, если подобное предусмотрено.
  8. Сдача каждого из этапов, сбор обратной связи и внесение корректировок при необходимости.
  9. Работа над каждым из этапов происходит параллельно с этапом внесения корректировок в предыдущий этап.
  10. Многоуровневое тестирование на каждом этапе и сдача всего проекта в срок с учетом доработок.
  11. Внедрение, выявление набора дополнительных требований и корректировок на основе пользовательского опыта.
  12. Выполнение доработок при необходимости.

Бывает ли отсутствие проблем?

Нет, не бывает. Опыт создания и внедрения более 30-ти систем разного размера и срока разработки от месяца до 2-х лет показывает, что проблемы есть всегда. Вопрос в том, что мы делаем, чтобы их стало меньше, а возникшие проблемы решались быстро и безболезненно. Для этого в компании ИНДИНС разработана методология проектирования и ведения проектов, которая минимизирует риски и позволяет доводить все проекты до логического завершения — внедрения в эксплуатацию.

Проблемы целеполагания и аналитики

Запрос может быть от «Хочу автоматизацию, но не знаю, что именно нужно» до «вот четкое ТЗ, надо сделать так». Не стоит забывать, что очевидное для проектировщиков и разработчиков может быть не очевидным для заказчика и наоборот. Техническое задание – результат работы предыдущих этапов проектирования, и, как правило, это всё-таки набор пожеланий. Поэтому между «есть ТЗ» или просто желанием автоматизировать процессы разница лишь в том, определился ли заказчик с целями и форматом автоматизации или нет.

Не знаем, чего хотим и как это должно быть реализовано

Цель внедрения ERP — решение конкретной проблемы на определенной стадии роста и развития компании.

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

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

Цель внедрения ERP — повысить эффективность и контролируемость, уменьшить количество ошибок. Это решается путем выявления самых неэффективных мест в бизнес-процессах, повторяющихся элементов. Для небольших компаний, руководителей и сотрудников есть простое упражнение. Выписать 10 самых часто повторяющихся действий. Что сотрудник и руководитель делает каждый день, неделю, месяц. Решение проблемы — определиться с целью и детализировать решение. Для этого используются этапы с 1 по 4. Появляются ответы на вопросы от «Зачем» до «Как это будет сделано».

Ошибками заказчиков, приводящими к проблеме, являются:

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

Ошибками разработчиков могут стать:

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

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

На этапе 4 — прототипировании интерфейсов, можно прямо по действиям в системе, количеству кликов, определить, сколько будет нужно действий для выполнения той или иной задачи в ERP.

На протяжении всей разработки и внедрения ERP необходимо задавать себе вопрос – соответствует ли то, что делается, изначальной цели или нет.

Проблемы проектирования ERP и их решения

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

В процесс проектирования входят этапы с 3 по 6. По итогам проведенного бизнес-анализа будут получены цели и понимание того, каким образом они будут достигнуты. Теперь необходимо не только структурировать то, как это будет реализовано. Самое главное, чтобы у заказчика и разработчика было общее понимание, необходимо синхронизировать это понимание.

Проблема синхронизации

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

Мы достаточно давно составляем MindMap по каждому проекту с ветками структуры данных, связей и перечислением интерфейсов. Именно эта информация ложится в основу оценки. Однако сталкивались с такой ситуацией, когда система уже готова и заказчик понимает, что в ней нет нужных вещей и увидел он это только сейчас. ТЗ писалось после составления MindMap, а интерфейсы проектировались после ТЗ. На последних проектах мы внедрили процесс Interface first: сначала мы делаем прототипы, а уже потом ТЗ. Это помогло решить проблему на корню и сократило непонимание.

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

Решение:

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

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

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