Модели разработки ПО
- Тиражный продукт. Доработки выполняются распространителями (компаниями-партнерами), производитель не обеспечивает их совместимость с обновлениями системы.
Использование тиражного продукта привлекательно для клиента тем, что он сразу получает некоторый гарантированно работоспособный объем функциональности и в дальнейшем может рассчитывать на его бесплатное (в рамках поставки обновлений) совершенствование. Новые модули могут докупаться в рамках расширения лицензионного соглашения со значительной скидкой. При этом первая модель характеризуется повышенными рисками, связанными с зачастую затрудненной идентификацией степени компетентности компании-распространителя и ее потенциальной неспособностью поддерживать совместимость выполненных при внедрении настроек и доработок. Поэтому выбор этой модели обычно обусловлен сильным брендом производителя.
- Заказной проект. Разработка нового продукта под потребности клиента. Тиражирование не осуществляется.
Заказной проект потенциально способен наиболее полно удовлетворить потребности клиента. При этом, однако, надо быть готовым к существенно большей длительности, а также иметь в виду, что риски, связанные с некорректной постановкой задач заметно перераспределяются на сторону заказчика, возможности системы по перенастройке бизнес-процессов окажутся ниже, чем у тиражных продуктов, и о планировании развития придется заботиться самостоятельно. Этот вариант может принести успех только предприятиям обладающим высокой культурой производства и процессов управления и сильной ИТ-командой. Но даже при этом крайне желательно привлечение внешних консультантов для проектирования и описания бизнес-процессов.
- Тиражный продукт. Доработки выполняет производитель и в дальнейшем обеспечивает их сопровождение и полную совместимость с обновлениями.
Тиражный продукт с ответственностью производителя за внедрение и поддержку доработок, выглядит в этой системе координат наиболее привлекательно. Небольшой по мировым меркам объем нашего рынка и высокая конкуренция среди разработчиков диктует производителям необходимость опускать цены значительно ниже обусловленного выбранной технологий уровня. С последствиями такого решения клиент в среднесрочной перспективе сталкивается только в виде низкого качества обновлений. Отсутствие должного развития купленной системы становится проблемой только на временном интервале 5-10 лет и оборачивается либо осознанием необходимости замены информационной системы, либо выпуском производителем принципиально нового продукта, эволюционный переход на который невозможен. В обоих случаях клиент вынужден проводить повторное внедрение со всеми сопутствующими этому процессу расходами и сложностями. Впрочем, надо отметить, что срок 5-10 лет в большинстве случаев достаточен, чтобы окупить проект.
10 лет занимаюсь разработкой АБС, IMHO, текст точно диагностирует текущую ситуацию: насыщение рынка + снижение рентабельности + вторая волна экспансии иностранных компаний (iFlex сотоварщи) на российский рынок.