Корпоративное ПО: заказ или тираж?
При разработке корпоративного ПО возможна реализация двух основных подходов. В первом случае сопровождение программного продукта включает в себя поставку обновлений и небольшой объем консультаций силами вендора, а адаптацию решения под требования клиента обеспечивает партнер. При этом производитель не поддерживает доработки последнего. Второй случай – реализация заказных проектов. Такой продукт не является тиражным и его сопровождение индивидуально. Каждый из подходов имеет свои плюсы и минусы.
Два полюса разработки
Для большинства мировых компаний-производителей ПО нормой является ситуация, когда сопровождение включает в себя поставку обновлений системы (патчей и версий) и – в лучшем случае – довольно скромный объем консультаций. Состав обновлений при этом определяется внутренними планами развития продукта, влияние потребностей отдельного клиента минимально. Адаптация под клиента выполняется фирмами-распространителями, производитель ответственности за поддержку сделанных ими доработок не несет. Такая схема работы позволяет обеспечить высокую устойчивость обновлений, характеризуется низкой себестоимостью инсталляции и последующего сопровождения и позволяет качественно управлять развитием продукта. Стоимость проекта внедрения для клиента (за вычетом стоимости услуг) определяется торговой политикой фирмы-производителя.
Другой сегмент рынка – реализация заказных проектов. Здесь возможна как разработка «с нуля», так и использование в качестве основы предыдущих наработок. Принципиально то, что полученная программа не тиражируется по клиентам и, если и сопровождается, то как отдельный продукт. В таких случаях себестоимость инсталляции очень велика, а себестоимость сопровождения низкая, хотя и несколько выше, чем в первом случае. Развитие продукта по инициативе разработчиков обычно не предполагается, а обновления возникают в результате дополнительных заказов на доработки и характеризуются стабильностью ниже среднего. Цена в первую очередь зависит от объема реализуемой функциональности.
Между этими полюсами располагается проблемная во многих отношения область, где фирма-разработчик, производя тиражный продукт, выполняет при каждом внедрении большой объем доработок, и в дальнейшем сопровождает их как единое целое с системой: т.е. обеспечивает их совместимость со всеми последующими обновлениями тиражного продукта или включает в его состав. Себестоимость инсталляции средняя, сопровождения – очень высокая. Стабильность обновлений – низкая. Стоимость качественного управления развитием продукта для фирмы-производителя очень высока, поэтому часто развитие хаотическое. Минимальная цена для клиента определяется объемом необходимых доработок, а также расходами по их дальнейшей адаптации, реинжинирингу и поддержке. Цена эта очень высока, а ее снижение за счет второй группы расходов либо означает перекрестное финансирование за счет других проектов, либо приводит к существенному снижению качества программного продукта в долгосрочной перспективе.
Модели работы
Рассмотрим более подробно эти три модели работы:
Модель 1. Тиражный продукт. Доработки выполняются распространителями (компаниями-партнерами), производитель не обеспечивает их совместимость с обновлениями системы.
Модель 2. Заказной проект. Разработка нового продукта под потребности клиента. Тиражирование не осуществляется.
Модель 3. Тиражный продукт. Доработки выполняет производитель и в дальнейшем обеспечивает их сопровождение и полную совместимость с обновлениями.
А также пять характеристик:
1. Себестоимость инсталляции. Прямые расходы производителя, связанные с установкой системы у нового клиента.
2. Себестоимость сопровождения. Прямые расходы производителя на сопровождение системы после завершения внедрения.
3. Устойчивость обновлений. Мера влияния выбранной модели на способность производителя обеспечить установку обновлений у клиента без возникновения серьезных ошибок и дополнительных трудозатрат. Прочие влияющие факторы, такие как совершенство процессов сборки и тестирования, в данном случае не рассматриваются.
4. Управление развитием. Мера влияния выбранной модели на способность производителя обеспечить осмысленное развитие функциональности системы, отвечающее планам и принятым внутренним стандартам.
5. Стоимость для клиента. Мера влияния выбранной модели на минимальную продажную цену, которую может себе позволить производитель. Стоимость услуг не учитывается.
Использование тиражного продукта привлекательно для клиента тем, что он сразу получает некоторый гарантированно работоспособный объем функциональности и в дальнейшем может рассчитывать на его бесплатное (в рамках поставки обновлений) совершенствование. Новые модули могут докупаться в рамках расширения лицензионного соглашения со значительной скидкой. При этом первая модель характеризуется повышенными рисками, связанными с зачастую затрудненной идентификацией степени компетентности компании-распространителя и ее потенциальной неспособностью поддерживать совместимость выполненных при внедрении настроек и доработок. Поэтому выбор этой модели обычно обусловлен сильным брендом производителя.
Заказной проект потенциально способен наиболее полно удовлетворить потребности клиента. При этом, однако, надо быть готовым к существенно большей длительности, а также иметь в виду, что риски, связанные с некорректной постановкой задач заметно перераспределяются на сторону заказчика, возможности системы по перенастройке бизнес-процессов окажутся ниже, чем у тиражных продуктов, и о планировании развития придется заботиться самостоятельно. Этот вариант может принести успех только предприятиям обладающим высокой культурой производства и процессов управления и сильной ИТ-командой. Но даже при этом крайне желательно привлечение внешних консультантов для проектирования и описания бизнес-процессов.
Тиражный продукт с ответственностью производителя за внедрение и поддержку доработок, выглядит в этой системе координат наиболее привлекательно. Небольшой по мировым меркам объем нашего рынка и высокая конкуренция среди разработчиков диктует производителям необходимость опускать цены значительно ниже обусловленного выбранной технологий уровня. С последствиями такого решения клиент в среднесрочной перспективе сталкивается только в виде низкого качества обновлений. Отсутствие должного развития купленной системы становится проблемой только на временном интервале 5-10 лет и оборачивается либо осознанием необходимости замены информационной системы, либо выпуском производителем принципиально нового продукта, эволюционный переход на который невозможен. В обоих случаях клиент вынужден проводить повторное внедрение со всеми сопутствующими этому процессу расходами и сложностями. Впрочем, надо отметить, что срок 5-10 лет в большинстве случаев достаточен, чтобы окупить проект.
Короткая ссылка на материал: //cnews.ru/link/a1119
