6.5.Прототип и его демонстрация
Внедрение ERP-системы отличается от разработки программного обеспечения под заказ с нуля хотя бы тем, что изначально система уже есть и, вообще говоря, готова к работе без каких либо доработок, в ней реализуется замкнутый бизнес-цикл учета и ведения бизнес-процессов. Другое дело, насколько эта готовая система покрывает потребности компании заказчика и требования конкретных ключевых пользователей. В главе 2 рассматривался fit-gap анализ ERP-систем в процессе участия в тендере. На том этапе проекта не было выделено достаточно времени для полноценного прототипирования и моделирования бизнес-процессов и ведения учета в системе для покрытия всех требований, оценка давалась больше экспертно с незначительной проверкой гипотез на существующей функциональности системы. А вот на фазе анализа и концептуального проектирования для развертывания и начала настройки прототипа системы – самое время. Результат этой работы покажет достоверный список требуемых модификаций и концепцию по ним, достаточный для оценки бюджета и сроков проекта. Сам прототип является отличным инструментом для коммуникации между специалистами исполнителя и заказчика, так как разговоры о том, как все будет, будут проходить на живой системе, что сразу минимизирует риски высказываний пользователей типа: «А мы думали, что будет совсем не так!»
Проведем аналогию с известным высказыванием. Однажды великого итальянского скульптора и живописца Микеланджело Буонаротти спросили «Как вы делаете свои скульптуры?» – на что он ответил: «Я беру камень и отсекаю все лишнее». С внедрением ERP похоже, но ровно наоборот. Можно перефразировать: «Нужно взять готовую ERP-систему и дописать в ней все недостающее для конкретной компании». То есть нужно мысленно представить идеальный итоговый результат из текущей ERP-системы и описать (а потом и сделать) недостающее функции до идеала в ней.
Прототип будущей корпоративной информационной системы позволяет заинтересованным сторонам экспериментировать с моделью ERP-системы, а не ограничиваться обсуждением абстрактных представлений о своих требованиях и их возможной реализации. Прототипирование поддерживает концепцию последовательного уточнения в итеративных циклах создания макетов, проверки гипотез, проведения экспериментов конечным пользователем совместно с консультантом, формирования отзывов и пересмотра прототипа. После проведения достаточного числа циклов обратной связи через демонстрацию прототипа в рабочих встречах (один на один с ключевыми пользователями или в групповых обсуждениях) требования уточняются или формируются новые. Этих уточненных требований достаточно для перехода к фазам дизайна архитектуры системы и разработки. Сбор требований при демонстрации прототипа – это отличный инструмент вовлечения заинтересованных сторон. Время, потраченное на этом этапе, окупится за счет сокращения в дальнейшем количества лишней работы. Помним график из раздела 5.1 жизненного цикла проекта внедрения: такая проверка требований на прочность на демонстрации прототипа позволяет гибко влиять на проект на начальной стадии с минимумом усилий, т. к. многое можно еще пересмотреть, уточнить приоритеты и очередность работ, пока нет жесткого утверждения границ проекта и разработанной функциональности.
Интересная статистика. На исправление логической ошибки в требованиях, выявленной на стадии работы над требованиями, тратится в среднем 30 минут, а на исправление уже во внедряемой функциональности той же ошибки, выявленной в ходе тестирования, необходимо от 4 до 16 часов. Поэтому польза от уточнений требований на прототипе несомненна.
Обязательно нужно фиксировать и максимально полно (исходя из понимания на момент прототипирования и обсуждения с пользователями) описывать выявленные потребные модификации системы в таблице в сводном списке по разделам (подсистемам). Такие полезные идеи, как это все можно сделать, возникающие по ходу анализа и показа прототипа, могут забыться со временем или из-за ротации в команде стать утерянными, тогда позже придется «продумывать эту идею еще раз». Полученный список модификаций будет основой для уточнения оценок и планирования сроков разработки.
Если фаза анализа не отделяется от фазы дизайна, то такие необходимые модификации сразу проектируются в достаточном для утверждения заказчиком и начала разработки виде.
Важным моментом при показе прототипа (и вообще фазы анализа) является уточнение требований к переносу начальных данных, исходя из возможностей системы по инициализации начальных данных и того, в каком виде эти начальные данные можно получить из текущих учетных систем заказчика. Задачи на подготовку начальных данных требуют внимания и планирования: для исполнителя эти задачи могут казаться находящимися за рамками проекта, т. к. начальные данные находятся в распоряжении заказчика, но вот сроки, когда эти данные предоставят, влияют на успешность и последовательность работ уже исполнителя. Потому лучше явно и заранее прописать работы по подготовке начальных данных и сроки по ним с ответственностью заказчика за его задачи. На прототипе нужно продемонстрировать возможности по вводу начальных данных для выработки у заказчика понимания, что потребуется системе для инициализации работы, и анализа, какие данные и как получить для этого.
Если исполнитель может как-то оптимизировать (автоматизировать) подготовку начальных данных (выгрузки из текущих систем, мэппинг по таблицам соответствий, агрегирование), то эти возможности нужно озвучить и предложить. Стоимость таких обработок и удорожание на них бюджета проекта могут быть незначительными на фоне трудозатрат (и оплаты труда) сотрудников заказчика. То есть при явной экономии сроков и сил сотрудников заказчика лучше на работы по автоматизации переноса начальных данных привлекать специалистов исполнителя, а не экономить по принципу «ну, это мы и сами подготовим».
А что делать, если в системе нет какой-то функциональности, но для целостности картины у ключевых сотрудников заказчика при моделировании бизнес-процессов в прототипе она нужна? Недостающие части (которые предстоит создать или доделать на следующих фазах проекта) могут быть обозначены схематически в виде упрощенных эскизов форм рабочих мест и макетов отчетов, показанных в виде слайдов презентации, или даже рисунков на флипчарте или маркерной доске, рисуемых в процессе демонстрации прототипа. То есть уместны фразы типа: «Тут мы сделаем такое вот рабочее место, – рисуем форму или показываем слайд, – а тут будет вызов этого отчета» (открываем файл Excel) в процессе показа прототипа системы и его обсуждения.
В процессе дизайна форм для работы с ними пользователей можно использовать прием наглядного макетирования. Такой прием практикуется в дизайне интерфейсов и проверке их юзабилити (от англ. usability – удобство и простота использования). При разработке и доработке ERP-систем есть средства визуального создания макета интерфейсных форм в самой системе без дополнительной логики (кнопки не жмутся, алгоритмов нет), но интерфейсно все наглядно.
Полноценное проектирование новых интерфейсов будет на следующей фазе (дизайна), а на фазе анализа детализация может быть ограничена достаточностью для обсуждаемых вопросов. В качестве макетов новых отчетов, которых нет в системе, можно брать текущие Excel-файлы отчетов, что используются у заказчика. Если по внешнему виду формы отчета есть сомнения, что итоговый отчет будет точно таким же, как был в файлах, а полноты понимания нового дизайна еще нет, то лучше такие моменты явно отразить в описании концепции: что итоговые отчетные формы будут согласовываться на фазе дизайна архитектуры системы.
При проведении демонстраций прототипа системы и возможностей функциональности можно использовать готовые презентации от поставщика ERP-системы. Так, по 1С:ERP довольно много готовых презентаций от самих разработчиков, доступных на сайте ИТС (Технологическая поддержка прикладных решений/Методическая поддержка «1С:Предприятия 8»/ERP Управление предприятием/Доклады и презентации), часть выложена в открытом доступе на странице описания конфигурации .
На фазе дизайна архитектуры системы финализируются решения по НСИ и используемым опциям настроек системы. В прототипе все эти настройки находят свое отражение уже в конечном для будущей рабочей версии виде. Ниже представлен скриншот 1С:ERP со списком пунктов из раздела НСИ и администрирование. К настройкам относятся:
- базовая НСИ (организации, структура предприятия, банковские счета, контрагенты, номенклатура и прочие);
- настройка опций разделов (подсистем) – позволяет включать или отключать подсистемы и особенности функций внутри подсистем;
- настройки интеграции с другими системами, например с «1С:Документооборотом»;
- различные общие настройки по сервисным возможностям и подключаемому оборудованию;
- подключаемые дополнительные отчеты и обработки.
Рис. 6.9. Пункты раздела «НСИ и администрирование» в 1С:ERP
Как мы видим, настроек большое количество, и правильное, подходящее компании заказчика, их сочетание – это залог успеха работы системы на многие годы ее использования заказчиком. Особенно важными являются настройки номенклатуры, учета затрат и расчета себестоимости.
Например, заказчик изначально хочет детализацию учета себестоимости выпускаемой продукции до последнего винтика (хорошее, в общем-то, желание максимальной точности всех сумм). Но на практике так настроенная система может не заработать, т. к. по факту такой детальной информации нет на уровне организации самого бизнес-процесса в компании: отслеживание и обособление по продукции всех затрат затруднительно для сотрудников на местах. Поэтому в процессе анализа прототипа на реальном бизнес-процессе исполнителем и заказчиком совместно принимается решение по упрощению схемы учета за счет распределения незначимых статей расходов без явного их отнесения на конкретный экземпляр продукции.
При этом систему можно настроить на изначальные требования заказчика по максимальной детализации, но проблемы без прототипирования выявятся только на уровне опытной эксплуатации в момент начала работы пользователей, что «откатит» проект обратно в перенастройку и согласование изменений в настройках. Этого можно избежать за счет моделирования в прототипе на малых наборах данных бизнес-процессов компании с участием ключевых сотрудников заказчика.
Начав настраивать прототип на фазах анализа и дизайна, далее остается поддерживать его настройки в актуальном состоянии по мере доработок системы. В результате прототип станет тестовой версией, в него можно провести тестовый перенос начальных данных. Так постепенно прототип перерастет в полноценную настроенную версию с реальными настройками, по которым в чистой базе на введенных на дату запуска начальных данных будет продолжаться опытная, а затем и промышленная эксплуатация.
