Вивек Кале: Внедрение SAP R/3: Руководство для менеджеров и инженеров

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

• Функциональное рассредоточение, задаваемое требованиями.

• Более позднее разрешение рисков.

• Более позднее обнаружение ошибок.

• Использование различных языков или артефактов на различных стадиях проекта.

• Большой процент отбраковки и необходимости дальнейшей доработки.

• Сложные взаимодействия с пользователями, не занятыми в сфере IT.

• Приоритет технических приемов над инструментальными средствами.

• Приоритет качества разработанного программного продукта над функциональностью как таковой.

• Значительный акцент на создании текущей правильной, полной и последовательной документации.

• Акцент на тестировании и периодическом просмотре.

• Большая работа в области контроля и управления изменениями.

• Многочисленные и разнообразные требования к ресурсам.

• Выполнение планов в авральном режиме.

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

• Унаследованные ограничения масштабируемости.

• Слабая интеграция между системами.

Многие альтернативные стратегии были задуманы как Автоматизированная Разработка Программного Обеспечения (Computer Aided Software Engineering, CASE) и прототипы, однако, ни одна из них не оказалась в состоянии преодолеть эти основные барьеры. В случае с CASE, существовали более точные условия для анализа и проектирования требований, и последующий процесс написания исходного кода, тестирования и создания документации был в значительной степени автоматизирован. Большее количество времени, посвященное проработке и определению требований с участием конечного пользователя, имело своей целью получение системы, максимально удовлетворяющей действительным требованиям пользователя. С другой стороны, прототипы разрабатывались для адресного сбора требований путем прямого участия конечного пользователя в процессе их определения. В основном такое участие фокусировалось на внешнем дизайне экранов и проектировании отчетов, поскольку данные элементы могли быть непосредственно визуализированы пользователем. Но ни одна из этих стратегий в действительности не разрешила проблему. ERP-системы оперируют абсолютно иным подходом, предоставляя наиболее полный и всеобъемлющий спектр функциональных возможностей внутри системы. При использовании системы персоналу компании нужно лишь отбирать то, что требуется на данный момент. Таким образом, ERP-системы способствуют значительному сокращению всего процесса приема требований. Традиционный жизненный цикл проекта, состоящий из анализа, проектирования, разработки, тестирования и реализации, трансформировался в цикл реализации ERP-программы, включающий стадии определения требований, анализа расхождений, конфигурации и адаптации, тестирования и реализации. На рис. 1.1 приведен сравнительный анализ затрат на разработку ERP-программ и традиционного программного продукта.

Рис 1.1. Сравнение затраченных усилий на разработку ERP и традиционного способа разработки программных продуктов.

В конечном счете, это привело к ERP-революции, что мы сейчас и наблюдаем.

В отличие от традиционных систем, ввод в действие ERP-системы подразумевает внедрение всеобъемлющих, заранее спроектированных приложений, характеризующихся:

• Превосходной архитектурой, процессно-ориентированным конфигурированием

• Непосредственным участием конечных пользователей в процессе разработки

• Ранним устранением рисков

• Ранним обнаружением пропусков и ошибок

• Повторяющимся жизненным циклом программы, ничтожным количеством брака и переделок

• Легко изменяемой и конфигурируемой функциональностью

• Непосредственной организацией работы сотрудников не занятых в сфере IT

• Приоритетом функциональности над методо-ориентированным инструментарием

• Качественной вариативностью и гибкостью предоставляемой функциональности

• Полным, максимально аккуратным документированием изменений в конфигурации и настройках

• Значительным акцентом на проверке интегрированности системы

• Постоянной демонстрацией функциональности на всех стадиях проекта

• Двойной категорией ресурсных требований: функциональной и технической