Когда внедряется масштабная информационная система или планируется автоматизация сложных бизнес-процессов в компании, обязательным предварительным этапом является предпроектное обследование. Как и зачем проводится предпроектное обследование, расскажет Юлия Каткова, заместитель руководителя отдела коммерческих проектов по работе с корпоративными клиентами компании «ГЭНДАЛЬФ».
Основные этапы предпроектного обследования
Первый этап – интервьюирование
Первым этапом предпроектного обследования является интервьюирование, в рамках которого специалисты исполнителя общаются с ключевыми пользователями заказчика и составляют описание концепции новой системы. Они фиксируют состояние процессов на момент беседы, ключевые к ним требования, выходные формы и отчеты и формируют представление всех составляющих в ERP. Описывают, какой функционал будет использоваться и какие настройки для этого потребуются.
К примеру, «1С:ERP Управление предприятием» существенно отличается от «1С:Управления производственным предприятием», т.е. нельзя взять одну базу и превратить в другую одним щелчком пальцев. Нужно сделать много первоначальных настроек, чтобы увязать между собой функционал закупок, продаж, склада, производства, регламентированного учета так, чтобы это заработало как единая система. И очень важно не только то, как мы перенесем какую-либо функцию из одной системы в другую, но и то, как мы можем сделать ее эффективнее и какие дополнительные преимущества мы получим за счет более широких возможностей ERP.
Далее специалисты формируют список расхождений с типовым функционалом новой системы и формулируют способ их автоматизации, рисуют карты процессов. Отмечают все вопросы, которые потребуют нетипового решения.
Например, клиент желает автоматизировать резерв сомнительных долгов. Есть критерии – важны не стандартные 30, 60 или 90 дней просрочки, а необходимо через 10 дней просрочки начислить 3%, через 15 дней – 10% и др. Т.е. дополнительно разработать специфический функционал.
Сценарии контрольного примера
Сценарии контрольного примера – это воссоздание реальных учетных ситуаций, на которых клиент будет готов проверить функционал новой программы. Они наполнены данными, описаны в цифрах и показателях.
Пример сценария: «Отправили заявку на покупку материалов А и Б, купили материалы за определенную сумму. Далее материалы привезла доставка с определенными дополнительными расходами. Материалы поместили на один склад, потом переместили на другой склад. Отправили в производство, выпустили продукцию, было столько брака и столько отходов, готовую продукцию отгрузили клиенту, получили определенную оплату».
Сценарии очень важны в части блока себестоимости: описать, как та или иная база себестоимости будет рассчитана, какие будут способы распределения, привести примеры товаров, услуг и их расчетов.
Сценарий – это требование к измеримости результата, поэтому он должен быть максимально проработан, понятен и согласован с заказчиком. И на выходе заказчик получит программный продукт, который выдает результат, зафиксированный в сценарии.
Унификация НСИ
Вся нормативно-справочная информация, которая используется в системе может быть унифицирована: справочники номенклатур, контрагентов, поставщиков, договоров, основных средств и другие.
Часто заказчики используют номенклатуру поставщика, и тем самым их справочник номенклатуры вырастает до невероятных масштабов. В этом случае необходимо дать методические рекомендации, как лучше вести учет и получать нормативно-справочную информацию для оперативного использования: создавать, хранить, отправлять. Не у всех есть права «Создать номенклатуру» или должны быть права «Создать номенклатуру», это можно делать через заявки, документооборот либо с ответственными пользователями – критериев может быть много.
Задача предпроектного обследования – решить, как будет происходить упорядочивание, кто будет исполнителем, в какие сроки и какую именно информацию мы перенесем в новую систему в рамках проекта.
Техническое задание
Техническое задание (ТЗ) получает заказчик в финале предпроектного обследования и именно в нем фиксируются все детали предстоящего проекта. В нем последовательно описаны этапы автоматизации и работа процессов, которые планируется реализовать в новой системе. Описываются цели и измеримые результаты автоматизации.
Этот документ дает понимание заказчику, что у него будет сделано, и в то же время является инструкцией для программиста. ТЗ должно содержать целевые части, согласованные с заказчиком и технические части, описывающие задачи программисту. Без одной из составляющих техническое задание не будет полноценным.
Однажды мы пришли к клиенту после одного из партнеров, и увидели, что техническое задание выполнено в Excel и представляет собой сравнение типового функционала с доработками. Да, этот подрядчик выполнил предпроект за более низкую цену, чем другие партнеры. Но и результат был менее качественным. Т.е. цели и экономическая эффективность проекта остались непонятными для руководителей и пользователей, а программист увидел только «было-стало» и не получил представления о правильной настройке процессов.
Техническое задание должно быть подробным настолько, чтобы положить его в основу проекта мог не только подрядчик, который его выполнил, но и другой партнер или сам заказчик, если решит внедрять систему силами своего IT-подразделения.
Что еще дает предпроектное обследование заказчику
После предпроектного обследования все детали предстоящего проекта становятся понятными для заказчика, а в том числе и стоимость, и подход подрядчика к исполнению этой масштабной задачи.
Прозрачная цена проекта
Прозрачный расчет стоимости проекта – предельно важен, так как цена внедрения ERP-системы может варьироваться от тысяч до сотен миллионов рублей.
Если на предпроекте выявляется, что 90% системы составит типовой функционал, сумма проекта будет минимальной. Но стоимость будет расти в зависимости от того, сколько планируется нетипового функционала. Чем больше доработок, тем больше работ по программированию, инструкций, обучений, тестирований. Также конечная цена будет зависеть от сложности переносов, количества обменов и пользователей, четко выстроенной последовательности блоков внедрения. Ведь может случиться так, что при запуске следующего блока в неправильном порядке придется переделывать уже имеющийся функционал предыдущих блоков.
Предпроектное обследование позволяет оценить реальный объём работ, выявить все подводные камни, минимизировать риски и детально рассчитать затраты. Понять, вписывается ли проект в выделенный бюджет заказчика или стоит отказаться от каких-либо задач, запланировать на следующие периоды.
Взаимодействие с подрядчиком и доверие
Предпроектное обследование может длиться около 6 месяцев. Закладывается в этот период не только документирование всех этапов исполнителем. Сюда входит и совместная работа подрядчика и заказчика – в соотношении 60% на 40%. На что же уходит время клиента? На участие в каждом этапе обследования: ответы на вопросы в рамках интервьюирования, проверка и комментарии к концепции, согласование технического задания в плане целей и результатов, составление контрольных примеров, а также совместное решение сложных вопросов различия между функциональными блоками.
Для этого придется провести не одно собрание с подразделениями. Часто выявляется, что интересы представителей разных отделов конфликтуют, и находить решения нужно всем сообща. Если ранее отделы контактировали мало, а в рамках общей автоматизации нужно выстроить процессы так, чтобы вместе они работали продуктивно, они могут болезненно воспринимать изменения.
По нашему опыту, заказчики, которые изначально закладывают мало времени на согласования, потом признают, что все не так просто. Был случай, когда на совещания уходило по несколько часов нескольких людей, а решали мы вопрос перемещения 3 копеек. Такой, на первый взгляд, маленький вопрос оказался масштабным. Поэтому без лофта во времени не обойтись.
В это же время заказчик знакомится с исполнителем, оценивает уровень его профессионализма. Находит общий тон коммуникаций и делает выводы, насколько эффективен исполнитель в решении сложных вопросов: готов ли договариваться или продавливает свою позицию и не вникает в бизнес клиента. Между партнерами в рамках предпроекта формируется доверие. Все это дает заказчику понимание, готов ли он войти в проект именно с этим подрядчиком.
И снова о результатах
На предпроекте должны быть сделаны замеры важных для заказчика показателей экономической эффективности проекта. Это может быть оборачиваемость склада, затраты на закупки материалов, издержки на изготовление и себестоимость продуктов, расходы на ГСМ, прибыль предприятия и многие другие. И запланирован желаемый их рост до конкретных цифр – за счет оптимизации или сокращения процессов, уменьшения числа вовлеченных сотрудников, роста прозрачности операций и достоверности отчетности и так далее.
Запущенная новая ERP-система, которая умеет делать то же самое, что и система ранее работавшая на предприятии – сомнительный результат для оплаты в миллионы. А когда заказчик наглядно видит, как новая система улучшает показатели его бизнеса – это результат качественно выполненного проекта.
Подходы к внедрению ERP
Во внедрении ERP чаще всего используется классический подход. Первым этапом которого и является предпроектное обследование с составлением технического задания. Далее следуют – поставка, установка и настройка техники, внедрение и доработки, обучение сотрудников заказчика и промышленная эксплуатация. Также существует Scrum-технология внедрения ERP. Но, к сожалению, она не дает комплексного понимания предстоящего проекта и возможности точно понимать сроки и бюджеты. При выполнении задач при таком подходе часто приходится откатываться назад для переработки каких-либо блоков.
Почему лучше не внедрять ERP самостоятельно
ERP – многопрофильная система, которая автоматизирует разноплановый функционал. У подрядчиков, внедряющих подобные системы, за каждый функциональный блок отвечают разные специалисты. Их может быть до 10.
Бывает, что заказчики ERP-систем отказываются от предпроектного обследования, т.к. считают, что его может провести их собственная IT-служба. Чаще всего – это иллюзия. IT-служба может быть действительно сильной. Они могут отлично разбираться в бизнесе и программировать на 1С, постоянно прокачивать свои знания. Но если у них еще нет опыта внедрения ERP, они не сталкивались с расхождением функциональных блоков системы, с реализацией общих процессов под различные требования отделов, вероятность того, что проект будет выполнен успешно – низкая.
Планируете внедрить ERP-систему?
Доверьте предпроектное обследование команде профессионалов!
