Техническая библиотека CITForum.ru CITKIT.ru - все об Open Source Форумы Курилка
Все новости / Все статьи Деловая газета - шквал(!) IT-новостей :: CITCITY.RU
Первая полоса ИТ-Инфраструктура Телекоммуникации Безопасность BI Интеграционные платформы КИС IT-бизнес Ширпотреб Точка зрения

23.03.2017

Новости:


Все новости

IT-бизнес

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

Сегодня большинство компаний внедряет готовое программное обеспечение. Наиболее интенсивный рост продаж тиражного ПО и одновременное сокращение заказных разработок наблюдались до 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 года.
  2. Близок ли конец готовых приложений? (The Death of Packaged Apps?), Эрик Келлер (Erik Keller), май 2006 года.


Комментарии

аноним, Fri Aug 22 10:06:54 2008:
аноним, пятница, 22 августа 2008 г. 00:52:30:
> А то, что экономисты у нас по 10 лет не могут сформулировать какие программы нужны для планирования это факт. Нет требований сформулированных без невнятного мычания.

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

> За открытыми стандартами - открытые проекты, за ними варианты реализации. Тоже открытые. И пузырь автоматизации сдуется, и адекватное ПО появится.

Открытых и даже Свободный решений в области инструментов полно. Есть и свободно доступные транзакционные ядра, причём даже крайне эффективные и производительные (тот же Постгри), есть удобные языки (Ява, Руби, Питон...), есть и серверы приложений. Все компоненты есть уже сейчас. Нет понимания примата методологии и проектирования в разработке. Верная методология разработки и внедрения это 90% успеха. А пока всё с ног на голову. Сначала пытаются выдумать сверхнеудобный велосипед, а потом думают как же на нём поездить или как-то может по-другому в хозяйстве использовать.

> Никто не заинтересован в гипертрофировании отдельной отрасли. В данном случае программировании/консультировании.

О какой гипертрофии вы говорите. Этой области услуг в России вообще нет. Поэтому и тотальная отсталость и падение производительности труда по экономике вообще. Современные технологии в области экономической деятельности в России крайне слабо интегрированы и почти везде носят декоративный характер.
аноним, Fri Aug 22 00:52:30 2008:
> Никакого готового ПО для автоматизации различного рода бизнес-процессов и поддержки производственных процессов просто не существует.

Вот и надо его создавать, начиная со стандартов внешних и внутренних документов при осуществлении деятельности.

За открытыми стандартами - открытые проекты, за ними варианты реализации. Тоже открытые. И пузырь автоматизации сдуется, и адекватное ПО появится.

Прикладные открытые системы обязательно появятся вслед за открытыми отдельными приложениями (типа OpenOffice) и открытым системным ПО(Linux всех мастей, базы данных и т.д). Это вопрос времени. Никто не заинтересован в гипертрофировании отдельной отрасли. В данном случае программировании/консультировании.

А то, что экономисты у нас по 10 лет не могут сформулировать какие программы нужны для планирования это факт. Нет требований сформулированных без невнятного мычания - нет софта(пресловутых ERP и протчих CRM, BI и т.д.). В этом смысле бухучет оказался понятней. Поэтому и программ учетных понаваяли для писюков почти сразу как только эти писюки появились.
аноним, Fri Aug 22 00:34:56 2008:
> 1С что не готовая система?

Если не распускать бухгалтеров, то готовая.
Если набрать бухгалтеров-креативщиков - среда разработки.
аноним, Thu Aug 21 09:46:30 2008:
Никакого готового ПО для автоматизации различного рода бизнес-процессов и поддержки производственных процессов просто не существует. При внедрении так называемого готового ПО почти всегда получается каша из топора. Производителям ПО в этой сфере давно пора сосредоточиться на производстве хороших инструментов и методик их применения, а непосредственно прикладные решения лучше реализуются через заказную проектную разработку (при условии понимания заказчиком целей и грамотной комадны, конечно).
Рынок готовых решений в этой области в значительной степени рынок "шоу-бизнеса", когда клиенту различными, часто довольно сомнительными, способами, что называется "втюхивают" совершенно бесполезные продукт, потом ещё и берёт дерут с клиента три шкуры за совершенно бессмысленную и бесполезную для бизнеса клиента поддержку. Этим грешат все крупные игроки. В России наиболее типичный пример это линейка продуктов 1С:Предприятие.
Crazy Alex, Fri Aug 15 15:18:49 2008:
Ну, что внедренец агитирует за то, чтобы ему была работа - неудивительно.
аноним, Thu Aug 14 21:36:49 2008:
Готовая система это что? Вот почему везде висит - требуется 1С программист? 1С что не готовая система?

Комментарии заморожены.

Последние комментарии:

Самое интересное:


© 2004–2009 Проект CITCITY.ru