Обеспечивающие подсистемы

 Информационное обеспечение – это совокупность средств и методов построения информационной базы. Оно определяет способы и формы отображения состояния объекта управления в виде данных внутри ИС, документов, графиков и сигналов вне ИС. Информационное обеспечение подразделяют на внешнее и внутреннее.

Математическое обеспечение состоит из алгоритмического и программного

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

     Программное обеспечение состоит:

·     из общего ПО (ОС, трансляторы, тесты и диагностика и др., т. е. все то, что обеспечивает работу аппаратных устройств);

·     специального ПО (прикладное ПО, обеспечивающее автоматизацию процессов управления в заданной предметной области).

Техническое обеспечение (рис. 21) состоит из устройств:

·     измерения;

·     преобразования;

·     передачи;

·     хранения;

·     обработки;

·     отображения;

·     регистрации;

·     ввода/вывода информации;

·     исполнительных устройств.

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

Вопросы № 30,31,32 Основные процессы жизненного цикла ИС. Вспомогательные

процессы жизненного цикла ИС. Организационные процессы жизненного цикла ИС.

 Понятие жизненного цикла (ЖЦ) является одним из ключевых понятий методологии проектирования информационных систем. Жизненный цикл информационной системы – это непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации.

Согласно стандарту структура жизненного цикла основывается на трех группах процессов:

· основные процессы (заказ, поставка, разработка, эксплуатация, сопровождение);

· вспомогательные процессы (обеспечивают выполнение основных процессов):

o документирование – работы по разработке, выпуску, редактированию, распространению и сопровождению документов, в которых нуждаются все заинтересованные лица;

o управление конфигурацией (конфигурационное управление) включает работы: определение и установление состояния программных объектов в системе; управление изменениями и выпуском объектов; обеспечение полноты, совместимости и правильности объектов; управление хранением, обращением и поставкой объектов;

o обеспечение качества – работы по обеспечению соответствия создаваемой системы и реализуемых процессов жизненного цикла установленным требованиям и утвержденным планам;

o верификация – работы соответствующего субъекта (заказчика, поставщика или независимой стороны) по проверке соответствия создаваемых промежуточных результатов установленным требованиям по мере реализации проекта. Различают верификацию договора, процесса, требований, проекта, системы, сборки системы и документации;

o аттестация – работы соответствующего субъекта по проверке полного соответствия требований и конечного продукта функциональному назначению системы;

o совместный анализ – работы по оценке состояния или результатов какой-либо работы (системы);

o аудит – работы независимых (по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и условиям договора;

o разрешение проблем – работы по анализу и устранению проблем, обнаруженных при реализации проекта;

· организационные:

o управление проектами – работы по планированию и управлению процессами, включая контроль, проверку и оценку выполненных работ с формированием отчетности;

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

o усовершенствование – работы по оценке, контролю и улучшению процессов жизненного цикла;

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

Вопросы № 33-34. Модели жизненного цикла ИС. Этапы проекта каскадной модели.

Модели жизненного цикла ИС. Спиральная и итерационная модели.

Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует.

Известны следующие базовые модели жизненного цикла.

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

В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ (или “водопад”). Его основной характеристикой является разбиение всей разработки на этапы, при этом переход на следующий этап происходит только после полного завершения работ на текущем (рис. 1).

Рис. 1. Каскадная схема разработки ПО.

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

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

Для преодоления этих проблем предложена поэтапная модель с промежуточным контролем (рис. 2).

Рис. 2. Поэтапная схема разработки ПО.

В поэтапной модели с промежуточным контролем разработка ПО ведётся итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоёмкость процесса разработки по сравнению с каскадной моделью. Время жизни каждого из этапов растягивается на весь период разработки.

Затем появилась спиральная модель ЖЦ (рис. 3), в которой на начальных этапах ЖЦ осуществляются анализ и проектирование.

Рис 3. Спиральная модель.

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

Полный жизненный цикл ИС должен поддерживаться комплексом инструментальных средств с учётом необходимости: адаптации типового проекта к различным системно-техническим платформам (техническим средствам, операционным системам и СУБД) и организационно-экономическим особенностям объектов внедрения; интеграции с существующими разработками (включая реинжиниринг приложений и конвертирование БД); обеспечения целостности проекта и контроля за его состоянием (наличие единой технологической среды создания, сопровождения и развития ИС, а также целостность репозитария). При этом желательно обеспечить независимость от программно-аппаратной платформы и СУБД, поддержку одновременной работы групп разработчиков, открытую архитектуру и возможности экспорта/импорта.

Вопросы № 35, 36, 37 Исследование и описание предметной области экономической ИС. Уровни описания предметной области. Модели предметных областей и предъявляемые к ним требования. Принципы структурного подхода к проектированию ИС.

В основе проектирования ИС лежит моделирование предметной области. Для того чтобы получить адекватный предметной области проект ИС в виде системы правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы. При этом под моделью предметной области понимается некоторая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой области. Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования предметной области велика вероятность допущения большого количества ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы. Вследствие этого все современные технологии проектирования ИС основываются на использовании методологии моделирования предметной области. К моделям предметных областей предъявляются следующие требования:

• формализация, обеспечивающая однозначное описание структуры предметной области;

• понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

• реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;

• обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей.

Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования предметной области. Структурный аспект предполагает построение:

• объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;

• функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;

• структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;

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

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

Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:

• время решения задач;

• стоимостные затраты на обработку данных;

• надежность процессов;

• косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.

В основе различных методологий моделирования предметной области ИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях: на внешнем уровне (определении требований), на концептуальном уровне (спецификации требований) и внутреннем уровне (реализации требований). Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств. На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе? информационных процессах.

Вопрос № 38. CASE-средства и CASE-технологии поддержки моделирования ИС

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС), создаваемых в различных областях экономики. Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:

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

                     наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);

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

                     необходимость интеграции существующих и вновь разрабатываемых приложений;

                     функционирование в неоднородной среде на нескольких аппаратных платформах;

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

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

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

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

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

CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.

Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:

                     CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

                     реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

                     широкое разнообразие качества и возможностей CASE-средств;

                     относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

                     широкое разнообразие в практике внедрения различных организаций;

                     отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

                     широкий диапазон предметных областей проектов;

                     различная степень интеграции CASE-средств в различных проектах.

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

Для успешного внедрения CASE-средств организация должна обладать следующими качествами:

                     Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;

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

                     Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

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

Вопрос № 39. Роль и место специалиста экономического профиля на стадиях жизненного цикла создания, развития и эксплуатации информационных систем

Существуют следующие этапы жизненного цикла программного продукта: 1. Разработка технического задания и эскизного проекта Техническое задание - это документ, определяющий требования и исходные данные, необходимые для разработки автоматизированной системы управления; структуру разрабатываемой системы, требования к отдельным ее частям, состав используемых технических средств. Документ регламентирует отношения сторон и охватывает не только работы, которые предполагается реализовать с помощью ЭВМ, но и выполняемые сотрудниками соответствующих служб вручную. Техническое задание должно быть: - точно сформулированным, что исключит неоднозначность его понимания разными исполнителями; - полным, т.е. содержать описание всех аспектов функционирования системы, в том числе и ее реакцию на ошибочные действия пользователя; - ясным: текст документа должен быть понятен и пользователю, и разработчику. После утверждения "Техническое задание" становится документом, которым руководствуются разработчики на всех этапах создания системы. На его основании составляются координационный план работ, сетевой график работ и производится расчет затрат на разработку системы. Эскизный проект (техническое предложение) - это документ, где излагаются основные концепции построения автоматизированной системы или отдельных ее подсистем. Поскольку в техническом задании только обозначаются цели, но не указываются пути их решения, то эскизный проект охватывает всю систему и описывает избранные пути решения задач. Документ представляется в виде проектной документации, описывающей архитектуру системы, структуру ее подсистем, состав модулей, предложения по выбору базовых программно-аппаратных средств, которые должны учитывать прогноз развития предприятия. Утверждая эскизный проект, заказчик дает свое согласие на предложения разработчиков, касающиеся направлений работ и вариантов основных проектных решений. После принятия эскизного проекта разрабатывается прототип автоматизированной системы, представляющий собой набор программ, имитирующих работу готовой системы.  2. Разработка технического и рабочего проектов  Разработка технического проекта предполагает:  - определение объектов информационной системы и их атрибутов; - расчет количества экземпляров каждого объекта; - определение методов вычисления производных показателей на основе значений исходных показателей; - установление связи между объектами и процессами; - разработку структуры базы данных и проверку ее полноты; -  определение порядка сбора, хранения, передачи, обработки и контроля данных;  - выбор необходимых для решения задачи программных средств; - выбор операционной системы и системы управления базами данных; - оценку объемов памяти и трудоемкости разработки программ. Рабочий проект - это техническая документация, разработанная на основе утвержденного заказчиком технического задания и утвержденная в установленном порядке. Документ содержит уточненные данные и детализированные общесистемные проектные решения, программы и инструкции по решению задач, уточненную оценку эффективности, перечень мероприятий по подготовке объекта к внедрению. В состав рабочей документации проекта входят: пояснительная записка, должностные инструкции, инструкции по заполнению входных документов, использованию выходных документов, организации и ведению нормативно-справочной информации и другие документы. 3. Внедрение и эксплуатация системы Внедрение системы представляет собой процесс постепенного перехода от существующей системы управления к новой, предусмотренной документацией рабочего проекта. Стадия внедрения и развития охватывает работы по комплексной отладке создаваемой системы в производственных условиях, диагностике работоспособности всех ее элементов, определению направлений развития и совершенствования системы. Опытная эксплуатация проводится в целях комплексной проверки функционирования задач системы, подготовленности обеспечивающей части системы к функционированию, окончательной отладки технологического процесса сбора и обработки информации. При положительных результатах опытной эксплуатации система сдается в промышленную эксплуатацию, в ходе которой проводится анализ функционирования системы, проверяется эффективность реализованных проектных решений, вырабатываются рекомендации по дальнейшему ее развитию. На этапе эксплуатации система заполняется реальными данными, производится слежение за изменениями ее параметров, а также параметров предметной области. В процессе функционирования системы осуществляется ее сопровождение - сопровождение программного обеспечения, базы данных, вычислительной системы.

Вопрос № 41. Системы комплексной автоматизации предприятий.

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

Комплексная система управлением предприятием представляет собой информационную систему, в которой оперативно накапливаются и обрабатываются данные о текущей финансово-хозяйственной деятельности предприятия. Эти системы часто так и называются – корпоративная информационная система (КИС).

Необходимо отметить, что в понятия «информационная система управления предприятием» (ИСУП) и «комплексная информационная система управления» современная наука об информационных технологиях вкладывает разный смысл. Несмотря на кажущуюся тождественность этих понятий, необходимо их отличать. Основные отличия КИС от ИСУП заключаются в следующем : 1.     КИС, в отличие от ИСУП, нельзя выбирать, ее можно только проектировать или строить. 2.     КИС всегда уникальна, поскольку отражает стиль управления и предпочтения высшего руководства предприятия, в то время как ИСУП вполне может быть тиражируемым решением. 3.     ИСУП — фундамент КИС, поэтому КИС невозможна без ИСУП. 4.     ИСУП отвечает за оперативный учет, КИС — за полный спектр управленческих действий (от учетных операций до стратегического планирования). 5.     ИСУП имеет ярко выраженную отраслевую направленность, в то время как КИС носит более абстрактный характер. 6.     КИС более редки, чем ИСУП, поскольку их построить существенно труднее. По большому счету, любая фирма, организация или государственное учреждение, имея сегодня в своем активе сеть с одним сервером и десятком компьютеров, по всем правилам развития, может или даже должна существенно расшириться завтра. Наиболее существенной чертой комплексной информационной системы должно стать расширение контура автоматизации для получения замкнутой, саморегулирующейся системы, способной гибко и оперативно перестраивать принципы своего функционирования. Хотя последнее осуществить совсем непросто. Очевидно, что в состав КИС должны войти средства для документационного обеспечения управления, информационной поддержки предметных областей, коммуникационное программное обеспечение, средства организации коллективной работы сотрудников и другие вспомогательные (технологические) продукты. Из этого, в частности, следует, что обязательным требованием к КИС является интеграция большого числа программных продуктов (зачастую — разных разработчиков). Наиболее органичным и эффективным способом построения КИС, при котором были бы выполнены все вышеперечисленные функции и требования к технологичности, является использование в качестве ядра всего информационного комплекса системы автоматизации именно управленческих процессов.

Вопрос № 42. Понятие ERP-системы: принципы организации и основные модули.

В начале 1990-х гг. аналитическая компания Gartner Group в системы финансового планирования ввела новое понятие «системы планирования ресурсов предприятий» (Enterprise Resource Planning - ERP).

В основе ERP-систем лежит принцип создания единого хранилища данных, содержащего всю корпоративную бизнес-информацию: плановую и финансовую информацию, производственные данные, данные по персоналу и др. Наличие единого корпоративного хранилища устраняет необходимость в передаче данных от одной системы к другой , а также обеспечивает одновременную доступность информации для любого числа сотрудников предприятия, обладающих соответствующими полномочиями. Целью ERP-систем является не только улучшение управления производственной деятельностью предприятия, но и уменьшение затрат и усилий на поддержку его внутренних информационных потоков.

Существует немало определений ERP-систем. Одно из них, наиболее часто встречающихся, следующее:

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

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

Рисунок 4.1.

Состав ERP-системы

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

• управления логистическими цепочками (Distribution Resource Planning - DRP);

• усовершенствованного планирования и составления производственных графиков (Advanced Planning and Scheduling - APS);

• управления взаимоотношениями с клиентами (Customer Relation Management – CRM, - ранее назывался модулем автоматизации продаж - Sales Force Automation - SFA);

• электронной коммерции (Electronic Commerce - ЕС);

• управления данными об изделии (Product Data Management - PDM);

• надстройки Business Intelligence, включающий решения на основе технологий OLAP (On-Line Analytical Processing) и DSS (Decision Support Systems);

• автономный модуль, отвечающий за конфигурирование системы (Standalone Configuration Engine - SCE);

• окончательного (детализированного) планирования ресурсов FRP (Finite Resource Planning).

На рис. 4.4 для примера приведен состав ERP-системы BAAN IV, а на рис. 4.5 - показан пример взаимосвязи функциональных блоков ERP-системы.   

Рисунок 4.4 - Структура ERP-системы BAAN IV   

Рисунок 4.5 - Пример взаимосвязи функциональных блоков ERP-системы