Корпоративное ПО: заказ или тираж?

Дмитрий Музалев
CNews.Ru

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

 

 

Каждый из подходов имеет свои плюсы и минусы.

Два полюса разработки

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

Другой сегмент рынка – реализация заказных проектов. Здесь возможна как разработка «с нуля», так и использование в качестве основы предыдущих наработок. Принципиально то, что полученная программа не тиражируется по клиентам и, если и сопровождается, то как отдельный продукт. В таких случаях себестоимость инсталляции очень велика, а себестоимость сопровождения низкая, хотя и несколько выше, чем в первом случае. Развитие продукта по инициативе разработчиков обычно не предполагается, а обновления возникают в результате дополнительных заказов на доработки и характеризуются стабильностью ниже среднего. Цена в первую очередь зависит от объема реализуемой функциональности.

Между этими полюсами располагается проблемная во многих отношения область, где фирма-разработчик, производя тиражный продукт, выполняет при каждом внедрении большой объем доработок, и в дальнейшем сопровождает их как единое целое с системой: т.е. обеспечивает их совместимость со всеми последующими обновлениями тиражного продукта или включает в его состав. Себестоимость инсталляции средняя, сопровождения – очень высокая. Стабильность обновлений – низкая. Стоимость качественного управления развитием продукта для фирмы-производителя очень высока, поэтому часто развитие хаотическое. Минимальная цена для клиента определяется объемом необходимых доработок, а также расходами по их дальнейшей адаптации, реинжинирингу и поддержке. Цена эта очень высока, а ее снижение за счет второй группы расходов либо означает перекрестное финансирование за счет других проектов, либо приводит к существенному снижению качества программного продукта в долгосрочной перспективе.

Модели работы

Рассмотрим более подробно эти три модели работы:
Модель 1. Тиражный продукт. Доработки выполняются распространителями (компаниями-партнерами), производитель не обеспечивает их совместимость с обновлениями системы.
Модель 2. Заказной проект. Разработка нового продукта под потребности клиента. Тиражирование не осуществляется.
Модель 3. Тиражный продукт. Доработки выполняет производитель и в дальнейшем обеспечивает их сопровождение и полную совместимость с обновлениями.

А также пять характеристик:

1. Себестоимость инсталляции. Прямые расходы производителя, связанные с установкой системы у нового клиента.
2. Себестоимость сопровождения. Прямые расходы производителя на сопровождение системы после завершения внедрения.
3. Устойчивость обновлений. Мера влияния выбранной модели на способность производителя обеспечить установку обновлений у клиента без возникновения серьезных ошибок и дополнительных трудозатрат. Прочие влияющие факторы, такие как совершенство процессов сборки и тестирования, в данном случае не рассматриваются.
4. Управление развитием. Мера влияния выбранной модели на способность производителя обеспечить осмысленное развитие функциональности системы, отвечающее планам и принятым внутренним стандартам.
5. Стоимость для клиента. Мера влияния выбранной модели на минимальную продажную цену, которую может себе позволить производитель. Стоимость услуг не учитывается.

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

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

Тиражный продукт с ответственностью производителя за внедрение и поддержку доработок, выглядит в этой системе координат наиболее привлекательно. Небольшой по мировым меркам объем нашего рынка и высокая конкуренция среди разработчиков диктует производителям необходимость опускать цены значительно ниже обусловленного выбранной технологий уровня. С последствиями такого решения клиент в среднесрочной перспективе сталкивается только в виде низкого качества обновлений. Отсутствие должного развития купленной системы становится проблемой только на временном интервале 5-10 лет и оборачивается либо осознанием необходимости замены информационной системы, либо выпуском производителем принципиально нового продукта, эволюционный переход на который невозможен. В обоих случаях клиент вынужден проводить повторное внедрение со всеми сопутствующими этому процессу расходами и сложностями. Впрочем, надо отметить, что срок 5-10 лет в большинстве случаев достаточен, чтобы окупить проект.

В поисках выхода

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

Описанные особенности работы с клиентами выступают как важное конкурентное преимущество, а значит нужно учиться зарабатывать и развиваться в этих условиях. Дополнительным преимуществом является расширенный набор услуг, входящих в сопровождение, который де-факто стал уже стандартом для отечественных ИТ-компаний. Это прежде всего своевременная поддержка изменений законодательства в рамках закупленной функциональности без дополнительной оплаты, исправление ошибок в жестко оговоренные сроки (обычно регламентируются соглашением о приоритетах) и выполнение доработок по ограниченной поддержке изменений бизнес-процессов клиента (объем может быть зафиксирован в договоре сопровождения).

Кроме того, за последние годы отечественные разработчики накопили богатый опыт реализации задач, связанных с промышленной разработкой информационных систем. В целом успешно решаются такие проблемы как: конфигурационное управление, управление тестированием (в том числе организация автоматизированного тестирования), управление требованиями, организация разработки и хранения проектной документации, управление внутренним документооборотом (регистрация и маршрутизация задач, в том числе обеспечение для клиентов сервисов по вводу задач и отслеживания их статусов), управление проектами, ресурсное планирование, регистрация и анализ потребностей клиентов, в том числе потенциальных и регистрация и обработка внешних контактов.

Проблема настоящего момента заключается в том, что при решении этих задач используются программные средства разных производителей никак между собой не интегрированные. Производители ПО страдают от той самой проблемы «кусочной» автоматизации, которую успешно решают для своих клиентов. Конечно, уровень компетенции сотрудников IT-компаний в некоторой степени сглаживает негативное влияние этого фактора и позволяет проводить самостоятельные работы по увязке приложений на наиболее важных участках, но осознание топ-менеджментом необходимости внедрения комплексной информационной системы управления разработкой уже стало фактом.

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

Второе направление, где сохраняются значительные резервы роста – оптимизация и стандартизация процессов управления, как в области качества, так и проектной деятельности. Большой интерес вызывает перспектива внедрения стандартов серии ISO и стандарта управления проектами PMI. Соответствующие предложения на рынке консультационных услуг представлены довольно широко, но надо отметить, что опыт консультантов по оптимизации и стандартизации процессов производства программного обеспечения пока недостаточен, и стандартные подходы не сформированы.

Комментарии

Владимир Рахтеенко: В основе заказной разработки ПО лежат специальные технологии

Комментарий по теме для CNews дал Владимир Рахтеенко , Генеральный директор компании «Заказные ИнформСистемы»

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

Оговоримся, что мы имеем ввиду средние и крупные компании, для которых цель автоматизации – повышение управляемости и/или интенсификация деятельности. Такие задачи заведомо предполагают, что бизнес-решение будет поддерживать конкурентные преимущества, то есть уникальность, а значит потребует столь же индивидуальной поддержки.

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

Объективными показателями для сравнения проектов доработки тиражных или заказных систем выступают начальный объем программного кода и количество необходимых изменений в исходной системе.

Допустим, заказчика устраивает 70%-80% функционала тиражной ERP-системы. Чем обернется переделка 20%-30% интегрированной системы? При реализации уникальных бизнес-процессов в тиражной системе велик риск затронуть работу ее базовых механизмов. Тогда заказчик получит настолько уникальную версию, что ее развитие может быть не просто слишком дорого, но вообще невозможно.

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

Известно, что в процессе внедрения объем дополнительных пожеланий заказчика возрастает в среднем на 2-10% в месяц. Риски, порождаемые бурными изменениями, – это не только усложнение, удорожающее каждый последующий шаг доработки системы, но и размывание ее концептуальной целостности. Гарантировать управление таким проектом будет не только управление процессом разработки, но и технология передачи знаний от разработчика заказчику. Тут мы согласимся с автором: у заказчика должна быть сильная ИТ-команда.

Развитие всех этих технологий является предметом постоянного внимания и инвестиций для компаний, занимающихся заказной разработкой ПО.

CNews: Спасибо.

Статья получена: Клерк.Ру

загрузка...