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

19.10.2017

Новости:


Все новости

IT-бизнес

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общая стоимость владения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Публикации:

  1. Управление эффективностью. Неужели заказная разработка популярнее готвого ПО? (Is Build now Bigger than Buy?), Крейг Шифф (Craig Schiff), июль 2006 года.
  2. Бизнес проблема. Разработка против покупки (Business Imperative. Build versus Buy), апрель 2004.


Комментарии

sts, Thu May 28 23:15:43 2009:
Не, што никто не понял, што ли - это ж реклама 1С!
"Наиболее продвинутые тиражные продукты позволяют сократить общую стоимость владения" - аццкий отжиг! и еще там куча таких же - маркетологи, закусывайте!
XAM, Thu Nov 20 01:04:14 2008:
Да уж... Жизнь - как вождение велосипеда. Чтобы не упасть, ты должен двигаться.
Геннадий Пастухов, Thu Sep 25 12:06:22 2008:
КГ/АМ. Такое ощущение, что автор никогда не сталкивался ни с заказной разработкой, ни с внедрением готового. В жизни всё озвученные критерии стоят наоборот.
Кирилл, Wed Aug 27 17:30:57 2008:
"Программист" 1С, он как собака Павлова -- ума ноль, одни хватательные рефлексы и обильное слюноотделение.
, Wed Aug 27 13:03:20 2008:
А ты пробовал в 1С писать?
прогер 1С частично еще и овладевает профессией того под чью конфигурацию пишет(бухгалтерия, зарпл. и кадры и т.д.), а умственный труд самый тяжелый, это те не мешки с песком тягать и если манагеры и бухи у нас такие тупые что не могут нормально систему под себя настроить пусть платят!!!
Валерий, Tue Aug 26 17:45:40 2008:
По прочтении статьи сложилось ощущение, что мы живём в какую-то древнюю эпоху. Как показывает практика, ПО из "коробки" (если это не "офис" или фотошоп какой, конечно) никогда нельзя сразу использовать в организациях. (Иначе все "программисты" 1С остались бы без работы, но как-то их требуется с каждым годом всё больше и зарплаты у них всё выше... Скажете, потому что у них квалификация запредельная или труд такой интенсивный?).
К счастью, организациям не обязательно начинать с нулевой точки отсчёта, есть масса opensource продуктов, которые за разумный срок можно адаптировать к бизнес-процессам организации, при этом система останется и расширяемой и обновляемой и поддерживать открытые стандарты.
В общем, об этом в статье ни слова, одни цитаты из... источники указаны.
Кирилл, Tue Aug 19 15:53:04 2008:
Блин, писаки, вы задалбали. Надо самому браться за подготовку нормальной вменяемой книги по проектированию бизнес-процессов в новых реалиях высокой доступности информационных технологий. Хватит пытаться костыль в задницу вставить. ИТ это не с боку припёка, во многих остраслях информационные технологии единственный способ радикального повышения продуктивности. Причём именно продуктивности, а не жалкой эффективности.
Savage, Tue Aug 19 13:45:32 2008:
Статья-бред сивой кабылы.
Автор пиши конкретно.
И сравнивай конкретные продукты, а еще лучше конкретных разработчиков.
andy, Wed Jul 30 16:21:19 2008:
тема очень размытая, однозначности нет
четкий критерий в статье не обозначен, а он один - минимум затрат при обеспечении необходимой функциональности
самые разные за и против есть и при том, и при другом подходе, так что нужно постараться посчитать в денежном эквиваленте
общие рекомендации, вроде приведенных в статье, являются уж слишком общими и годятся только для самых простых случаев

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

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

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


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