Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Журнал ВРМ World

Дискуссия со сторонниками заказной разработки

Сегодня большинство компаний внедряет готовое программное обеспечение. Наиболее интенсивный рост продаж тиражного ПО и одновременное сокращение заказных разработок наблюдались до 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 и веб-сервисов.

Публикации:

  1. Управление эффективностью. Неужели заказная разработка популярнее готового ПО (Performance Management. Is Build now Bigger than Buy?), Крейг Шифф (Craig Schiff), июль 2006 года, http://www.b-eye-network.com/print/3089.
  2. Близок ли конец готовых приложений? (The Death of Packaged Apps?), Эрик Келлер (Erik Keller), май 2006 года, href=http://www.sandhill.com/opinion/editorial.php?id=83.