Семь способов сокращения бюджета проекта внедрения 1С: ERP.

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

Таблица 1. Смета на внедрение 1С: ERP. Первоначальный вариант.

Цифры в таблице условные, и таблица немного упрощена для простоты восприятия. Однако, для передачи идей по сокращению бюджета проекта такая таблица вполне сгодится.

Специалисты предприятия посмотрели на смету и немного загрустили. В бюджете на автоматизацию заложены несколько другие цифры, явно ниже. Что же делать? Как уложиться в бюджет и все же провести внедрение системы?

Рассмотрим семь способов сокращения бюджета проекта. Часть из них очевидна, а часть, возможно станет находкой для читателей.

Способ первый. Уменьшение тарифа

Если мы имеем дело с проектом внедрения, и внедрение происходит по методике «waterfall» («водопад», с последовательным выполнением этапов проекта), то, как правило, стоимость проекта заранее известна и фиксирована. При этом подрядчик несет определенные риски, и закладывает их в цену. Можно, конечно, провести торги с целью снижения тарифа и стоимости внедрения. Но если цена на торгах значительно снизится, можно потерять надежного подрядчика. А значит, есть риск и вовсе не внедрить проект и потерять все деньги, выделенные на него.

Как же снизить тариф, не рискуя проектом? Можно вместо проектного договора с фиксированной ценой заключить договор сопровождения. И выполнять каждый этап проекта внедрения просто как отдельный заказ по договору сопровождения. В этом случае риски подрядчика существенно снижаются, так как у него появляется возможность пересмотреть стоимость и сроки каждого следующего этапа по факту выполнения предыдущего. Как правило, тарифы на услуги сопровождения на 10-15% ниже тарифов на проектные услуги. А отсутствие рисков у подрядчика позволяет ему не завышать заранее и объемы выполняемых работ.

Способ второй. Исключение описания бизнес-процессов

Если внимательно рассмотреть смету, то мы увидим такие работы как «разработка моделей бизнес-процессов «как есть» и «как будет». Такие модели позволяют понять текущую логику бизнес-процессов, сравнить их с бизнес-процессами в типовом решении 1С: ERP, и спроектировать изменения. Но ведь мы имеем дело с готовым и гибким программным решением, которое без значительных доработок внедрено на десятках предприятий. В этом случае допустимо предположить, что логика бизнес-процессов типового решения подойдет и нашему предприятию. А значит, от описания бизнес-процессов «как есть» и разработки бизнес-процессов «как будет» можно отказаться. Это позволит сэкономить до 10% от стоимости работ.

Способ третий. Отказ от разработки локальных технических заданий (технических решений, технических проектов)

Казалось бы, наличие технического проекта страхует заказчика и подрядчика от многократной переделки программы. Однако, разработка таких решений сама по себе трудоемка, и время на разработку может превышать время на переделку. Документация также требует согласования у заказчика, на что тоже тратится значительное время. Кроме того, выполнение разработки строго по проекту снижает гибкость разработки. И, наконец, разработка документации как страховка от переделок — это определенная иллюзия. Часто пользователи начинают понимать, что сделано, только увидев разработку, а не изучив документы. Если вместо разработки документации начать чаще общаться с пользователями и показывать им прототипы разработки как можно раньше, этап проектирования также можно исключить. Таким образом вы можете сэкономить до 5% от стоимости проекта.

Способ четвертый. Отказ от опытной эксплуатации

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

Способ пятый. Отказ от повторного моделирования после доработки программы.

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

Способ шестой. Выполнение части работ силами заказчика

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

• Разработка части несложных доработок. Как правило, это простые отчеты;

• Перенос и проверка перенесенных данных. При этом разработка конвертеров по переносу данных остается за подрядчиком;

• Обучение персонала по готовым инструкциям. Инструкции должны быть разработаны подрядчиком.

В общем случае экономия на этих работах может составить до 15% от бюджета проекта.

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

Вот что у нас может получиться.

Таблица 2. Смета на внедрение 1С: ERP. Экономный вариант с тарифами на сопровождение.

Таким образом, нам удалось сократить трудоемкость проекта примерно на треть, а стоимость — на половину.

Способ седьмой. Внедрение собственными силами

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

• Наличие опытного выделенного руководителя проекта;

• Наличие выделенной проектной команды, не занятой другими работами;

• Почти полная остановка текущих работ по сопровождению;

• Изменение системы мотивации проектной команды так, чтобы она учитывала реальные результаты этапов внедрения.

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

Заключение

Ну и наконец, необходимо сделать важное замечание. В любом случае, при использовании каждого из предложенных способов, сокращение не происходит безнаказанно. За каждым исключением работы или передачей работ на сторону заказчика стоит определенный риск. Риски проекта и способы их нейтрализации — тема отдельной большой статьи. Сейчас же просто напомним о том, что любое сокращение бюджета проекта — это возможность его невыполнения и срыва. То есть риск потери всего бюджета проекта. Поэтому сокращать бюджет проекта нужно осторожно, и при полном согласии заказчика и подрядчика.