Просмотр исходного текста страницы В основе заказной разработки ПО лежат специальные технологии

;[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]], генеральный директор ООО «Заказные ИнформСистемы».

<blockquote>
Комментарий на статью Дмитрия Музалева [http://www.cnews.ru/reviews/articles/index.shtml?2005/07/27/183211  «Корпоративное ПО: заказ или тираж?»]
</blockquote>

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

Поскольку детальный анализ тоже потребовал бы написания целой статьи, а возможно и не одной, мы ограничимся некоторыми соображениями, основанными на опыте заказной разработки ПО, которой наша компания — CUSTIS (Заказные ИнформСистемы) [http://www.custis.ru http://www.custis.ru] - занимается с момента ее основания в 1996 г.

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

Отличие заказного ПО от тиражного заключается в том, что программа изменяется под заказчика, а не наоборот. Это обеспечивается использованием особых '''инструментария разработки и технологий ведения проектов'''. Например, в заказных проектах используется инструментарий, обеспечивающий масштабирование не только по «железу и базовому софту», но и по бизнес-логике, что, вопреки утверждению автора статьи, нехарактерно для тиражных решений. Фактически такая разработка — тоже проект доработки, а не создания системы «с нуля», но стартовые позиции и затрачиваемые ресурсы совершенно иные, чем в случае тиражных систем.

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

Допустим, заказчика устраивает 70 %-80 % функционала тиражной ERP-системы. Чем обернется переделка 20 %-30 % интегрированной системы? При реализации уникальных бизнес-процессов в тиражной системе велик риск затронуть работу ее базовых механизмов. Тогда заказчик получит настолько уникальную версию, что ее развитие может быть не просто слишком дорого, но вообще невозможно.

Компаниям, планирующим развивать свой бизнес, может быть выгодно заказывать систему, приобретая небольшой базовый функционал вместе с заложенной в нем '''технологией развития'''. Это снижает давление «присоединенной массы» готового ПО на дальнейшее развитие, оптимизирует цену владения и обеспечивает жизнеспособность системы на большом промежутке времени.

Известно, что в процессе внедрения объем дополнительных пожеланий заказчика возрастает в среднем на 2-10 % в месяц. Риски, порождаемые бурными изменениями, — это не только усложнение, удорожающее каждый последующий шаг доработки системы, но и размывание ее концептуальной целостности. Гарантировать управление таким проектом будет не только управление процессом разработки, но и '''технология передачи знаний''' от разработчика заказчику. Тут мы согласимся с автором: у заказчика должна быть сильная ИТ-команда.

Развитие всех этих технологий является предметом постоянного внимания и инвестиций для компаний, занимающихся заказной разработкой ПО.

[[Категория:Владимир Рахтеенко (Статьи)]]
[[Категория:2005 год (Статьи)]]
[[Категория:CNews (Публикации)]]
[[Категория:Технологии разработки ПО (Статьи)]]

{{replicate-from-custiswiki-to-lib}}