Новая страница
Главная /
Минимизация стоимости неудачного проекта автоматизации
31.01.2007
В первую группу способов минимизации отнесем «управление финансовыми рисками». Что сюда входит:
1. Страхование внедрение на случай неудачи. Страховая компания берет обязательства по оплате неудачного проекта. Данный вариант тяжеловесен, сложен в управлении и увеличивает стоимость проекта, однако есть возможность компенсировать убытки.
2. Двухстороннее страхование. Компании Заказчик и Исполнитель договариваются, что 10% стоимости каждого этапа резервируются и выплачиваются в конце удачного проекта в целом. В случае неудачи резервируемая сумма идет на дополнительные работы. В конце концов, Заказчик сохраняет часть средств выполненных работ.
3. Стимулирование работ. Заказчик и Исполнитель решают, что в случае закрытия этапа на неделю раньше стоимость возрастает на 10%, а в случае продлении падает на 10% с каждой неделей. Очень красивое решение, однако, требования к друг другу резко возрастают.
Следующее решение связано с Управлениями Проектами. По этой идеологии надо каждый проект разбивать на минимальные неделимые единицы (задачи). Оплату выполненных работ следует привязать не к этапу, а непосредственно к задаче. Таким образом, будет масса мелких платежей. И в случае остановки работ Заказчик платит только за выполненные работы. Поэтому в случае провала этапа, Заказчик оплачивает только часть работ. Хотя оплата выполненных работ идет после подписание акта, минимизация достигается за уменьшения сумм авансов. Кроме того, легче выплачивать 10 раз по 1000 руб, чем один раз 10 000.
Программное и аппаратное обеспечение также необходимо оплачивать частями. Покупку лицензий рекомендуется делать только в то время, когда идет внедрение данных рабочих мест. Нежелательно оплачивать лицензии после написания техзадания и подписания договора. Отказаться от лишних рабочих мест будет трудно даже в случае успешного внедрения. Хотя сервер останется у Заказчика в любом случае и потом может быть использован на другом внедрении, все-таки лучше решать проблемы по мере возникновения. До 20 рабочих мест в качестве сервера часто подходят обычные двухядерные компьютеры, что на первом этапе внедрения полностью устраивает по количеству пользователей и загрузке. Кроме того, сервера приложений корпоративных систем могут работать одновременно на нескольких физических серверах.
В конце хотелось отметить прототипную модель внедрения, которая также позволяет избежать финансовых потерь путем отказа от внедрения уже на первом этапе. Перед внедрением Исполнитель разрабатывает прототип будущей системы. Если прототип обеспечивает должную функциональность и гибкость, на его основе создается автоматизированная система. В противном случае ищется новая программная платформа или Исполнитель. Например, Заказчику нужно разработать «Приходный Кассовый Ордер». Исполнитель создает работающий прототип. Если в прототипе есть недоработки: не проставляются данные из сотрудника в документ, то его принимают. А вот если отсутствует сам справочник сотрудников, то такой прототип отвергается. В идеале прототип должен выполнять нужный функционал Заказчика и быть лишенном некоторых сервисов, связанных с удобством ввода информации и получения отчетов. В хорошем случае прототип становится ядром будущей системы, в плохом сразу видна неработоспособность систем и естественен отказ от нее.
Об способах по минимизации стоимости убытков при неудачном внедрения Заказчик должен оповестить Исполнителя до начала взаимодействия. Часть крупных Исполнителей хотят сразу и все. Также надо помнить, что Исполнитель не несет ответственности за работоспособность программы. Гарантийные обязательства заканчиваются опытной эксплуатацией, которую также оплачивает Заказчик. Заказчик интересен Исполнителю до тех пор, пока Заказчик не оплатит большую часть внедрения.
1. Страхование внедрение на случай неудачи. Страховая компания берет обязательства по оплате неудачного проекта. Данный вариант тяжеловесен, сложен в управлении и увеличивает стоимость проекта, однако есть возможность компенсировать убытки.
2. Двухстороннее страхование. Компании Заказчик и Исполнитель договариваются, что 10% стоимости каждого этапа резервируются и выплачиваются в конце удачного проекта в целом. В случае неудачи резервируемая сумма идет на дополнительные работы. В конце концов, Заказчик сохраняет часть средств выполненных работ.
3. Стимулирование работ. Заказчик и Исполнитель решают, что в случае закрытия этапа на неделю раньше стоимость возрастает на 10%, а в случае продлении падает на 10% с каждой неделей. Очень красивое решение, однако, требования к друг другу резко возрастают.
Следующее решение связано с Управлениями Проектами. По этой идеологии надо каждый проект разбивать на минимальные неделимые единицы (задачи). Оплату выполненных работ следует привязать не к этапу, а непосредственно к задаче. Таким образом, будет масса мелких платежей. И в случае остановки работ Заказчик платит только за выполненные работы. Поэтому в случае провала этапа, Заказчик оплачивает только часть работ. Хотя оплата выполненных работ идет после подписание акта, минимизация достигается за уменьшения сумм авансов. Кроме того, легче выплачивать 10 раз по 1000 руб, чем один раз 10 000.
Программное и аппаратное обеспечение также необходимо оплачивать частями. Покупку лицензий рекомендуется делать только в то время, когда идет внедрение данных рабочих мест. Нежелательно оплачивать лицензии после написания техзадания и подписания договора. Отказаться от лишних рабочих мест будет трудно даже в случае успешного внедрения. Хотя сервер останется у Заказчика в любом случае и потом может быть использован на другом внедрении, все-таки лучше решать проблемы по мере возникновения. До 20 рабочих мест в качестве сервера часто подходят обычные двухядерные компьютеры, что на первом этапе внедрения полностью устраивает по количеству пользователей и загрузке. Кроме того, сервера приложений корпоративных систем могут работать одновременно на нескольких физических серверах.
В конце хотелось отметить прототипную модель внедрения, которая также позволяет избежать финансовых потерь путем отказа от внедрения уже на первом этапе. Перед внедрением Исполнитель разрабатывает прототип будущей системы. Если прототип обеспечивает должную функциональность и гибкость, на его основе создается автоматизированная система. В противном случае ищется новая программная платформа или Исполнитель. Например, Заказчику нужно разработать «Приходный Кассовый Ордер». Исполнитель создает работающий прототип. Если в прототипе есть недоработки: не проставляются данные из сотрудника в документ, то его принимают. А вот если отсутствует сам справочник сотрудников, то такой прототип отвергается. В идеале прототип должен выполнять нужный функционал Заказчика и быть лишенном некоторых сервисов, связанных с удобством ввода информации и получения отчетов. В хорошем случае прототип становится ядром будущей системы, в плохом сразу видна неработоспособность систем и естественен отказ от нее.
Об способах по минимизации стоимости убытков при неудачном внедрения Заказчик должен оповестить Исполнителя до начала взаимодействия. Часть крупных Исполнителей хотят сразу и все. Также надо помнить, что Исполнитель не несет ответственности за работоспособность программы. Гарантийные обязательства заканчиваются опытной эксплуатацией, которую также оплачивает Заказчик. Заказчик интересен Исполнителю до тех пор, пока Заказчик не оплатит большую часть внедрения.