В первой части статьи мы рассмотрели проблемы, с которыми могут столкнуться компании при внедрении ERP-систем. Прошлись по этапам разработки и интеграции, поняли, какие ошибки чаще всего допускают заказчики и разработчики и определили важность аналитики бизнес-процессов. Первую часть можно прочитать здесь.
Проблема фиксации данных и описания ERP
Частично это тоже можно назвать синхронизацией, ведь самое главное, чтобы было полное понимание между заказчиком и разработчиком, что будет входить в состав ERP и как это будет выглядеть. Но как все это оформить и добиться синхронизации? Про прототипы описано в прошлой проблеме, пояснения здесь излишни. Также есть этап дизайна, когда заказчик «на чистовую» увидит, как будет выглядеть его система что называется «в цвете». Данный дизайн впоследствии ляжет в основу верстки.
Сколько технических заданий нам встречалось, столько же было его разновидностей. Мы всегда говорим заказчику, что для каждого нового проекта нужно писать новое. Сначала эта рекомендация встречается скептически, но после получения документа скепсис уходит. Мы прошли весь путь от ТЗ в виде «надо чтобы работало и было красиво» на 1 листе, до огромных технических трактатов и обратно, пока не нашли наилучший баланс с наивысшей эффективностью. Основное требование к техническому заданию — оно должно быть понятно как заказчику, так и разработчикам.
Что такое эффективность в применении к техническому заданию? Это когда по итогу проекта разница между ожиданиями клиента и тем, что описано в техническом задании, минимальна. Техническое задание на разработку ERP является документом от заказчика разработчику. Оно не должно содержать формулировок «выглядит», «делает». Исходя из сути документа формулировки должны быть точными, например: «при нажатии на кнопку должно открываться» или «должен формироваться документ».
Мы делаем техническое задание, в котором 4 составляющих:
- Описание целей проекта, набора технологий, требований к хранению данных и безопасности. Это позволяет взять в руки ТЗ и понять, что за проект, какие задачи решает, как он сделан и как организован.
- Структура данных, всех таблиц, сущностей, связей. Это позволяет разработчикам быстро создать структуру данных, а заказчику понять, не забыто ли хранение времени или отметки о готовности для производственной операции или электронный ящик менеджера поставщика в перечисленных данных. Эта информация дублируется и проверяется на основе MindMap и прототипов.
- Описание интерфейсов: всех таблиц, фильтров, окон, страниц, кнопок, столбцов. Это позволяет ничего не упустить на стадии разработки. Фактически, разные виды информации дублируют друг друга и перепроверяются на основе прототипов.
- Описание логики и пользовательские тесты. Описывается реакция системы на действия пользователя, а также описывается, как в системе, по шагам и по пунктам, производить действия. Например, создать заказ, отправить письмо, внести поступление компонентов и расходников или отметить готовность операции. Данный раздел ТЗ также является подспорьем для тестирования системы при сдаче и внедрении.
Решение: перед разработкой все особенности системы должны быть четко описаны и зафиксированы с помощью отрисованных интерфейсов, структуры данных, выполняемых функций и действий в системе.
Проблема погружения
Данная проблема является проблемой высокого уровня и приводит к фатальным последствиям для проекта. Можно составить идеальное ТЗ, прототипы и всё синхронизировать, однако в конце проекта получить от заказчика «ТЗ составляли вы, а я не вникал, так что в итоге получилось не то, что нужно».
Именно поэтому необходимо не просто составить ТЗ, а убедиться в том, что каждая строчка в нем понятна, все прототипы интерфейсов проверены, есть понимание того, как это будет работать. Для этого мы организуем встречи, вместе проходимся по всему документу, обсуждаем его, если необходимо, то корректируем, включая изменения в MindMap и прототипы.
Решение: очень важно, чтобы каждая строчка была понятна как разработчику, так и заказчику. Необходимо найти время для полного погружения в проект. ТЗ — ключевая точка в разработке проекта, обратной дороги не будет. Если не будет погружения, вы получите не то, что хотели. Если чего-то нет в ТЗ — этого не будет в проекте, потому что разработчики будут делать проект согласно ТЗ.
Проблемы разработки ERP и их решения
После подписания технического задания проект идет в разработку и больше в него вносить изменения нельзя. А ведь так хочется, и это основная проблема. Даже если надо внести правки из-за ошибки в ТЗ или логике системы. Мы пробовали, это неизбежно приводит к множеству больших проблем.
Все участники процесса должны быть нацелены на отличный результат и решение проблем клиента: где-то что-то улучшить, где-то сделать что-то дополнительно. Разумеется, всего не учесть и невозможно всё описать в ТЗ — иначе оно было бы размером с многотомное издание. Но есть самая распространенная проблема, которая инициируется как действиями заказчика, так и действиями разработчиков или менеджеров проекта.
Поправим ТЗ
Конечно, намерения благие. Или добавить раздел, или поправить недочет в ТЗ. Мы пришли к решению, позволяющему делать это безболезненно.
Разработка ERP — процесс, выполняемый группой разработки, где каждый разработчик делает свой фронт задач. Все элементы системы связаны между собой. Сущности делает один разработчик, функционал — другой, а интерфейсы — третий. Если внести изменения в одну деталь, то учесть изменения в других местах, где это может вылезти, невозможно. Такие попытки в 100% случаев приводят к проблемам в разработке, латанию дыр, срыву сроков проекта и неучтенным работам. Изменения нарастают как снежный ком. Лучшее описание всего этого — взмах крыла бабочки, спровоцировавший ураган на другом конце света.
Решение: всё делать строго по ТЗ. Есть один формат корректировки, на стыке этапов. После завершения этапа, в котором заказчик тестирует результат, могут поступать предложения по улучшению системы. Мы делаем протокол разногласий с ТЗ: четкие пункты с техническим описанием корректировок. Это всё оценивается по применимости к проекту и ТЗ, возможным изменениям. Документ составляется совместно техническим руководителем проекта (ведущим программистом по проекту) и менеджером проекта, затем согласовывается с клиентом. Как правило, документ содержит косметические корректировки функционала, нацеленные на оптимизацию работы пользователей с системой по итогам тестирования этапа клиентом. Понятно, что добавить новый раздел это не корректировка и потребность выносится за рамки проекта и ТЗ. Корректировки могут быть относительно того, что не было описано в ТЗ. Косметические вещи мы берем в работу в рамках проекта без увеличения стоимости, но суть в другом. Все эти корректировки должны четко фиксироваться и быть применимы к проекту, изучены на предмет влияния на другие части системы. Таким образом, ТЗ не меняется, но при этом прописываются пожелания, оформленные в технические задачи. Вектор разработки корректируется с учетом этого. Таким образом, происходит синхронизация с заказчиком в процессе разработки. Итак, ERP разработана, перенесена на сервер клиента или в облако под доменным именем клиента и готова к эксплуатации. Для начала её необходимо протестировать.
ERP работает не так, как хочется
Если вы сталкиваетесь с ошибками в работе системы, какая-то запись не создается, один из интерфейсов на мобильном устройстве выглядит так, что пользоваться неудобно, то что делать? В разных компаниях по разработке разный подход. Тут уже всё зависит от компании и её реакции на проблему.
Есть 3 вида проблем:
- Проблема не позволяет работать с системой, ошибка.
- Система работает не по ТЗ.
- Проблема позволяет работать, но это неудобно или некрасиво.
Не стоит сбрасывать сразу каждую ошибку по телефону, мессенджерам и прочим каналам. Сложно отслеживать и вы сами запутаетесь. Необходимо взять время на тестирование, и лучше проводить его по бизнес-процессам, которые вы будете выполнять. В идеале нужно сделать так, чтобы тестирование выполняли люди, которые будут работать с системой. Не все конечно, но хотя бы по 1 человеку на функцию. Например, не стоит отправлять весь отдел на тестирование новой системы. Необходимо составить список всех проблем, которые обнаружены: по пунктам и с номерами. По проблемам 1 и 2 разработчик обязан исправить в кратчайшие сроки. По пункту 3 не обязан, тут уже зависит от компании и договоренностей. Заранее пытаться прописать эти вещи в договоре бесполезно, всё прописать в ТЗ невозможно.
Далее, как правило, действует человеческий подход или официальный. Официальный гласит: если нет прямого указания в техническом задании сделать именно так, то необходимо доплатить за указанные корректировки. Человеческий заключается в разделении списка на то, что логично и что действительно надо было предусмотреть для удобства пользователей. Это будет сделано в рамках проекта и добавится новый раздел, который не был предусмотрен в ТЗ.
Отторжение сотрудниками
Данная проблема решается на этапе проектирования интерфейсов. Существует 3 способа решения данной проблемы:
- Если сотрудники уже используют какую-то систему, то необходимо проектировать новую систему с учетом интерфейса прошлой, к которой уже привыкли сотрудники. Ни в коем случае нельзя допускать, чтобы в новой системе требовалось больше действий для выполнения задачи, чем в прошлой.
- На стадии проектирования интерфейса необходимо применять следующий подход: выводить для наполнения или показа наиболее важную информацию в начало (или на одном экране). Все знакомы с ситуацией, когда для получения необходимой для выполнения действия информации необходимо зайти в несколько интерфейсов. Или, чтобы добавить заказ, сначала необходимо сходить в интерфейс клиентов и добавить клиента там. Это необходимо исключить и сделать выполнение действия в системе в рамках одного окна.
- Необходимо проектировать функциональные интерфейсы, то есть интерфейсы для выполнения определенных функций, для разных ролей в системе или разных должностей сотрудников. Классические шаблонные системы строятся по принципу проектирования интерфейса в зависимости от типа данных. Например, интерфейс клиента, заказа, или детали производства. Правильно проектировать исходя из выполняемого действия. Например, если для изготовления детали необходимо видеть переписку с клиентом, файлы и спецификации, то сделать это нужно в рамках одного окна.
Выводы
Большинство проблем внедрения ERP связаны с ошибками проектирования или недостаточной проработкой проекта ERP при проектировании и прототипировании. Как описано в статье, если попробовать выбросить из процесса любой этап из перечисленных, то это неизбежно приведет к проблемам при внедрении ERP.
Если вам была полезна данная статья, рекомендуем прочитать статью о методологии разработки.
Для достижения целей проекта, для уменьшения разницы между ожиданиями клиента и итоговым результатом можно добавлять другие этапы, но ключ успеха при внедрении ERP заключается в правильном проектировании. Изготовление информационной системы — уже дело техники и тут всё зависит от квалификации группы разработки, но понимание деталей проекта заказчиком и исполнителем — является определяющим фактором.