Сегодня большинство
компаний внедряет готовое программное обеспечение. Наиболее интенсивный рост
продаж тиражного ПО и одновременное сокращение заказных разработок наблюдались
до 2000 года. К 2004 году не менее 30% программных средств было представлено в
виде готовых продуктов. Далее рост расходов на покупку готового ПО несколько сократился, однако по-прежнему большинство компаний не стремится
«изобретать велосипед» и не прибегает к заказным проектам.
Тем не
менее, на этот счет есть и другие мнения. Некоторые эксперты считают, что в связи с некоторыми переменами на
рынке перевес может сместиться от использования тиражных приложений на сторону
заказной разработки. Попытаемся подробнее разобраться в ситуации, рассмотрев
каждый аргумент против использования тиражных приложений и соответствующий ему
контраргумент.
«Росту популярности индивидуальных проектов способствуют некоторые факторы. В
первую очередь, это появление сервис-ориентированной архитектуры, доступность ПО с открытым кодом и
оффшорных разработок. Кроме того, клиенты все чаще
недовольны эффективностью некоторых программных пакетов», - пишет Эрик Келлер (Erik Keller), консультант компании Wapitti. «Парадоксально то,
что желание разрабатывать проект на заказ проистекает из тех же причин, что в
свое время подтолкнули многих на покупку готовых пакетов», — продолжает он. — Перечислим их: медленный выход на рынок; низкое качество; большие расходы.
При учете этих факторов не удивительно, что клиенты отказываются от
первоначального стремления к покупке тиражного приложения и переходят к
заказной разработке».
Однако Крейг Шифф (Craig Schiff) — руководитель BPM Partners, известный эксперт в области BPM, считает так: «Когда
речь идет об управлении эффективностью, можно смело утверждать, что опытные специалисты-внедренцы, как правило, добиваются более
качественных результатов и в более короткие сроки, нежели внутренняя группа
разработчиков, не имеющая широкого опыта в BPM».
«Принятие сервисно-ориентированной архитектуры крупными пользователями — один из путей к упрощению заказной
разработки. За последние несколько лет лидеры (начиная с Motorola и заканчивая American Express) используют SOA для двух целей — построения приложений, заполняющих пробелы в корпоративном
рынке приложений, и для разработки стратегических систем путем комбинирования
целого набора сервисов. Многие считают,
что развертывание SOA станет ключевой инициативой в будущем», — отмечает Келлер.
Тем не
менее, то же самое можно сказать и о готовом программном обеспечении. Почти все
поставщики корпоративного ПО активно внедряют свои пакеты с использованием SOA и веб-сервисов,
упоминая такие преимущества, как более быстрая разработка приложений, быстрое
реконфигурирование, развертывание, низкие затраты.
Согласно
исследованиям, проводимым компанией BPM Partners, повсеместно внедряемая технология управления эффективностью вступила в
новый этап (BPM 2.0) и включает в себя массу разнообразных возможностей, в том числе SOA.
По словам Келлера, появление технологии Web 2.0 «являет собой еще один потенциальный катализатор к разработке
приложений. Сегодня новые возможности Web 2.0. распространяются очень быстро,
самостоятельно прокладывая себе путь. Пути этой технологии пока еще не слились
с корпоративными стратегиями, но по первым признакам можно судить, что и эти
инструменты будут способствовать скорее заказной разработке, чем тиражной».
Мнение
более чем спорное. Возможности Web 2.0. используют крупные поставщики корпоративных приложений,
и активно внедряют их клиенты.
«Когда в отрасли корпоративного ПО говорится о росте, то это рост связывается только с текущими расходами на
поддержку, обучение, устранение неполадок, обслуживание уже существующих
пакетов, их настройку и расширение и проч.», — продолжает Келлер.
В некоторых
рыночных исследованиях дается прямо противоположная оценка. В частности, если
говорить о рынке средств управления эффективностью (BPM), то, согласно данным отраслевого
опроса BPM Pulse Survey 2008, почти 40% компаний за последний год выбрали готовые
приложения, еще столько же — используют готовые приложения и инструменты.
Крейг Шифф утверждает, что «рост рынка программного обеспечения для
управления эффективностью за счет продаж (а не поддержки) достаточно стабилен
и ускоряется с каждым годом».
По данным Pulse Survey 2008, компаний, занимающихся
заказными разработками либо создающих программную среду собственными силами с
помощью инструментов, очень немного (не более 10%). В целом, мнение о том, что
основной составляющей дохода поставщиков являются поддержка и обучение, недостаточно обосновано.
Эта информация
относится к крупному и среднему бизнесу. Возможно, в малом бизнесе ситуация
несколько иная. Отчасти картина зависит от масштабов и сути проекта. Небольшие
транзакционные системы могут и сегодня разрабатываться в индивидуальном
порядке.
«В области BPM мелкие компании
склонны использовать инструменты для разработки собственно проекта, а крупные
компании предпочитают покупать пакетные приложения», — замечает Крейг Шифф.
«Сейчас "правят бал" оффшорные
компании. Рост влияния оффшорных компаний происходит не только в области разработки и поддержки простых
транзакционных приложений, но и в сфере создания сложных приложений.
Привлекательность для покупателей заключается в получении продукта, который
предназначен для конкретных нужд и обходится на 50% дешевле, нежели готовый
пакет. Кроме того, оффшорные компании часто предлагают поддержку за гораздо
более скромные деньги, чем известные разработчики», — утверждает консультант Wapitti.
Однако
кажущаяся привлекательность оффшорных разработок имеет и обратную сторону
медали. Одним из сложнейших этапов является сбор требований и планирование
проекта, поскольку разработчик и заказчик разделены географически. Кроме
того, в процессе создания программного обеспечения возникает множество рисков,
в том числе:
- риск
увеличения сроков разработки, который связан с тем, что IT-специалисты не могут работать в
тесном контакте с клиентом и часто вынуждены многое переделывать и возвращаться
к уже пройденным этапам;
- риск
выхода за рамки бюджета, обусловленный теми же причинами, что и увеличение
сроков;
- риск невозможности интеграции нового программного
обеспечения в уже имеющуюся IT-инфраструктур из-за несоответствия заказного ПО тем
стандартам и программным интерфейсам, которые уже имеются в информационной
системе заказчика;
- риск
получения недостаточной и несвоевременной, пусть и более дешевой поддержки.
«Развивающиеся
инфраструктуры с открытым кодом упрощают использование недорогих и
высококачественных компонентов для создания заказных проектов. Вместо того чтобы тратить сотни тысяч долларов (и более) на сложные
системы, серверы приложений, базы данных, средства наладки, инструменты и
проч., покупатели выбирают нужные компоненты из целой палитры средств с открытым кодом и создают
уникальные приложения. Некоторые поставщики иронизируют над
потенциалом открытого кода, однако как новички, так и профессионалы в
разных сферах активно эксплуатируют открытый код для построения стратегических
приложений… Множество поставщиков этого класса представляют ERP-,CRM- и BI-пакеты. Мало кто считает, что им удастся добиться
огромных прибылей и большого рынка сбыта, однако потенциальных пользователей
достаточно, и миллионы копий этих продуктов расходятся по миру. Если хотя бы 1%
этих копий используется, то уже можно говорить о том, что тысячи корпоративных
приложений основаны на программном обеспечении с открытым кодом», — пишет Келлер.
Согласно
множеству рыночных исследований последних лет, программное обеспечение с
открытым кодом действительно находит свой рынок сбыта, однако он по-прежнему невелик, и составляет лишь
небольшой процент по отношению к рынку коммерческого ПО.
Разработка проекта на заказ на основе открытого кода привлекательна лишь для
небольшого круга компаний. Если же заказчик уже имеет в своем арсенале
достаточное количество тиражных приложений, то задача встраивания в эту
структуру нестандартной системы (построенной с помощью средств с открытым
кодом) становится очень сложной, риск неудачного внедрения весьма велик.
«В IT-кругах многие говорят об инновациях, но при этом огромные
суммы денег тратятся не на инновационные бизнес-методы,
а на приложения. По-прежнему
используются стандартизированные процессы и транзакции. Как правило,
инновационные компании применяют заказные пакеты, а не стандартные решения. Готовое программное обеспечение
может быть инновационным только в двух случаях: в период его первоначального
появления на рынке, и когда стандартный пакет используется для расширения
дифференцированных бизнес-процессов заказчика (это случается редко, так как
большинство компаний, пытающихся использовать стандартный пакет, пытаются внедрить
"оптимальные методы", которые на практике оказываются в лучшем случае средними)»,
— считает Келлер.
Это
утверждение сегодня можно с уверенностью оспорить. В связи с нарастающей
конкуренцией в сфере корпоративного ПО, а также с консолидацией поставщиков и приобретением крупными
компаниями мелких инновационных фирм все технологические новшества очень
быстро внедряются в тиражных программных средствах.
«Заказные проекты
представляют собой не стандартный набор приложений, а набор сервисов (часто скомпонованный
с помощью инструментов SOA), который можно
сконфигурировать так, как это требуется клиенту. Часто это решение выполнено на
50-70%, а все "пустые места" заполняются по требованию заказчика. Такие решения
не ограничивается узким кругом областей, а представлены практически на всех
рынках, включая банковскую отрасль, финансы, правительственную деятельность,
производство и проч. Они менее представлены в области крупных корпоративных
систем (ERP, CRM и проч.)», — отмечает Келлер.
Да, отчасти
эксперт прав.
«Сегодня небольшое количество продуктов можно
отнести к категории "собираемых". Их не покупают в готовой форме и не разрабатывают на заказ. Заказчик ставит задачу разработки сложного многокомпонентого приложения, а также удобного пользовательского интерфейса, оптимизации процессов и других функций. Сборка зависит от доступности множества
корпоративных функций через сервисы. Технологические изменения, которые
упрощают сборку сложных приложений из сервисов, очень важны в установившейся
корпоративной среде (например, в ERP или CRM)», — замечает Шифф.
Заключение
Вопрос о
выборе между покупкой готового программного обеспечения и разработкой на заказ чаще
всего упирается в три основных проблемы:
- сроки
исполнения;
- бюджет;
- наличие
квалифицированных специалистов.
Если
область деятельности заказчика столь специфична, что для нее не существует
готовых программных средств, либо бюджет очень ограничен, но есть богатый опыт
в предметной области, квалифицированные
разработчики, а также умение решать задачи интеграции, то возможна и индивидуальная разработка.
Однако у большинства компаний такого опыта нет.
Оффшорные проекты несут в себе множество рисков. При этом на
рынке тиражного ПО доступны необходимые средства. Очевидно, что большинство руководителей делает
выбор в сторону готовых систем.
Поставщикам же следует иметь в виду, что, поскольку заказная разработка все же привлекает
определенную категорию клиентов, необходимо создавать продукты и
маркетинговые стратегии для такой специфической IT-среды, в том числе на основе
архитектуры SOA и веб-сервисов.
Публикации
- Управление эффективностью. Неужели заказная разработка популярнее готового ПО (Performance Management. Is
Build now Bigger than Buy?), Крейг Шифф (Craig Schiff), июль 2006 года.
- Близок ли конец готовых приложений? (The Death of Packaged Apps?), Эрик Келлер (Erik Keller), май 2006 года.
