Журнал «Компьютерра» № 8 от 28 февраля 2006 года - Компьютерра - Страница 24

• Предыдущая
• 24/33
• Следующая

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

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

1.1. Взгляд со стороны заказчика

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

< низкая квалификация Куратора в области информационных технологий;

< и/или недостаточная квалификация Куратора в области бизнеса Заказчика;

< и/или низкая ответственность Куратора за результаты проекта;

< и/или недостаточная мотивация Куратора на результаты проекта;

< и/или низкая зарплата Куратора.

Пытаясь снизить возможные издержки от неудачного выбора Куратора, Заказчик может совершить серьезную ошибку, доверив все Исполнителю. Зачастую это происходит на этапе выбора Куратора (когда Исполнитель еще неизвестен) и формулируется примерно так: «Сейчас мы найдем фирму, которая нам все сделает».

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

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

1.2. Взгляд со стороны исполнителя

Введем упрощение. Будем считать, что невнедренный проект не влияет на репутацию Исполнителя. Это не совсем верно, но верно настолько, что мы можем это допустить.

С точки зрения Исполнителя очевидно следующее:

< Результат проекта неизвестен.

< Договор заключать надо так, чтобы получить прибыль.

< Чем больше денег будет получено до начала внедрения, тем лучше.

Исполнитель знает, что составить такие описания бизнес-процессов и другую требуемую для проекта документацию, которую подпишет комиссия Заказчика, в общем-то нетрудно.

2.1. Описание бизнес-процессов

Принимая описание бизнес-процессов (БП), Заказчик хочет увидеть документ, в котором правильно описаны бизнес-процессы, указанные в договоре (иногда их даже забывают записать в договор – всякое бывает).

Когда главная цель – понравиться, у Исполнителя остается большое поле для маневра. Например, в описании бизнес-процессов важна детализация. Большинство бизнес-процессов кроме основной ветки развития включают в себя и другие, дополнительные ветки, которые происходят реже, но все же происходят. К примеру, в процессе производства (основная ветка) может обнаружиться брак, может быть выявлена ошибка конструкции, на склад недопоставят необходимый материал, ценный специалист, без которого не запустить определенное оборудование, может заболеть и т. д. Без учета этих ситуаций описание бизнес-процессов будет неполным, а значит, его нельзя использовать для решения задач Заказчика (точнее, можно, но ровно до тех пор, пока не случится нештатная ситуация).

Обычно Исполнитель хотя бы часть дополнительных веток БП описывает. Но часто Заказчик не замечает, что некоторые ветки были упущены. Это может происходить по нескольким причинам, часть которых является следствиями ошибок, допущенных на этапе формирования проектной команды Заказчика:

1. Специалистами Заказчика, ответственными за приемку работ, являются ИТ-специалисты, и их квалификации недостаточно для оценки качества документа.

2. Ответственность своих специалистов оценивается Заказчиком неадекватно. То есть человек, принимающий основные решения по проекту общей стоимостью 500 тысяч долларов, может иметь зарплату 1 тысячу долларов.

3. Ответственность за результат работы отодвинута во времени на длительный срок. Если описание БП будет неправильным, это станет заметно только через несколько месяцев.

4. У специалистов заказчика есть другие сложные задачи, вне данного проекта, ответственность по которым сиюминутная и дорогая.

5. Компетентные специалисты Заказчика не любят сбои в работе процесса, так как несут за них реальную ответственность. Если в описании БП такой сбой не будет описан, это произведет благоприятное впечатление на подсознательном уровне.

6. Бизнес-процессы могут измениться к моменту начала внедрения.

Если при правильной организации приемки работ с причинами 1, 2, 4, 5, 6 можно и нужно бороться, то причина 3 является неотъемлемой частью этапа описания БП.

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

2.2. Техническое задание на проект

Техническое задание – это задание Заказчика Исполнителю. Не странно ли, что и его готовит Исполнитель? Дело в том, что аппетит зачастую приходит во время еды, требования Заказчика в процессе внедрения обычно начинают расти, и одна из задач консультантов Исполнителя – держать Заказчика в рамках.

Принимается этот документ почти так же, как принимается описание бизнес-процессов. Не исключено, что Заказчик заставит Исполнителя включить в задание еще пару пунктов, которые неявно упоминались в договоре. Специалисты Заказчика довольны – им удалось настоять на своем. Исполнитель доволен – этап закрыт.

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

2.3. Настройка системы, описание доработок

Настройка системы требует грамотного консультанта. Это уже технология, и ясно, за что платятся деньги – у Заказчика нет специалиста, который сможет это сделать. Описание доработок – документ еще более сложный. Консультант, хорошо знающий систему, определяет, что из описанного в техническом задании системе по силам, а что потребует написания дополнительных программ.

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

• Предыдущая
• 24/33
• Следующая