Тиражные приложения и заказная разработка. Преимущества для заказчика.

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

Слияния и поглощения, выполнение нормативных требований, использование самых современных технологий, необходимость доступа к большим объемам данных — все эти явления требуют все более серьезного подхода к выбору корпоративной IT-среды.

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

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

Рассмотрим все «за» и «против» заказной разработки и покупки тиражного приложения.

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

Однако часто задача стоит иначе, например: в уже имеющуюся среду компании нужно интегрировать какое-то новое приложение. В этом случае лучше приобрести готовый продукт, но прежде — провести тщательный анализ.

Важно оценить следующие факторы относительно предполагаемого проекта:

• доступность внутренних ресурсов, включая штат разработчиков;
• сложность и назначение проекта;
• особые потребности организации;
• время на разработку.

Кроме того, нужно учитывать следующие моменты:

• возможна ли разработка программной инфраструктуры собственными силами?
• имеется ли квалифицированный персонал, знакомый с технологиями и стандартами?
• целесообразно ли отвлекать на этот проект именно собственные ресурсы?
• если ответы на предыдущие вопросы отрицательные, то выяснить, есть ли возможность привлечь сторонних разработчиков.

Среди наиболее важных проблем, связанных с заказной разработкой, можно перечислить следующие:

• большие затраты на разработку и последующую поддержку;
• длительные сроки;
• невысокая эффективность.

Большие затраты

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

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

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

Если же заказная разработка осуществляется силами внешних разработчиков, то тут расходы могут быть еще выше:

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

Затратность поддержки

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

Длительные сроки

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

Нет реального улучшения процессов

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

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

Преимущества использования тиражного программного обеспечения

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

• низкая стоимость владения (TCO - total cost of ownership);
• быстрый выход на рынок;
• гибкость и масштабируемость внедрения;
• более высокий уровень интеграции со средствами третьих фирм;
• межфункциональная интеграция;
• автоматизированные, стандартизованные процессы проектирования;
• оптимизация ресурсов;
• высокая надежность и эффективность;
• документирование.

Стоимость владения

Наиболее продвинутые тиражные продукты позволяют сократить расходы на владение за счет:

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

Быстрый выход на рынок

Длительный цикл разработки заказного приложения не подходит многим организациям. Тиражные приложения сокращают время внедрения за счет:

• быстроты освоения;
• упрощения бизнес-процессов;
• краткого период внедрения для фундаментальных проектов;
• простоты использования как для профессионалов в области IT, так и для конечных пользователей.

Гибкость и масштабируемость внедрения

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

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

Более высокий уровень интеграции с приложениями третьих фирм

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

Интегрированные межфункциональные процессы

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

Автоматизированные процессы проектирования

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

Оптимизация ресурсов

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

Высокая надежность за счет обеспечения эффективности

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

Заключение

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

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

Публикации:

1. Управление эффективностью. Неужели заказная разработка популярнее готвого ПО? (Performance Management. Is Build now Bigger than Buy?), Крейг Шифф (Craig Schiff), июль 2006 года, href=http://www.b-eye-network.com/print/3089.
2. Бизнес проблема. Разработка против покупки (Business Imperative. Build versus Buy), апрель 2004, http://ww1.pervasive.com/documentation/whitepapers/pdf/Build_vs_Buy.pdf.

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