Предпроектное обследование при внедрении ERP

Классический подход к внедрению ERP-системы

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

Однако, компания «Гэндальф» использует иной подход, который обусловлен запросами крупных клиентов к результатам предпроектного обследования. Он выработан на основании более 25 лет опыта автоматизации крупных коммерческих предприятий и госсектора. Предпроектное обследование в компании «Гэндальф» включает такие этапы проекта в классическом его понимании, как инициация, формирование или уточнение перечня требований и в итоге дает заказчикам прикладные инструменты для оперативного входа в проект и максимально точной его предварительной оценки.

Около 10 лет назад мы делали предпроектное обследование менее комплексно, без детальной проработки ТЗ, сценариев и других элементов проекта. Однако, крупные клиенты стали расширять требования к проработке проекта до его старта, в том числе в условиях тендеров. Это заставило компанию «Гэндальф» включить описанные этапы или шаги в предпроектное обследование и проводить его в таком расширенном формате. К примеру, в одном из тендеров, в которых мы участвуем, результатом предпроектного обследования является готовое, детально проработанное ТЗ.

Основные шаги предпроектного обследования

Интервьюирование и диагностика состояния процессов

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

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

Анализ потенциальных доработок

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

Например, компания желает автоматизировать резерв сомнительных долгов. Есть критерии — важны не стандартные 30, 60 или 90 дней просрочки, а необходимо через 10 дней просрочки начислить 3%, через 15 дней — 10% и др. Для этого необходимо разработать специфический функционал.

Планирование сценариев контрольного примера

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

Пример сценария. «Отправили заявку на покупку материалов А и Б, купили материалы за определенную сумму. Далее материалы привезла доставка с определенными дополнительными расходами. Материалы поместили на один склад, потом переместили на другой склад. Отправили в производство, выпустили продукцию, было столько брака и столько отходов, готовую продукцию отгрузили клиенту, получили определенную оплату».

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

Определение способов унификации НСИ

Вся нормативно-справочная информация, которая используется в системе может и должна быть унифицирована: справочники номенклатур, контрагентов, поставщиков, договоров, основных средств и другие. Однако, реальное состояние НСИ в компании может быть весьма далеко от идеала. Задача предпроектного обследования — решить, как будет происходить упорядочивание, кто будет исполнителем, в какие сроки и какую именно информацию мы перенесем в новую систему в рамках проекта.

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

Техническое задание

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

Этот документ дает понимание заказчику, что у него будет сделано, и в то же время является инструкцией для программиста. Техническое задание должно содержать целевые части, согласованные с заказчиком и технические части, описывающие задачи программисту. Без одной из составляющих техническое задание не будет полноценным.

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

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

Что ещё дает предпроектное обследование заказчику

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

Прозрачная цена проекта

Прозрачный расчет стоимости проекта — предельно важен, так как цена внедрения ERP-системы может варьироваться от тысяч до сотен миллионов рублей. Если на предпроектном обследовании выявляется, что 90% системы составит типовой функционал, сумма будет минимальной. Но стоимость будет расти в зависимости от того, сколько планируется нетипового функционала. Чем больше доработок, тем больше работ по программированию, инструкций, обучений, тестирований. Также конечная цена будет зависеть от следующих факторов:

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

Предпроектное обследование позволяет оценить реальный объём работ, выявить все подводные камни, минимизировать риски и детально рассчитать затраты. Понять, вписывается ли проект в выделенный бюджет заказчика или стоит отказаться от каких-либо задач, запланировать на следующие периоды.

Взаимодействие с подрядчиком и доверие

Предпроектное обследование может длиться довольно долго — около 6 месяцев. В это время подрядчик и заказчик работают совместно— в соотношении 60% на 40%. На что же уходит время клиента? На участие в каждом этапе обследования: ответы на вопросы в рамках интервьюирования, проверка и комментарии к концепции, согласование технического задания в плане целей и результатов определение контрольных примеров, а также совместное решение сложных вопросов различия между функциональными блоками.

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

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

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

И снова о результатах

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

Если результат проекта — лишь запущенная новая ERP-система, которая умеет делать то же самое, что и ранее работавшее на предприятии ПО, деньги потрачены зря. Результат качественно выполненного проекта — когда заказчик наглядно видит, как новая система улучшает показатели его бизнеса.

Комментарии 0