С появлением PC-ориентированных функциональных возможностей, запросы пользователей стали сложнее и требовательнее.
Как следствие, приложения стали более крупными и комплексными.
Соответственно, производительность скорее падала, чем увеличивалась.
Время разработки программного обеспечения возросло, увеличение затрат и времени
стали обычной практикой.
Высококвалифицированные профессионалы всегда были в цене, и это требовало увеличения затрат на содержание штата программистов; поэтому затраты на разработку систем неуклонно возрастали.
Процент прекращения эксплуатации систем был очень высок.
В среднем, из общего числа IT-систем, находящихся в разработке, более половины прекращают свое существование, а из второй половины приблизительно две трети идут в разработку. Половина этих систем так никогда и не реализуется, а реализация другой четверти не доводится до середины. В свою очередь, из оставшейся четверти половина систем не способна обеспечить необходимый набор функциональных возможностей, и, вследствие этого, отбраковывается за ненадобностью. И лишь остаточная половина систем используется после внесения значительного количества модификаций, что влечет дополнительные задержки и издержки практически бесконечного процесса.
Одной из главных причин вышеперечисленных проблем являлась наследуемая слабость стадии приема и анализа требований. Считалось, что на данной стадии невозможно собрать корректные и полные требования. В результате, завершенные проекты не предлагали всей обещанной полноты функциональных возможностей, вынуждая возвращаться к стадии дополнительного анализа и доработки. Процесс сопровождения и усовершенствования был практически бесконечным, и с течением времени все труднее реализовывался. Вследствие того, что индивидуумы меняются как со стороны разработчиков, так и пользователей, системные требования менялись соответственно, продлевая весь процесс практически до бесконечности. Основная причина этого состоит в фундаментальном разрыве между людьми бизнеса и работниками IT/IS. Несмотря на попытки обеих сторон сократить этот разрыв, существует огромное расхождение между восприятием бизнес-пользователя и тем, что подразумевается системным персоналом; оба класса людей говорят на абсолютно разных языках. Даже при использовании системным персоналом методологий и инструментов для дополнительных спецификаций и описаний, пользователи не в состоянии в полной мере ратифицировать документированные требования вследствие неосведомленности о таких инструментах.
Судя по проводимым исследованиям, от 50 до 80 % ресурсов IT/IS расходуются на сопровождение приложений. Прибыли по отношению к инвестируемому капиталу в IT-отрасли были крайне низки в соответствии с любым стандартом и уровнем ожиданий. При бюджетах IT/IS, значительно превышающих возможности большинства организаций, существовала настоятельная необходимость в радикально новом подходе, результатом которого явились бы удобные и простые в использовании функциональные средства, разработанные на высоком профессиональном уровне и в установленные временные рамки. Это является своеобразной постмодернистской версией понятия «двух культур», введенного Ч.П.Сноу в середине прошлого столетия для обсуждения мира искусства и мира науки.
Традиционный процесс реализации программных решений, включающий разработку приложений, характеризовался следующими особенностями:
Функциональное рассредоточение, задаваемое требованиями.
Более позднее разрешение рисков.
Более позднее обнаружение ошибок.
Использование различных языков или артефактов на различных стадиях проекта.
Большой процент отбраковки и необходимости дальнейшей доработки.
Сложные взаимодействия с пользователями, не занятыми в сфере IT.
Приоритет технических приемов над инструментальными средствами.
Приоритет качества разработанного программного продукта над функциональностью как таковой.
Значительный акцент на создании текущей правильной, полной и последовательной документации.
Акцент на тестировании и периодическом просмотре.
Большая работа в области контроля и управления изменениями.
Многочисленные и разнообразные требования к ресурсам.
Выполнение планов в авральном режиме.
Особое внимание аспекту планируемой или ориентировочной целевой производительности.
Унаследованные ограничения масштабируемости.
Слабая интеграция между системами.
Многие альтернативные стратегии были задуманы как Автоматизированная Разработка Программного Обеспечения (Computer Aided Software Engineering, CASE) и прототипы, однако, ни одна из них не оказалась в состоянии преодолеть эти основные барьеры. В случае с CASE, существовали более точные условия для анализа и проектирования требований, и последующий процесс написания
исходного кода, тестирования и создания документации был в значительной степени автоматизирован. Большее количество времени, посвященное проработке и определению требований с участием конечного пользователя, имело своей целью получение системы, максимально удовлетворяющей действительным требованиям пользователя. С другой стороны, прототипы разрабатывались для адресного сбора требований путем прямого участия конечного пользователя в процессе их определения. В основном такое участие фокусировалось на внешнем дизайне экранов и проектировании отчетов, поскольку данные элементы могли быть непосредственно визуализированы пользователем. Но ни одна из этих стратегий в действительности не разрешила проблему. ERP-системы оперируют абсолютно иным подходом, предоставляя наиболее полный и всеобъемлющий спектр функциональных возможностей внутри системы. При использовании системы персоналу компании нужно лишь отбирать то, что требуется на данный момент. Таким образом, ERP-системы способствуют значительному сокращению всего процесса приема требований. Традиционный жизненный цикл проекта, состоящий из анализа, проектирования, разработки, тестирования и реализации, трансформировался в цикл реализации ERP-программы, включающий стадии определения требований, анализа расхождений, конфигурации и адаптации, тестирования и реализации. На рис. 1.1 приведен сравнительный анализ затрат на разработку ERP-программ и традиционного программного продукта.