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

Предлагаем читателю дискуссионную статью, представляющую два противоположных
взгляда на заказную разработку и тиражные приложения. Сторонником
индивидуальных проектов выступает консультант компании Wapitti Эрик Келлер
(Erik Keller). В противовес его мнению приводятся высказывания известного
специалиста по BPM Крейга Шиффа (Craig Schiff), позиция которого подкрепляется
отраслевыми исследованиями.

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

Автор: По материалам зарубежных сайтов