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