Проблемы при внедрении ERP бывают как у заказчиков, так и у разработчиков. Чтобы получить общее видение проблем и их решения, будут описаны и те, и другие.
В статье вы найдете ответы на следующие вопросы:
- Бывает ли отсутствие проблем?
- Проблемы целеполагания и аналитики
- Проблемы проектирования ERP и их решения
- Проблемы разработки ERP и их решения
- Проблемы внедрения ERP
Сразу надо сказать, что в статье идет речь про полноценное проектирование и внедрение ERP. Системы ERP в стиле «вот вам шаблонный продукт (коробка, пакет), а дальше круглое таскайте, а квадратное катите», проблемы в стиле «как внедрить то, что не соответствует нашим процессам» или «как в детских игрушках: в круглое отверстие вставить кубик» здесь не решаются, но упоминаются в виде примеров «как делать не надо».
Внедрение ERP — заключительный этап в разработке и его успех зависит от проблем и ошибок, выявленных на других этапах. Трудности могут возникнуть на всех уровнях. В данной статье опишем, какие проблемы возникают и как с ними бороться. Существуют такие сложности, как оценка стоимости и другие моменты, которые не имеют отношения к внедрению ERP, поэтому мы не будем рассматривать их в данной статье.
Этапы разработки и внедрения ERP:
- Определение целей создания системы. Понимание того, что именно автоматизируем. Проводится в ходе первой встречи.
- Бизнес-аналитика, выявление и фиксация бизнес-процессов. Это происходит в процессе проведения серии встреч: от общей встречи с руководителями до встреч с руководителями отделов и сотрудниками. По итогам встреч структурируются и фиксируются потребности бизнеса.
- Составление структуры проекта с использованием данных в MindMap (концепции в виде диаграммы), с которой будет работать система, и список потенциально необходимых интерфейсов.
- Составление прототипов интерфейсов, схематичного расположения структурных элементов.
- Составление дизайна интерфейсов, чтобы представить, как это будет выглядеть в готовой системе.
- Составление технического задания. Определение этапов и сроков проекта.
- Разработка системы. Это может проходить поэтапно, если подобное предусмотрено.
- Сдача каждого из этапов, сбор обратной связи и внесение корректировок при необходимости.
- Работа над каждым из этапов происходит параллельно с этапом внесения корректировок в предыдущий этап.
- Многоуровневое тестирование на каждом этапе и сдача всего проекта в срок с учетом доработок.
- Внедрение, выявление набора дополнительных требований и корректировок на основе пользовательского опыта.
- Выполнение доработок при необходимости.
Бывает ли отсутствие проблем?
Нет, не бывает. Опыт создания и внедрения более 30-ти систем разного размера и срока разработки от месяца до 2-х лет показывает, что проблемы есть всегда. Вопрос в том, что мы делаем, чтобы их стало меньше, а возникшие проблемы решались быстро и безболезненно. Для этого в компании ИНДИНС разработана методология проектирования и ведения проектов, которая минимизирует риски и позволяет доводить все проекты до логического завершения — внедрения в эксплуатацию.
Проблемы целеполагания и аналитики
Запрос может быть от «Хочу автоматизацию, но не знаю, что именно нужно» до «вот четкое ТЗ, надо сделать так». Не стоит забывать, что очевидное для проектировщиков и разработчиков может быть не очевидным для заказчика и наоборот. Техническое задание – результат работы предыдущих этапов проектирования, и, как правило, это всё-таки набор пожеланий. Поэтому между «есть ТЗ» или просто желанием автоматизировать процессы разница лишь в том, определился ли заказчик с целями и форматом автоматизации или нет.
Не знаем, чего хотим и как это должно быть реализовано
Цель внедрения ERP — решение конкретной проблемы на определенной стадии роста и развития компании.
Как правило, понимание необходимости информационной системы приходит, когда «достало». «Достало» возникает тогда, когда критическая точка пройдена, в ходе роста компании увеличивается количество определенного вида задач или они становятся актуальны. Именно тогда приходит понимание, что их надо срочно решать, что это слабое звено и оно мешает развиваться. Когда есть проблема, решение которой видится во внедрении информационной системы и действительно часть проблем можно решить. Например, «заказы постоянно проваливаются по срокам», «производство сдает всё не вовремя», «необходимость закупки расходников выявляется, когда поезд производства идет полным ходом и приходится его останавливать». Когда «менеджеры не звонят повторно интересовавшемуся продуктом клиенту». Когда руководитель вручную подтверждает счета на оплату, ставя визы на каждый счет в оплату и количество счетов от роста компании превращается в папку высотой в монитор. Это всё цели — решить проблему.
Для разработки ERP с целью решения проблемы необходимо правильно её обозначить. Потому что зачастую одна проблема вызвана другой проблемой. Необходимо понять, в каком виде данная задача будет решена.От того, в каком виде необходимо решить проблему, зависит всё. Ошибка на данном этапе является самой большой проблемой. Мы уже встречали компании, которые приходили к нам со словами «нам внедрили систему, но она не делает то, что нам надо, а нам обещали, что она будет». Определиться, готовы ли вы менять бизнес-процессы. Иногда это необходимо для решения проблемы, а иногда требуется не внедрение ERP, а достаточно внести изменения в процессы.
Цель внедрения ERP — повысить эффективность и контролируемость, уменьшить количество ошибок. Это решается путем выявления самых неэффективных мест в бизнес-процессах, повторяющихся элементов. Для небольших компаний, руководителей и сотрудников есть простое упражнение. Выписать 10 самых часто повторяющихся действий. Что сотрудник и руководитель делает каждый день, неделю, месяц. Решение проблемы — определиться с целью и детализировать решение. Для этого используются этапы с 1 по 4. Появляются ответы на вопросы от «Зачем» до «Как это будет сделано».
Ошибками заказчиков, приводящими к проблеме, являются:
- Отсутствие понимания того, что и зачем делается;
- Нежелание вникать в процесс;
- Желание добавить в систему паразитные вещи, не решающие проблемы, просто «чтобы было».
Ошибками разработчиков могут стать:
- Требование только технических деталей без вникания в процессы;
- Непонимание того, какая проблема решается и зачем;
- Согласие с добавлением ненужных вещей, продажа заказчику того, что ему не нужно.
Чтобы исключить проблему целей и прийти к общему видению, заказчику необходимо совместно с разработчиком убедиться, что есть общее понимание того, какая проблема решается и каким образом она будет решена. За счет чего, какие именно действия будут выполняться в системе, как они решат проблему, за счет чего будет прирост в эффективности, повысится контролируемость и уменьшится количество ошибок. Выполнение бизнес-задачи после внедрения ERP должно занимать меньше времени, чем занимало до внедрения. Это ключевой обязательный фактор, иначе система снизит эффективность, а не повысит его.
На этапе 4 — прототипировании интерфейсов, можно прямо по действиям в системе, количеству кликов, определить, сколько будет нужно действий для выполнения той или иной задачи в ERP.
На протяжении всей разработки и внедрения ERP необходимо задавать себе вопрос – соответствует ли то, что делается, изначальной цели или нет.
Проблемы проектирования ERP и их решения
Самой распространенной проблемой является отсутствие проектирования как такового или ориентирование только на ТЗ, составленное на основе пожелания клиентов. И попытка разработчиков на основе этого ТЗ сделать продукт. Но эту проблему мы не будем сейчас рассматривать.
В процесс проектирования входят этапы с 3 по 6. По итогам проведенного бизнес-анализа будут получены цели и понимание того, каким образом они будут достигнуты. Теперь необходимо не только структурировать то, как это будет реализовано. Самое главное, чтобы у заказчика и разработчика было общее понимание, необходимо синхронизировать это понимание.
Проблема синхронизации
Это является проблемой не только для разработчика, но и для заказчика. В чем заключается эта проблема? Допустим, что система разработана и приходит время внедрения ERP, но заказчик понимает, что многого не хватает. Разработчик указывает на ТЗ и говорит, что этого в ТЗ нет, значит недостающее необходимо оплачивать дополнительно. Эта проблема есть и будет, но как её минимизировать? Для этого необходимо максимально детализировать все элементы системы, которые требуют трудозатрат.
Мы достаточно давно составляем MindMap по каждому проекту с ветками структуры данных, связей и перечислением интерфейсов. Именно эта информация ложится в основу оценки. Однако сталкивались с такой ситуацией, когда система уже готова и заказчик понимает, что в ней нет нужных вещей и увидел он это только сейчас. ТЗ писалось после составления MindMap, а интерфейсы проектировались после ТЗ. На последних проектах мы внедрили процесс Interface first: сначала мы делаем прототипы, а уже потом ТЗ. Это помогло решить проблему на корню и сократило непонимание.
Как заказчик, вы смотрите на то, как это будет выглядеть в итоге и отмечаете, что удобно, а что — нет. Где-то не хватает некоторых элементов, а бывает и целого раздела. Это поможет наглядно продемонстрировать, что вы получите в итоге и как это будет работать. Позволит внести коррективы еще до того, как будет составлено техническое задание.
Решение:
Просите разработчика показать, как будет выглядеть система, возможно на примере других проектов. Так у вас сформируется понимание того, как будет выглядеть ваша собственная система.
Разбейте проект на этапы, где прототипы интерфейсов будут создаваться раньше технического задания и расчета итоговой стоимости. Это обезопасит вас от того, чтобы получить в конце проекта результат, который вам не понравится и не будет содержать необходимого функционала.
Во второй части статьи мы рассмотрели затруднения в фиксации данных, проблемы погружения в бизнес-процессы клиента и описали другие сложности, с которыми сталкиваются компании при проектировании ERP-системы. Например, на каком этапе работы над проектом стоит писать ТЗ и что делать в случае, если ERP работает не так, как хочется.