Проект автоматизации документооборота

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

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

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

Вопросы для анализа:

1. На основе каких показателей руководитель проекта мог бы выявить ошибки в управлении стоимостью?

2. Какие ошибки были допущены в управлении стоимостью со стороны консалтинговой фирмы?

3. Как Вы оцениваете решение, принятое на совещании?

4. Какое решение было бы более целесообразно, по Вашему мнению?

Внедрение точно в срок

Ознакомьтесь с приведенным ниже текстом.

С целью повышения прозрачности ведения учета страховая компания РОСНО приняла решение внедрить систему Oracle E-Business Suite. За этим кроется естественное желание о6еспечить конкурентоспособность компании, привлечь больше клиентов и инвестиции.

Главной целью внедрения Oracle E-Business Suite в компании РОСНО было ведение бухгалтерского учета и отчетности по МСФО (международные стандарты финансовой отчетности). По словам Михаила Хабарова, первого заместителя генерального директора и финансового директора РОСНО, прежде в компании отчетность по МСФО готовилась путем трансформации РСБУ. Вся информация получалась раз в квартал с задержкой в 45 дней. С ростом бизнеса естественно возросли и объемы, которые требовалось обрабатывать. РОСНО стала первой страховой компанией в России, сделавшей успешный шаг по внедрению системы такого класса, как Oracle E-Business Suite. При этом, конечно же, пришлось взвесить все «за» и «против», оценить риски, поскольку на тот момент отсутствовала полная информация по удачно реализованным архитектурным решениям применения модулей Oracle E-Business Suite в российском страховом бизнесе.

Лучше маленькая победа

Как рассказал Михаил Хабаров на ERP-Forum-2004, проводимом компанией TopsBI, первая попытка внедрить Oracle E-Business Suite была предпринята в 2002 году и оказалась неудачной. «Наши ошибки на первой стадии проекта заключались в следующем, — рассказывает Михаил Хабаров. — Выбор системы начинается с презентаций, на которых консультанты из различных компаний говорят о том, какие многофункциональные системы предлагают и как быстро могут их внедрить. Огромная ошибка — поддаться на это, так как оказывается, во-первых, что не у всех поставщиков ERP-систем такой уж большой опыт внедрений в России, а во-вторых, для внедрения каждого блока требуется как минимум 70% усилий внутри компании (по времени, принятию решений и прочему). На каждого внешнего консультанта должно быть выделено еще минимум 1,5 человека внутри компании».

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