close

Вход

Забыли?

вход по аккаунту

?

Osipov 06CCD291B6

код для вставкиСкачать
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное
образовательное учреждение высшего образования
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ
Л. А. Осипов, С. А. Яковлев
ВВЕДЕНИЕ В СИСТЕМНУЮ
ИНЖЕНЕРИЮ
Учебное пособие
Допущено Учебно-методическим объединением вузов
Российской Федерации по университетскому политехническому
образованию в качестве учебного пособия для студентов высших
учебных заведений, обучающихся по направлению подготовки
магистров 09.04.02 «Информационные системы и технологии»
Санкт-Петербург
2016
УДК 004.8
ББК 32.973.26-018.5
О-73
Рецензенты:
доктор технических наук, профессор О. С. Ипатов;
доктор технических наук, профессор П. И. Падерно
Утверждено
редакционно-издательским советом университета
в качестве учебного пособия
Осипов, Л. А.
О-73 Введение в системную инженерию: учеб. пособие /
Л. А. Осипов, С. А. Яковлев. – СПб.: ГУАП, 2016. – 130 с.
ISBN 978-5-8088-1096-9
Даны основные понятия и определения предметной области «системная инженерия», подробно рассмотрены практически все аспекты деятельности системного инженера на протяжении полного жизненного цикла сложной системы. Существенное внимание уделено
особенностям программной и системной инженерии. В соответствии
с международными стандартами детально рассмотрены процессы соглашения, предприятия, проекта и технические процессы жизненного цикла системы. Рассмотрены особенности применения концепций
системной инженерии для реализации современных корпоративных
информационных систем.
Пособие предназначено для студентов вузов, обучающихся по направлению подготовки магистров «Информационные системы и технологии», а также будет полезно специалистам, занимающимся проблемами создания сложных технических, социотехнических и организационных систем.
УДК 004.45
ББК 32.973.26-018.5
ISBN 978-5-8088-1096-9 ©
©
Осипов Л. А., Яковлев С. А., 2016
Санкт-Петербургский государственный
университет аэрокосмического
приборостроения, 2016
ПРЕДИСЛОВИЕ
Современный этап развития человечества отличается тем, что
на смену века энергетики приходит век информатики. Происходит
интенсивное внедрение новых информационных технологий во все
сферы человеческой деятельности. Встает реальная проблема перехода в информационное общество, для которого приоритетным
должно стать развитие инженерного образования. Применение
принципов системной инженерии к созданию крупных, сложных
программных систем, включая корпоративные информационные
системы, дает мощный инструментарий управления процессами
разработки.
Поэтому дисциплина «Системная инженерия» стала одной из
основных в структуре подготовки магистров по направлению высшего образования 09.04.02 – «Информационные системы и технологии».
Содержание учебного пособия «Введение в системную инженерию» соответствует профессиональным компетенциям дисциплины «Системная инженерия» базовой части программы магистратуры ФГОС ВО (приказ Минобрнауки РФ от 30.10.2014 № 1402
«Об утверждении федерального государственного образовательного стандарта высшего образования по направлению подготовки
09.04.02 Информационные системы и технологии (уровень магистратуры)»).
Авторы благодарны заведующему кафедрой «Программно-аппаратные комплексы реального времени» Санкт-Петербургского
государственного политехнического университета Петра Великого
доктору технических наук, профессору О.С. Ипатову и профессору
кафедры «Автоматизированные системы обработки информации и
управления» Санкт-Петербургского государственного электротехнического университета «ЛЭТИ», доктору технических наук П.И.
Падерно за ценные замечания, сделанные при рецензировании рукописи учебного пособия.
Авторы
3
ВВЕДЕНИЕ
Управление предприятием, а тем более корпорацией, или говоря
современным языком, управление бизнесом, с тех пор, как появились первые предприятия, претерпело существенные изменения.
Но основа этого процесса осталась та же. Руководитель принимает
решения на основании той информации, которая ему доступна на
момент принятия решения, а подчиненные принимаются с той или
иной степенью прилежания исполнять это решение, как только им
станет оно известно.
Применение принципов системной инженерии (СИ): (англ.:
System Engineering – SE) к созданию крупных, сложных программных систем, включая корпоративные информационные системы
(КИС), дает мощный инструментарий управления процессами разработки [1, 4, 12, 14].
Современные КИС становятся все больше и сложнее. Но есть и
другие причины. Программное обеспечение (ПО) становится ключевым компонентом во многих, если не в большинстве технических систем. Зачастую оно обеспечивает тот уровень интеграции и
управления данными, который позволяет такой сложной системе,
как КИС, решать стоящие перед ней задачи.
Подавляющее большинство крупных программных систем при
реализации КИС часто не укладывается в запланированные сроки, выходит за рамки сметы, и при этом не вполне оправдывает
ожидания заказчика. Этот феномен хорошо известен как «кризис
программного обеспечения». Чтобы разрешить этот кризис, разработчики ПО используют при создании продуктов различные инженерные методики.
Причем простой контроль управленческого и технического состояния проекта – использование ресурсов, выполнение этапов, соответствие требованиям, прохождение тестов – не дает адекватного
представления о его «здоровье». На самом деле, необходимо управлять процессами и продуктами, создаваемыми в рамках проектов.
Системная инженерия предоставляет инструментарий, требуемый
для решения задачи технического управления.
Применение принципов СИ к разработке КИС, как программной системы, выявляет операции, задачи и процедуры, называемые системной инженерией программного обеспечения (СИПО)
(англ.: Software System Engineering – SwSE). Многие считают
СИПО специфичным случаем СИ, а другие относят ее к программной инженерии (ПИ). Однако можно утверждать, что СИПО – совсем иной мощный инструментарий, используемый для
4
управления технической разработкой крупных программных
проектов [2, 3, 13].
Системы и системная инженерия
Системная инженерия – это практическое применение научных,
инженерных и управленческих навыков, необходимых для преобразования операционных требований в описание конфигурации системы, которая наилучшим образом удовлетворяет этим требованиям.
Это – общий процесс решения проблем, который применяется ко всему техническому управлению в проекте, посвященному разработке
системы, предоставляя механизм формулирования и совершенствования определений изделий и процессов системы.
Национальный стандарт РФ ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем» описывает процесс СИ и ее применение на
протяжении всего жизненного цикла (ЖЦ) изделия. Системная
инженерия порождает документы, а не оборудование. Документы
связывают процессы разработки с ЖЦ проекта. Они определяют
предполагаемые окружения процессов, интерфейсы и инструменты управления рисками в рамках всего проекта.
Системная инженерия включает в себя пять функций.
1. Определение проблемы – указание потребностей и ограничений путем анализа требований и взаимодействия с заказчиком.
2. Анализ решений – выделение набора возможных способов
удовлетворения потребностей и ограничений, их анализ и выбор
оптимального.
3. Планирование процессов – определение: задач, которые должны быть выполнены; объема ресурсов и затрат, необходимых для
создания изделия; очередности задач и потенциальных рисков.
4. Контроль процессов – определение методов мониторинга проекта и процессов; измерение прогресса; оценка промежуточных изделий
и принятие по мере необходимости корректирующих действий.
5. Оценка изделий – определение качества и количества создаваемых изделий путем оценочного планирования, тестирования,
демонстрации, анализа, верификации и контроля.
Системная инженерия формирует основу всего хода проекта
разработки КИС, а также механизм определения пространства решений в терминах систем и интерфейсов с внешними системами.
Пространство решений описывает изделие на самом высоком уровне, прежде чем требования к нему будут разделены на аппаратную
и программную составляющие.
5
Этот подход аналогичен присущей ПИ практике – накладывать
ограничения как можно позже в процессе разработки. Чем позже на
проект будут наложены ограничения, тем более гибким будет реализованное решение.
Системная инженерия
Термин «системная инженерия программного обеспечения» появился в начале 80-х годов прошлого века. Системная инженерия
программного обеспечения отвечает за общее техническое управление системой и подтверждение корректности окончательных
системных продуктов. Как и СИ, СИПО порождает документы,
а не компоненты. В этом она отличается от ПИ (англ.: Software
Engineering – SwE), порождающей компьютерные программы и
руководства пользователей [2, 9, 20].
Системная инженерия программного обеспечения начинается, когда системные требования разделены на аппаратные и программные подсистемы, и формируется основа для всей разработки ПО в проекте и, как и ПИ, представляет собой одновременно и
технический и управленческий процессы. Технический процесс
СИПО – аналитическая работа, необходимая для преобразования
операционных требований в:
– описание программной системы;
– дизайн ПО заданного размера, конфигурации и качества;
– документацию программной системы в виде требований и
спецификаций для проектирования;
– процедуры, необходимые для верификации, тестирования и
принятия окончательного программного продукта;
– документацию, необходимую для его использования и сопровождения.
Следует отметить, что СИПО не является описанием работ.
Это – процесс, который выполняют многие люди и организации:
системные инженеры, менеджеры, программные инженеры, программисты и, не стоит забывать, пользователи.
По мере того как эффективность КИС все больше зависит от совершенства программ, применение методов СИ к разработке ПО
в состоянии помочь избежать существенных проблем.
Впрочем, разработчики ПО часто игнорируют эти методы. Они
считают, что исключительно программные системы или системы, работающие на массовых компьютерах, – всего лишь программные, а не
системные проекты. Игнорирование системных аспектов разработки
ПО и ведет к снижению эффективности его эксплуатации в КИС.
6
Система инженерного программного обеспечения
и программная инженерия
Система инженерного программного обеспечения и программная
инженерия – это технические и управленческие процессы, однако
ПИ порождает только программные компоненты и описывающую
их документацию. Более строго, ПИ включает в себя следующее.
– Практическое применение компьютерных дисциплин, менеджмента и других наук к анализу, проектированию, конструированию и обслуживанию ПО и связанной с ними документации.
– Науку инженерии, применяющую методы анализа, проектирования, кодирования, тестирования, документирования и управления с целью создания крупных, удовлетворяющих специфическим требованиям программ в определенное время и с определенными затратами.
– Систематическое применение методов, инструментов и методик,
которые позволяют выполнить оговоренные требования и добиться
цели, создав эффективную и полезную программную систему.
Связи между системной инженерией SE, системной инженерией
программного обеспечения SwSE и программной инженерией SwE
показаны на рис.В.1.
Традиционная СИ выполняет первоначальный анализ и проектирование, а также интеграцию и тестирование окончательной системы.
Системный
анализ
Тестирование
программной системы
Системная
инженерия
SE
Тестирование
интеграции ПО
Системная
инженерия ПО
SwSE
Тестирование
системы
Системный
дизайн
Анализ
требований к ПО
Архитектурный
дизайн ПО
Программная
инженерия
SwE
Детальный
дизайн ПО
Тестирование
интеграции системы
Тестирование
программной
системы
Программная
инженерия
SwE
Тестирование
кода и модулей
Рис. В.1. Инженерные связи между системной инженерией, системной
инженерией программного обеспечения и программной инженерией
7
Во время первой стадии разработки СИПО отвечает за анализ
требований к ПО и архитектурный дизайн. При этом СИПО также
управляет окончательным тестированием программных систем.
Наконец, ПИ управляет тем, что системные инженеры называют
инженерией компонентов (подсистем).
Система инженерного программного обеспечения
и управление проектом
Процесс управления проектом включает в себя оценку рисков
и затрат на создание программной системы, определение графика
выполнения, объединение различных специалистов и инженерных
групп, конфигурационное управление и постоянный аудит, позволяющий гарантировать, что проект укладывается в сроки и смету и
соответствует техническим требованиям.
Управленческие связи между проектным менеджментом, СИПО
и ПИ показаны на рис. В.2.
Руководство проектом включает в себя общее управление распределением работ в проекте и полномочия в предоставлении ресурсов.
При этом СИПО определяет технический подход, принимает технические решения, взаимодействует с техническими представителями
заказчика, а также одобряет и принимает конечный программный
продукт, а ПИ отвечает за разработку программного дизайна, кодирование и разработку программных компонентов.
Пять основных функций СИ, коррелирующих с СИПО, и краткое описание функций СИПО представлены в табл. В.1.
Проектный менеджмент:
– Планирование
– Организация
– Подбор персонала
– Руководство
– Контроль
Системная инженерия ПО:
– Анализ требований
– Дизайн ПО
– Планирование процессов
– Контроль процессов
– Верификация, подтверждение и тестирование
Программная инженерия:
– Дизайн ПО
– Кодирование
– Тестирование модулей
– Интеграция программных
подсистем
Рис. В.2. Управленческие связи между системной инженерией
программного обеспечения, программной инженерией и проектным
менеджментом
8
Таблица В.1
Функции СИ, коррелирующие с СИПО
Системная
инженерия
Функции СИПО
Описание функций СИПО
Определение
проблемы
Анализ требований
Определение потребностей и
ограничений путем анализа
требований к ПО
Анализ
решений
Дизайн ПО
Определение путей, позволяющих удовлетворить решения и
ограничения, анализ и оптимизация возможных решений
Планирование
процессов
Планирование процессов
Определение связанных с разработкой задач, очередности и
потенциальных рисков проекта
Контроль
процессов
Контроль процессов
Определение методов контроля
проекта и процесса, измерение
процесса и выполнение корректирующих действий
Оценка
продукта
Верификация,
подтверждение и
тестирование
Оценка конечного продукта и
подготовка документации
Анализ требований
Первый шаг в любой активности, связанной с разработкой ПО такой сложной системы, как КИС, – это определение и документирование требований системного уровня в виде спецификации системных
требований, а также в виде спецификации программных требований.
Программные требования включают в себя свойства, которые необходимы пользователю для решения тех или иных задач, а также свойства, которые нужны КИС в целом или подсистеме для выполнения тех
или иных формально представленных документов [5, 11, 12, 14].
Программные требования можно классифицировать следующим образом.
Функциональные требования указывают функции, которые система или подсистема (компонента) должны выполнять.
Требования к производительности указывают характеристики
производительности, которым должны удовлетворять система или
ее подсистемы, такие как скорость, точность или частота.
Требования к внешним интерфейсам указывают элементы аппаратного, программного обеспечения или баз данных, с которыми
система или подсистема должны взаимодействовать, либо устанав9
ливают ограничения на форматы, время или другие факторы, порождаемые такими интерфейсами.
Ограничения дизайна влияют или накладывают ограничения на
архитектуру программной системы или подсистемы (например, требования к языку, физические характеристики аппаратного обеспечения, стандарты разработки ПО и стандарты гарантии качества).
Параметры качества указывают степень приближения ПО к параметрам, которые влияют на качество (например, корректность,
надежность, сопровождаемость и переносимость).
Анализ программных требований начинается после того, как
СИ определила системные требования заказчика. В его функции
входят указание всех (или максимального числа) требований к программной системе и завершение анализа означает формирование
утвержденных базовых требований.
Дизайн программного обеспечения
Дизайн (проектирование) ПО – это процесс выбора и документирования наиболее эффективных элементов, которые в совокупности будут реализовать требования к программной системе. Дизайн
определяет специфический, логический подход к удовлетворению
программных требований.
Дизайн ПО традиционно разделяется на две части: дизайн архитектуры и детальный дизайн.
Дизайн архитектуры – эквивалент системного проектирования,
во время которого разработчик выбирает структуру системного уровня и определяет программные требования к компонентам структуры. Дизайн архитектуры, который иногда называют дизайном верхнего уровня или предварительным дизайном, обычно указывает и
структурирует компоненты программы, определяет интерфейсы и
готовит временные и объемные оценки. Он включает в себя такую
информацию, как общая архитектура обработки, назначение функций (но не их детальное описание), потоки данных, системные утилиты, интерфейсы ОС и параметры системы хранения.
Детальный дизайн – эквивалент инженерии компонентов.
В данном случае компоненты представляют собой независимые
программные модули и искусственные объекты.
Обычно архитектурный дизайн относят к СИПО, а детальный
дизайн – к ПИ.
Планирование процессов
Планирование специфицирует цели и назначение проекта, а
также стратегии, политику, планы и процедуры, позволяющие их
10
добиться. Оно заранее определяет, что делать, как делать, когда делать и кто это будет делать.
Существует ошибочное предположение, что проектный менеджмент выполняет все действия по планированию проекта. На самом
же деле, планирование проекта состоит из двух составляющих – одна относится к проектному менеджменту, а другая – к СИПО, причем основная часть выполняется именно в рамках СИПО.
Контроль процессов
Контроль – совокупность операций управления, используемых
для того, чтобы гарантировать развитие проекта в соответствии
с утвержденным планом. Контроль процессов предусматривает
определение производительности и результатов в соответствии
с планами, выявление отклонений и выполнение корректирующих
действий, призванных гарантировать соответствие фактических
результатов планам.
Контроль процессов – это система обратной связи, необходимая
для того, чтобы определить, как движется проект. Контроль процессов предполагает ответы на следующие вопросы. Есть ли потенциальные проблемы, способные привести к задержке с выполнением
конкретного требования в указанные сроки и в рамках имеющегося
бюджета? Есть ли риск, что такие проблемы станут реальными? Выполним ли подход к проектированию?
Контроль должен порождать корректирующие действия – либо приводить состояние проекта в соответствие с планом, либо изменять план, либо прекращать проект. Контроль проекта также
состоит из двух отдельных компонентов: контроль, который предусмотрен проектным менеджментом, и контроль, который выполняется в рамках инженерии программных систем.
Верификация, подтверждение и тестирование
Процесс верификации, подтверждения и тестирования (англ.:
Verification, Validation and Testing – VV&T) определяет, корректен
ли процесс инженерии и соответствуют ли продукты предъявляемым требованиям.
Верификация определяет, соответствуют ли продукты на данном этапе цикла разработки ПО требованиям, утвержденным во
время предыдущего этапа, и дает ответ на вопрос: «Так ли я создаю
продукт?»
Подтверждение определяет соответствие окончательной программы или всего ПО требованиям и нуждам пользователя, т.е. дает ответ на вопрос: «Тот ли я создаю продукт?»
11
Тестирование – это выполнение программы или части программы с известными входными и выходными данными, которые известны заранее и которые можно проверить, что позволяет обнаружить ошибки. Тестирование часто считается частью верификации.
Процесс верификации, подтверждения и тестирования – это непрерывный процесс мониторинга операций СИ, СИПО, ПИ и проектного менеджмента с целью убедиться, что они следуют техническим и управленческим планам, спецификациям, стандартам и
процедурам. Кроме того, процесс верификации, подтверждения и
тестирования оценивает промежуточные и окончательные продукты проекта ПИ. Промежуточные продукты включают в себя спецификации требований, описание архитектуры, планы тестирования
и оценку результатов. К окончательным продуктам относятся ПО,
руководства пользователей, учебные материалы и т.д.
При этом СИПО использует методы и инструментарий верификации, подтверждения и тестирования для оценки требований
спецификаций, описания архитектуры и других промежуточных
продуктов. Тестирование выполняется для того, чтобы определить
соответствует ли окончательный продукт спецификациям требований данного проекта.
Финальный шаг в любой деятельности, связанной с разработкой ПО, – это подтверждение и тестирование окончательного программного продукта на соответствие спецификации программных
требований, а также подтверждение и тестирование окончательного системного продукта на соответствие этой спецификации.
Дисциплины (СИ и СИПО), используемые в первую очередь для
технического планирования «на входе» ЖЦ системы и для проверки того, что к окончанию проекта все планы были выполнены.
К сожалению, в реальных проектах эти дисциплины часто игнорируются. Игнорирование системных аспектов программного проекта КИС может привести к созданию ПО, которое не будет работать
на выбранной аппаратной платформе или не будет интегрироваться
с другими программными системами.
После того как расставлены акценты относительно проблемных
областей «СИ», «СИПО» и «ПИ» перейдем непосредственно к проблематике СИ, особое внимание уделяя практике разработки и внедрения КИС.
12
1. СИСТЕМНЫЕ КОНЦЕПЦИИ
В данном разделе учебного пособия даются стандартные определения предметной области «Системная инженерия». Рассматриваются концепции жизненного цикла (ЖЦ) системы, а также модели
и стадии ЖЦ.
1.1. Основные термины и определения
В настоящем пособии в соответствии с ГОСТ Р ИСО/МЭК 152882005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем» используются следующие термины с соответствующими определениями [9, 20].
Система (system) – комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей. Система может рассматриваться как продукт
или как совокупность услуг, которые она обеспечивает. На практике интерпретация данного термина зачастую уточняется с помощью ассоциативного существительного, например, система самолета. В некоторых случаях слово «система» может заменяться
контекстным синонимом, например, самолет, хотя это может впоследствии затруднять восприятие системных принципов.
Элемент системы (system element) – представитель совокупности элементов, образующих систему. Элемент системы является
отдельной частью системы, которая может быть создана для выполнения заданных требований.
Жизненный цикл системы (system life cycle) – развитие рассматриваемой системы во времени, начиная от замысла и заканчивая
списанием.
Модель жизненного цикла (life cycle model) – структурная основа процессов и действий, относящихся к жизненному циклу,
которая также служит в качестве общей ссылки для установления
связей и взаимопонимания сторон.
Рассматриваемая система (system-of-interest) – система,
жизненный цикл которой рассматривается в рамках стандарта.
Обеспечивающая система (enabling system) – система, которая
служит дополнением к рассматриваемой системе на протяжении
стадий ее жизненного цикла, но необязательно вносит непосредственный вклад в ее функционирование. Например, когда рассматриваемая система вступает в стадию производства, требуется обеспечивающая производственная система. Каждая обеспечивающая
система имеет свой собственный жизненный цикл. Стадия (stage) – период в пределах жизненного цикла системы,
относящийся к состоянию системного описания или непосредственно
13
к самой системе. Стадии относятся к периодам значительного продвижения системы и достижения запланированных сроков на протяжении жизненного цикла (стадии могут перекрывать друг друга).
Деятельность (activity) – совокупность действий, в результате
которых расходуются время и ресурсы и выполнение которых необходимо для достижения или содействия достижению одного или
нескольких результатов.
Процесс (process) – совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы.
Проект (project): попытка действий с определенными начальной и конечной датами, предпринимаемая для создания продукта
или услуги в соответствии с заданными ресурсами и требованиями.
Проект может рассматриваться как уникальный процесс, включающий в себя координируемые и контролируемые действия, и может быть комбинацией действий из процессов проекта и технических процессов.
Организация (organization) – группа работников и необходимых средств с распределением ответственности, полномочий и взаимоотношений.
Предприятие (enterprise) – часть организации, отвечающая за
приобретение и поставку продукции и (или) услуг в соответствии
с соглашениями. Организация может входить в состав нескольких
предприятий, а предприятие может включать в себя одну или несколько организаций.
Оператор (operator) – лицо или организация, которые вносят
вклад в реализацию функциональных возможностей системы и
применяют знания, умение и процедуры при выполнении определенной функции. Роль оператора и роль пользователя могут выполняться одновременно или последовательно одним и тем же человеком или организацией. Некоторые операторы в сочетании с их
знаниями, умением и выполняемыми процедурами могут рассматриваться как элемент системы.
Ресурс (resource) – активы (организации), которые используются или потребляются в ходе выполнения процесса. Ресурсы могут
включать в себя такие разнообразные объекты, как персонал, оборудование, основные средства, инструменты, а также коммунальные услуги: энергию, воду, топливо и инфраструктуру средств связи. Ресурсы могут быть многократно используемыми, возобновляемыми или расходуемыми.
Приобретающая сторона (acquirer) – правообладатель, который приобретает или получает продукт или услугу от поставщика.
14
Другими широко используемыми терминами, обозначающими это
понятие, являются покупатель, заказчик, плательщик. Приобретающая сторона может быть одновременно владельцем, пользователем или эксплуатирующей организацией.
Соглашение (agreement) – взаимное признание сроков и условий,
в соответствии с которыми осуществляются рабочие отношения.
Базовая линия (baseline) – спецификация или продукт, которые
были официально рассмотрены и согласованы, чтобы впоследствии
служить основой для дальнейшего развития, и которые могут быть
изменены только посредством официальных и контролируемых
процедур изменения.
Основные средства (facility) – физические средства или оборудование, способствующие выполнению действий (например, здания, инструменты, принадлежности).
Правообладатель (stakeholder) – сторона, имеющая право, долю или претензии на систему или на владение ее характеристиками, удовлетворяющими потребности и ожидания этой стороны.
Поставщик (supplier) – организация или лицо, которые вступают в соглашение с приобретающей стороной на поставку продукта
или услуги.
Компромисс (trade-off) – действия по принятию решений,
в ходе которых производится выбор из различных требований и
альтернативных решений на основе конечной выгоды правообладателей.
Пользователь (user) – лицо или группа лиц, извлекающих
пользу в процессе применения системы. Роль пользователя и роль
оператора может выполняться одновременно или последовательно
одним и тем же лицом или организацией.
Онтология (ontology) – в информационных технологиях и компьютерных науках под онтологией подразумевается эксплицитная, т.е. явная, спецификация концептуализации, где в качестве
концептуализации выступает описание множества объектов и связей между ними. Формально онтология состоит из понятий терминов, организованных в структуры классификаций, их описаний и
правил вывода. Выделяют следующие типы онтологий:
– мета-онтологии – описывают наиболее общие понятия, которые не зависят от предметных областей;
– онтология предметной области – формальное описание предметной области, обычно применяется для того, чтобы уточнить понятия, определённые в мета-онтологии (если используется), и/или
определить общую терминологическую базу предметной области;
15
– онтология конкретной задачи – онтология, определяющая общую терминологическую базу задачи, проблемы;
– сетевые онтологии часто используют для описания конечных
результатов действий, выполняемых объектами предметной области или задачи.
Валидация (validation) – подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены. Валидация в контексте жизненного цикла системы является
совокупностью действий, гарантирующих и обеспечивающих уверенность в том, что система способна выполнять заданные функции
в соответствии с установленными целями и назначением в конкретных условиях функционирования.
Верификация (verification) – подтверждение на основе представления объективных свидетельств того, что установленные требования были выполнены. Верификация в контексте жизненного
цикла системы является совокупностью действий по сравнению
полученного результата жизненного цикла системы с требуемыми
характеристиками для этого результата.
1.2. Системная инженерия и современные системы
Системы
Системы, рассматриваемые в настоящем учебном пособии, являются искусственными, они созданы и используются с целью
предоставления функциональных возможностей в заданных условиях для удовлетворения потребностей пользователей и иных
заинтересованных лиц. Эти системы могут состоять из одного или
нескольких компонентов: технические средства, программные
средства, человеческие ресурсы, процессы (например, процесс
оценки), процедуры (например, инструкции оператора), оборудование и природные ресурсы (например, вода, объекты живой природы, минералы). Фактически системы являются результатами
реализации замысла в виде получаемой продукции или услуг [1,
14, 19].
Восприятие и определение конкретной системы, ее архитектуры и системных элементов зависит от интересов и обязанностей
наблюдателя. Система, которая представляет интерес для одного
лица, может рассматриваться другим лицом как элемент рассматриваемой им системы. И наоборот, она может рассматриваться
как часть внешней среды системы, представляющей интерес для
третьего лица.
16
Для примера на рис.1.1 представлено восприятие систем самолета и его эксплуатационной среды. На рисунке проиллюстрированы следующие аспекты:
– важность определенных границ, которые влияют на формирование значимых потребностей и практических решений;
– иерархическое восприятие физической структуры системы;
– объект любого уровня иерархической структуры может рассматриваться как система;
– система включает полностью интегрированное, определенное
множество подчиненных систем;
– характерные свойства на границе системы возникают в результате взаимодействия между системными элементами;
– люди могут рассматриваться как внешние пользователи по отношению к системе (например, экипаж самолета и навигационная
система) и как элементы в рамках системы (например, экипаж самолета и сам самолет);
Система
наземного
транспорта
Система воздушного
транспорта
Система
покупки
билетов
Система
управления
воздушным
движением
Система
распределения
топлива
Система
аэропорта
Система самолета
Система
корпуса
Взлетнопосадочная
система
Система
управления
полетом
Система
жизнеобеспечения
Экипаж
самолета
Дисплейная
Система
система
навигации
Приемная система глобального
местоположения
Система
морского
транспорта
Рис. 1.1. Стандартное представление системы самолета
в среде его использования
17
– система может рассматриваться как отдельный, изолированный от внешней среды объект, т. е. продукт, или как упорядоченный набор функций, способных взаимодействовать с окружающей
средой, т. е. набор услуг.
Какими бы ни были границы системы, концепции и модели
в стандарте ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем» являются универсальными и позволяют практикующим специалистам связывать или адаптировать отдельные примеры жизненных циклов со своими системными принципами.
В этом стандарте люди рассматриваются как пользователи и как
элементы системы. В первом случае пользователь является получателем результатов функционирования системы. Во втором случае человек является оператором, выполняющим заданные системные функции. Таким образом, человек одновременно или попеременно может
выступать как в качестве пользователя, так и элемента системы.
Люди осуществляют вклад в эксплуатационные характеристики
множества систем по многочисленным причинам, например, в силу
своих специфических навыков, потребности в гибком поведении или
по официальным причинам. Независимо от того, являются ли люди
пользователями или операторами, они представляют собой весьма
сложные объекты системы, поведение которых зачастую трудно предсказать, и они сами нуждаются в защите от нанесения им вреда. Следовательно, процессы жизненного цикла системы должны учитывать
человеческий фактор в качестве системного элемента при проектировании, обеспечении безопасности, оценке угроз здоровью, подборе и
обучении кадров. Эти вопросы решаются посредством специфических
действий и итераций в течение ЖЦ систем.
Структура системы
Процессы ЖЦ системы представлены в их отношении с системой
(рис.1.2), состоящей из множества взаимодействующих системных
элементов, каждый из которых может быть создан для полного выСистема
Системный
элемент
Системный
элемент
Системный
элемент
Система
полностью состоит
из набора
взаимодействующих
системных
элементов
Рис. 1.2. Взаимосвязь между системой и системными элементами
18
Рассматриваемая
система
Система
Система
Системный
элемент
Системный
элемент
Системный
элемент
Система
Системный
элемент
Система
Система
Системный
элемент
Системный Системный
элемент
элемент
Системный
элемент
Системный
элемент
Системный
элемент
Система
Системный
элемент
Система
Системный
элемент
Системный
элемент
Системный
элемент
Рис. 1.3. Структура рассматриваемой системы
полнения заданных требований. Ответственность за реализацию
любого системного элемента может быть передана другой стороне
посредством заключения соглашения.
Взаимосвязь между системой и множеством ее системных элементов может быть определена за один шаг, если речь идет о простейшей системе. Для более сложных систем может потребоваться, чтобы сам предполагаемый системный элемент рассматривался
в качестве системы (которая, в свою очередь, состоит из системных
элементов), и так до тех пор, пока с уверенностью можно будет
определить полный набор системных элементов (рис.1.3). Таким
образом, процессы ЖЦ системы применяются рекурсивно по отношению к рассматриваемой системе для правильного определения
ее структуры, в составе которой доступные и управляемые системные элементы могут быть созданы, использованы повторно или
приобретены у другой организации.
Иерархия систем и проектов
Каждая из систем в иерархии (рис.1.4) может соответствовать
отдельному проекту. Таким образом, может существовать (и обычно существует) сильная взаимосвязь между уровнями детализации
в структуре архитектуры и уровнями ответственности в иерархии
проектов. Каждый проект ответствен за приобретение и использование системных компонентов более низкого уровня и создание и
поставку компонентов на более высокий уровень.
19
Иерархический вид
структуры ситемы
Иерархический вид
структуры ситемы
Иерархия
проектов
Система
Рассматриваемая
система
Проект
Состоит из
Одна из многих
Система
Система
Система
Отвечает
за
Обеспечение
Один
из многих
Система
Один
из многих
Отвечает
Закупка
за
Системный
Подчиненный
элемент
проект
Рис. 1.4. Иерархия систем и проектов
Любой отдельно взятый проект обычно рассматривает создаваемую систему как систему, представляющую интерес, и пока со
стороны самого проекта может быть осуществлено воздействие на
более высокие системные уровни, он не несет за них ответственности. Однако проект отвечает за элементы, входящие в состав самой
рассматриваемой системы, и, следовательно, за результаты проектов всех подчиненных уровней (рис.1.4).
На практике риски, связанные с реализацией систем, которые полностью удовлетворяют заданным требованиям, обычно уменьшаются
с переходом на более низкий уровень детализации структуры рассматриваемой системы и, в конечном счете, могут не иметь значения для
отдельного проекта. При различных способах декомпозиции рассматриваемой системы уровни могут не совпадать и системный элемент
может быть приобретен с приемлемым уровнем риска и при этом необязательно рассматривать подробности его структуры.
С точки зрения рассматриваемого объекта системы системные
элементы могут появляться там, где требуется дисциплина работы
специалистов или присутствуют специфические методы технологии их изготовления.
Обеспечивающие системы
На протяжении ЖЦ рассматриваемой системы требуются специальные услуги от систем, которые не являются непосредствен20
ной частью среды функционирования, например, систем массового
производства, систем обучения, систем обслуживания технических и сопровождения программных средств. Каждая из таких систем обеспечивает часть (например, стадию) ЖЦ рассматриваемой
системы. Названные обеспечивающими системами, они облегчают
развитие рассматриваемой системы на протяжении ее ЖЦ.
Отношения между услугами, поставляемыми в среду функционирования рассматриваемой системой, и услугами, поставляемыми
обеспечивающими системами рассматриваемой системе, показаны
на рис.1.5. Обеспечивающие системы, таким образом, могут косвенно способствовать формированию продукции или предоставлению услуг рассматриваемой системой.
В течение стадии ЖЦ рассматриваемую систему и системы, обеспечивающие ее функционирование, вследствие их высокой взаимозависимости можно также рассматривать как одну систему.
Таким образом, диапазон ответственности проекта для стадии ЖЦ
рассматриваемой системы расширяется до ответственности за услуги, предоставляемые соответствующей обеспечивающей системой. Если подходящей обеспечивающей системы еще не существуСистема В
в среде
функционирования
Система С
в среде
функционирования
Система А
в среде
функционирования
Взаимодействие
с системами,
включенными в среду
функционирования
Обеспечивающая
система А
Рассматриваемая
система
Взаимодействие
с обеспечивающими
системами
Обеспечивающая
система В
Обеспечивающая
система С
Рис. 1.5. Рассматриваемая система, среда функционирования и
обеспечивающие системы
21
ет, проект, который отвечает за рассматриваемую систему, может
непосредственно отвечать за создание и использование обеспечивающей системы.
1.3. Концепции жизненного цикла системы
1.3.1. Модели и стадии жизненного цикла
Каждая система имеет свой ЖЦ, который может быть описан
с использованием абстрактной функциональной модели, представляющей концептуализацию потребности в системе, ее реализации,
применения, развития и ликвидации.
Система развивается на протяжении ЖЦ в результате действий,
осуществляемых и управляемых людьми, работающими в организациях и использующими определенные процессы в своей деятельности. Детали модели жизненного цикла выражаются в терминах
этих процессов, их результатов, взаимосвязи и возникновения.
Стандарт ГОСТ Р ИСО/МЭК 15288-2005 определяет множество
процессов, названных процессами ЖЦ, при помощи которых может быть смоделирован ЖЦ системы [1, 9, 12].
Жизненные циклы различаются по свойствам, целям, использованию системы, а также по преобладающим условиям. Тем не менее,
несмотря на очевидное множество различий в ЖЦ систем, существует
базовый набор стадий ЖЦ, составляющих полный ЖЦ любой системы. Каждая стадия имеет определенную цель и вклад в полный ЖЦ и
рассматривается при планировании и выполнении ЖЦ системы. Стадии представляют собой основные периоды ЖЦ, связанные
с системой и относящиеся к состоянию описания системы или непосредственно к системе. Стадии отображают значимый прогресс
и достижение запланированных этапов развития системы на протяжении всего ЖЦ и дают начало важнейшим решениям относительно своих входов и выходов. Эти решения используются организациями для учета неопределенностей и рисков, непосредственно
связанных с затратами, сроками и функциональностью при создании или применении системы. Таким образом, стадии обеспечивают организации структурой работ, в рамках которых управление
предприятием обладает высокой способностью для обзора и контроля проекта и технических процессов.
Наиболее часто встречающиеся примеры стадий ЖЦ представлены в табл.1.1, отражены принципиальные цели каждой из этих
стадий и возможные варианты решений, используемых для управления достижениями и рисками, связанными с развитием системы
на протяжении ЖЦ.
22
Таблица 1.1
Пример стадий, их целей и основных схем решений
Стадия ЖЦ
Цель
Схема решений
Замысел
Определить потребности
правообладателей
Исследовать замыслы
Предложить жизнеспособные
решения
Вариант решения:
– выполнить следующую стадию;
– продолжить данную
стадию;
– вернуться к предыдущей стадии;
– приостановить проект;
– завершить проект
Разработка
Уточнить требования
к системе
Создать описание решений
Создать систему
Провести верификацию и
валидацию системы
Производство
Произвести систему
Проконтролировать и
испытать
Применение
Обеспечить применение
системы для удовлетворения
потребностей пользователей
Поддержка
применения
Обеспечить устойчивую
реализацию возможностей
системы
Перевод
Хранение, архивирование
в категорию
или списание системы
непригодных
для применения
Организации проходят стадии ЖЦ различными способами,
устраняя противоречия между стратегией осуществления бизнеса и стратегией уменьшения рисков. Параллельное прохождение
стадий или их прохождение в различном порядке может привести
к формам ЖЦ с совершенно разными характеристиками. Часто
в качестве альтернативных вариантов используются последовательная, инкрементная или эволюционная формы ЖЦ; в отдельных случаях могут быть разработаны комбинации этих форм. Выбор и разработка организацией конкретных форм ЖЦ зависят от
ряда факторов, включая бизнес-контекст, природу и сложность си23
стемы, стабильность требований, технологические возможности,
потребность в различных системных возможностях во времени и
наличие бюджетных средств и ресурсов.
Аналогично тому, как все системные элементы осуществляют вклад в систему как в единое целое, так и каждая стадия ЖЦ
должна учитываться на любой другой ее стадии. Следовательно,
участвующие стороны должны координировать свои действия и
кооперироваться друг с другом на протяжении всего ЖЦ. Синергия стадий ЖЦ и сторон, вкладывающих средства в реализацию
функциональностей на этих стадиях, является необходимой для
успешного осуществления проектных мероприятий. Тесная связь
и, по возможности, единение проектных команд, различных функций и организаций, ответственных за другие стадии ЖЦ, приводят
к логичности и согласованности ЖЦ.
1.3.2. Стадии рассматриваемой системы
и обеспечивающих ее систем
Каждая обеспечивающая система (как и любая система) имеет свой собственный ЖЦ. Каждый ЖЦ привязывается и синхронизируется с циклом рассматриваемой системы. Например, если
рассматриваемая система еще не существует, то требования к обеспечивающей системе определяются на стадии планирования рассматриваемой системы (или позднее, если позволяют сроки), когда
обеспечивающая система используется для предоставления конкретных услуг рассматриваемой системе (рис.1.6).
Обеспечивающая система может существовать еще до появления
рассматриваемой системы, т. е. быть фактической составляющей
инфраструктуры организации, ответственной за рассматриваемую
систему, или существовать в организации поставщика. В этом случае существующие обеспечивающие системы могут налагать дополнительные ограничения на рассматриваемую систему.
Очевидно, каждую обеспечивающую систему можно представлять как рассматриваемую систему, которая, в свою очередь, может
иметь свои обеспечивающие системы. Таким образом, настоящий
стандарт может применяться и для обеспечивающих систем.
1.4. Концепции процесса
1.4.1. Процессы жизненного цикла
Процессы ЖЦ, определенные стандартом ГОСТ Р ИСО/МЭК
15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем», могут применяться
24
25
Замысел
Замысел
Замысел
Разработка
Услуги
обеспечивающих
систем,
предоставляемые
рассматриваемой
системе
Рассматриваемая система
Производство Примечание Поддержка
Списание
Услуги, предоставляемые
рассматриваемой системой
в среду ее функционирования
Списание
Производство Примечание Поддержка
Списание системы
Списание
Поддержка системы
Списание
Производство Примечание Поддержка
Разработка
Разработка
Замысел
Замысел
Производство Примечание Поддержка
Производство системы
Списание
Разработка системы
Производство Примечание Поддержка
Разработка
Разработка
Списание
Замысел системы
Производство Примечание Поддержка
Требования
рассматриваемой
системы
к обеспечивающим
системам
Рис. 1.6. Взаимодействие системы со стандартными обеспечивающими системами
Замысел
Разработка
Потребности в услугах,
предоставляемых
рассматриваемой системой
любой организацией при приобретении и использовании или создании и поставке системы. Они распространяются на любой уровень
системной иерархии и на любую стадию ЖЦ [1, 2, 9].
Процессы ЖЦ основываются на принципах модульности (максимальная слаженность функций процесса и минимальная связь
между процессами) и собственности (процесс связывается с ответственностью). Функции, которые осуществляются данными
процессами, определяются в зависимости от конкретных целей,
результатов и набора действий, составляющих данный процесс.
Процессы, описанные в стандарте ГОСТ Р ИСО/МЭК 15288-2005,
не препятствуют и не исключают использование дополнительных
процессов, которые организация посчитает полезными.
1.4.2. Ответственность и соглашения внутри
и между организациями
Ответственность за процесс
Обычно организации различают разные области управленческой
ответственности и действий (рис.1.7). Взятые вместе эти области вноОрганизация А
Процессы
предприятия
Процессы
проекта
Технические
процессы
Организация С
Процессы
соглашения
Процессы
предприятия
Процессы
проекта
Технические
процессы
Процессы
соглашения
Организация В
Процессы
предприятия
Процессы
проекта
Технические
процессы
Рис. 1.7. Процессы соглашения, предприятия, проекта и технические
процессы во взаимодействующих организациях
26
сят вклад в способность организации продвигать свою продукцию на
рынок. В настоящем стандарте используется модель процессов, основанная на трех основных областях (или уровнях) ответственности: ответственность предприятия, ответственность проекта и техническая
ответственность. В рамках каждой организации скоординированное
множество процессов предприятия, проектных и технических процессов способствует эффективному созданию и использованию систем, содействуя, таким образом, достижению целей организации.
Различные организации и различные области ответственности
внутри организации устанавливают между собой рабочие взаимоотношения и подтверждают свою ответственность путем заключения соглашений. Эти соглашения унифицируют и координируют
вклады, сделанные различными областями ответственности с целью достижения общих бизнес-целей.
Процессы заключения соглашения
Организации являются производителями и потребителями систем, т. е. они торгуют продуктами и услугами. Одна организация
может, выступая в качестве приобретающей стороны, ставить задачу другой организации, выполняющей роль поставщика продуктов
или услуг, что достигается путем соглашений между ними. Вообще,
организации одновременно или поочередно выступают и как приобретатели, и как поставщики систем. Например, на рис.1.7 вертикальные отношения организаций А и В могут рассматриваться как
отношения организаций-поставщиков, осуществляющих торговлю
в течение одного этапа ЖЦ. Аналогично, отношения организаций
А и С могут представлять отношения организаций, последовательно
принимающих ответственность за осуществление стадий ЖЦ.
Процессы заключения соглашений могут применяться с меньшими формальностями, если приобретающая сторона и поставщик
принадлежат одной организации. Подобным же образом эти процессы могут использоваться в рамках организации для согласования распределения ответственностей на уровне предприятия, проекта и технических функций.
Процессы предприятия
Процессы предприятия связаны с гарантиями того, что потребности и ожидания заинтересованных сторон, взаимодействующих
с организацией, будут удовлетворены. На стратегическом уровне
процессы предприятия связаны с управлением и совершенствованием бизнеса или обязательств организации, с обеспечением и развертыванием ресурсов и активов и с управлением рисками в конку27
рентных или неопределенных ситуациях. Ответственность за эти
процессы обычно несет высший уровень организации.
Процессы предприятия создают устойчивый имидж предприятия для многих организаций и подразумевают в качестве движущей силы коммерческий успех или прибыль. Тем не менее, процессы предприятия в равной степени относятся и к бесприбыльным
организациям, поскольку эти организации также подотчетны заинтересованным сторонам, ответственны за ресурсы и сталкиваются с рисками в своей деятельности. Таким образом, настоящий
стандарт может применяться как бесприбыльными, так и создающими прибыль организациями.
Процессы проекта
Процессы проекта связаны с управлением ресурсами и активами, распределяемыми управленческим персоналом предприятия, и
с их использованием для безусловного выполнения соглашений, заключенных организацией. Они относятся к управлению проектами,
в частности к планированию в терминах затрат, сроков выполнения
и достижения результатов, к контролю мероприятий для гарантии
того, что они соответствуют планам и техническим критериям, а
также к определению и выбору корректирующих действий, устраняющих задержки в развитии и недостатки в достижениях.
Обычно в одной организации может осуществляться сразу несколько проектов. Процессы проекта могут использоваться для обеспечения инфраструктуры организации на корпоративном уровне,
например, на уровнях оборудования, обеспечивающих служб, технологической базы.
Технические процессы
Технические процессы связаны с техническими мероприятиями, проводимыми в течение ЖЦ. Они преобразуют потребности
правообладателей сначала в продукт, а затем, используя данный
продукт, обеспечивают устойчивую реализацию услуги тогда и
там, где это необходимо, с целью удовлетворения заказчика. Технические процессы применяются для создания и использования
системы независимо от того, представлена ли она в виде модели или
в виде конечного продукта. Технические процессы применяются на
любом уровне иерархии структуры системы.
1.4.3. Применение процессов
Каждый процесс ЖЦ (рис.1.8) может быть инициирован при необходимости в любой момент ЖЦ, причем не существует фиксиро28
Процессы
предприятия
Процессы
проекта
Технические
процессы
Определение
требований
правообладателей
Управление
средой
предприятия
Планирование
проекта
Управление
инвестициями
Оценка проекта
Анализ
требований
Управление
процессами
жизненного цикла
Контроль
проекта
Проектирование
архитектуры
Принятие
решений
Реализация
Управление
рисками
Комплексирование
Управление
конфигурацией
Верификация
Управление
ресурсами
Управление
качеством
Процессы
соглашения
Приобретение
Поставка
Управление
информацией
Передача
Валидация
Функционирование
Обслуживание
Изъятие
и списание
Рис. 1.8. Процессы жизненного цикла системы
ванных правил его использования. Подробности задач и сроки применения этих процессов на протяжении ЖЦ зависят от множества
факторов, включая социальные, торговые, организационные и технические факторы, каждый из которых может изменяться в течение жизненного цикла системы. Отдельный ЖЦ системы является,
таким образом, сложной системой процессов, обычно обладающих
параллельными, итеративными, рекурсивными и зависящими от
времени характеристиками.
Процессы могут выполняться параллельно в рамках проекта
(например, проектные действия и действия по подготовке к созданию системы выполняются одновременно) или между проектами,
например, когда системные элементы разрабатываются одновременно в различных проектах.
29
Итеративное использование процессов, т. е. повторное применение процесса или множества процессов на одном уровне иерархии,
имеет важное значение для постоянного уточнения результатов
процесса, например взаимодействие между последовательными
действиями по верификации и действиями по комплексированию
может постепенно укреплять уверенность в соответствии продукта
предъявленным требованиям.
Рекурсивное использование процессов, т. е. повторное применение одного и того же процесса или множества процессов к последовательным уровням детализации иерархической структуры
системы, является ключевым аспектом применения ГОСТ Р ИСО/
МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем».
Результаты процессов на любом уровне, будь то информация
или услуги, являются входами для таких же процессов, но реализуемых на более низком или более высоком уровнях. В итоге возникает ответная информация, артефакты или услуги, которые могут
модифицировать первоначальный выход процесса. Таким образом,
результаты процессов, полученные на всех уровнях системной архитектуры, могут быть согласованы и совместимость их достигнута, например, в виде описаний системных элементов, формирующих системную архитектуру.
Изменяющийся характер воздействий на систему (например,
изменения среды функционирования, новые возможности реализации системных элементов, модифицированная структура и обязанности в организациях) требует постоянной проверки выбора и
синхронизации использования процессов. Таким образом, применение процесса в течение ЖЦ является интенсивно меняющимся
во времени действием, реагирующим на множество внешних воздействий на систему.
Стадии ЖЦ помогают при планировании, выполнении и управлении процессами ЖЦ, несмотря на их сложность, обеспечивая достижимые и распознаваемые цели и структуру на высоком уровне.
В частности, предшествующий опыт работы на аналогичных рынках или в аналогичных производственных секторах может помочь
в выборе стадий и применении процессов ЖЦ для построения соответствующей и эффективной модели ЖЦ для любой системы.
30
2. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА СИСТЕМЫ
В разделе представлены требования к процессам ЖЦ системы,
определены цели, результаты, а также деятельность, необходимая
для их воплощения. Организация осуществляет процессы ЖЦ избирательно, чтобы достичь целей и результатов стадий ЖЦ [2, 9, 13].
Процессы ЖЦ системы подразделяются на четыре группы процессов: – процессы соглашения;
– процессы предприятия;
– процессы проекта;
– технические процессы.
2.1. Процессы соглашения
Определяются требования к процессам соглашения с организационными подразделениями корпорации (предприятия), являющимися внешними и внутренними по отношению к организации.
Процессы соглашения состоят из:
1) процесса приобретения, используемого организациями для
приобретения продукции или получения услуг;
2) процесса поставки, используемого организациями для поставок продукции или оказания услуг.
Данные процессы определяют действия, необходимые для достижения соглашения между двумя организациями. В результате
осуществления процесса приобретения обеспечиваются условия
для ведения дел с поставщиком продукции, используемой как действующей системой и службами ее поддержки, так и элементами
системы, разрабатываемой в рамках проекта. В результате процесса поставки обеспечиваются условия для управления проектом,
результатом которого является продукт или услуга, поставляемые
приобретающей стороне.
2.1.1. Процесс приобретения
Цель процесса приобретения состоит в получении продукта или
услуги в соответствии с требованиями приобретающей стороны. В результате успешного осуществления процесса приобретения:
1) определяется стратегия приобретения;
2) выбирается поставщик;
3) устанавливается связь с поставщиком;
4) объявляется обоснование для выбора поставщика;
5) заключается соглашение о приобретении продукта или услуги в соответствии с определенными критериями приемки;
31
6) принимается продукт или услуга, соответствующие соглашению;
7) осуществляется оплата или другие согласованные расчеты.
Приобретающая сторона должна осуществлять следующие действия в соответствии с принятой в организации политикой и процедурами в отношении процесса приобретения:
1) утверждать план приобретения;
2) подготавливать заявку на поставку продукта или услуги;
3) передавать заявку на поставку продукции или услуг определенным поставщикам;
4) выбирать поставщика;
5) заключать соглашение с поставщиком;
6) оценивать выполнение соглашения;
7) подтверждать, что поставленный продукт или услуга соответствуют условиям соглашения;
8) осуществлять оплату.
2.1.2. Процесс поставки
Цель процесса поставки заключается в обеспечении приобретающей стороны продукцией или услугами, удовлетворяющими согласованным требованиям.
В результате успешного осуществления процесса поставки:
1) определяется приобретающая сторона продукта или услуги;
2) составляется ответ на заявку приобретающей стороны;
3) заключается соглашение о поставке продукта или услуги в соответствии с определенными критериями приемки;
4) обеспечивается связь с приобретающей стороной;
5) в соответствии с согласованными процедурами и условиями
поставок поставляется продукт или услуга, удовлетворяющие соглашению;
6) в порядке, указанном в соглашении, передается ответственность за приобретенный продукт или услугу;
7) производится оплата или осуществляются другие согласованные взаиморасчеты.
При реализации процесса поставки поставщик должен осуществлять следующие действия в соответствии с принятыми в организации политикой и процедурами:
1) определять наличие и подлинность приобретающей стороны,
которая нуждается в продукте или услуге или представляет сторону или стороны, имеющие такую потребность;
2) оценивать заявку на поставку продукта или услуги, чтобы
определить ее выполнимость и содержание ответа на нее;
32
3) готовить предложение по удовлетворению ходатайства;
4) заключать соглашение с приобретающей стороной;
5) выполнять соглашение в соответствии с утвержденными поставщиком проектными планами и в соответствии с текстом соглашения;
6) оценивать выполнение соглашения;
7) поставлять продукт или услугу в соответствии с критериями
соглашения;
8) принимать и подтверждать получение оплаты или выполнение других согласованных способов расчета;
9) передавать ответственность за продукт или услугу приобретающей стороне или другой стороне в порядке, предусмотренном
соглашением.
2.2. Процессы предприятия
Процессы предприятия управляют способностью организации приобретать и поставлять продукцию или услуги посредством запуска
проектов, их поддержки и контроля. Процессы предприятия обеспечивают ресурсы и инфраструктуру, необходимые для осуществления
проектов, и гарантируют достижение целей и исполнение обязательств
организации по соглашениям. Эти процессы не рассматриваются в качестве исчерпывающей совокупности бизнес-процессов, которые делают возможным стратегическое управление деятельностью организации. Процессы предприятия включают в себя: 1) процесс управления средой предприятия; 2) процесс управления инвестициями;
3) процесс управления процессами жизненного цикла системы;
4) процесс управления ресурсами;
5) процесс управления качеством.
2.2.1. Процесс управления средой предприятия
Цель процесса управления средой предприятия заключается
в определении и проведении политики и процедур, необходимых
для функционирования организации в соответствии с положениями настоящего стандарта.
В результате успешного осуществления процесса управления
средой предприятия:
1) реализуется политика и процедуры стратегического управления ЖЦ системы;
2) определяется степень ответственности и объем полномочий
при осуществлении управления ЖЦ системы;
33
3) реализуется политика усовершенствования процессов ЖЦ
системы.
При реализации процессов управления средой предприятия необходимо осуществлять следующие действия в соответствии с принятой организацией политикой и процедурами:
1) устанавливать планы действий для каждой области деятельности;
2) подготавливать политику и процедуры управления ЖЦ системы, необходимые для реализации требований данного стандарта, не
противоречащие стратегическому плану предприятия и планам действий для каждой области деятельности;
3) определять, интегрировать и связывать между собой роли,
степень ответственности и полномочия для облегчения реализации
процессов ЖЦ системы и стратегического управления жизненным
циклом системы;
4) определять деловые критерии, позволяющие контролировать
развитие процессов ЖЦ; 5) периодически пересматривать используемую при проектировании модель ЖЦ системы; 6) согласовывать с проектами политику и процедуры, принятые на
предприятии, с целью реализации требований настоящего стандарта.
2.2.2. Процесс управления инвестициями
Цель процесса управления инвестициями состоит в запуске
в производство и поддержке обоснованных и успешных проектов,
способствующих достижению целей организации. Управление инвестициями заключается в адекватном инвестировании фондов и
ресурсов организации и в определении полномочий, необходимых
для осуществления отобранных проектов. В процессе управления
инвестициями осуществляется постоянная оценка проектов с целью подтверждения их обоснованности или доработки до приемлемого уровня и продолжения инвестирования.
В результате успешного выполнения процесса управления инвестициями:
1) квалифицируются и отбираются инвестиционные возможности или потребности;
2) определяются и распределяются ресурсы и денежные средства;
3) определяются полномочия и ответственность при управлении
проектом;
4) поддерживаются проекты, удовлетворяющие условиям соглашения, требованиям правообладателей и организации;
34
5) переориентируются, приостанавливаются или прекращаются
проекты, не удовлетворяющие условиям соглашения, требованиям
правообладателей или организации.
При реализации процессов управления инвестициями организация должна осуществлять следующие действия в соответствии
с принятой политикой и процедурами:
1) находить новые возможности и формы развития бизнеса, заключать новые соглашения, соответствующие стратегическому
плану предприятия и планам для каждого из направлений его деятельности;
2) структурировать проекты, определять ответственность и полномочия участников;
3) оценивать предполагаемые результаты осуществления проектов;
4) распределять ресурсы для достижения целей проекта;
5) выявлять все возможные взаимосвязи проекта с другими проектами;
6) устанавливать требования к проектной отчетности и периодически оценивать реализацию ключевых событий, от которых зависит выполнение проекта;
7) санкционировать начало выполнения утвержденных проектных планов, включая технические планы;
8) оценивать текущие проекты с целью подтверждения того, что:
– проекты продвигаются в направлении достижения поставленных целей;
– проекты ведутся согласно соответствующим директивам;
– проекты реализуются в соответствии с планами и процедурами жизненного цикла систем;
– проекты остаются жизнеспособными, что подтверждается, например, постоянной потребностью в услуге, практичным выполнением продукта и приемлемыми доходами от инвестиций;
9) принять решение о продолжении реализации или доработке
проектов для того, чтобы их реализация прошла успешно;
10) в случаях, оговоренных соглашением, принять меры по отмене или приостановке тех проектов, ущерб или риски по которым
превышают доходность инвестиций. 2.2.3. Процесс управления процессами
жизненного цикла системы
Цель процесса управления процессами ЖЦ системы заключается в гарантировании доступности эффективных процессов ЖЦ для
использования организацией.
35
Данный процесс обеспечивает процессы ЖЦ системы, которые
согласованы с целями и политикой организации, определены,
адаптированы и поддержаны соответствующим образом для учета особенностей отдельных проектов и способны реализовываться
с помощью эффективных проверенных методов и инструментальных средств.
В результате эффективного управления процессами ЖЦ системы:
1) определяются процессы ЖЦ системы, которые будут использоваться организацией;
2) определяется политика применения процессов ЖЦ системы;
3) определяется политика адаптации процессов ЖЦ системы
для удовлетворения потребностей отдельных проектов;
4) определяются критерии оценки результатов применения процессов ЖЦ системы;
5) предпринимаются действия по совершенствованию способов
определения и применения процессов ЖЦ системы.
При реализации процессов управления процессами ЖЦ системы организация должна осуществлять следующие действия в соответствии с принятой политикой и процедурами:
1) устанавливать стандартные наборы процессов ЖЦ систем для
соответствующих стадий ЖЦ системы;
2) определять приемлемые политику и процедуры адаптации и
требования к их утверждению;
3) определять методы и инструментальные средства, которые
поддерживают выполнение процессов ЖЦ системы;
4) по возможности устанавливать показатели, которые позволяют
определять характеристики выполненных стандартных процессов;
5) контролировать выполнение процесса, сохранять и анализировать показатели процесса и определять тенденции по отношению
к критериям предприятия;
6) определять возможности для усовершенствования стандартных процессов ЖЦ систем;
7) совершенствовать имеющиеся процессы, методы и инструментальные средства, используя найденные возможности.
2.2.4. Процесс управления ресурсами
Цель процесса управления ресурсами состоит в обеспечении
проектов необходимыми ресурсами.
В результате процесса определяются ресурсы, материалы и услуги, необходимые для обеспечения организации и целей проектов в течение их ЖЦ. В ресурсы включают квалифицированный, обученный
36
и опытный персонал, способный реализовывать процессы ЖЦ. Процесс управления ресурсами гарантирует эффективную координацию
и совместное использование ресурсов, информации и технологий.
В результате успешного выполнения процесса управления ресурсами:
1) проекты обеспечиваются необходимыми ресурсами, материалами и обслуживанием;
2) поддерживается или улучшается квалификация персонала;
3) разрешаются конфликты, возникающие в результате одновременного осуществления нескольких проектов.
При реализации процессов управления ресурсами организация
должна осуществлять следующие действия в соответствии с принятой политикой и процедурами:
1) определять и обеспечивать поддержку инфраструктуры ресурсов, необходимой для выполнения организацией требований
настоящего стандарта и осуществления поддержки проекта;
2) получать ресурсы, за исключением персонала, необходимые
для внедрения и осуществления проектов;
3) проявлять заботу о персонале, занятом в осуществлении текущих проектов;
4) стимулировать персонал, например, посредством предоставления возможности карьерного роста или при помощи системы поощрений;
5) контролировать области взаимодействия нескольких проектов для разрешения связанных с графиками их реализации конфликтов:
– из-за ограниченных возможностей организационной инфраструктуры, вспомогательных служб и ресурсов при распределении
между текущими проектами;
– из-за занятости персонала работой над несколькими проектами одновременно.
2.2.5. Процесс управления качеством
Цель процесса управления качеством состоит в том, чтобы обеспечить такой уровень качества продукции, услуг и реализации
процессов жизненного цикла, который бы соответствовал целям
предприятия в области качества и удовлетворял заказчика.
В результате успешного осуществления процесса управления
качеством:
1) определяются политика организации и процедуры в области
управления качеством;
37
2) определяются цели и задачи организации в области управления качеством;
3) определяется ответственность и полномочия для управления
качеством;
4) контролируется степень удовлетворенности заказчика;
5) предпринимаются необходимые меры в случае, если цели
в области управления качеством не достигнуты.
При реализации процессов управления качеством организация
должна осуществлять следующие действия в соответствии с принятыми политикой и процедурами:
1) устанавливать политику, стандарты и процедуры управления
качеством;
2) устанавливать цели организации в области управления качеством, основанные на стратегии, направленной на обеспечение
удовлетворенности заказчика;
3) определять ответственность и полномочия при реализации
управления качеством;
4) проводить оценку и составлять отчеты о степени удовлетворенности заказчика;
5) проводить периодическую переоценку планов обеспечения
качества проектов;
6) непрерывно контролировать состояние усовершенствования
качества продукции и услуг.
2.3. Процессы проекта
Процессы проекта используются для установления и выполнения планов, оценки фактических достижений и продвижений
проекта в соответствии с планами и для контроля выполнения проекта вплоть до его завершения. Отдельные процессы проекта могут
осуществляться в любой момент ЖЦ и на любом уровне иерархии
проектов как в соответствии с проектными планами, так и с учетом непредвиденных обстоятельств. Уровень точности и формализации, с которой осуществляются процессы проекта, зависит от
сложности самого проекта и проектных рисков.
Процессы проекта состоят из следующих процессов:
1) процесс планирования проекта;
2) процесс оценки проекта;
3) процесс контроля проекта;
4) процесс принятия решений;
5) процесс управления рисками;
6) процесс управления конфигурацией;
38
7) процесс управления информацией.
Планирование, оценка и контроль являются ключевыми процессами практически для всех видов управления. Они присутствуют в управлении любыми предпринимаемыми действиями, начиная с уровня всей организации и заканчивая каким-либо одним
процессом жизненного цикла и его действиями. В пособии термин
«проект» используется в контексте описания процессов, связанных
с планированием, оценкой и контролем. Принципы, относящиеся
к этим процессам, могут применяться в любой области управления
организацией.
2.3.1. Процесс планирования проекта
Цель процесса планирования проекта состоит в составлении и
доведении до заинтересованных сторон эффективного и выполнимого плана проекта.
Этот процесс определяет область управления проектом и техническими мероприятиями, определяет результаты процесса,
проектные задачи и поставки, устанавливает графики выполнения задач проекта, включая критерии достижения результатов и
ресурсы, необходимые для выполнения задач проекта.
В результате успешного выполнения процесса планирования
проекта:
1) обеспечивается доступ к проектным планам;
2) определяются роли, ответственность и полномочия участников;
3) формируется официальный запрос на ресурсы и услуги, необходимые для достижения целей проекта;
4) определяются показатели для характеристик проекта;
5) штат проекта ориентируется в соответствии с планами проекта.
При реализации процесса планирования проекта организация
должна осуществлять следующие действия в соответствии с принятой политикой и процедурами: 1) определять проектные цели и ограничения;
2) определять границы проекта в соответствии с соглашением;
3) устанавливать декомпозицию работ, основанную на развивающейся системной архитектуре;
4) определять и поддерживать графики работ в рамках проекта,
основываясь на целях проекта и оценках выполнимости работ; 5) определять критерии достижения результатов проекта для
схем принятия решений на стадиях ЖЦ, сроков поставок и основных зависимостей от внешних входов или выходов;
6) определять расходы на проект и планировать бюджет;
39
7) устанавливать структуру полномочий и ответственности за
выполнение работ в рамках проекта;
8) определять инфраструктуру и службы, необходимые для реализации проекта; 9) планировать приобретение материалов, покупных изделий и
услуг обеспечивающих систем для выполнения проекта; 10) формировать и доводить план до заинтересованных сторон
для технического управления проектом, включая соответствующие
ревизии;
11) определять проектные показатели, которые должны быть
сформированы, и связанные с ними данные, которые должны быть
собраны, подвергнуты валидации и анализу. 2.3.2. Процесс оценки проекта
Цель процесса оценки проекта заключается в определении статуса проекта.
В ходе этого процесса периодически или при возникновении
важных событий проводится оценка развития проекта и достижений относительно требований, планов и целей бизнеса. В случае
обнаружения существенных отклонений информация о результатах
оценки сообщается заинтересованным сторонам для осуществления
адекватных управляющих воздействий.
В результате успешного осуществления процесса оценки проекта:
1) становятся доступными показатели или результаты оценки
рабочих характеристик проекта;
2) оценивается адекватность ролей, обязанностей и полномочий
участников проекта;
3) оценивается адекватность ресурсов и услуг, необходимых для
реализации проекта;
4) анализируются отклонения от планируемых значений показателей рабочих характеристик проекта;
5) заинтересованные стороны информируются о статусе проекта.
При реализации процесса оценки проекта организация должна
осуществлять следующие действия в соответствии с проводимой
политикой и установленными процедурами:
1) оценивать статус проекта относительно соответствующих
проектных планов для определения отклонений в затратах, сроках
и качестве;
2) обеспечивать гарантии качества в соответствии с проектными
планами;
40
3) оценивать результативность структуры команды участников
проекта, распределения ролей и ответственности;
4) оценивать адекватность и готовность инфраструктуры, обеспечивающей выполнение проекта;
5) оценивать развитие проекта, используя измеренные достижения и результаты выполнения проекта в промежуточных контрольных точках;
6) проводить требуемые управленческий и технический анализы, аудит и проверки для определения готовности к переходу на
следующую стадию ЖЦ системы или на следующий этап осуществления проекта;
7) отслеживать критические процессы и новые технологии;
8) анализировать данные и показатели для выявления значимых отклонений или изменений по отношению к запланированным показателям и давать соответствующие рекомендации для
корректировки;
9) обеспечивать периодическую отчетность о статусе проекта и
обязательную отчетность об отклонениях в соответствии с соглашением и принятыми в организации политикой и процедурами.
2.3.3. Процесс контроля проекта
Цель процесса контроля проекта заключается в организации исполнения плана проекта и обеспечении гарантий реализации проекта в соответствии с планами и графиками в пределах бюджета
проекта и гарантий удовлетворения технических целей.
При необходимости этот процесс включает в себя изменение направлений деятельности в рамках проекта, устранение выявленных отклонений и изменений, связанных с управлением другими
проектами или техническими процессами. Соответственно, переориентирование может включать в себя перепланирование.
В результате успешного осуществления процесса контроля
проекта:
1) определяются и совершаются корректирующие действия, если
результаты проекта не соответствуют запланированным заданиям;
2) инициируется перепланирование проекта, если цели проекта
или ограничения изменились, или допущения, сделанные при планировании, оказались неверными;
3) санкционируются действия по переходу от одного запланированного этапа или события к следующему (при условии успешной
реализации предыдущего этапа или события);
4) достигаются цели проекта.
41
При реализации процесса контроля проекта организация должна осуществлять следующие действия в соответствии с принятой
политикой и процедурами:
1) управлять проектными требованиями и изменениями требований в соответствии с проектными планами;
2) инициировать корректирующие действия, необходимые для
достижения целей и получения результатов выполнения задач проекта при отклонениях свыше допустимых или заранее определенных
пределов;
3) соответствующим образом инициировать превентивные действия для гарантии достижения целей и результатов проекта;
4) инициировать действия по разрешению проблем для коррекции несоответствий;
5) разворачивать во времени содержание, определение и соответствующую декомпозицию работ, которые должны быть выполнены
в рамках проекта вследствие принятых решений о корректирующих
действиях и оцененных изменениях, которые эти действия вносят;
6) по просьбе приобретающей стороны или поставщика инициировать действия, связанные с изменениями предусмотренных договором затрат, сроков или качества;
7) осуществлять действия по исправлению нарушенных условий
поставки приобретаемой продукции и услуг посредством конструктивного взаимодействия с поставщиком;
8) санкционировать, если это обосновано, переход к реализации
следующего запланированного этапа или события проекта.
2.3.4. Процесс принятия решений
Цель процесса принятия решений заключается в выборе из существующих альтернатив наиболее предпочтительного направления проектных действий.
Этот процесс является реакцией на возникающие в процессе
жизненного цикла системы запросы о принятии решений, направленных на достижение заданных, желаемых или оптимальных
результатов вне зависимости от характера или источников таких
запросов. Альтернативные действия анализируются и выбирается
направление действий. Решения и их обоснование документируются для поддержки принятия решений в будущем.
В результате успешного осуществления процесса принятия
решений:
1) определяется стратегия принятия решений;
2) определяются альтернативные направления действий;
42
3) выбирается наиболее предпочтительное направление действий;
4) принятое решение, его обоснование и допущения документируются и доводятся до сведения заинтересованных сторон.
При реализации процесса принятия решений организация
должна осуществлять следующие действия в соответствии с принятой политикой и процедурами:
1) определять стратегию принятия решений;
2) привлекать заинтересованные стороны к принятию решений
для использования их опыта и знаний;
3) устанавливать обстоятельства и необходимость принятия решений;
4) выбирать и объявлять стратегию принятия решений для каждой ситуации, в которой необходимо принимать решение;
5) оценивать баланс последствий альтернативных действий, используя определенную стратегию принятия решений, с целью оптимизации или улучшения ситуации принятия решений;
6) документировать, отслеживать, оценивать и сообщать о результатах принятия решения для подтверждения эффективности
решения проблем, устранения отрицательных тенденций и получения возможных преимуществ;
7) поддерживать записи о проблемах и возможностях их решения, а также размещать эти записи в соответствии с соглашениями
или организационными процедурами таким образом, который позволяет проводить аудит и изучать полученный опыт.
2.3.5. Процесс управления рисками
Цель процесса управления рисками заключается в снижении
последствий отрицательного воздействия вероятных событий, которые могут явиться причиной изменений качества, затрат, сроков
или ухудшения технических характеристик.
В ходе данного процесса проводится определение, оценка, обработка и мониторинг рисков, возникающих в течение полного жизненного цикла, а также вырабатывается реакция на каждый риск
в терминах реализации соответствующих мер противодействия риску или его принятия.
В результате успешного осуществления процесса управления
рисками:
1) определяются и классифицируются риски;
2) количественно оцениваются вероятности и последствия осуществления рисков;
3) устанавливается стратегия реакции на каждый из рисков;
43
4) определяется и объявляется статус риска;
5) принимаются соответствующие меры в случае, если риск вышел за пределы приемлемых значений. В процессе управления рисками организация должна осуществлять следующие действия в соответствии с принятой политикой и
процедурами:
1) утвердить систематический подход к определению рисков, их
оценке и обработке;
2) идентифицировать и определять риски;
3) определять вероятности событий, связанных с рисками, используя установленные критерии;
4) оценивать риски в терминах их возможных последствий, используя установленные критерии;
5) определять градации рисков по их вероятности и последствиям;
6) определять стратегии реакции на риски;
7) определять значения допустимых границ для каждого идентифицированного риска;
8) определять действия по обработке рисков в случае превышения ими допустимых границ;
9) сообщать о мерах по обработке рисков и их статусе в соответствии с действующими соглашениями, политикой и процедурами;
10) вести учет рисков в течение всего жизненного цикла.
2.3.6. Процесс управления конфигурацией
Цель процесса управления конфигурацией состоит в установлении и поддержании целостности всех идентифицированных выходных результатов проекта или процесса обеспечения доступа к ним
любой заинтересованной стороны.
В результате успешного осуществления процесса управления
конфигурацией:
1) определяется стратегия управления конфигурацией;
2) определяются элементы, нуждающиеся в управлении конфигурацией;
3) устанавливается базовая линия конфигурации;
4) контролируются изменения элементов, нуждающихся
в управлении конфигурацией;
5) контролируется конфигурация выделенных элементов;
6) становится доступным на протяжении всего жизненного цикла статус элементов конфигурации, на которые распространяется
управление.
44
При реализации процесса управления конфигурацией организация должна осуществлять следующие действия в соответствии
с принятой политикой и процедурами:
1) определять стратегию управления конфигурацией;
2) идентифицировать элементы, которые необходимо контролировать в процессе управления конфигурацией; 3) поддерживать информацию о конфигурации на приемлемом
уровне целостности и защищенности;
4) гарантировать, что изменения базовой линии конфигурации
соответствующим образом идентифицируются, записываются,
оцениваются, утверждаются, проводятся и верифицируются.
2.3.7. Процесс управления информацией
Цель процесса управления информацией состоит в своевременном предоставлении заинтересованным сторонам необходимой
полной, достоверной и, если требуется, конфиденциальной информации в течение и, соответственно, после завершения жизненного
цикла системы.
В рамках процесса управления информацией реализуются функции создания, сбора, преобразования, хранения, восстановления,
распространения и размещения информации. Этот процесс управляет
перечисленной информацией, включая техническую и проектную информацию, информацию предприятия и пользовательскую информацию, а также информацию, содержащуюся в соглашениях.
В результате успешного осуществления процесса управления
информацией:
1) определяется информация, подлежащая управлению;
2) определяются формы представления информации;
3) информация преобразуется и распределяется в соответствии
с требованиями;
4) документируется статус информации;
5) информация является «свежей», полной и достоверной;
6) информация становится доступной для уполномоченных
сторон.
При реализации процесса управления информацией организация должна осуществлять следующие действия в соответствии
с принятой политикой и процедурами:
1) определять элементы информации, которые будут подлежать
управлению в течение ЖЦ системы и, согласно политике организации или законодательству, поддерживаться в течение определенного периода после завершения ЖЦ;
45
2) распределять полномочия и обязанности, относящиеся к зарождению, созданию, накоплению, архивированию и уничтожению элементов информации;
3) определять права, обязанности и обязательства, касающиеся
хранения, передачи и доступа к элементам информации;
4) определять содержание, семантику, форматы и средства для
представления, хранения, передачи и поиска информации;
5) получать идентифицированные элементы информации;
6) обслуживать элементы информации и хранящиеся записи
этих элементов в соответствии с требованиями к целостности, защите и сохранению тайны;
7) определять действия по сопровождению информации;
8) находить и распределять информацию между определенными
сторонами в соответствии с требованиями согласованных графиков
или при определенных обстоятельствах;
9) предоставлять официальную документацию в соответствии
с требованиями;
10) архивировать заданную информацию в соответствии с целями аудита и сохранения знаний;
11) уничтожать ненужную, искаженную или не поддающуюся
проверке информацию в соответствии с политикой организации,
требованиями к защите информации и сохранению тайны. 2.4. Технические процессы
Технические процессы используются для определения требований к системе, преобразования этих требований в эффективный
продукт, позволяющий осуществлять, при необходимости, устойчивое воспроизводство этого продукта, использовать его для обеспечения требуемых услуг, поддерживать обеспечение этими услугами и удалять продукт, когда он изымается из обращения.
Технические процессы определяют совокупность работ, которые
позволяют в рамках задач предприятия и проекта оптимизировать
прибыли и уменьшать риски, возникающие вследствие принятия
технических решений и осуществления соответствующих действий. Эти работы обеспечивают условия для того, чтобы продукция и услуги были нужными и полезными, экономически выгодными, функциональными, надежными, пригодными к обслуживанию, производству и использованию и обладали другими качествами, необходимыми для того, чтобы удовлетворить требования как
приобретающих организаций, так и организаций-поставщиков.
Они также обеспечивают условия для того, чтобы продукция и ус46
луги соответствовали ожиданиям или законодательным требованиям общества, включая требования к факторам здоровья, безопасности, защиты и экологии.
Технические процессы включают в себя:
1) процесс определения требований правообладателей;
2) процесс анализа требований;
3) процесс проектирования архитектуры;
4) процесс реализации элементов системы;
5) процесс комплексирования;
6) процесс верификации;
7) процесс передачи;
8) процесс валидации;
9) процесс функционирования;
10) процесс технического обслуживания;
11) процесс изъятия и списания.
2.4.1. Процесс определения требований правообладателей
Цель процесса определения требований правообладателей состоит в выявлении требований к системе, выполнение которых может
обеспечить функциональные возможности, необходимые пользователям системы и иным заинтересованным лицам в заданной эксплуатационной среде.
Процесс позволяет определить правообладателей или классы
правообладателей, которые связаны с системой на протяжении всего ЖЦ, а также их потребности и пожелания. В рамках процесса
эти данные анализируются и преобразуются в общий набор требований правообладателей, описывающих ожидаемое поведение системы в процессе взаимодействия с эксплуатационной средой, и
совокупность базовых показателей, проверка на соответствие которым является целью процесса валидации, позволяющего подтвердить, что система отвечает заявленным требованиям.
В результате успешной реализации процесса определения требований правообладателей:
1) задаются требуемые характеристики и условия использования функциональных возможностей системы;
2) определяются ограничения для системных решений;
3) достигается возможность текущего отслеживания связей
между требованиями правообладателей и самими правообладателями и их потребностями;
4) описывается основа для определения системных требований;
5) определяется основа для валидации соответствия функциональных возможностей системы;
47
6) формируется основа для ведения переговоров и заключения
соглашения о поставке продукции или услуг.
При реализации процесса определения требований правообладателей организация должна осуществлять следующие действия
в соответствии с принятой политикой и процедурами:
1) идентифицировать отдельных правообладателей или классы
правообладателей, имеющих законный интерес к системе в течение ее ЖЦ;
2) выявлять требования правообладателей;
3) определять ограничения системных решений, которые являются неизбежным следствием существующих соглашений, управленческих или технических решений;
4) определять представительный набор последовательных действий для идентификации всех требуемых функциональных возможностей, которые отвечают предполагаемым сценариям и средам
функционирования и сопровождения;
5) определять взаимодействие между пользователями и системой;
6) устанавливать и специфицировать экологические, медицинские
требования, требования безопасности и другие требования правообладателей, имеющие отношение к критическим показателям;
7) анализировать полную совокупность выявленных требований;
8) разрешать проблемы, возникающие в связи с определением
требований;
9) доводить результаты анализа требований до сведения соответствующих правообладателей для гарантии того, что их потребности и ожидания были правильно поняты и выражены;
10) устанавливать совместно с правообладателями корректность
выражения их требований;
11) документировать требования правообладателей в форме,
приемлемой для управления требованиями в течение жизненного
цикла и за его пределами;
12) поддерживать взаимное соответствие между требованиями
правообладателей и потребностями заинтересованных лиц.
2.4.2. Процесс анализа требований
Цель процесса анализа требований состоит в преобразовании
требований правообладателя, выраженных в виде его представлений о желаемых функциональных возможностях, в техническое видение требуемого продукта, способного предоставить такие
функциональные возможности.
48
В ходе этого процесса создается представление о будущей системе,
которая сможет удовлетворить требования правообладателей и, если
позволят ограничения, не подразумевают какой-либо специфической
реализации. В результате данного процесса задаются измеримые системные требования, зависящие от видения разработчика, в которых
определяется, какими характеристиками должна обладать система и
какими должны быть значения этих характеристик, чтобы удовлетворить требования правообладателей.
В результате успешного осуществления процесса анализа требований:
1) устанавливаются требуемые характеристики, свойства, функциональные и эксплуатационные требования к техническим решениям;
2) устанавливаются ограничения, влияющие на архитектурное
проектирование системы, а также на средства по его реализации;
3) достигается целостность и прослеживаемость системных требований к требованиям правообладателей;
4) определяется основа для верификации системных требований.
При реализации процесса анализа требований организация
должна осуществлять следующие действия в соответствии с принятой политикой и процедурами:
1) определять функциональные границы системы в терминах ее
поведения и свойств, которые должны быть обеспечены;
2) определять каждую функцию, которую система должна выполнять, насколько хорошо система, включая операторов, должна
выполнять эту функцию, условия, при которых система способна
выполнять данную функцию и при которых система начинает и
прекращает ее выполнение;
3) определять необходимые ограничения по изготовлению системы и ее элементов, которые обусловлены требованиями правообладателей или неизбежными ограничениями, связанными с принятием решений;
4) определять технические показатели и показатели качества при
использовании, позволяющие оценивать технические достижения;
5) устанавливать системные требования и функции, в соответствии с которыми определяются риски и критические параметры
системы, связанные с такими свойствами, как здоровье, безопасность, защищенность, безотказность, готовность, а также со свойствами обеспечивающих систем;
6) анализировать целостность системных требований для обеспечения уверенности в том, что каждое требование, пары требований или наборы требований обладают системной целостностью;
49
7) демонстрировать связь между системными требованиями и
требованиями правообладателей;
8) на протяжении всего ЖЦ вести учет совокупности системных
требований вместе с их обоснованиями, связанными решениями и
допущениями.
2.4.3. Процесс проектирования архитектуры
Цель процесса проектирования архитектуры состоит в синтезе
решения, которое бы удовлетворяло системным требованиям.
Этот процесс выделяет и устанавливает области решения,
представленные в виде набора различных проблем управленческого, концептуального и, наконец, реализационного характера. В рамках процесса определяются и исследуются одна или
несколько стратегий реализации системы со степенью детализации, соответствующей техническим и коммерческим требованиям и рискам. Исходя из этого выбирается решение о проектировании архитектуры. Оно определяется на основе требований
к набору системных элементов, из которых компонуется система. Конкретные требования, формируемые в результате этого
процесса, являются основой для проведения верификации реализованной системы и для разработки стратегий комплексирования и верификации.
В результате успешного осуществления процесса проектирования архитектуры:
1) устанавливается порядок, в соответствии с которым выполняется проектирование архитектуры;
2) задается реализуемый набор описаний системных элементов,
которые удовлетворяют требованиям, предъявляемым к системе;
3) включаются в решение по проектированию архитектуры
требования к интерфейсу;
4) устанавливается связь между проектированием архитектуры
и системными требованиями;
5) определяется основа для верификации системных элементов;
6) устанавливается основа комплексирования системных элементов.
При реализации процесса проектирования архитектуры организация должна осуществлять следующие действия в соответствии
с принятой политикой и процедурами:
1) определять приемлемые проекты логической архитектуры;
2) выполнять декомпозицию функций системы, определенных
в процессе анализа требований, и поставить им в соответствие эле50
менты архитектуры системы, сформировать производные требования, необходимые для такого сопоставления;
3) анализировать итоговый проект архитектуры с целью установления проектных критериев для каждого элемента;
4) определять, какие системные требования должны выполняться операторами;
5) определять, доступны ли в готовом виде те элементы технического и программного обеспечения, которые удовлетворяют проектным и интерфейсным критериям;
6) оценивать альтернативные проектные решения, моделируя
их с той степенью детализации, которая позволяет сравнивать
спецификации, выраженные в системных требованиях, с эксплуатационными характеристиками, стоимостными и временными
показателями и рисками, выраженными в требованиях правообладателей;
7) определять и документировать области взаимодействия между
системными элементами и области взаимодействий на границе
системы с внешними системами;
8) задавать выбранные физические проектные решения в соответствии с порядком проектирования архитектуры в терминах проектных функций, характеристик эксплуатации, поведения, интерфейсов
и неизбежных ограничений при реализации проекта;
9) вести документальный учет информации по проектированию
архитектуры;
10) поддерживать взаимосвязь и взаимозависимость между архитектурой и системными требованиями. 2.4.4. Процесс реализации элементов системы
Цель процесса реализации элементов системы состоит в создании заданных (специфицированных) элементов системы.
В ходе этого процесса происходит преобразование заданных
поведенческих, интерфейсных и производственных ограничений
в действия по реализации, в результате которых в соответствии со
сложившимися правилами и технологией создается элемент системы. Системный элемент конструируется или адаптируется путем
обработки материалов и (или) информации, соответствующих выбранной технологии реализации, и использования соответствующих технических приемов и дисциплин. Результатом процесса
является элемент системы, удовлетворяющий как архитектурным
решениям, что подтверждается при верификации, так и требованиям правообладателей, что подтверждается при валидации.
51
В результате успешного осуществления процесса реализации
элементов системы:
1) определяется стратегия реализации элементов системы;
2) определяются технологические ограничения, связанные с конструкцией системного элемента;
3) изготавливается системный элемент;
4) системный элемент упаковывается и хранится в соответствии
с соглашением о его поставке.
При осуществлении процесса реализации элементов системы
организация должна выполнять следующие действия в соответствии с принятой политикой и процедурами:
1) разрабатывать стратегию реализации элементов системы;
2) определять ограничения, которые стратегия и технология реализации элементов системы налагают на проектные решения;
3) реализовывать или адаптировать системные элементы, используя обеспечивающие системы и определенные материалы
в соответствии с заданными процедурами изготовления для производства технических средств, создания программных средств и
(или) для обучения операторов;
4) вести регистрацию доказательств соответствия элементов системы соглашениям с поставщиками, законодательству и политике
организации;
5) упаковывать элемент системы и хранить его в соответствующем виде.
2.4.5. Процесс комплексирования
Цель процесса комплексирования заключается в сборке системы согласно архитектурному проекту.
В ходе этого процесса системные элементы комбинируются таким образом, чтобы сформировать конфигурацию всей системы
или ее части и создать продукт в соответствии с заданными системными требованиями.
В результате успешного осуществления процесса комплексирования:
1) определяется стратегия комплексирования системы;
2) определяются неизбежные ограничения, связанные с процессом комплексирования, которые влияют на системные требования;
3) компонуется и комплексируется система, допускающая верификацию на соответствие требованиям, заданным архитектурным
проектом;
52
4) ведется документальный учет несоответствий, возникших
в процессе комплексирования.
При реализации процесса комплексирования организация должна осуществлять следующие действия в соответствии с принятой политикой и процедурами:
1) определять последовательность и стратегию сборки системы,
которые минимизируют риски в процессе комплексирования;
2) идентифицировать ограничения на конструктивные решения, возникающие в результате следования стратегии комплексирования;
3) получать системы, обеспечивающие комплексирование, и необходимые материалы в соответствии с установленными процедурами комплексирования;
4) получать системные элементы согласно графикам;
5) гарантировать, что системные элементы были верифицированы на соответствие критериям приемки, указанным в соглашении;
6) комплексировать системные элементы в соответствии
с применяемыми описаниями контроля интерфейсов и установленными процедурами сборки, используя заданные средства интеграции;
7) вести учет информации, касающейся комплексирования,
в соответствующей базе данных.
2.4.6. Процесс верификации
Цель процесса верификации состоит в подтверждении того, что
заданные (специфицированные) требования проекта полностью реализованы в системе.
В ходе этого процесса получают информацию, которая требуется для совершения действий по устранению недостатков, что позволяет корректировать несоответствия в реализованной системе или
процессы, происходящие в ней.
В результате успешного осуществления процесса верификации:
1) определяется стратегия верификации;
2) в качестве входных данных используются ограничения, накладываемые на верификацию;
3) получаются отчетные данные, являющиеся источником для
совершения корректирующих действий;
4) предоставляются объективные доказательства того, что реализованная продукция удовлетворяет системным требованиям и
требованиям архитектурного проекта.
53
При реализации процесса верификации организация должна
осуществлять следующие действия в соответствии с принятой
политикой и процедурами:
1) определять стратегию верификации систем в течение ЖЦ;
2) определять план верификации, основываясь на системных
требованиях;
3) идентифицировать и сообщать о потенциальных ограничениях
на проектные решения;
4) подготавливать обеспечивающую систему, а также соответствующие средства, оборудование и операторов к проведению верификации;
5) осуществлять верификацию для демонстрации соответствия
заданным проектным требованиям;
6) формировать доступные верификационные данные о системе;
7) анализировать и регистрировать информацию о верификации,
отклонениях и корректирующих действиях, а также составлять
соответствующие отчеты.
2.4.7. Процесс передачи
Цель процесса передачи состоит в достижении способности обеспечивать услуги в среде функционирования согласно заданным
требованиям правообладателей.
В ходе этого процесса в соответствии с соглашениями приводится в рабочее состояние верифицированная система вместе с соответствующими обеспечивающими системами, например, операционной
системой, системой поддержки, системой обучения операторов, системой обучения пользователей.
В результате успешного осуществления процесса передачи:
1) определяется стратегия передачи;
2) система приводится в рабочее состояние на месте ее применения;
3) в процессе работы система способна выполнять свои функции;
4) конфигурация приведенной в рабочее состояние системы документируется;
5) регистрируются отчеты о корректирующих действиях;
6) обеспечивающими системами предоставляются необходимые
услуги.
В процессе передачи организация должна осуществлять следующие действия в соответствии с принятой политикой и процедурами:
1) определять стратегию передачи;
2) проводить подготовку места для размещения в соответствии
с требованиями по установке;
54
3) выполнить поставку системы в заданное место и в установленные сроки для приведения ее в рабочее состояние;
4) установить систему на рабочем месте и связать ее со средой
функционирования согласно спецификации;
5) продемонстрировать, что система установлена надлежащим
образом;
6) активизировать систему;
7) продемонстрировать способность установленной системы
выполнять требуемые функции;
8) вести документированный учет данных по установке,
включая рабочую конфигурацию, обнаруженные отклонения,
предпринятые действия и уроки, извлеченные из опыта этих
действий.
2.4.8. Процесс валидации
Цель процесса валидации заключается в получении объективных
доказательств того, что функции, обеспечиваемые системой при ее
использовании, соответствуют требованиям правообладателей.
В ходе данного процесса выполняется сравнительная оценка и
подтверждается тот факт, что требования правообладателей правильно определены. В случае обнаружения отклонений они регистрируются и корректируются. Валидация системы утверждается
правообладателями.
В результате успешного осуществления процесса валидации:
1) определяется стратегия валидации;
2) подтверждается готовность к выполнению функций, требуемых правообладателями;
3) предоставляются данные валидации;
4) составляется отчет по данным валидации, на основании которых можно осуществить корректирующие действия.
При реализации процесса валидации организация должна осуществлять следующие действия в соответствии с принятой политикой и процедурами:
1) определять стратегию валидации реализуемых системой функций в среде функционирования при условии достижения удовлетворенности правообладателей;
2) подготавливать план валидации;
3) убеждаться в готовности операторов, обеспечивающих систем
и соответствующего оборудования для проведения валидации;
4) проводить валидацию для демонстрации соответствия функциональных возможностей системы требованиям правообладателей;
55
5) приводить данные по валидации в соответствие с законодательством, регулирующими требованиями или требованиями производственного сектора;
6) согласно условиям соглашений или организационным целям
проводить валидацию с изолированием той части системы, в которой
могут возникать несоответствия;
7) анализировать, регистрировать и составлять отчеты по валидационным данным в соответствии с критериями, определенными
стратегией валидации.
2.4.9. Процесс функционирования
Цель процесса функционирования состоит в использовании системы для выполнения заданных функций.
В ходе этого процесса назначается персонал для работы в системе контроля выполнения функций и рабочих характеристик
взаимодействия в звене «оператор – система». Для поддержания
соответствующих услуг определяются и анализируются проблемы
функционирования, связанные с соглашениями, требованиями
правообладателей и организационными ограничениями.
В результате успешного осуществления процесса функционирования:
1) определяется стратегия функционирования;
2) поставляются услуги, удовлетворяющие требованиям правообладателей;
3) успешно выполняются заявки на принятые корректирующие
действия;
4) поддерживается удовлетворенность правообладателей.
При реализации процесса функционирования организация в соответствии с принятой политикой и процедурами должна осуществлять
следующие действия:
1) подготавливать стратегию функционирования;
2) получать другие услуги, относящиеся к функционированию
системы;
3) назначать на должности операторов обученный и квалифицированный персонал;
4) активизировать систему в заданных условиях функционирования для представления примеров функций или продолжения
непрерывного выполнения функций в соответствии с целевым назначением;
5) применять материалы, требуемые для поддержания необходимых услуг;
56
6) контролировать функционирование системы для подтверждения того, что система управляется в соответствии с планами работы,
в безопасном режиме и в соответствии с законодательными актами,
касающимися охраны труда и окружающей среды;
7) осуществлять мониторинг функционирования системы для
подтверждения того, что показатели выполнения функций находятся в пределах допустимых значений;
8) осуществлять действия по обнаружению отказов при появлении несоответствий в выполняемых функциях;
9) определять приемлемое направление действий, если требуется проведение корректирующих мероприятий для устранения
ошибок, появившихся в результате изменений в потребностях;
10) вводить необходимые изменения в порядок эксплуатации, среду функционирования, интерфейсы «человек-машина» и в обучение
операторов, если ошибки человека приводят к отказам;
11) постоянно или регулярно общаться с пользователями для
определения степени, с которой предоставляемые услуги удовлетворяют их потребности.
2.4.10. Процесс обслуживания
Цель процесса обслуживания состоит в поддержании способности системы выполнять заданные функции.
В ходе данного процесса контролируется способность системы
выполнять заданные функции, регистрируются проблемы для
анализа, предпринимаются действия по корректировке, адаптации, исправлению и предупреждению нарушений функционирования, а также подтверждаются возможности выполнения
функций в случае их восстановления после нарушений функционирования.
В результате успешного осуществления процесса обслуживания:
1) разрабатывается стратегия обслуживания;
2) ограничения процесса обслуживания применяются в качестве
исходных данных при формировании системных требований;
3) становятся доступными системные элементы, используемые
для замены;
4) осуществляется поддержка услуг, удовлетворяющих требования правообладателей;
5) в отчетах сообщается о необходимости корректирующих проектных изменений;
6) ведется документальный учет данных об отказах и сроках
службы.
57
При реализации процесса обслуживания организация в соответствии с принятой политикой и процедурами должна осуществлять
следующие действия:
1) подготавливать стратегию обслуживания;
2) определять ограничения системных требований, являющиеся
неизбежным следствием реализации стратегии обслуживания;
3) получать обеспечивающие системы, системные элементы и
услуги, которые должны быть использованы при обслуживании
системы;
4) составлять отчеты о проблемах и вести записи об инцидентах с целью проведения диагностики отдельных событий и учета
прошлых реализаций для поддержки последующего корректирующего, адаптирующего, совершенствующего или превентивного
обслуживания;
5) осуществлять процедуры исправления случайных неисправностей и (или) плановых замен системных элементов;
6) инициировать корректирующие действия по устранению ранее необнаруженных конструкционных ошибок;
7) подтверждать, что мероприятия по материально-техническому обеспечению удовлетворяют требуемым уровням пополнения запасов, в результате чего хранящиеся на складе системные элементы
удовлетворяют требованиям по интенсивности восстановлений и запланированным срокам проведения технического обслуживания и
ремонта;
8) осуществлять превентивное обслуживание путем замены или обслуживания системных элементов до их отказа в соответствии с планами-графиками и процедурами технического обслуживания;
9) выполнять действия по идентификации отказов при появлении
любых несоответствий в системе;
10) поддерживать составление отчетов, содержащих историю
проблемы, выполненные корректирующие действия и обнаруженные тенденции для информирования операторов и персонала технического обслуживания и ремонта, а также лиц, занятых в других проектах, в которых создаются или используются подобные
системные элементы.
2.4.11. Процесс изъятия и списания
Цель процесса изъятия и списания состоит в прекращении существования системного объекта.
В течение этого процесса происходит деактивация, демонтаж и
удаление системы и любых отходов, переход их в финальное состо58
яние, возвращение окружающей среды к начальным или приемлемым условиям. В ходе данного процесса происходит уничтожение,
сохранение или восстановление полезных свойств системного элемента и отходов экологически приемлемым способом в соответствии
с законодательством, соглашениями, организационными ограничениями и требованиями правообладателей. При необходимости
ведутся записи с целью контроля состояния здоровья операторов и
пользователей, а также безопасности окружающей среды.
В результате успешного осуществления процесса изъятия и списания:
1) определяется стратегия изъятия и списания;
2) ограничения по изъятию и списанию предоставляются в качестве входных данных для требований;
3) системные элементы уничтожаются, сохраняются, перерабатываются или восстанавливаются;
4) окружающая среда возвращается к своему первоначальному
или согласованному (с заинтересованными сторонами) состоянию;
5) обеспечивается доступ к записям о действиях по изъятию и
списанию и результатах анализа долгосрочных угроз.
При реализации процесса изъятия и списания организация в соответствии с принятой политикой и процедурами должна осуществлять следующие действия:
1) определять стратегию изъятия и списания системы, включая
каждый системный элемент и любые произведенные отходы;
2) сообщать информацию о неизбежных ограничениях на конструкцию системы, вытекающих из стратегии изъятия и списания;
3) приобретать обеспечивающие системы или получать услуги, которые будут использованы в процессе изъятия и списания системы;
4) деактивировать систему с целью ее подготовки к удалению
с места функционирования;
5) выводить оперативный персонал из системы и выполнять записи полученных им оперативных знаний;
6) расчленять систему на управляемые элементы с целью облегчения их удаления для повторного использования, переработки,
восстановления, переделки, архивирования или уничтожения;
7) удалять систему из среды функционирования для повторного использования, переработки, восстановления, переделки или
уничтожения;
8) определять средства для хранения, места хранения, критерии
для инспекций и периоды хранения, если система подлежит хранению;
59
9) при необходимости проводить уничтожение системы таким
образом, чтобы понизить объемы обработки отходов или чтобы отходы было легче перерабатывать;
10) подтверждать, что после изъятия и списания не существует вредных факторов для здоровья, безопасности, защищенности и
окружающей среды;
11) архивировать информацию, собранную в течение времени
жизни системы, для проведения аудиторских проверок и анализа
в случае, если существуют устойчивые угрозы здоровью, безопасности, защищенности и окружающей среде, а также для предоставления возможности последующим разработчикам и пользователям
систем создавать базу знаний, используя накопленный опыт.
60
3. СТАДИИ ЖИЗНЕННОГО ЦИКЛА СИСТЕМЫ
В этом разделе изложены требования для стадий ЖЦ системы
согласно ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем». Стадии ЖЦ образуют структуру работ для детализированного моделирования ЖЦ системы при использовании процессов
ЖЦ системы, представленных в разд. 2 [1, 9, 13].
3.1. Модели жизненного цикла
Должна быть создана модель ЖЦ, состоящая из стадий. Модель
ЖЦ включает одну или несколько моделей стадий в зависимости от
необходимости. Модель собирается в виде последовательности стадий, которые могут перекрываться или повторяться в зависимости
от сферы применения рассматриваемой системы, от ее размеров,
сложности, изменяющихся потребностей и возможностей. Иллюстрации стадий основаны на использовании наиболее часто встречающихся примеров стадий ЖЦ систем.
Стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств» не предлагает конкретную
модель ЖЦ и методы разработки ПО. Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и
взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики КИС и специфики
условий, в которых последняя создается и функционирует. Ее регламенты являются общими для любых моделей ЖЦ, методологий
и технологий разработки. Стандарт ИСО/МЭК 12207 описывает
структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как
реализовать или выполнить действия и задачи, включенные в эти
процессы [2, 10].
К настоящему времени наибольшее распространение получили
следующие две основные модели ЖЦ:
– каскадная модель;
– спиральная модель.
Каскадная модель. В изначально существовавших однородных
ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ.
Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на
текущем (рис.3.1). Каждый этап завершается выпуском полного
61
комплекта документации, достаточной для того, чтобы разработка
могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем:
– на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
– выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно
точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше
с технической точки зрения. В эту категорию попадают сложные
расчетные системы, системы реального времени и другие подобные
задачи. Однако в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался
в такую жесткую схему. В процессе создания КИС постоянно возникала потребность в возврате к предыдущим этапам и уточнении
или пересмотре ранее принятых решений. В результате реальный
процесс создания ПО принимал следующий вид (рис.3.2).
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к КИС «заморожены» в виде технического задания на все время ее создания.
Таким образом, пользователи могут внести свои замечания только
после того, как работа над системой будет полностью завершена.
В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают
Анализ
Проектирование
Реализация
Внедрение
Сопровождение
Рис. 3.1. Каскадная схема разработки ПО
62
Анализ
Проектирование
Реализация
Внедрение
Сопровождение
Рис. 3.2. Реальный процесс разработки ПО по каскадной схеме
КИС, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта
могут устареть одновременно с их утверждением.
Спиральная модель. Для преодоления перечисленных проблем
была предложена спиральная модель ЖЦ (рис.3.3), делающая упор
на начальные этапы ЖЦ: анализ и проектирование. На этих этапах
реализуемость технических решений проверяется путем создания
прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики
проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта, и в результате выбирается
обоснованный вариант КИС, который доводится до реализации.
Разработка итерациями отражает объективно существующий
спиральный цикл создания КИС. Неполное завершение работ
на каждом этапе позволяет переходить на следующий этап, не
дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет
выполнить на следующей итерации. Главная же задача – как
можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла – определение момента
перехода на следующий этап. Для ее решения необходимо ввести
временные ограничения на каждый из этапов жизненного цикла.
Переход осуществляется в соответствии с планом, даже если не вся
запланированная работа закончена. План составляется на основе
статистических данных, полученных в предыдущих проектах, и
личного опыта разработчиков.
63
Анализ
Определение
требований
Проектирование
Версия 1
Реализация
и тестирование
Интеграция
Версия 2
Версия 3
Рис. 3.3. Спиральная модель ЖЦ
CASE-средства. Перечисленные факторы способствовали появлению программно-технологических средств специального
класса – CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software
Engineering) используется в настоящее время в весьма широком
смысле. Первоначальное значение термина CASE, ограниченное
вопросами автоматизации разработки только лишь ПО, а в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных КИС в целом. Теперь под термином CASE-средства
понимаются программные средства, поддерживающие процессы
создания и сопровождения КИС, включая анализ и формулировку
требований, проектирование прикладного ПО (приложений) и баз
данных (БД), генерацию кода, тестирование, документирование,
обеспечение качества, конфигурационное управление и управление
проектом, а также другие процессы. Современные CASE-средства
вместе с системным ПО и техническими средствами образуют полную среду разработки КИС.
3.2. Стадии жизненного цикла
Необходимо определять цели и результаты каждой стадии ЖЦ.
Процессы и действия ЖЦ отбираются, соответствующим образом
настраиваются и используются в течение стадии ЖЦ для полного
удовлетворения целей и результатов на этой стадии. В различных
стадиях ЖЦ могут принимать участие разные организации. Тем не
менее, каждая из стадий управляется организацией, ответственной за
данную стадию, при этом должное внимание необходимо уделять рассмотрению доступной информации по планам и решениям ЖЦ, принятым на предыдущих стадиях. Аналогичным образом организация,
64
ответственная за эту стадию, ведет записи принятых решений и допущений, относящихся к последующим стадиям в данном ЖЦ.
Стадии могут применяться для построения структур, при помощи которых процессы ЖЦ используются для моделирования непосредственно ЖЦ. Масштабы и точность применения процессов
в рамках описанных стадий и с учетом их продолжительности зависят от изменяющихся технических и деловых потребностей проекта, определяющих и использующих ЖЦ.
В пособии в качестве примера приведены следующие шесть стадий ЖЦ:
1) стадия замысла;
2) стадия разработки;
3) стадия производства;
4) стадия применения;
5) стадия поддержки применения;
6) стадия прекращения применения и списания.
Рассмотрим описание каждой из этих стадий, определим их цели и результаты.
3.2.1. Стадия замысла
Данная стадия начинается с момента осознания потребности или
замысла создания новой или модификации существующей системы. Она является началом исследований, поиска фактов и периода
планирования, когда оцениваются экономические, технические,
стратегические и рыночные основы будущих действий через изучение запросов приобретающей стороны и рынка, через анализ реализуемости и поиск компромиссов. Осуществляется обратная связь
приобретающей стороны и пользователя с замыслом системы.
Одно или несколько альтернативных решений, удовлетворяющих идентифицированным потребностям или замыслу, разрабатываются посредством анализа, оценки реализуемости, выполнения
приблизительных расчетов (таких как затраты, сроки, параметры
рынка и логистики), изучения компромиссов, создания и демонстрации экспериментальных или опытных образцов. Определяется необходимость в одной или нескольких обеспечивающих системах для разработки, производства, применения, поддержки
применения и списания рассматриваемой системы. В результате
этой работы в оценку альтернатив включаются варианты решений
с целью достижения сбалансированного решения по ЖЦ системы.
Выходными результатами стадии являются требования правообладателей, концепции функционирования, оценки реализуемости,
65
предварительные системные требования, примерные проектные
решения, выраженные в форме чертежей, моделей, прототипов и
т.п., а также планы стадии замысла для обеспечивающих систем,
включая оценку стоимости всего времени их жизни, требований
к человеческим ресурсам и предварительных проектных графиков.
Принимается решение о продолжении выполнения работ на стадии
разработки или об отказе от дальнейшей работы.
Предполагается, что у организации имеются в наличии методы,
способы, инструментальные средства и компетентный персонал
для проведения анализа рынка и экономического анализа, прогнозирования, анализа реализуемости проектных решений, анализа
компромиссов, технического анализа, оценки общих затрат в течение времени жизни, моделирования, имитации или макетирования
системы.
Стадия замысла выполняется с целью оценки новых возможностей в деловой сфере, разработки предварительных системных требований и осуществимых проектных решений.
Результаты выполнения стадии замысла следующие:
1) установление новых замыслов, в которых предлагаются новые
возможности, увеличение производительности или снижение общей
стоимости собственности правообладателей в течение ЖЦ системы;
2) оценка осуществимости замысла и решений для рассматриваемой системы в течение ЖЦ, включая обеспечивающие системы,
с учетом как технических, так и деловых целей правообладателя;
3) подготовка и формирование базовой линии требований правообладателя и предварительных системных требований (технических спецификаций для выбранной рассматриваемой системы и
пригодности спецификаций для предусмотренного способа взаимодействия между человеком и системой);
4) уточнение результатов стадий в модели ЖЦ системы;
5) планы идентификации, оценки и уменьшения рисков для стадий модели ЖЦ системы;
6) идентификация и предварительная спецификация услуг, которые необходимо получать от обеспечивающих систем в течение
ЖЦ рассматриваемой системы;
7) замыслы выполнения всех последующих стадий;
8) планы и критерии завершения стадии разработки;
9) планы идентификации, оценки и уменьшения рисков для
данной и последующих стадий модели ЖЦ системы;
10) удовлетворение критерием завершения данной стадии;
11) санкционирование перехода на стадию разработки.
66
3.2.2. Стадия разработки
Стадия разработки начинается с достаточно детального технического уточнения системных требований и проектных решений,
их преобразования в один или несколько реализуемых продуктов,
которые способны выполнять заданные функции в течение стадии
использования по назначению. На этой стадии может использоваться прототип рассматриваемой системы. Соответствующим образом определяются, анализируются, проектируются, производятся, комплексируются, испытываются и оцениваются технические
и программные средства и интерфейсы операторов, определяются
требования к средствам производства, обучения и поддержки. На
стадии разработки должны даваться гарантии того, что особенности последующих стадий (производство, применение, поддержка
применения и списание), требований и возможностей обеспечивающих систем рассмотрены и учтены в проекте с привлечением
всех заинтересованных сторон. Реализуется обратная связь между
правообладателями и теми, кто будет производить, управлять, использовать, поддерживать и списывать рассматриваемую систему.
Результатом является рассматриваемая система или прототип
рассматриваемой системы в ее окончательном виде, усовершенствованные обеспечивающие системы или имеющиеся обеспечивающие системы, вся документация и оценки стоимости последующих стадий.
Планирование на стадии разработки начинается на предыдущей
стадии для гарантии того, что организация имеет в наличии или
может создать инфраструктуру систем, обеспечивающих разработку, включающих методы, технические приемы, инструментальные
средства и компетентный персонал, способный проводить анализ,
моделирование и имитацию, макетирование, конструирование,
комплексирование, тестирование и разработку документации. Эти
составляющие инфраструктуры разрабатываются или приобретаются для того, чтобы быть в наличии при необходимости поддерживать разработку.
Стадия разработки осуществляется с целью создания такой
рассматриваемой системы, которая удовлетворяет требованиям
приобретающей стороны и может быть создана, испытана, оценена, применена по назначению, поддержана при применении и
списана.
Результатами стадии разработки являются:
1) оцененные и уточненные системные требования, бюджет проекта,
базовые сроки выполнения и оценки затрат для собственника ЖЦ;
67
2) архитектура рассматриваемой системы, состоящая из элементов программных и технических средств и их интерфейсов
(внутренних и внешних);
3) документация по верификации и валидации;
4) подтверждение того, что рассматриваемая система соответствует всем требованиям правообладателей и системным требованиям, может быть запущена в производство, применяться по назначению и поддерживаться в процессе применения, а также может
переводиться в категорию непригодных к применению (списываться) и является эффективной по стоимости для правообладателей;
5) уточненные и соответствующие базовой линии требования
к обеспечивающим системам;
6) техническая информация, в том числе:
– диаграммы, чертежи и модели технических средств;
– проектная программная документация;
– спецификации интерфейсов;
– производственные планы;
– рабочие инструкции;
– руководства по тренингу операторов;
– процедуры обслуживания;
– особенности изъятия и списания;
7) прототип или непосредственно рассматриваемая система
в окончательном виде;
8) уточненные результаты и оценки затрат на стадиях производства, применения по назначению, поддержки применения, изъятия и списания;
9) определения функциональных возможностей обеспечивающих систем, требуемых на последующих стадиях ЖЦ;
10) планы и критерии завершения стадии производства;
11) идентифицированные текущие риски и определенные действия по их уменьшению;
12) соответствие критериям перехода на следующую стадию;
13) санкционирование перехода на стадию производства.
3.2.3. Стадия производства
Данная стадия начинается с принятия к производству рассматриваемой системы. Рассматриваемая система может производиться, собираться, комплексироваться и испытываться в единственном экземпляре или может быть продуктом массового производства. Планирование для этой стадии начинается на предыдущей
стадии. Производство может продолжаться на протяжении остав68
шегося периода ЖЦ. В течение данной стадии продукт может быть
улучшен или перепроектирован, обеспечивающие системы могут
нуждаться в реконфигурации, а производственный персонал в переобучении для продолжения развития экономически эффективных,
с точки зрения правообладателей, функциональных возможностей
системы.
Предполагается, что в распоряжении организации имеется производственная инфраструктура, состоящая из бюджетных средств,
производственного оборудования, инструментальных средств, процедур и компетентного персонала. Эти составляющие разрабатываются или приобретаются, чтобы быть в наличии при необходимости
обеспечить производство.
Данная стадия может пересекаться со стадиями разработки,
применения по назначению и поддержки в процессе применения.
Цель стадии производства состоит в производстве или изготовлении продукта, испытании продукта и производстве соответствующих
необходимых поддерживающих и обеспечивающих систем.
Результаты стадии производства следующие:
1) оцениваются возможности производства;
2) приобретаются ресурсы, материалы, услуги и системные
элементы для поддержки выполнения производственных заданий
в количественном выражении; 3) производится продукт в соответствии с утвержденной и оцененной информацией о производстве;
4) упакованный продукт передается в каналы распределения
или приобретающей стороне;
5) составляются планы и критерии завершения стадии применения и стадии поддержки применения;
6) формируются обновленные концепции осуществления всех
последующих стадий;
7) определяются текущие риски и действия по их уменьшению;
8) рассматриваемая система принимается приобретающей стороной с гарантированным уровнем качества;
9) удовлетворяется критерий завершения стадии производства;
10) санкционируется переход на стадию применения.
3.2.4. Стадия применения
Стадия применения начинается после установки и передачи
системы для применения по назначению. Данная стадия осуществляется с целью использования продукта в предназначенном месте
функционирования для предоставления требуемых услуг с продол69
жительной функциональной и стоимостной результативностью.
Стадия завершается, когда рассматриваемая система прекращает
предоставление услуг.
Планирование для этой стадии начинается на предшествующих
стадиях. Стадия включает процессы, относящиеся к использованию
продукта для предоставления услуг, а также мониторинг характеристик функционирования, идентификацию, классификацию и составление отчетов об отклонениях, недостатках и отказах. Ответной реакцией на обнаруженные проблемы может быть отсутствие действия;
техническое обслуживание и незначительная (с низкой стоимостью
и кратковременная) модификация (относится к стадии поддержки
применения); значительная (постоянная) модификация и продление
срока жизни рассматриваемой системы (относится к стадии разработки и производства); изъятие и списание при окончании срока жизни
(относится к стадии изъятия и списания).
В течение данной стадии продукт или услуги могут совершенствоваться, являясь, таким образом, причиной появления различных конфигураций. Пользователь оперирует различными конфигурациями, а ответственный поставщик продукции управляет статусом и описаниями различных версий и конфигураций используемых продуктов или услуг.
Предполагается, что организация имеет в своем распоряжении
рабочую инфраструктуру, включающую устройства, оборудование, обученный персонал, эксплуатационную документацию и отлаженные процедуры. Эти составляющие разрабатываются или
приобретаются для оперативной поддержки применения.
Стадия применения осуществляется для того, чтобы использовать
продукт, предоставлять услуги в заданных условиях функционирования и гарантировать продолжительную результативность.
Результаты стадии применения следующие:
1) комплектуется опытный персонал с уровнем компетенции,
необходимым для выполнения функций операторов в рассматриваемой системе и предоставления соответствующих услуг;
2) на месте применения устанавливается рассматриваемая система, способная работать и предоставлять устойчивые функциональные услуги;
3) проводится мониторинг стоимости, рабочих характеристик
и их оценка для подтверждения соответствия целям применения
системы;
4) идентифицируются проблемы или недостатки, а соответствующие организации (пользователи, разработчики, производители
70
или обслуживающие органы) информируются о необходимости
проведения корректирующих действий;
5) выявляются и анализируются новые возможности для совершенствования рассматриваемой системы через обратную связь
с правообладателем;
6) составляются планы и формируются критерии перехода на
стадию изъятия и списания;
7) фиксируется удовлетворение критерия завершения данной
стадии;
8) санкционируется переход на стадию изъятия и списания.
3.2.5. Стадия поддержки применения
Стадия поддержки применения начинается с обеспечения техническим обслуживанием и сопровождением, материально-техническим
снабжением и другими видами поддержки функционирования и использования рассматриваемой системы. Планирование для данной
стадии начинается на предшествующих стадиях. Стадия поддержки
применения завершается в момент прекращения применения и отмены поддерживающих услуг, в результате чего осуществляется переход на стадию изъятия и списания рассматриваемой системы.
Данная стадия включает процессы, относящиеся к функционированию поддерживающей системы и обеспечению поддерживающих
услуг пользователям рассматриваемой системы. Также на данной
стадии осуществляется контроль рабочих характеристик служб и системы поддержки, идентификация, классификация и составление отчетов об аномалиях, недостатках и отказах служб и системы поддержки. Действия, которые предпринимаются в результате обнаружения
проблем, включают техническое обслуживание и незначительные
модификации служб и системы поддержки, существенные модификации служб или системы поддержки (относится к стадии разработки
и производства), перевод служб и системы поддержки в категорию непригодных для использования в связи с истекшим сроком жизни (относится к стадии изъятия и списания).
В течение данной стадии службы и система поддержки могут развиваться в виде различных версий или конфигураций. Организация,
обеспечивающая поддержку, работает с этими версиями и конфигурациями, а организация, ответственная за продукт, осуществляет
управление статусом и описаниями различных версий и конфигураций служб и системы поддержки при их функционировании.
Предполагается, что организация может обеспечивать поддержку,
если она располагает участками для осуществления операций под71
держки, устройствами, оборудованием и инструментами, обученным
персоналом, инструкциями и процедурами по техническому обслуживанию и текущему ремонту. Составные части инфраструктуры
поддержки разрабатываются и приобретаются для оперативной поддержки функционирования рассматриваемой системы.
Стадия поддержки применения используется для осуществления материально-технического снабжения, технического обслуживания и текущего ремонта, которые обеспечивают непрерывное
функционирование рассматриваемой системы и устойчивое предоставление услуг, поддерживающих ее применение.
Результаты стадии поддержки применения следующие:
1) комплектуется обученный персонал, который будет обслуживать и обеспечивать работу служб поддержки;
2) налаживаются организационные интерфейсы с техническими и
производственными организациями, обеспечивающими гарантированное решение проблем и проведение корректирующих действий;
3) проводится обслуживание и предоставляются услуги, обеспечивающие все соответствующие службы поддержки (включая материально-техническое снабжение) на рабочих местах;
4) обеспечивается поддержка функционирования рассматриваемой системы, ее составных частей и предоставляемых ею услуг,
исправляются недостатки, допущенные при проектировании;
5) обеспечивается поддержка всего необходимого материальнотехнического снабжения, в том числе запасными частями в количестве, которое требуется для достижения целей эксплуатационной готовности;
6) определяются текущие риски и предпринимаются действия
для их уменьшения;
7) заключается соглашение об окончании функционирования
служб поддержки;
8) устанавливается соответствие критерию завершения стадии.
3.2.6. Стадия изъятия и списания
Стадия изъятия и списания обеспечивает ликвидацию рассматриваемой системы и связанных с нею эксплуатационных и поддерживающих служб. Планирование для стадии изъятия и списания
начинается на предыдущих стадиях. Данная стадия начинается
в момент снятия рассматриваемой системы с обслуживания.
Стадия изъятия и списания включает процессы, которые относятся к функционированию списываемой системы, а также включает мониторинг ее рабочих характеристик, определение, классификацию и
72
составление отчетов об аномалиях, дефектах и отказах списываемой
системы. Действия, предпринимаемые в результате обнаружения
проблем, включают обслуживание и незначительные модификации
списываемой системы (относятся к стадии поддержки применения),
значительные модификации списываемой системы (относятся к стадии разработки и производства), изъятие и списание системы по причине окончания срока жизни (относится к данной стадии).
Предполагается, что организация имеет доступ к инфраструктуре для поддержки изъятия и списания, включая средства, инструменты, оборудование и персонал, обученный соответствующим
действиям и процедурам, и, при необходимости, доступ к средствам переработки, удаления или сохранения. Составляющие инфраструктуры списания разрабатываются или приобретаются для
оперативного выполнения функции списания.
Данная стадия применяется, когда заканчивается срок выполнения функций рассматриваемой системы. Окончание этого срока может наступить вследствие замещения новой системой, невосстанавливаемого износа, катастрофического отказа, утраты интереса со стороны пользователя или в случае, когда продолжение применения и
поддержки рассматриваемой системы экономически неэффективно.
Стадия изъятия и списания осуществляется с целью обеспечить
удаление рассматриваемой системы и связанных с нею обслуживающих и поддерживающих служб из среды применения, непосредственно оперировать самой списываемой системой и поддерживать
процесс ее изъятия и списания.
Результаты стадии изъятия и списания следующие:
1) комплектуется опытный персонал, способный обеспечить выполнение функций изъятия и списания;
2) прекращается применение рассматриваемой системы, включая ее удаление, обновление или переработку в соответствии с законодательством в области здравоохранения, безопасности, защиты,
сохранения тайны и охраны окружающей среды;
3) формируются планы и процедуры передачи функций новой
рассматриваемой системе (если это приемлемо);
4) удаляются отходы;
5) окружающая среда возвращается к первоначальному или согласованному состоянию;
6) обеспечивается архивирование элементов;
7) проводится перемещение, перевод или увольнение операторов;
8) констатируется удовлетворение критерия завершения стадии
изъятия и списания.
73
4. ПРИМЕНЕНИЕ СИСТЕМНОЙ ИНЖЕНЕРИИ
ДЛЯ РЕАЛИЗАЦИИ СОВРЕМЕННЫХ КОРПОРАТИВНЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ
В разделе дается краткий исторический экскурс эволюционного
развития КИС, приводится методология их разработки и обсуждаются основные международные стандарты.
4.1. Краткий исторический обзор развития КИС
Периоды развития взглядов с точки зрения СИ на функции КИС
и характерные названия типов систем в рамках каждого периода
показаны на рис.4.1. В дальнейшем рассмотрим каждый тип систем подробнее. Следует отметить, что КИС любого типа включает
в себя системы более ранних типов. Это значит, что системы всех
типов мирно сосуществуют и ныне [6, 7, 14, 16].
Рассмотрим с позиций СИ основные этапы становления информационных систем (ИС) вообще и этапы развития КИС в частности.
Сложность
CSRP
ERP
MRPII
MRP
Планирование:
– материальных
потребностей
Планирование – продаж и
материальных производства
– потребностей
потребностей
в ресурсах
(Material
Requirements
Planning)
(Manufacturing
Resources
PlanningII)
Управление:
– материальными и
финансовыми
ресурсами
– закупками и
сбытом
– заказами и
поставками
– кадрами
– основными
фондами
– складами
(Enterprise
Resources
Planning)
ERP
+
Процессы внешнего
и внутреннего
сотрудничества
предприятия
Операционные и
финансовые
процессы
(Customer
Synchronized
Resources
Planning)
Время
Рис. 4.1. Эволюция корпоративных информационных систем
74
В традиционном понимании ИС – это системы обработки данных о какой-либо предметной области со средствами накопления,
хранения, обновления, поиска и выдачи данных. По выполняемым
функциям выделяют информационно-поисковые системы, управляющие, моделирующие, обучающие и многие другие, которые
широко применяются во всех отраслях современного производства
и управления.
Рассматривая диапазон возможных значений слов «информация» и «система» можно предложить ряд более широких толкований
термина «ИС». Можно считать, что он относится ко всем автоматизированным системам или, в еще более широком смысле, ко многим системам, в состав которых входят ЭВМ.
Информационные системы предназначены для решения задач
обработки данных (Data Processing), автоматизации офисных работ
(Office Automation), а также задач, характерных для экспертных
систем. Системы, основной функцией которых является информационное обеспечение процесса управления, называются управляющими ИС (Management Information System). Трудности разработки
ИС обусловлены следующими их особенностями:
а) среда, в которой работают ИС, весьма сложна, не полностью
определена и с трудом поддается моделированию;
б) системы имеют сложное сопряжение со средой, выполняющей множество входных и выходных целей;
в) функциональные взаимосвязи входных и выходных сигналов
сложны в структурном, а иногда и в алгоритмическом отношении;
г) обычно включают в себя большие и сложные базы данных
(БД) и базы знаний (БЗ));
д) организации-заказчики весьма заинтересованы в постоянной
и продолжительной работоспособности ИС, причем сроки первоначального ввода их в эксплуатацию и последующих модернизаций
устанавливаются крайне сжатыми.
Анализ определений и подходов к понятию «информационная
система» показывает, что это понятие является чрезвычайно широким, охватывающим весьма различные классы систем. Поэтому
авторы этой книги хотят сосредоточить свое внимание на более узком классе ИС – «информационно-управляющих системах» (ИУС),
в основном, корпоративного типа, функционирующих на предприятиях или в структурах организационного управления.
Начало практической реализации концепции ИУС (единое информационное пространство, однократный ввод и многократное
использование информации, уменьшение количества бумажных
75
документов и дублирования информации в них, автоматические
бухгалтерские проводки и т.д.) стало возможным только с появлением компьютеров третьего поколения с такими базовыми элементами как средства хранения информации большого объема и
средства интерактивного доступа к хранимой информации. Такие
средства появились в начале 70-х гг. с выходом на рынок системы
IBM/360. Поскольку эти средства стоили дорого, реализацию ИУС
могли позволить себе только крупные предприятия.
В ИУС первого поколения практически все программное обеспечение было создано на самих предприятиях и было приспособлено
либо к конкретному предприятию, либо к узкому кругу родственных компаний и требовало значительных трудозатрат на поддержку силами высококлассных программистов.
Дальнейшая эволюция ИУС была связана прежде всего с совершенствованием инструмента, обеспечивающего уменьшение трудозатрат на создание и сопровождение ИУС путем углубления специализации, стандартизации и кооперации, а также с появлением новых
средств хранения, переработки и передачи информации. В конце
70-х – начале 80-х гг. появились фирмы, специализирующиеся
на разработке и внедрении ИУС. Естественно, вперед вырвались
те, которые использовали типовые бизнес-модели, пригодные для
широкого круга предприятий. К этому времени уже существовали
методологические проработки таких моделей, а базовой моделью
для ИУС второго, третьего и четвертого поколений стало направление MRP (Material Requirements Planning) – MRPII (Manufacturing
Resource Planning) – ERP (Enterprise Resource Planning).
В основе методологии MRP лежат следующие основные положения:
– фундаментом таких систем является полная инвентаризация
всех видов ресурсов предприятия в «едином информационном пространстве» c обеспечением автоматической поддержки «уникальных идентификаторов» для всех элементов и их использованием во
всех подсистемах ИУС;
– все виды регистрации хозяйственных операций максимально
приближаются к местам их возникновения и обязательно используют общую БД инвентаризации с уникальными идентификаторами;
– базовые понятия в MRP-системах обобщаются и типизируются для любого предприятия (рабочие центры, запасы, центры затрат, маршруты, операции, планирование мощностей и т.п.);
– разработана типовая методология согласования планов и отчетов разных уровней от предприятия и до участков производства;
76
– MRP-системы унаследовали функциональные возможности
ИУС первого поколения, например автоматическое формирование
бухгалтерских проводок.
Каждый производитель систем класса MRP использовал в основном собственные средства поддержки БД и собственные средства разработки приложений. Впоследствии некоторые начали
использовать и появившиеся коммерческие иерархические и сетевые СУБД. В Советском Союзе в 80-х годах также активно велись
методологические работы по типизации и стандартизации методов
разработки АСУ. Существовавшие в то время АСУ автоматизировали лишь часть функций управления производственными системами, поэтому и была поставлена задача перехода к интегрированным
системам управления (ИАСУ), которые должны были на основе совершенствования организационных структур управления, рационального использования вычислительных ресурсов и увеличения
числа решаемых оптимизационных задач обеспечить интегральную
автоматизацию производства на всех уровнях управления, автоматизировать проектирование АСУ на базе унификации и типизации
проектных решений.
Типовые проектные решения (ТПР) делились на три уровня реализации: элементные – ориентированные на решение отдельных
задач и функций управления; подсистемные – охватывающие комплекс задач, связанных по функциональному или производственному
принципу, системные – включающие типовые проекты АСУ.
Многие полученные в то время результаты и разработанные
интегрированные АСУ опирались на серьезный научный фундамент и по качеству технических решений не уступали зарубежным аналогам. Но в условиях жесткого централизованного
управления предприятиями, технического отставания средств
отечественной вычислительной техники не мог сформироваться
рынок ИС и не произошло массового перехода предприятий к подлинным интегрированным АСУ.
В конце 80-х начали появляться производители нового поколения MRP- систем, чему способствовали следующие предпосылки:
– появились компании, специализирующиеся на создании типовых реляционных СУБД и началось бурное развитие соответствующих средств разработки; при этом появилось некоторое количество
коммерческих продуктов ведущих компаний;
– произошел спад интереса к мэйнфреймам при одновременном
расцвете открытых систем на основе UNIX, TCP/IP и технологии
клиент/сервер.
77
Новые поставщики MRP/ERP-систем начали использовать появившиеся на рынке коммерческие реляционные СУБД (естественно при этом был сделан акцент на новый уровень открытости и
стандартизации технологии клиент/сервер). Это позволяло новым
поставщикам, с одной стороны, не тратить ресурсы на собственные
инструментальные средства, а с другой, оперативно отслеживать
и использовать новые достижения информационных технологий.
Пользователям при внедрении новых систем не требовалось дополнительно изучать новые инструментальные средства, отличные от
стандартно поставляемых на рынок.
Ведущие поставщики MRP/ERP-систем второго поколения
(например, фирмы CA, SAP) и ряд новых производителей (например, фирмы BAAN, ICL) также начали переходить на технологию
клиент/cервер, но использовали собственные средства разработки.
При этом, с одной стороны, они могли применять СУБД нескольких фирм (Oracle, Informix, Sybase, Ingres), но с другой – им было
гораздо труднее воспользоваться новыми возможностями очередных версий СУБД.
Системы управления отношений с заказчиками CRM (Customer
Relationship Management) обычно являются внутренними приложениями систем ERP. Целью CRM-систем является предоставление точной оперативной информации о заказчиках и выработка на
ее основе стратегии управления ресурсами предприятия. В подмножество CRM-систем входят системы автоматизации «мощностей продаж» SFA (Sales Force Automation), задача которых – предоставление
отделам сбыта в онлайновом режиме свежей информации о клиентах,
ассортименте товара, договорах, поставках и т.д. (со всеми необходимыми документами). Компонентами систем SFA могут служить так
называемые системы электронной коммерции (E-Purchasing), отвечающие только за сбор заявок от заказчиков.
Если процессы закупки товаров выходят за рамки одного предприятия и охватывают также его поставщиков (логистическую
цепочку), то возникают так называемые отношения Business-toBusiness (B2B). В качестве среды передачи информации между
предприятиями чаще всего используется глобальная сеть Internet,
а взаимодействие различных программных систем предприятий
обеспечивается связующим программным обеспечением промежуточного слоя.
Системы SCM (Supply Chain Management) обеспечивают управление расширенной производственной цепочкой, т.е. управление
не только внутренними ресурсами предприятия, но и важнейшими
78
внешними (например, учет заказчиков и поставщиков). SCM-системы
реализует новейшую технологию управления, описываемую стандартом CSRP (Customer Synchronized Resource Planing), который предполагает наличие в системе возможностей по управлению внешними по отношению к предприятию элементами производственной
цепочки. Целью стандарта является управление полным циклом
выпуска продукции.
К четвертому поколению ИУС (с точки зрения использования
новых инструментальных средств и дальнейшей специализации)
можно отнести системы со следующими характеристиками:
– активное использование типовых процедур и функций, выполняемых на уровне СУБД;
– использование CASE-средств для поддержки программных
систем на всех этапах жизненного цикла ERP-системы;
– применение стандартных средств графического пользовательского интерфейса (в том числе и Web-технологии);
– выделение в подсистемы и типизация аналитических средств
поддержки принятия решений по технологии Data Warehouse,
OLAP-поддержка библиотек типовых бизнес-функций для удобства
их реорганизации в процессе эксплуатации.
Информационно-управляющие системы четвертого поколения
получили название КИС, так как в 90-е годы концепция традиционных автоматизированных систем управления (АСУ, АСУП, ИАСУ)
претерпела существенные изменения.
Таким образом, с позиций СИ современные КИС явились результатом эволюционного развития автоматизированных систем
управления предприятием. Новые экономические условия привели
к изменению задач управления предприятиями, поэтому возникли
и новые требования к автоматизированным информационным системам, главными из которых являются:
– повышение качества управления за счёт более оперативного
и полного использования информации о ходе производственного
процесса, о материальных, финансовых, энергетических потоках,
о запасах сырья и материалов;
– определение и эффективное использование комплексных показателей в системах управленческого и бухгалтерского учёта, улучшающих информационное обеспечение оперативного управления;
– наличие комплексной системы управления финансовым состоянием предприятия, объединённой с информационными БД;
– наличие единого информационного пространства всего предприятия, в состав которого входят фактографические БД, пред79
метно-ориентированные хранилища данных, позволяющие использовать всю накопленную информацию для принятия управленческих решений.
Современная КИС – это «человеко-машинная» система, которая
непосредственно осуществляет организационные, управленческие
и производственные функции предприятия [14, 15, 17].
Для того чтобы оперативно и обоснованно выработать правильное
управляющее воздействие, руководству необходим более глубокий
управленческий учёт с точки зрения управления подразделением и
предприятием в целом. Управленческий учёт позволяет анализировать внутренние производственные и хозяйственные операции
более точно, оперативно, вплоть до масштаба реального времени,
определять издержки всего предприятия.
Корпоративные информационные системы – как западные, так
и российские – различаются принципами построения, набором реализованных функций, инструментальными средствами проектирования, способами настройки параметров.
К общим тенденциям создания и развития КИС можно отнести
следующие:
– организация или реорганизация бизнес - процессов;
– разработка системного проекта КИС, ориентированной на поддержку рациональных бизнес-процессов;
– наличие фактически стандартного набора функциональных
подсистем;
– переход на архитектуру «клиент/сервер» как более эффективную и перспективную;
– широкое использование в качестве основы их функционирования мощных универсальных СУБД.
В результате анализа разработок КИС следует выделить типовой
набор основных функциональных подсистем, который охватывает основные сферы и уровни управления предприятием, включая
в себя полный комплекс информационных процессов – от учёта выработки на рабочем месте производственного участка до расчёта и
предоставления экономических показателей руководству в целях
принятия решений.
Наиболее типичный состав подсистем КИС промышленного предприятия и их функций выглядит следующим образом
(табл.4.1).
Одним из новых уровней специализации в КИС стало выделение
автономных типовых средств OLAP (On Line Analytical Processing).
Ранее аналитические функции типа принятия решений включались
80
Таблица 4.1
Типичный состав подсистем КИС и их функций
Подсистема
Функции
ПЛАНИРОВАНИЕ
Маркетинг
Определение потребностей в ресурсах и материалах
Планирование производственных мощностей
Ценообразование
Проектирование
Составление бюджетов
АНАЛИЗ
Определение показателей деятельности предприятия
Создание пультов управления
ФИНАНСЫ
Ведение расчётного счёта
Выполнение кассовых операций
Отслеживание денежных потоков
Ведение платёжных календарей
Составление финансового плана
БУХГАЛТЕРИЯ
Ведение главной книги
Бухгалтерия дебиторов
Бухгалтерия кредиторов
Учёт основных средств
Материальный учёт
Начисление заработной платы
Распределение затрат
Ведение отчётности
ПРОИЗВОДСТВО
Учёт выпуска продукции
Оперативное планирование
ТЕХОБСЛУЖИВАНИЕ
Планирование ремонта оборудования
Управление заказами на ремонт
ЗАПАСЫ
Складской учёт
Учёт закупки сырья и комплектующих
СБЫТ
Учёт заказов
Планирование и учёт отгрузки
Фактурирование
КАЧЕСТВО
Отслеживание качества продукции
Ведение статистического учёта
Анализ качества
ПЕРСОНАЛ
Ведение штатного расписания
Определение штатной расстановки
Отслеживание приёма – увольнения персонала
Ведение личных дел
81
Окончание табл. 4.1
Подсистема
Функции
Учёт рабочего времени
Определение затрат на персонал
Составление отчётов
ДИЛЕРСКАЯ СЕТЬ
Планирование дилерской сети
Контроль за работой дилеров
Ведение статистического учёта
Анализ деятельности дилеров
в MRP/ERP-приложения на уровне модулей. Новые OLAP-продукты
реализовались уже на уровне инструментальных средств.
Характерной особенностью новых OLAP-средств является возможность использовать данные из разных систем (разного типа
MRP/ERP-модулей или из собственных систем предприятий), которые могут быть реализованы в различных СУБД. Наряду с появлением новых фирм-поставщиков, сразу ориентированных на
новые средства, важную роль на рынке ERP систем четвертого поколения начали играть производители систем третьего поколения,
которые естественно следовали за эволюцией инструментальных
средств ведущих поставщиков.
Из перечисленных основных типовых решений КИС поставщики
MRP/ERP систем, ориентированные на собственные нестандартные
средства, использовали в основном средства OLAP, которые могли
быть взяты из других фирм. Что касается таких новых возможностей, как улучшение логической структуры системы за счет переноса поддержки ограничений целостности БД и типовых программ на
уровень СУБД, а также поддержки электронного проекта системы
CASE-средствами, то их использование было принципиально ограничено – требовалась значительная переделка собственных средств.
Кроме того, над поставщиками довлела необходимость поддержки
уже внедренных MRP/ERP-систем старого образца, количество которых значительно превышало долю систем нового поколения.
С точки зрения СИ необходимость создания и внедрения КИС
обусловлена тем, что:
– КИС стали необходимым средством успешного функционирования современного предприятия в условиях рынка, так как резко
возросли потребности в оперативной информации, требуется высокая приспособляемость к изменяющимся условиям внутри и вне
предприятия;
82
– происходит переход к единому информационному пространству предприятий, распределенных корпораций и агентов.
В настоящее время на российских предприятиях используются
системы типа ERP и SCM.
Системы ERP (Enterprise Resource Planning) обеспечивают
управление всеми ресурсами предприятия (производственными
ресурсами, финансовыми ресурсами, заказами и т.д.) и являются
фактическим стандартом современных интегрированных производственных систем управления.
Главная задача ERP-систем – добиться оптимизации (по времени и ресурсам) всех перечисленных процессов. Довольно часто вся
присущая концепции ERP совокупность задач реализуется не одной
интегрированной системой, а некоторым комплектом ПО. В основе
такого комплекта, как правило, лежит базовый ERP-пакет, к которому через соответствующие интерфейсы подключены специализированные продукты третьих фирм (отвечающие за электронную
коммерцию, OLAP, автоматизацию продаж и др.).
Системы SCM (Supply Chain Management) обеспечивают управление расширенной производственной цепочкой, т.е. управление
не только внутренними ресурсами предприятия, но и важнейшими
внешними (например, учет заказчиков и поставщиков). Системы
SCM реализуют новейшую технологию управления, описываемую
стандартом CSRP (Customer Synchronized Resource Planning), который предполагает наличие в системе возможностей по управлению
внешними по отношению к предприятию элементами производственной цепочки. Целью стандарта является управление полным
циклом выпуска продукции от проектирования до гарантийного и
сервисного обслуживания после продажи.
С точки зрения базовых принципов, заложенных в разработку
представленных на российском рынке программных продуктов,
можно выделить два направления их разработки и развития:
– первое направление берет свое начало от автоматизации учетных бухгалтерских функций, что было актуально в конце 80-х гг. и
позволяло без больших затрат создавать коммерческие продукты;
“Интегрированная система управления” создавалась путем постепенной разработки и подключения новых модулей к системе автоматизации бухгалтерии;
– второе направление основано на автоматизации производственных функций; новые модули системы интегрировались с производственным ядром “естественным путем”, исходя из необходимости обеспечения производства материалами, компонентами, оборудованием,
83
финансами, заказами и т.д. Финансовый учет и финансовый анализ
является логичным завершением интегрированного решения всех задач при управлении производственным предприятием.
Основное отличие представленных на российском рынке интегрированных систем управления предприятием заключается в том,
что одни из них созданы с учетом требований стандарта ERP, а другие
не отвечают этим требованиям.
К продуктам первого направления относятся практически все
российские системы управления предприятием и некоторые западные системы, которые разрабатывались исходя из автоматизации
финансовых функций («Галактика», «Парус», «Босс», ACPlus,
V-Trad5). Объединение различных модулей в системе, спроектированной “в обратном порядке”, не позволяет обеспечить подлинную
интеграцию в соответствии со стандартом ERP.
Продуктов второго направления на российском рынке меньше.
К ним относятся такие известные системы, как SAP/R3, Baan, Oracle
Applications, Renaissance CS, Platinum, Axapta и некоторые другие.
Причины одновременного существования систем двух направлений заключаются в следующем:
– объективно существует множество предприятий, которым
требуется автоматизация ограниченного числа функций, например, финансово-учетных; производственные функции либо вообще
отсутствуют, либо не отличаются сложностью;
– отсутствие у разработчиков средств, достаточных для создания
интегрированной производственной системы современного уровня;
– высокие затраты на покупку и внедрение производственных
систем ERP-класса;
– непонимание руководителями предприятий того, что внедрение современной интегрированной производственной системы имеет не меньшее значение, чем покупка новой автоматической линии
или строительство нового цеха;
– отсутствие у предприятий средств, достаточных для закупки и
внедрения интегрированных производственных систем;
– отсутствие у предприятий детального представления о том,
как они действительно работают и непонимание существенных отличий одних систем от других.
В первую очередь среди всех информационных систем выделим
два класса:
– системы, созданные в соответствии с требованиями стандарта
ERP (ERP-системы);
– системы, не соответствующие требованиям ERP.
84
Для каждого из этих классов, в свою очередь, можно выделить несколько категорий, аналогичных классификации Deloitte & Touche,
когда все автоматизированные информационные системы, представленные на рынке в России, могут быть разделены на четыре
группы: локальные, малые интегрированные, средние интегрированные и крупные интегрированные.
При выборе КИС первым решением, которое должен принять
руководитель, является решение о том, какого класса система ему
необходима. Это решение зависит от размера компании, характера ее деятельности и ее возможностей. Например, экономически
не оправдано применение ERP-систем для небольших предприятий,
компаний и организаций, которые имеют простой производственный
процесс, несложную организационную структуру; консервативны
к изменениям.
Для автоматизации управления такими компаниями, как правило, успешно используются локальные или малые системы не
ERP-класса.
Предприятия (крупные и средние), для которых первоочередное
значение имеет управление производством, фактически не имеют
альтернативы ERP-системам. Настоящая интегрируемость, четкая
производственная ориентация дают возможность организовать эффективное управление предприятием. Выбор конкретной системы
управления необходимо выполнять внутри ERP класса.
Для небольших, но развивающихся компаний также эффективно
использование ERP-систем. В этом случае, по мере открытия новых
направлений деятельности, предприятия не будут иметь проблем
с интеграцией автоматизированной системы.
За последние годы со стороны основных производителей корпоративных систем (SAP, Baan, PeopleSoft и Oraclе) наметилась тенденция
к формированию массового рынка ERP-систем, ориентированного
помимо гигантских корпораций на средние предприятия. Существуют также ERP системы (iRenaissancе), специально разработанные для автоматизации средних и малых производственных предприятий.
В последнее время российские IT-компании создают достаточно
эффективные продукты для автоматизации средних и малых производственных предприятий, так например, получает широкое
распространение система «1С: Предприятие».
Кроме того, на практике уже сейчас наблюдается широкое применение отдельных модулей и групп модулей ERP-систем для
управления непроизводственными компаниями и организациями
85
в областях здравоохранения, энергетики, транспорта, для общественных, учебных организаций, дистрибьюторских и некоторых
других компаний.
С точки зрения концепции СИ можно прогнозировать в ближайшее время рост интереса со стороны крупных, средних и малых
российских предприятий к ERP-системам. В этих условиях актуальными становятся проблемы выбора конкретной ERP-системы и
разработки новых систем такого класса, учитывающих специфику
современного российского производства.
4.2. Основы методологии MRP
Рассмотрим методологические основы реализации концепций СИ
на примерах разработки и внедрения КИС. Как уже отмечалось, любая производственная компания, в том числе и корпорация, борется
за конкурентоспособность своих товаров на рынке. Основными целями производственных компаний для получения прибыли являются:
– снижение реальной себестоимости продукции;
– повышение производительности производства за счет эффективного планирования производственных мощностей и ресурсов.
С начала 70-х гг., когда появилась возможность хранения и анализа больших объемов информации, стала развиваться отрасль разработки ПО для предприятий. Задача планирования потребностей
в материалах (Materials Requirements Planning, MRP) оказалась
той первой задачей, которая привела к созданию целой индустрии
ПО для управления предприятием.
Решение задачи планирования потребностей в материалах
реализуется с помощью алгоритма, который называется MRPалгоритмом. MRP-алгоритм – это алгоритм оптимального управления заказами на готовую продукцию, производством и запасами
сырья и материалов, а MRP-методология – это идеологическая
основа реализация MRP-алгоритма с помощью компьютерной системы [4, 14].
Реализация ИС, работающей по этой методологии, представляет собой комплекс ПО, позволяющий оптимально регулировать
поставки комплектующих в производственный процесс, контролируя запасы на складе и саму технологию производства. Главной
задачей MRP-системы является обеспечение гарантии наличия необходимого количества требуемых материалов и комплектующих
в любой момент времени в рамках срока планирования, наряду
с возможным уменьшением постоянных запасов, а следовательно,
разгрузкой склада.
86
В настоящее время MRP-системы присутствуют практически
во всех интегрированных информационных системах управления
предприятием.
Если предприятие имеет процессное производство (Process
Industry, Continuous-Batch Processing), то применение MRPметодологии оправдано в случае длительного производственного
цикла. MRP-системы редко используются для планирования материальных потребностей в сервисных, транспортных, торговых и
других организациях непроизводственного профиля, хотя потенциально идеи MRP-систем могут быть с некоторыми допущениями
применены и для непроизводственных предприятий, деятельность
которых требует планирования материалов в относительно длительном интервале времени.
MRP-системы базируются на планировании материалов для оптимальной организации производства и включают непосредственно функциональность MRP, функциональность по описанию и планированию загрузки производственных мощностей CRP (Capacity
Resources Planning) и имеют своей целью создание оптимальных
условий для реализации производственного плана выпуска продукции.
Рассмотрим структуру MRP-системы и используемую терминологию.
Материалы – все сырье и отдельные комплектующие, составляющие конечный продукт. В дальнейшем мы не будем делать различий
между понятиями «материал» и «комплектующий».
MRP-система, MRP-программа – компьютерная программа,
работающая по MRP-алгоритму.
Статус материала – указатель на текущее состояние материала.
Каждый отдельный материал, в каждый момент времени, имеет
статус в рамках MRP-системы, например:
– материал есть в наличии на складе,
– материал есть на складе, но зарезервирован для других целей,
– материал присутствует в текущих заказах,
– заказ на материал планируется.
Как видно, статус материала отражает степень готовности этого
материала быть пущенным в производственный процесс.
Страховой запас материала необходим для поддержания процесса производства в случае возникновения непредвиденных и неустранимых задержек в его поставках. По сути, в идеальном случае,
если механизм поставок полагать безупречным, MRP-методология
не постулирует обязательного наличия страхового запаса, и его
87
объемы устанавливаются различными для каждого конкретного
случая, в зависимости от сложившейся ситуации с поступлением
материалов. Подробней об этом будет рассказано далее.
Потребность в материале в MRP-программе представляет собой
определенную количественную единицу, отображающую возникшую в некоторый момент времени в течение периода планирования
необходимость в заказе данного материала.
Различают понятия полной потребности в материале, которая
отображает то количество, которое требуется пустить в производство, и чистой потребности, при вычислении которой учитывается
наличие всех страховых и зарезервированных запасов данного материала. Заказ в системе автоматически создается по возникновению
отличной от нуля чистой потребности.
Формула вычисления чистой потребности такова:
«Чистая потребность = полная потребность –  инвентаризовано на
руках –  страховой запас –  зарезервировано для других заказов».
Концептуально с позиций кибернетики MRP-систему можно
рассматривать как «черный ящик». Основные элементы MRPсистемы можно разделить на элементы, предоставляющие информацию, программную реализацию алгоритмической основы MRPметодологии, и элементы, представляющие результат функционирования программной реализации MRP-системы.
Входными данными MRP-системы являются следующие.
Программа производства (Master Production Schedule (MPS)).
Основной производственный план-график (ООП), как правило,
формируется для пополнения запаса готовой продукции или удовлетворения заказов потребителей. На практике разработка ОПП
представляется петлей планирования. Первоначально формируется
черновой вариант для оценки возможности обеспечения реализации
по материальным ресурсам и мощностям. Система MRP осуществляет детализацию ОПП в разрезе материальных составляющих. Если
необходимая номенклатура и ее количественный состав не присутствует в свободном или заказанном ранее запасе или в случае неудовлетворительных по времени планируемых поставок материалов
и комплектующих, ОПП должен быть соответствующим образом
скорректирован. После проведения необходимых итераций ОПП утверждается как действующий и на его основе осуществляется запуск
производственных заказов.
Перечень составляющих конечного продукта (Bill Of Materials
(BOM)). Ведомость материалов (ВМ) и состав изделия представляет
88
собой номенклатурный перечень материалов и их количество для
производства некоторого узла или конечного изделия. Совместно
с составом изделия ВМ обеспечивает формирование полного перечня готовой продукции, количество материалов и комплектующих
для каждого изделия и описание структуры изделия (узлы, детали,
комплектующие, материалы и их взаимосвязи). Ведомость материалов и состав изделия представляют собой таблицы БД, информация которых корректно отражает соответствующие данные, при
изменении физического состава изделия или ВМ состояние таблиц
должно быть своевременно скорректировано.
Описание состояния материалов (состояние запасов, Stock/
Requirement List). Текущее состояние запасов отражается в соответствующих таблицах БД с указанием всех необходимых характеристик учетных единиц. Каждая учетная единица, вне зависимости от вариантов ее использования в одном изделии или многих
готовых изделиях, должна иметь только одну идентифицирующую
запись с уникальным кодом. Как правило, идентификационная запись учетной единицы содержит большое количество параметров и
характеристик, используемых MRP-системой.
Выходные данные MRP-системы
Выходными данными MRP-системы являются следующие.
План-график снабжения материальными ресурсами производства – количество каждой учетной единицы материалов и комплектующих для каждого периода времени для обеспечения ОПП.
Для реализации плана-графика снабжения система порождает план-график заказов в привязке к периодам времени, который
используется для размещения заказов поставщикам материалов и
комплектующих или для планирования самостоятельного изготовления.
Кроме того, на выходе MRP-системы имеются изменения планаграфика снабжения ( внесение корректировок в ранее сформированный план-график снабжения производства) и ряд отчетов, необходимых для управления процессом снабжения производства.
Одной из составляющих интегрированных информационных
систем управления предприятием класса MRP является система
планирования производственных мощностей, основной задачей
которой является проверка выполнимости ОПП с точки зрения
загрузки оборудования по производственным технологическим
маршрутам с учетом времени переналадки, вынужденных простоев, субподрядных работ и т.д. Входными данными для системы
89
планирования являются план-график производственных заказов
и заказов на поставку материалов и комплектующих, а выходными
данными – график загрузки оборудования и рабочего персонала.
4.3. Системы стандарта MRPII
После появления концепции MRP, казалось бы, все основные проблемы производства были решены, активно создавались и продавались компьютерные программы, реализующие ее нехитрые принципы. Однако в процессе дальнейшего анализа существующей ситуации
в мировом бизнесе и ее развития, выяснилось, что все большую составляющую себестоимости продукции занимают затраты, напрямую не
связанные с процессом и объемом производства. В связи с растущей от
года к году конкуренцией, конечные потребители продукции становятся все более “избалованными”, ощутимо увеличиваются затраты
на рекламу и маркетинг, уменьшается жизненный цикл изделий. Всё
это требует пересмотра взглядов на планирование коммерческой деятельности. Отныне нужно не “что-то производить и стараться потом
продать”, а “стараться производить, то, что продается”. Таким образом, маркетинг и планирование продаж должны быть непосредственно
связаны с планированием производства. Исходя из этих предпосылок и
зародилась новая концепция корпоративного планирования.
Рассмотрим концепцию систем класса MRPII (Manufacturing
Resource Planning) [4, 14, 21].
Очевидно, на любом производственном предприятии существует
набор стандартных принципов планирования, контроля и управления функциональными элементами. Такими элементами являются
производственные цеха, функциональные отделы, аппарат руководства и т.д. Давайте на основании этих принципов попытаемся
создать замкнутую логическую систему, которая позволяет отвечать на следующие тривиальные вопросы: «Что мы собираемся
производить?» «Что для этого нужно?» «Что мы имеем в данный
момент?» «Что мы должны получить в итоге?»
На эти, на первый взгляд, простые вопросы всегда должны иметь
ясные ответы для руководящего состава любого коммерческого
(производственного и непроизводственного) предприятия. Одной
из основ эффективной деятельности любого предприятия является
правильно поставленная система планирования. Собственно, она и
призвана содействовать ответам на эти вопросы.
Эта система планирования должна чётко отвечать на вопрос:
«Что нам конкретно нужно в тот или иной момент времени в будущем?» Для этого она должна планировать потребности в матери90
але, производственные мощности, финансовые потоки, складские
помещения и т.д., принимая во внимание текущий план производства продукции (или услуг – здесь и далее) на предприятии.
Такая система называется системой планирования ресурсов предприятия, или MRPII-системой (Manufacturing Resource Planning
System). Окончание аббревиатуры – римская цифра «II» не несет
никакого лексического смысла, впрочем, далее мы объясним историю возникновения этого окончания.
Функциональные модули MRPII-системы
Таким образом, MRPII-система должна состоять из следующих
функциональных модулей:
– Планирование развития бизнеса (составление бизнес-плана).
– Планирование деятельности предприятия.
– Планирование продаж.
– Планирование потребностей в сырье и материалах.
– Планирование производственных мощностей.
– Планирование закупок.
– Выполнение плана производственных мощностей.
– Выполнение плана потребности в материалах.
– Осуществление обратной связи.
Модуль планирования развития бизнеса MRPII-системы определяет миссию компании: её нишу на рынке, оценку и определение
прибылей, финансовые ресурсы. Фактически он утверждает, в условных финансовых единицах, что компания собирается произвести и продать, и оценивает, какое количество средств необходимо
инвестировать в разработку и развитие продукта, чтобы выйти на
планируемый уровень прибыли. Таким образом, выходным элементом этого модуля является бизнес-план.
Модуль планирования продаж MRPII-системы оценивает (обычно в единицах готового изделия), какими должны быть объем и динамика продаж, чтобы был выполнен установленный бизнес-план.
Изменения плана продаж, несомненно, влекут за собой изменения
в результатах других модулей.
Модуль планирования производства MRPII-системы утверждает план производства всех видов готовых изделий и их характеристики. Для каждого вида изделия в рамках выпускаемой линии
продукции существует своя собственная программа производства.
Таким образом, совокупность производственных программ для
всех видов выпускаемых изделий представляет собой производственный план предприятия в целом.
91
Модуль планирования потребности в материалах MRPIIсистемы на основе производственной программы для каждого вида
готового изделия определяет требуемое расписание закупки и/или
внутреннего производства всех материалов комплектующих этого
изделия, и, соответственно, их сборку.
Модуль планирования производственных мощностей MRPIIсистемы преобразует план производства в конечные единицы загрузки рабочих мощностей (станков, рабочих, лабораторий и т.д.)
Модуль обратной связи MRPII-системы позволяет обсуждать и
решать возникающие проблемы с поставщиками комплектующих
материалов, дилерами и партнерами. Тем самым, этот модуль собственно и реализует знаменитый «принцип замкнутой петли» (closed
loop principl5) в системе. Обратная связь особенно необходима при
изменении отдельных планов, оказавшихся невыполнимыми и подлежащими пересмотру.
Рассмотрим коротко механизм работы MRPII-системы. Началом
является составление производственного плана (Master Production
Schedule – MPS) и общего плана деятельности (Production
Plan – PP). На самом деле, логика работы MRPII-системы достаточно проста.
Следующим шагом является планирование потребностей
в материалах. Модуль планирования потребностей в материалах (MRP – Materials Requirements Planning) исторически является тем самым зерном, из которого выросла концепция MRPII
(Manufacturing Resources Planning), римская цифра «II» появилась на конце ввиду аналогичности аббревиатур с MRP). Цель этого
модуля – так спланировать поставку всех комплектующих, чтобы
исключить простои производства и минимизировать запасы на складе. Уменьшение запасов материалов-комплектующих, кроме очевидной разгрузки складов и уменьшения затрат на хранение, дает
ряд неоспоримых преимуществ, главное из которых – минимизация
замороженных средств, вложенных в закупку материалов, не сразу
идущих на конвейер, а подолгу дожидающихся своей участи.
Входные элементы MRP-системы
Входными элементами MRP-модуля являются следующие.
Описание состояния материалов (Inventory Status Fils). Этот
элемент является основным входным элементом MRP-модуля.
В нем должна быть отражена максимально полная информация
о всех типах сырья и материалах-комплектующих, необходимых
для производства конечного продукта. В этом элементе должен
92
быть указан статус каждого материала, определяющий, имеется
ли он на руках, на складе, в текущих заказах или его заказ только
планируется, а также описания его запасов, расположения, цены,
возможных задержек поставок, реквизитов поставщиков. Информация по всем перечисленным позициям должна быть заложена отдельно по каждому материалу, участвующему в производственном
процессе.
Программа производства (Master Production Scheduls). Этот
элемент представляет собой оптимизированный график распределения времени для производства необходимой партии готовой продукции за планируемый период или диапазон периодов.
Перечень составляющих конечного продукта (Bills of Material
Fils). Этот элемент представляет собой список материалов и их количество, требуемое для производства конечного продукта. Таким
образом, каждый конечный продукт имеет свой перечень составляющих. Кроме того, здесь содержится описание структуры конечного продукта, т.е. он содержит в себе полную информацию по
последовательности его сборки. Чрезвычайно важно поддерживать
точность всех записей в этом элементе и соответственно корректировать их всякий раз при внесении изменений в структуру и/или
технологию производства конечного продукта.
Принцип работы MRP-модуля состоит в следующем: для каждого отрезка времени (обычно таким отрезком являются неделя или
сутки) в течение всего периода планирования на основании инвентарных списков, плана производства и текущих запасов на складе
создаётся полная потребность в материалах. Она представляет собой интегрированную таблицу, выражающую потребность в каждом материале (суть элементе списка) в каждый конкретный момент времени.
Далее вычисляется чистая потребность. Это делается путем вычитания из полной потребности тех материалов-комплектующих,
которые имеются в текущих запасах или занесены, в качестве позиций, в активные заказы. Другими словами, чистая потребность
определяет: какое количество материалов нужно заказать (или
произвести, в случае внутреннего производства комплектующих)
в каждый конкретный момент времени, чтобы удовлетворить текущие потребности производственного процесса.
Последний этап работы заключается в том, что чистая потребность в материалах конвертируется в соответствующий план заказов на требуемые материалы и, в случае необходимости, вносятся
поправки в уже действующие планы. При этом строго учитывается
93
время выполнения каждого заказа, другими словами MRP-система,
автоматически составляя план заказов, руководствуется известным
временем выполнения каждого из них (lead tim5). Это время, как
правило, определяется поставщиком данного материала. Этот план
заказов является руководящим документом отдела закупок.
Результатами работы MRP-модуля являются следующие основные элементы.
План заказов (Planned Order Scheduls). Этот элемент определяет, какое количество каждого материала должно быть заказано
в каждый рассматриваемый период времени в течение срока планирования. План заказов является руководством для дальнейшей
работы с поставщиками и, в частности, определяет производственную программу для внутреннего производства комплектующих,
при наличии такового.
Изменения к плану заказов (Changes in planned orders). Этот элемент несёт в себе модификации к ранее спланированным заказам.
Некоторые заказы могут быть отменены, изменены или задержаны,
а также перенесены на другой период.
Планирование потребностей в производственных мощностях
(CRP – Capacity Requirements Planning). Для того чтобы производственная программа была осуществима, необходимо, чтобы имеющиеся в наличие производственные мощности смогли обработать то
количество сырья и материалов-комплектующих, которое предписывает составленный MRP-модулем план заказов, и изготовить из
них готовые изделия. Собственно MRP-план является основным
входным элементом модуля планирования потребностей в производственных мощностях (CRP-модуля). Другим немаловажным
входным элементом является технологическая схема обработки/
сборки конечного готового изделия. Эта схема является определенной таблицей, аналогичной инвентарному списку, только с точки
зрения этапов обработки и их длительности, а не комплектующих
и их количества. Обычно производственные мощности предприятия классифицируются на производственные единицы. Такой производственной единицей может быть станок, инструмент, рабочий
и т.д. Результатом работы CRP-модуля является план потребности
в производственных мощностях (Capacity Requirements Plan). Этот
план определяет, какое количество стандартных часов должна работать каждая производственная единица, чтобы обработать необходимое количество материалов.
Также очень важно заметить, что модули MRPII-системы являются четко и однозначно взаимосвязанными. Это, в свою очередь.
94
означает собой тот факт, что в любом случае, если потребности в материалах (MRP-план, являющийся следствием изначально составленной программы производства) не могут быть удовлетворены ни
за счет внутреннего производства, ни за счет закупок на стороне,
в план производства, очевидно, должны быть внесены изменения.
Однако подобные явления должны быть исключениями. Одной из
основных задач является составление успешного производственного
плана с самого начала.
Таким образом, заметим еще раз: если в результате работы CRPмодуля установлено, что MRP-план неосуществим, то производственная программа должна быть пересмотрена, более того, вероятно, необходимо пересмотреть весь план деятельности. Однако важно осознавать, что такой шаг должен быть сделан в самом крайнем
случае, так как планировщик, работающий с CRP-системой, должен
быть компетентен и сам осознавать производственные возможности
своего предприятия, понимая, что задача компьютера – лишь оптимально распределить загрузку производственных мощностей на
период планирования. Тем самым, планировщик должен стараться
определить и опротестовать заведомо неосуществимый MRP-план
до отправления его в CRP-систему, или найти пути для расширения
производственных мощностей до необходимого уровня.
Контроль выполнения производственного плана отражается в контрольных отчётах по производительности и потреблению (Input/
Output Reports). В тот момент, когда определено, что план потребностей в производственных мощностях может быть осуществлен,
начинает функционировать контроль поддержания установленной
производительности. Для этого в течение всего срока планирования
системой регулярно создаются контрольные отчеты по производительности (Output Control Reports).
Для адекватной работы системы необходимо определить величину допустимого отклонения от плана производства. В тот момент,
когда величина реального отклонения превышает конкретное количество часов, система сигнализирует о необходимости немедленного вмешательства в работу данной производительной единицы и
принятия мер к повышению ее производительности, вплоть до её
выхода на плановый уровень. Такими мерами может быть привлечение дополнительных рабочих, допустимое увеличение общего
времени её работы и т.д.
Кроме контрольных отчетов производительности для каждой
производительной единицы существуют контрольные отчеты потребления материалов-комплектующих. Эти отчеты существуют
95
для быстрого определения ситуаций, когда та или иная производительная единица не развивает плановой мощности из-за недостаточного снабжения материалами. Еще одним необходимым документом, регулярно (как правило, ежедневно) создаваемым MRPIIсистемой является список операций (Operation Lists). Списки операций обычно формируются в начале дня и передаются (или пересылаются) мастерам соответствующих производственных цехов.
В этих документах отображена последовательность проведения
рабочих операций над сырьем и комплектующими материалами на
каждой производственной единице и их длительность. Списки операций позволяют каждому мастеру получать актуальную информацию и фактически делают его частью MRPII-системы.
Чрезвычайно важно обратить внимание на функции обратной
связи в MRPII-системе. Например, если поставщики не способны
поставить материалы-комплектующие в оговоренные сроки, они
должны послать отчет о задержках, сразу, как только они узнают
о существовании этой проблемы. Обычно стандартная компания
имеет большое количество просроченных заказов с поставщиками. Но, как правило, даты этих заказов не отражают в достаточной
степени дат реальной потребности в этих материалах. На предприятиях же, управляемых системами класса MRPII, даты поставки
являются максимально близкими к времени реальной потребности
в поставляемых материалах. Поэтому крайне важно заранее поставить систему в известность о возможных проблемах с заказами.
В этом случае система должна сгенерировать новый план работы
производственных мощностей, в соответствии с новым планом заказов. В ряде случаев, когда задержка заказов далеко не является
исключением, в MRPII-системе задаётся объем минимального поддержания запасов «ненадежных» материалов на складе.
В настоящее время системы MRPII класса прочно входят в жизнь
крупных и средних производственных организаций. Основной и
эффективной чертой этих систем является возможность планировать потребности предприятия на короткие промежутки времени
(недели и даже дни) и осуществлять обратную связь (например, автоматически изменять ранее построенные планы производства при
сбоях поставок или поломке оборудования), внося в систему данные
о проблемах в реальном времени.
Алгоритм работы MRPII-системы нацелен на внутреннее моделирование всей области деятельности предприятия. Его основная
цель – учитывать и с помощью компьютера анализировать все внутрикоммерческие и внутрипроизводственные события: все те, что
96
происходят в данный момент и все те, что запланированы на будущее. Как только в производстве допущен брак, как только изменена программа производства, как только в производстве утверждены новые технологические требования, MRPII-система мгновенно
реагирует на произошедшее, указывает на проблемы, которые могут
быть результатом этого и определяет, какие изменения надо внести
в производственный план, чтобы избежать этих проблем или свести
их к минимуму. Разумеется, далеко не всегда реально полностью
устранить последствия того или иного сбоя в производственном процессе, однако MRPII-система информирует о них за максимально
длительный промежуток времени до момента их возникновения.
Таким образом, предвидя возможные проблемы заранее и создавая руководству предприятия условия для предварительного их
анализа, MRPII-система является надежным средством прогнозирования и оценки последствий внесения тех или иных изменений
в производственный цикл.
Любая MRPII-система обладает определенным инструментарием для проведения планирования. Перечисленные далее системные методологии – являются фундаментальными рычагами управления любой MRPII-системы:
– методология расчёта и пересчета MRP- и CRP-планов;
– принцип хранения данных о внутрипроизводственных и внутрикоммерческих событиях, которые необходимы для планирования;
– методология описания рабочих и нерабочих дней для планирования ресурсов;
– установление горизонта планирования (planning horizon).
Эти методологии и принципы не являются универсальными и
определяются исходя из постановки конкретной задачи, применительно к конкретному коммерческому предприятию.
Перечислим преимущества использования MRPII-систем. Применение систем MRP-II позволяет:
– улучшить обслуживание заказчиков – за счет своевременного
исполнения поставок,
– сократить цикл производства и цикл выполнения заказа – следовательно, бизнес будет более гибко реагировать на спрос,
– сократить незавершенное производство – работа не будет выдаваться, пока не потребуется «точно ко времени» для удовлетворения конечного спроса,
– значительно сократить запасы, что позволит более экономно
использовать складские помещения и потребуется меньше средств
на его хранение,
97
– сбалансировать запасы – будет меньше дефицита и меньше
устаревших запасов,
– повысить производительность – людские ресурсы и материалы будут использоваться в соответствии с заказами с меньшими потерями; можно использовать анализ «что-если», чтобы проверить,
соответствует ли производство задачам предприятия по получению
прибыли,
– создать скоординированную группу управления, которая сможет
решать стратегические и оперативные вопросы и организовать работу, в соответствии с выработанным основным планом производства.
4.4. Системы стандарта ERP
Основные понятия СИ применительно к производственному менеджменту (в том числе и термин «ERP») можно считать вполне
устоявшимися. В этой области признанным «стандартом де-факто»
служит терминология Американской ассоциации по управлению
запасами и производством (American Production and Inventory
Control Society, APICS). Основные термины и определения приводятся в Словаре APICS, который регулярно обновляется по мере
развития теории и практики управления. Именно в этом издании
содержится наиболее полное и точное определение ERP-системы
[6, 8, 14, 16].
В соответствии со Словарем APICS, термин «ERP-система»
(Enterprise Resource Planning – управление ресурсами предприятия) может употребляться в двух значениях.
ERP-система – информационная система для идентификации
и планирования всех ресурсов предприятия, которые необходимы
для осуществления продаж, производства, закупок и учета в процессе выполнения клиентских заказов.
ERP методология – это методология эффективного планирования и управления всеми ресурсами предприятия, которые необходимы для осуществления продаж, производства, закупок и учета
при исполнении заказов клиентов в сферах производства, дистрибьюции и оказания услуг.
Таким образом, термин ERP может означать не только информационную систему, но и соответствующую методологию управления, реализуемую и поддерживаемую этой КИС.
Отличия ERP- и MRPII-систем
Рассмотрим основные отличия ERP от MRPII. В настоящее время практически все разработчики MRPII/ERP-систем относят свои
системы к классу ERP. «ERP» – очень модная аббревиатура, способ98
ная увеличить продажи системы, по сути не принадлежащей к этому
классу. Дело доходит до того, что начинают позиционировать финансово-управленческие системы со слабым производственным блоком
как «полноценные ERP-системы», вводя потребителей в заблуждение. Эта путаница усугубляется отсутствием ERP-стандарта.
Проведем сравнительную характеристику систем двух классов – ERP и MRPII. Сразу следует отметить, что и для MRPIIсистем, и для ERP-систем основным является производство. Они,
безусловно, развиваются в связи с запросами рынка: добавляются
новые функциональности, решения переносятся на новые технологические платформы. Однако производственные подсистемы
остаются центральными для рассматриваемых систем, и различия
между MRPII- и ERP-системами лежат именно в области планирования производства. Связаны эти различия с глубиной реализации
планирования, что обусловлено ориентацией этих систем на различные сегменты рынка.
ERP-системы создаются для больших многофункциональных и
территориально распределенных производственных корпораций
(например, холдингов, ТНК, ФПГ и т.д.). MRPII-системы ориентированы на рынок средних предприятий, которым не требуется вся
мощность ERP-систем.
Собственно, различие MRPII- и ERP-систем понятно уже из их
названия: с одной стороны, планирование корпоративных ресурсов
(Enterprise Resources Planning), а с другой – планирование производственных ресурсов (Manufacturing Resources Planning).
Существенные же отличия ERP от MRP II можно выразить следующей формулой:
«ERP = MRPII + реализация всех типов производства + интегрирование планирования ресурсов по направлениям деятельности +
многозвенное планирование».
Безусловно, многие MRPII-системы развиваются с позиций глубины планирования и по некоторым параметрам приближаются к ERPсистемам. Однако «по некоторым» не значит «по всем», поэтому с употреблением термина «ERP» нужно обращаться осторожно.
В то же время среди ERP- , MRPII-систем не все могут предложить решения по системе планирования и управления производством процессного типа.
Современный рынок информационных управленческих систем
состоит из тройки (по другим оценкам – пятерки) систем-лидеров,
которые, собственно, и относятся к классу ERP, и множества «продвинутых» систем класса MRPII.
99
Безусловными лидерами являются системы SAP R/3 немецкой компании SAP AG, Oracle Applications американской компании Oracle и Baan, разработанная нидерландской компанией Baan.
Иногда к этому «элитному» списку добавляют OneWorld компании
J.D.Edwards и PeopleSoft, выпускаемую одноименной компанией.
Что же касается MRPII-систем, то тут наблюдается большее
количество решений, каждое из которых несет в себе уникальное
сочетание функциональных и технологических особенностей. Все
они отличаются различной степенью проработки производственных, финансовых и иных функций, поэтому с помощью консультантов предприятия могут подобрать систему, более всего отвечающую их запросам. Поэтому «MRPII» – это не признак ущербности
системы, а показатель того, что система ориентирована на рынок
средних предприятий.
Концепция ERP-систем
Главная цель концепции ERP – распространить принципы
MRPII (Manufactory Resource Planning, планирование производственных ресурсов) на управление современными корпорациями.
Концепция ERP представляет собой надстройку над методологией
MRPII. Не внося никаких изменений в механизм планирования
производственных ресурсов, она позволяет решить ряд дополнительных задач, связанных с усложнением структуры компании.
Концепция ERP до сих пор не стандартизована. Когда возникает
вопрос об отнесении конкретной информационной системы управления к классу развитых MRP II-систем или к классу ERP, специалисты расходятся во мнениях, поскольку выделяют различные
критерии принадлежности системы классу ERP. Однако суммируя
различные точки зрения, можно указать основные черты, которыми должны обладать ERP-системы.
Системы класса ERP отличает набор следующих свойств:
– универсальность с точки зрения типов производств;
– поддержка многозвенного производственного планирования;
– более широкая (по сравнению с MRPII) сфера интегрированного планирования ресурсов;
– включение в систему мощного блока планирования и учета
корпоративных финансов;
– внедрение в систему средств поддержки принятия решений.
Рассмотрим возможность планирования производства всех типов в рамках одной системы. Даже на обычном предприятии (не
говоря уже о корпорации) могут сосуществовать производства
100
различных типов – проектного, дискретного, непрерывного (процессного). К предприятиям, работающим по непрерывному процессному производству, можно отнести предприятия пищевой,
химической, фармацевтической, нефтехимической, нефтяной, металлургической промышленности. Предприятия, работающие по
дискретному циклу, принадлежат к машиностроительной, легковой промышленности.
Для поддержки планирования и управления всем предприятием
в целом, информационная система должна «уметь» работать с каждым из этих типов производств. Системы класса ERP содержат набор модулей, каждый из которых специализирован на определенном типе производства.
Большие производственные объединения, распределенные территориально, могут состоять из обособленных структурных подразделений или филиалов (звеньев). Каждый филиал, как правило, имеет отдельный законченный производственный процесс. Однако зачастую
подразделения связаны между собой цепочкой поставок некоторых
единиц продукции. Это усложняет процесс планирования деятельности, как отдельных подразделений, так и всего производственного
объединения. Чтобы предотвратить простои и перегрузки отдельных
производств из-за не поставленных вовремя деталей, план-графики
закупок/производства различных производственных подразделений
компании должны быть согласованы между собой.
Логика работы заложенных в ERP-системы средств агрегирования планов проста. Сначала формируются собственные планы закупок/поставок и производства для каждого предприятия-звена
единой организационной структуры. По каждой номенклатурной
единице, входящей во внутрипроизводственную сеть поставок,
указываются источник (потребитель) и приоритетность поставки
этой единицы. Затем ERP-система создает многозвенный (агрегированный) план. Прежде чем представить эти планы для утверждения, система проводит сценарную оценку их выполнимости. Как и
в обычных MRPII-системах, оценка выполнимости планов происходит путем создания системой потока заказов зависимого спроса
на уровне всего производственного объединения. При выявлении
критических состояний планы корректируются и лишь затем поступают на утверждение.
В классических MRPII-системах интегрированное планирование ресурсов охватывало лишь производственные, складские,
снабженческие и сбытовые подразделения предприятия. Действия
других тесно связанных с производственным процессом подразде101
лений и служб (например, ремонтных, транспортных) не вовлекались в планирование. Точно так же за кадром оставались проектные работы.
ERP-системы позволяют вовлечь в сферу интегрированного планирования ресурсов все подразделения предприятия, так или иначе эти ресурсы использующие. Это позволяет достичь оптимизации
бизнес-операций предприятия, а также координации действий всех
служб и подразделений для обеспечения их эффективной работы.
В связи с этим, в ERP-системах появляются следующие дополнительные подсистемы.
– Планирование и управление реализацией производственных проектов. В этой подсистеме ведется анализ проекта (разработка его структуры, выделение подпроектов, разбиение подпроектов на отдельные работы), формирование сетевых графиков работ,
планирование материальных и трудовых ресурсов, оборудования,
финансовых затрат для выполнения этих работ, управление ходом
их выполнения.
– Планирование работы сервисно-технических служб. Подсистема позволяет планировать ресурсы и оптимизировать выполнение работ по техническому обслуживанию производственных
объектов. Подсистема оказывает сильное влияние на работу модуля
планирования производства. Если проводится аварийный или плановый ремонт некоторой единицы производственных мощностей,
то подсистема должна оповестить модуль планирования производства о блокировке данной единицы производственных мощностей
на определенный период и указать на этот период альтернативный
производственный маршрут.
– Планирование и управление распределенными ресурсами
(Distribution Resources Planning). Такая подсистема предоставляет
возможность работать со сложной многозвенной структурой сбытовых подразделений и складов. В частности, в ее компетенцию входит и планирование работы транспортных служб. С помощью подсистемы можно:
– минимизировать транспортные затраты на доставку сырья и
комплектующих;
– организовать сбалансированное распределение материалов и
продукции по складам компании;
– выбрать оптимальные транспортные маршруты при проведении межскладских перемещений (когда есть несколько складов)
или перемещений между сбытовыми подразделениями (когда есть
сеть дилерских организаций).
102
– Планирование и управление послепродажным и специальным обслуживанием. Как следует из названия, подсистема предназначена для управления всеми видами сервисных услуг.
Во многих современных MRPII-системах появляются подсистемы
«Проект», «Сервис», «Транспорт» и т. д. Однако хотя в этих подсистемах и ведется учет затрат и доходов, бюджетирование, зачастую
в них нет необходимой для ERP функциональности по созданию потока заказов, порождающей интегрированное планирование потребностей в ресурсах и мощностях в масштабах всего предприятия.
Несмотря на довольно широкую функциональность, ERPсистемы не являются полностью интегрированными системами
управления: на многих предприятиях существуют подразделения,
деятельность которых хотя и связана с производственным процессом, однако не укладывается в существующую идеологию MRPII /
ERP-систем. Для автоматизации работы таких подразделений используются свои системы. Речь идет, например, о системах автоматизированного проектирования (САПР), системах конструкторской и технологической подготовки производства (PDM-системы,
Product Data Management). Поэтому реально ERP-системы (так же,
как и MRPII-системы) практически всегда используются совместно
с подобными подсистемами.
Реализация в ERP-системах поддержки планирования ресурсов
разветвленной корпорации влечет за собой необходимость усиления финансового блока, реализации управления сложными финансовыми потоками и возможности корпоративной консолидации.
Поэтому в ERP-системы входят мощные системы управления корпоративными финансами, характеризующиеся следующими особенностями.
Управленческие решения принимаются людьми. Сама по себе
ERP-система не является инструментом для принятия управленческих решений, она лишь поставляет необходимую для этого информацию. Реальную же поддержку принятия управленческих решений оказывают специальные аналитические средства, вводимые
в ERP-системы (обычно эти средства называют OLAP – On-Line
Analysis Processing).
Приведем некоторые возможности систем поддержки принятия
решений:
– отслеживание эффективности работы различных участков и
служб для выявления и устранения слабых звеньев, а также для
совершенствования структуры бизнес-процессов и организационных единиц;
103
– анализ деятельности отдельных подразделений;
– агрегирование данных из различных подразделений;
– анализ показателей различных направлений финансово-хозяйственной деятельности предприятия для выделения перспективных и убыточных направлений бизнеса;
– выявление тенденций, развивающихся как внутри предприятия, так и на рынке.
4.5. Системы класса CRM
Последнее десятилетие ХХ-го века явилось началом отсчета нового поколения продуктов, реализующих концепцию СИ. Несмотря на то, что передовые предприятия для укрепления на рынке
внедряют мощнейшие системы класса ERP, этого уже оказывается
недостаточно для повышения доходов предприятия [6, 8, 14, 16].
Причины такой ситуации лежат в области, казалось бы, далекой от производства, а именно, в области человеческих отношений
и психологии. Обратимся к теории менеджмента, успешно впитавшей в себя законы психологии, и к рыночной экономике.
В настоящее время усиливается конкуренция на мировом рынке
товаров и услуг. С одной стороны, доходность бизнеса снижается
из-за перенасыщенности внутренних рынков сходными товарами и
услугами, а также из-за сложностей при организации экспорта на
другие региональные рынки. С другой стороны, владельцы бизнеса
требуют от менеджмента повышения прибыли, объемов продаж.
Широко используемое в настоящее время решение состоит в согласованных действиях «всего предприятия», а не только отдела маркетинга, по поиску, привлечению и, главное, удержанию клиента.
Управление отношениями с клиентами (Customer Relations
Management, CRM) – это стратегия, основанная на применении таких управленческих и информационных технологий, с помощью
которых компании аккумулируют знания о клиентах для выстраивания взаимовыгодных отношений с ними. Подобные отношения
способствуют увеличению прибыли, так как привлекают новых
клиентов и помогают удержать старых.
CRM – это клиент-ориентированная стратегия, с одной стороны,
формирования наценки «выше рыночной» за счет обеспечения индивидуального обслуживания каждого клиента, а с другой – ориентации на долгосрочные отношения, в том числе и в ущерб краткосрочным экономическим задачам. Обе стороны «CRM-медали»
требуют создания и поддержания долгосрочных отношений с клиентами на качественно более высоком, чем простая декларация
104
«клиент всегда прав», уровне. Целью CRM является не просто увеличение объема продаж, а прибыльное «увязывание» потребностей
клиента с возможностями продавца, что и требует совместной коллективной работы на клиента различных функциональных подразделений организации.
Таким образом, CRM «в большом» – это стратегия «отличительного» ведения бизнеса. CRM «в малом» – собственно информационные технологии, позволяющие формализовать и автоматизировать
различные аспекты взаимодействия с клиентами подразделений
маркетинга, продаж и сервисного сопровождения на основе автоматических/автоматизированных процессов (в том числе сбытовых) и единого «информационного пространства» организации.
Таким образом происходит консолидация всей информации о каждом клиенте путем обмена данными с другими информационными
системами. Объединяя ключевые блоки информации о контактах,
организациях, сделках, заказах/проектах и связях между этими
«сущностями», CRM-система позволяет, опираясь на факты, узнать все о поведении клиентов и подобрать экономически целесообразный способ их обслуживания, ведя бизнес «проактивно».
Рынок CRM можно условно разделить на две части – средний и
крупный. Все западные поставщики CRM-решений позиционируют свои продукты для компаний среднего или крупного бизнеса.
CRM-продукты, предлагаемые западными поставщиками, можно
классифицировать по семи основным категориям:
– SFA (Sales Force Automation) – автоматизация деятельности
торговых представителей;
– МА (Marketing Automation) – автоматизация деятельности
маркетинга;
– CSA, CSS (Customer Service Automation, Customer Service
Support) – автоматизация службы поддержки и обслуживания
клиентов;
– Call/Contact Center Management – центры обработки вызовов,
контакт-центры;
– Field Service Management – управление территориально удаленными подразделениями или пользователями;
– PRM (Partner Relationship Management) – управление взаимоотношениями с партнерами (не поставщиками, а элементами товаропроводящей сети, разделяющими риски);
– Help Desk – техническая поддержка пользователей.
На рынке присутствуют как продукты, обеспечивающие определенную узкую функциональность (например, управление кон105
тактами), так и полнофункциональные интегрированные CRMсистемы, объединяющие в себе несколько модулей (в частности,
модули продаж, маркетинга, сервисного сопровождения, проектного управления и электронной коммерции).
Основное отличие CRM-систем от всех остальных информационных систем предприятия состоит в следующем. Прочие системы (ERP, документооборот) минимизируют расходы и/или «наводят порядок», а значит, работают на экономичность и экономию
(снижение цены покупки), тогда как CRM-системы призваны наращивать эффективность бизнеса: отбором правильных клиентов
и корректным выстраиванием отношений с первого раза.
Основой CRM-системы являются приложения автоматизации
продаж (Sales Force Automation, SFA). На них возлагаются следующие функции:
– ведение календаря событий и планирование работы;
– управление контактами (благодаря ему ни один важный звонок или личное обращение не будут пропущены);
– работа с клиентами (каждый клиент будет обслужен на высочайшем уровне, благодаря зафиксированной истории взаимодействия с ним);
– мониторинг потенциальных продаж (ни одна потенциальная
возможность не будет упущена, каким бы плотным не было расписание сотрудника);
– поточная организация продаж (эффективное управление циклом продаж);
– повышение точности прогнозов продаж;
– автоматическая подготовка коммерческих предложений (освобождает сотрудников от рутинной работы);
– предоставление информации о ценах;
– автоматическое обновление данных о размере бонуса в зависимости от выполнения поставленных задач;
– предоставление актуальной информации о состоянии дел в региональных представительствах;
– формирование отчетов (эффективный инструментарий автоматического создания отчетов по результатам деятельности);
– организация продаж по телефону (создание и распределение
списка потенциальных клиентов, автоматический набор номера,
регистрация звонков, прием заказов).
В современных CRM-системах SFA-приложения дополняются
средствами автоматизации маркетинга (Marketing Automation,
MA). Эти приложения позволяют:
106
– организовывать маркетинговые кампании (предусмотрены
инструменты планирования, разработки, проведения и анализа результатов маркетинговых акций, как традиционных, так и через
Интернет);
– создавать маркетинговые материалы и управлять ими (в том
числе заниматься автоматической рассылкой);
– генерировать список целевой аудитории (создание списков потенциальных клиентов и их распределение между торговыми представителями);
– отслеживать бюджетирование и прогнозирование результатов
маркетинговых кампаний;
– вести маркетинговую энциклопедию (репозиторий информации о продуктах, ценах и конкурентах).
Приложения МА предоставляют менеджерам по маркетингу
мощный инструмент для разработки, проведения и анализа маркетинговых кампаний, а также осуществления других маркетинговых функций. С помощью совместно используемых MA- и SFAприложений можно формировать рабочие планы продавцов и отслеживать их выполнение.
Приложения автоматизации обслуживания клиентов (Customer
Service Automation & Support, CSA/CSS) в последнее время приобрели первостепенное значение, так как в условиях жесткой конкуренции удержать прибыльного клиента можно, прежде всего, благодаря высокому качеству обслуживания.
Как правило, к этой категории приложений относятся средства
обработки вызовов и самообслуживания через Интернет. Приложения CSS позволяют удовлетворять индивидуальные потребности
заказчиков быстро, точно и эффективно, обеспечивая выполнение
следующих функций:
– мониторинг потребностей клиента (сотрудники отдела обслуживания всегда в курсе проблем и предпочтений того или иного покупателя услуг);
– мониторинг прохождения заявок (процесс отслеживается автоматически);
– мониторинг мобильных продаж (в любой момент времени
можно получить информацию о качестве выполнения услуги, ее
стоимости, удовлетворенности клиентов, сроках выполнения заявки и др.);
– ведение БЗ (эффективный инструмент снижения себестоимости услуг – большинство проблем могут быть решены во время
первого звонка клиента);
107
– контроль над исполнением сервисных соглашений (автоматическое отслеживание сроков и условий);
– управление запросами клиентов с помощью присвоения приоритетов.
Приложения CSS превращают отделы обслуживания клиентов
из затратных в прибыльные. Будучи интегрированными с приложениями SFA и МА, они способствуют тому, чтобы каждый контакт клиента с компанией был использован для продажи дополнительных услуг и более дорогих продуктов.
Прочие функции:
– составление отчетов для высшего руководства;
– интеграция с ERP (Интернетом, внешними данными);
– синхронизация данных (включая данные, хранящиеся в многочисленных портативных устройствах, серверах приложений и
в различных базах);
– электронная торговля (управление закупками B2B и B2C через
систему EDI, Web-сервер и другие средства);
– мобильные продажи (генерация заказов, передача информации торговым представителям вне офиса в режиме реального времени через мобильные устройства).
Field Service Management (FSM) – это системы управления сервисным обслуживанием проданной продукции. Предназначены
для управления гарантийным и постгарантийным обслуживанием продукции, ведения и контроля сервисных заявок и договоров,
планирования ресурсов предприятия.
Использование FSM системы позволяет существенно снизить затраты, связанные с обслуживанием продукции, и повысить качество обслуживания заказчиков, благодаря оперативному наличию
информации по каждой единице изделия (серийные номера), использованию БЗ и точности календарного планирования сервисного персонала.
PRM (Partner Relationship Management, управление взаимоотношениями с партнерами) – это системы повышения эффективности процессов взаимодействия с партнерами в области продаж,
маркетинга, поставок и обслуживания за счет интеграции различных аспектов партнерской деятельности в единую систему.
Данные системы реализуются в различных приложениях для
автоматизации и оптимизации указанных процессов.
В современной ситуации эффективность деятельности компании
во многом зависит от взаимодействия с партнерами на различных
сегментах рынка. Однако организовать эффективное взаимодей108
ствие с партнерами не так просто: вокруг лучших каналов сбыта
развернута острейшая борьба между поставщиками, которые часто
переманивают партнеров друг у друга.
PRM-системы – корпоративные приложения нового класса,
цель которых – оптимизировать взаимоотношения компании
с партнерами.
Функции PRM-систем:
– PRM-системы позволяют повысить эффективность каналов
сбыта благодаря более оперативному ознакомлению партнеров
с новыми инициативами и другой информацией, имеющей отношение к партнерской деятельности. Кроме того, производители смогут координировать продажи продуктов и оптимальным образом
перераспределять их между различными каналами сбыта.
– PRM-системы позволяют производителям точнее определять,
кто из дилеров-партнеров приносит наибольшую прибыль, чтобы
соответственно их поощрять, а также определять партнеров, генерирующих наибольшее количество заказов и предоставлять им
наилучшие условия.
– PRM-системы упрощают и стандартизируют процессы сотрудничества с партнерами (поиск новых партнеров, учет, оценка деятельности партнеров и определение их специализации).
– PRM-системы также дают возможность проводить тренинги
для партнеров в режиме онлайн.
Преимущества PRM-систем:
– PRM-системы предоставляют компаниям эффективное средство коммуникации с партнерами и обеспечивают все сотрудничающие стороны необходимой информацией и навыками для обеспечения максимально высокой прибыли и высококачественного
обслуживания их общих клиентов.
– Объединенный потенциал компаний-партнеров, использующих PRM-систему, позволит обеспечить их взаимодействие и согласовать финансовые потоки за счет интеграции информации о
заказах с маркетингом партнеров, продажами и производством.
– PRM-системы обеспечивают владельцев брендов мощными
возможностями управления и универсальными аналитическими
инструментами, предоставляющими всестороннюю информацию
по деятельности отдельных партнеров, сегментам их деятельности
и всех партнеров вместе. Многие системы включают до нескольких
сотен встроенных отчетов и аналитических инструментов, которые
позволяют руководителям компаний быстро оценить эффективность совместных продаж, услуг и маркетинговой деятельности.
109
Системы класса CRM зачастую интегрируют с системами управления предприятием (такими как MRPII, ERP), однако даже такое
детальное ведение всей маркетинговой информации может не дать
того эффекта, который ожидается со стороны топ-менеджмента
предприятия.
Более современной концепцией управления ресурсами предприятия является CSRP (Customer Synchronized Resource Planning,
планирование ресурсов, синхронизированное с клиентом), захватывающая почти весь ЖЦ товара. Такой подход позволяет на порядок точнее управлять стомостью товара, учитывая производство,
продвижение и обслуживание товара данного типа, и учитывать
все элементы его функционального ЖЦ, а не только производства,
как во всех стандартных системах предыдущих поколений.
Сущность концепции CSRP состоит в том, что при планировании
и управлении компанией можно и нужно учитывать пожелания конечных пользователей непосредственно при оформлении заказа, т. е.
ориентироваться в большей степени на производство индивидуальных конфигураций товаров «под заказ». Такой подход дает большие
преимущества в конкурентоспособности предприятия в отраслях, где
жизненный цикл товара невелик, и требуется оперативно реагировать на изменение желаний потребителя.
Исключительно важным следствием данной концепции явилась
реализация задачи тонкого управления производственными графиками в условиях ограниченных мощностей (так называемой APS
задачи – Advanced Planning and Scheduling – расширенного управления производственными графиками). Автономные решения такого класса были известны и раньше, однако в систему управления ресурсами предприятия впервые были интегрированы фирмой
SYMIX в ее флагманском продукте SyteLine. Системы типа APS
позволяют решать такие задачи, как «проталкивание» срочного заказа в производственные графики, распределение заданий с учетом
приоритетов и ограничений, перепланирование с использованием
полноценного графического интерфейса. Благодаря принципиально новой «математике» расчет типовых задач MRP осуществляется
значительно быстрее, чем раньше.
4.6. Проблемы внедрения КИС
Как уже отмечалось, в концепциях СИ в основе деятельности по
созданию и использованию ПО современных КИС лежит понятие
его ЖЦ, который является моделью создания и использования ПО,
отражающей его различные состояния, начиная с момента возник110
новения необходимости в данном ПО и заканчивая моментов его полного выхода из употребления у всех пользователей [4, 12, 14].
Жизненный цикл образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итеративный характер: реализованные этапы, начиная с самых ранних, циклически
повторяются в соответствии с изменениями требований и внешний
условий, введением ограничений и т.п. Каждым этапом ЖЦ порождается определенный набор документов и технических решений, при
этом для каждого этапа исходными являются документы и решения,
полученные на предыдущем этапе. Каждый этап завершается верификацией порожденных документов и решений с целью проверки их
соответствия исходным документам.
Существующие модели ЖЦ, рассмотренные в разд. 3, определяют
порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. Как уже отмечалось, наибольшее распространение получили две модели ЖЦ: каскадная и спиральная модель.
Главная особенность индустрии ПО современных КИС состоит
в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают
на более поздних этапах трудные, часто уже неразрешимые проблемы, и приводят к неуспеху всего проекта.
Рассмотрим этапы ЖЦ более подробно.
Анализ требований: требования заказчика уточняются, формализуются и документируются. На этом этапе дается ответ на вопрос: «Что должна делать система?».
Список требований к разрабатываемой системе должен включать:
– совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы,
внешние условия функционирования, состав людей и работ, имеющих отношение к системе);
– описание функций системы;
– ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные
процедуры и мероприятия, обеспечивающие защиту информации).
Целью анализа является преобразование общих, неясных знаний о требованиях к будущей системе в точные (по возможности)
определения. На этом этапе определяются:
– архитектура системы, ее функции, внешние условия, распределение функций между аппаратным и программным обеспечением;
111
– интерфейсы и распределение функций между человеком и
системой;
– требования к программным и информационным компонентам
ПО, необходимые аппаратные ресурсы, требования к БД, физические характеристики компонентов ПО, их интерфейсы.
Этап проектирования дает ответ на вопрос: «Как (каким образом) система будет соответствовать предъявленным требованиям?». Задачей этого этапа является исследование структуры системы и логических взаимосвязей ее элементов, причем без внимания
к вопросам реализации.
Обычно этот этап разбивают на два подэтапа:
– проектирование архитектуры ПО, т.е. разработка структуры
и интерфейсов компонентов, согласование функций и технических
требований к компонентам, стандартам проектирования, производство отчетных документов;
– детальное проектирование, т.е. разработка спецификаций каждого компонента, интерфейсов между компонентами, разработка
требований к тестам и план интеграции компонентов.
В результате деятельности на этапах анализа и проектирования
должен быть получен проект системы, содержащий достаточно информации для реализации системы на его основе в рамках бюджета
выделенных ресурсов и времени.
Процесс разработки и внедрения КИС исполняется по следующему
сценарию:
1. Анализ существующих систем или разработка требований
к создаваемой системе.
2. Типовой процесс внедрения.
2.1. Разработка стратегии автоматизации.
2.2. Анализ деятельности предприятия.
2.3. Реорганизация деятельности.
2.4. Выбор системы.
2.5. Внедрение системы.
2.6. Эксплуатация.
К типичным проблемам при внедрении КИС относят: подготовку предприятия к автоматизации приведены и выбор ПО системы.
Примерные функции системы и их характеристики приведены
в табл. 4.1. При разработке технического задания на разработку системы или при сравнительном анализе сопоставимых альтернативных систем желательно составить подобную таблицу и заполнить
её для альтернативных систем.
112
Таблица 4.1
Функции системы и достоинства их использования
Функция системы
Позволяет делать
Качественный выигрыш
Блок проектирования
Item Part Number
Control (Управление
структурой изделия)
Управляет структурой
изделия с точностью
до комплектующих
(узлов и агрегатов)
Повышение точности
данных для планирования производственной деятельности,
обеспечение стыка
с системами проектирования
Bill of Materials
Control (Управление
спецификациями продуктов)
Контролирует весь
перечень материалов,
требуемых для производства конечного
изделия (как количественно, так и в финансовом эквиваленте)
Повышение точности
данных для планирования производственной деятельности,
обеспечение стыка
с системами проектирования
Блок контроля инженерной документации
Routings
(Маршрутизация)
Управляет распредеОптимальная загрузка
лением потока заказов цехов (оборудования)
по цехам (рабочим
местам)
Estimating (Смета)
Оценка влияния изменений
Точный учет затрат,
связанных с изменениями
Design Engineering
(Разработка технологии)
Подготавливает
технологию выпуска
продукции
Оптимальная технология выпуска продукции
Блок управления закупками
Vendor Performance
(Исполненные
поставки)
Учет исполнения запланированных
поступлений
Точный учет запасов,
повышение достоверности планирования
Purchase Order
Management (Управление заказами на
закупку)
Планирование и ввод
заказов на закупку
Сокращение материальных запасов за счет
обеспечения поставок
в требуемый срок
Subcontract Purchase
Orders (Заказы на
закупку по субконтрактам)
Планирование и ввод
заказов на закупку,
выполняемых субподрядчиками
Сокращение материальных запасов за счет
обеспечения поставок
в требуемый срок
113
Продолжение табл. 4.1
Функция системы
Позволяет делать
Качественный выигрыш
Блок управления материальными запасами
Inventory Control
(Управление
запасами)
Планирование и учет
запасов
Сокращение материальных запасов за счет
планирования поставок
к требуемому сроку
Master Production
Scheduling (Планграфик выпуска
продукции)
Среднесрочный объем- Выпуск продукции
но-календарный план к требуемому сроку,
выпуска продукции
сокращение издержек
на хранение
продукции
Material Requirements
Planning (Планирование потребностей
в материалах)
Планирование необходимых материалов по
количеству и срокам
Сокращение времени
простоя из-за нехватки материалов, сокращение материальных
запасов
Lot/Serial Tracking
(Отслеживание
партий/серий)
Учет выпуска партий
продукции
Повышение точности
планирования продаж, сокращение материальных запасов
Rough-Cut Capacity
Planning (Укрупненное
планирование мощностей)
Планирование необходимых мощностей на
основании требуемых
для выпуска видов
продукции ресурсов
Оптимальная загрузка
критических ресурсов
под виды продукции
Производственный блок
Shop Floor Control
Составление опера(Управление на уровне тивных (дни-месяц)
производственного
план-графиков
цеха)
Оптимальная загрузка
цеха, детальное планирование выпуска
продукции
Capacity Requirements
Planning (Планирование потребностей
в мощностях)
Детальное планирование потребных
мощностей до уровня
рабочих центров
Оптимальная загрузка
всех рабочих мест
Project Control (Управление проектом)
Управление проектами предприятия
Выполнение проектов
с требуемым качеством
в заданные сроки
Блок управления издержками
Job Costing (Трудовые
издержки)
114
Рассчитывает трудоза- Выделение затрат,
траты
связанных с работой
персонала
Продолжение табл. 4.1
Функция системы
Позволяет делать
Качественный выигрыш
Cash Flow Analysis
(Анализ наличных
потоков)
Анализ всех денежных потоков предприятия
Оптимальное регулирование денежных
потоков
Actual Costs (Действительные издержки)
Расчет реальной себестоимости
Выявление неэффективных участков и
технологий
Standard Costs (Нормативная стоимость)
Расчет плановой себестоимости
Поддержка процесса
снижения издержек
Work Breakdown
Structure (Стоимость
этапов работ)
Расчет себестоимости
работ по отдельным
этапам
Поддержка процесса
снижения издержек
Блок управления финансами
Accounts Receivable
(Выставленные счета)
Выставление счетов
к оплате
Учет выставленных
счетов
Accounts Payable
(Оплаченные счета)
Регистрация оплаты
счетов
Учет реальной оплаты
выставленных счетов
General Ledger (Главная книга)
Учет всех бухгалтерских операций
Реальная картина
текущего баланса
Multi-Company
Consolidation (Консолидация баланса от
многих компаний)
Объединение баланса
нескольких дочерних
компаний
Реальная картина
баланса нескольких
компаний
Foreign Currency
Conversion (Конвертор
валют)
Работа с несколькими
валютами
Возможность осуществления расчетов в нескольких валютах
Блок маркетинга/продаж
Sales Order
Management (Управление заказами на
продажу)
Учет заказов на
продукцию
Оптимальная загрузка
производства
Order Configurator
(Конфигурация заказов)
Планирование последовательности заказов
Оптимальная загрузка складов, поддержка процесса оптимизации денежных
потоков
Billing/Invoicing
(Выставление счетовфактур)
Ведение книги продаж/покупок
Соответствие законодательству, сокращение затрат
115
Окончание табл. 4.1
Функция системы
Позволяет делать
Качественный выигрыш
Full Sales Analysis
(Полный анализ
продаж)
Анализ всех аспектов
продаж
Повышение достоверности прогнозирования/ планирования
Commission
Calculation/Reporting
(Расчет комиссионных/ отчетность)
Расчет скидок/комиссионных
Гибкая работа с поставщиками и потребителями
Sales Forecasting/
Rollups (Прогнозирование продаж)
Подготовка исходных
данных для производственых планов
верхнего уровня
Повышение достоверности планирования
Quoting
(Квотирование)
Квотирование продаж
Повышение прибыли
за счет управления
спросом
Понятие стратегии СИ включает в себя базовые принципы, используемые при автоматизации предприятия. В ее состав входят
следующие компоненты:
– цели: области деятельности предприятия и последовательность, в которой они будут автоматизированы;
– способ автоматизации: по участкам, направлениям, комплексная автоматизация;
– долгосрочная техническая политика: комплекс внутренних
стандартов, поддерживаемых на предприятии;
– ограничения: финансовые, временные и т.д.;
– процедура управления изменениями плана.
Стратегия автоматизации в первую очередь должна соответствовать приоритетам и стратегии (задачам) бизнеса. В понятие
стратегии также должны входить пути достижения этого соответствия.
Стратегический план автоматизации должен составляться с учетом следующих факторов:
– средний период между сменой технологий основного производства,
– среднее время жизни выпускаемых предприятием продуктов
и его модификаций,
– анонсированные долгосрочные планы поставщиков технических решений в плане их развития,
116
– срок амортизации используемых систем,
– стратегический план развития предприятия, включая планы
слияния и разделения, изменение численности и номенклатуры
выпускаемой продукции,
– планируемые изменения функций персонала.
Автоматизация – лишь один из способов достижения стратегических бизнес-целей, а не процесс, развивающийся по своим
внутренним законам. Во главе стратегии автоматизации должна
лежать стратегия бизнеса предприятия: миссия предприятия, направления и модель бизнеса.
Таким образом, стратегия автоматизации представляет собой
план, согласованный по срокам и целям со стратегией организации.
Второй важной особенностью является степень соответствия
приоритетов автоматизации и стратегии бизнеса, а именно: какие
цели должны быть достигнуты:
– снижение стоимости продукции,
– увеличение количества или ассортимент,
– сокращение цикла: разработка новых товаров и услуг – выход
на рынок,
– переход от производства на склад к производству под конкретного заказчика с учетом индивидуальных требований и т.д.
Стратегические цели бизнеса с учетом ограничений (финансовых,
временных и технологических) конвертируются в стратегический
план автоматизации предприятия.
При этом следует помнить, что автоматизация предприятия является инвестиционной деятельностью и к ней применимы все подходы, используемые при оценке эффективности инвестиций.
К основным ограничениям, которые необходимо учитывать при
выборе стратегии автоматизации, относятся следующие: финансовые, временные, ограничения, связанные с влиянием человеческого фактора, и технические.
Финансовые ограничения определяются величиной инвестиций, которые предприятие способно сделать в развитие автоматизации. Этот тип ограничений наиболее универсален, так как
остальные три вида могут быть частично конвертированы в финансовые.
Временные ограничения обычно связаны со следующими факторами:
– сменой технологий основного производства,
– рыночной стратегией предприятия,
– государственным регулированием экономики.
117
К ограничениям, связанным с влиянием человеческого фактора,
относятся следующие ограничения:
– корпоративная культура – отношение персонала к автоматизации,
– особенности рынка труда, трудовое законодательство.
Типичные проблемы, которые возникают при разработке стратегии
автоматизации, как правило, связаны со следующими факторами:
– состояние рынка информационных технологий,
– определение эффективности инвестиций в информационные
технологии,
– необходимость реорганизации деятельности предприятия при
внедрении информационных технологий.
Анализ и реорганизация деятельности предприятия – довольно
общее понятие. Под анализом деятельности предприятия понимается следующее: сбор и представление информации о деятельности
предприятия в формализованном виде, пригодном для выбора и
дальнейшего внедрения КИС.
В зависимости от выбранной стратегии автоматизации предприятия технологии сбора и представления информации могут быть
различными.
Стандарты IDEF
Итоговое представление информации на этапе анализа деятельности играет одну из ключевых ролей во всей дальнейшей работе.
Желательно, чтобы анализ предприятия закончился построением набора моделей, соответствующих семейству стандартов IDEF
(Integrated DEFinition), разработанных в США в рамках программы
Integrated Computer-Aided Manufacturing (ICAM) [3, 12, 14].
IDEF0 – это классический метод функционального моделирования, представляющий собой переработанный метод SADT (Structured
Analysis and Design Technique). Метод SADT был создан в конце 60-х гг.
как набор рекомендаций по разработке сложных систем, предполагающих активное взаимодействие механизмов и обслуживающего персонала. В конце 70-х гг. ядро SADT было принято ВВС США как часть
программы ICAM (Integrated Computer-Aided Manufacturing – интегрированная компьютерная поддержка производства) и стало основой IDEF0. Довольно быстро IDEF0 стал стандартом моделирования
деятельности в рамках министерства обороны США. В 1993 г. был
создан документированный открытый стандарт для IDEF0, опубликованный как федеральный стандарт обработки информации (Federal
Information Processing Standard – FIPS).
118
IDEF3 – это метод описания бизнес-процессов, который был специально разработан для проекта ВВС США. Метод ориентирован на
получение описания деталей процесса от экспертов в предметной
области и разработки схем таких процессов, для которых важно
понять последовательность выполнения действий и взаимозависимости между ними. Метод может быть также использован при проектировании бизнес-процессов и анализе систем имитационными
методами. IDEF3 получил широкое распространение как средство
детализации схем IDEF0.
Метод DFD (Data Flow Diagrams – диаграммы потоков данных)
получил популярность как структурное средство для разработки
проектов КИС. Диаграммы потоков данных схожи с IDEF0 и IDEF3
и могут быть использованы в сочетании с ними, но обеспечивают возможность одновременного проектирования функций и данных.
Реорганизация деятельности преследует, как правило, цель
повышения эффективности деятельности предприятия в целом.
В понятиях бизнес-процессов она предполагает реорганизацию
полученной модели деятельности предприятия «как есть» (IT-IS)
в оптимизированную с точки зрения стоимости, исключения дублирования функций и т.д. модель «как будет» (TO-BE) с использованием, например, схем стандарта IDEF0.
Функционально-ориентированное управление предприятием
имеет такие отличительные черты:
– разобщенность целей подразделений, несовпадения частных
интересов подразделений с целевыми задачами предприятия;
– потенциальная конфликтность взаимоотношений.
Одной из ключевых проблем сложившихся систем управления
является доминирование функционального управления в организациях, что порождает множество трудностей. Функциональные
структурные подразделения прямо не заинтересованы в общих результатах, поскольку система оценки их деятельности традиционно
оторвана от результативности работы предприятия в целом. Разрушительная конкуренция между ними – результат обособленного положения каждого подразделения внутри предприятия. На практике
это переходит в постоянные конфликты между сотрудниками бухгалтерии, финансового и планово-экономического отделов, между
отделом сбыта и производством, между производством и инженерными службами, между конструкторами и технологами и т.д.
В функционально-ориентированных организационных структурах чрезмерно усложнен обмен информацией между различными
подразделениями. А, как известно, актуальная информация явля119
ется базовым фактором принятия эффективного управленческого
решения.
Наконец, в функционально-ориентированных структурах сотрудники подразделений не ориентированы на целевые задачи
предприятия. Этот подход жив до сих пор, и многие руководители
предприятий убеждены, что альтернативы ему не существует.
Вместе с тем, реальная работа не движется вдоль линейно-функциональной иерархии (такой маршрут имеют поручения руководства,
информация по принятию решений и приказы). Она пронизывает
предприятия в виде набора деловых процессов, которые в большинстве своем никем не управляются и никто за них не отвечает.
Деловой процесс (бизнес процесс, business process) – это логически завершенный набор этапов работы, поддерживающий деятельность предприятия и реализующий его политику, направленную
на достижение поставленных целей.
Как правило, набор деловых процессов для каждого предприятия своеобразен. Такие процессы, так или иначе, существуют на
каждом предприятии. Проблема заключается в их упорядочивании и организации управления.
Большие потенциальные преимущества управления деловыми
процессами заключаются в том, что работа становится более эффективной, поскольку переходит от одного специалиста к другому, от
одного подразделения к другому с меньшим количеством ошибок и
задержек, а требования клиента удовлетворяются вовремя (чего никак не скажешь о функционально-ориентированной организации).
Среди других преимуществ перехода на процессно-ориентированную организацию деятельности можно выделить простоту
проведения оптимизации как самих процессов, с точки зрения их
организации, синхронизации, взаимной согласованности, так и ресурсов, потребляемых процессами, особенно это касается человеческих ресурсов.
Общепризнанно, что одним из важнейших факторов успеха
предприятия является наличие на нем единой мощной «управленческой команды», владеющей ситуацией и работающей согласованно на достижение общей цели. Процессная организация управления в сочетании с другими методами позволяет сформировать
такую команду, ориентированную на единые цели предприятия.
Таким образом, необходимость использования процессного подхода становится все более и более очевидной. Внедрение такого подхода требует осознанной реорганизации деятельности предприятия
на основе принципов процессно-ориентированного управления.
120
Подобная реорганизация требует определенной технологии перехода от существующей системы к новой, соответствующей поставленным целям. На отечественном рынке услуг большое значение
приобретают услуги, связанные с консалтингом, направленным на
совершенствование систем управления предприятий. Вторым важным составляющим такого совершенствования, помимо внедрения
процессно-ориентированного управления, является внедрение современных информационных технологий, в том числе построенных
на основе автоматизированных систем.
Существует также матричный подход, который сочетает в себе
функционально-ориентированный и процессно-ориентированный
подходы. Ответственность за выполнение задания возложена на
исполнителей бизнес-процесса, а ответственность за контроль качества, за своевременность этапов этого бизнес-процесса берут на
себя участники различных функциональных групп. Матричный
подход предполагает дополнительные расходы на согласование
всех этапов бизнес-процесса, поэтому может быть использован
в критических секциях управления предприятием, в случаях,
когда ошибочное решение управления приводит к катастрофическим последствиям.
Таким образом, можно выделить следующие направления совершенствования системы управления предприятия: переход на
процессно-ориентированное управление и внедрение современных
информационных технологий управления.
Выбор системы – многокритериальная задача. Задание объективных критериев, по которым будет осуществляться выбор конкретной системы, напрямую связано с качеством и полнотой проработки
всех предшествующих этапов цепочки выбора.
Практически все объективные соображения, которыми руководствуются при выборе системы (функциональные возможности,
стоимость системы и совокупная стоимость владения, перспективы
развития, поддержки и интеграции, технические характеристики
системы и т.п.), выводятся на предыдущих этапах. При тщательной
проработке всех предшествующих этапов выбор системы перестает
быть проблемой.
Существуют следующие основные стратегии внедрения системы:
Параллельная стратегия – когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если они согласуются длительное время, осуществляется переход на новую систему.
«Скачок». Эта стратегия привлекательна, но не рекомендуется.
121
«Пилотный проект». Это наиболее часто используемая стратегия. «Пилотный проект» – это тактика «скачка», но применяемая к ограниченному числу процессов. Область применения стратегии – небольшой участок деятельности. Такой подход снижает
риск и наиболее надежен. Практически все предприятия применяют эту тактику сегодня.
«Узкое место» – это малая часть производственного процесса.
При использовании подхода «узкое место» план внедрения выполняется только для «узкого места» и для людей, работающих в нем.
Точность данных повышается только для изделий в этом «узком
месте»; переподготовка – только для людей, работающих в нем;
анализ эффекта затрат делается только для него и т.д.
Этап эксплуатации или сопровождения системы в динамично
меняющемся предприятии представляет собой довольно сложную
задачу. Модернизация программно-аппаратной части, вызванная
физическим и моральным старением компонентов АСУ; необходимость отслеживания изменений в законодательстве; необходимость
доработки системы под новые требования ее пользователей; обеспечение безопасности информации в процессе эксплуатации – эти и
многие другие вопросы постоянно встают перед персоналом, ответственным за процесс эксплуатации системы.
Затраты на эксплуатацию системы в рамках предприятия могут
и должны быть снижены за счет качественной проработки предшествующих этапов, в основном, за счет разработки стратегии автоматизации и осуществления выбора системы.
Типичные проблемы при внедрении КИС начинаются с этапа подготовки предприятия к автоматизации. Типичный вариант, при котором работы начинаются с выбора системы, после чего специалисты
поставщика ИС проводят анализ деятельности предприятия (чаще
принято говорить «обследование» предприятия) на выявление некоторых проблем в области управления и формирования соответствующих рекомендаций. Поставщик программного решения может дать
конкретные рекомендации по изменению деятельности предприятия, однако существует большая вероятность, что эти рекомендации
будут отталкиваться от возможностей самого поставщика. И с еще
большей вероятностью все они в конечном итоге будут направлены
на изменение схемы ведения бизнеса предприятия таким образом,
чтобы на нее лучше «легла» их система.
122
ЗАКЛЮЧЕНИЕ
Перспективы использования концепций системной инженерии
в информационном обществе можно сформулировать следующим
образом:
– для того чтобы договариваться и передавать знания всем участникам проекта, необходимо иметь междисциплинарный язык;
– для учета последствий любых решений для всего периода жизни системы и возможности исправлять ошибки на как можно более
ранних стадиях необходимо использовать концепцию ЖЦ;
– для обеспечения накопления и использования всей информации о системе, начиная с самых ранних стадий ЖЦ необходимо руководствоваться идеей моделецентричности.
Системная инженерия – это гармонизация следующих концепций:
– системной (назначение, элементы системы и внешняя среда);
– процессной (деятельность, поведение во времени);
– архитектурной (методы описания и их группировка);
– ЖЦ (4D-эволюция системы);
– оценки зрелости процессов (стадии ЖЦ процесса).
Перечислим подходы, гармонизацию которых в своем составе
предполагает предметная область «системная инженерия».
Переход от редукционистского к системному подходу. Целое невозможно свести к сумме частей этого целого – вот суть системного подхода. Само выделение целого как «фигуры из фона» не
может быть произвольным, то же относится к элементам системы:
важна цель системы, важно взаимодействие элементов для достижения этой цели, а не просто наличие произвольно выбранных частей. Любая система имеет метасистему и подсистемы, т.е. системы
иерархичны. Границы системы с окружающими ее системами важны и требуют явного определения: все участники междисциплинарного обсуждения должны говорить об одной и той же системе
в одних и тех же границах, чтобы не подменять системы в ходе их
обсуждения. Само выделение системы из окружающего мира происходит в форме описаний. Важным является вопрос, являются ли
эти описания частью системы, а также как связаны между собой
системы, выполненные по одним и тем же описаниям разного уровня
абстракции.
Переход от структурного к процессному подходу. Главное,
что происходит в системе – это ее изменения во времени, динамика.
Рассмотрения системы (организационной или технической) с точки зрения его структуры (схемы, отражающей связи элементов123
подсистем) совершенно недостаточно, нужно рассматривать изменения во времени и взаимодействия, разворачиваемые во времени.
Сюда относится концепция полного ЖЦ, все варианты проектного
подхода и связанные с ним методы управления ЖЦ. Тут нужно обратить особое внимание, что в СИ процессы ЖЦ – это процессы,
которые происходят в обеспечивающей системе для продвижения
целевой системы по ее ЖЦ, а не в целевой системе. Поэтому иногда уточняют, что речь идет о процессах управления ЖЦ. Сюда же
можно отнести необходимость перехода (как минимум, в информационном моделировании систем) к представлениям 4D-онтологии,
в которых у объектов есть темпоральные части, и поэтому легче обсуждать изменения объектов во времени, чем в «бытовой»
3D-онтологии.
Переход от одной группы описаний ко множественности
групп описаний. Никакой одной профессиональной точки зрения
недостаточно, чтобы получить более или менее полное описание
системы. Для системы должны быть получены различные группы взаимосвязанных описаний, получаемые междисциплинарно:
в СИ – это стандарт архитектурных описаний.
Переход от рабочего проектирования к обязательному предварительному архитектурному проектированию. Вместо того
чтобы сразу работать с кодом программного продукта, схемами и
чертежами оборудования, инструкциями и прочими реализационными описаниями систем, для начала нужно сделать сущностное,
не зависящее от деталей реализации описание создаваемой системы: архитектуру. Архитектура описывает основные подсистемы
и их взаимодействие в языке, свободном от деталей реализации.
Причем одной архитектуре может соответствовать множество разных реализаций.
Переход от непосредственной реализации к моделецентричной реализации. Вместо того чтобы строить реальную систему, для
начала создаются всевозможные модели системы – как абстрактные архитектурные, так и имитационные, отражающие динамику реализации моделируемой системы. Эти модели представляют
адекватное реальности подробное описание системы, т.е. речь идет
прежде всего об имитационном моделировании, включая имитационные эксперименты с архитектурными моделями. Сначала система «строится» в идеальном мире моделирования и только затем
в реальном мире: все ошибки корректируются на этапе моделирования, а не на этапе реального воплощения. Сюда же относится идея,
что описания системы (включая архитектурные описания) долж124
ны быть представлены не на естественном языке, а на формальном
языке (например, использовать математику не как средство вычисления, а как язык математических схем).
Переход от документоцентризма к датацентризму. Различные описания системы не должны готовиться в форме отдельных документов, а должны храниться в виде взаимосвязанных
отдельных информационных единиц-данных, готовых для объединения в той или иной форме. Речь идет о хранении информации
в виде БД, а в случае интеллектуализации системы для поддержки
принятия решений по управлению объектом в виде БЗ и доступе
к этой информации с разнообразными запросами.
Переход от работы для одного заказчика к работе со множеством заинтересованных сторон. Для любой системы всегда есть
множество заинтересованных сторон, мнение которых нужно учитывать. Это означает, что требования к системе всегда противоречивы, исходят из самых разных источников и нужна специальная
работа по их согласованию: значительная часть этой работы сводится не к техническим решениям, а к проведению переговоров между
заинтересованными лицами. Наличие множества заинтересованных в системе сторон существенно меняет содержание инженерной
деятельности: эта деятельность по «инженерии требований» уже не
проходит в мире исключительно технических решений, а должна
учитывать противоречивые интересы самых разных коллективов.
Переход от проверки к раздельным верификации и валидации. Идея верификации, т.е. проверки на соответствие формальным требованиям, является общепринятой, но более трудно воспринимается идея, что такой проверки явно недостаточно: важно
не столько соответствие требованиям, сколько то, чтобы системой
можно было пользоваться, так как при разработке системы ошибка
могла закрасться в сами требования.
Переход от методов планирования к использованию адаптивных методов прогнозирования. Идея, что любые предсказания будущего (в том числе в таких формах, как тщательно разработанные
планы) являются заведомо неполными и неточными, и с планами
нужно работать, как с «прогнозами», а не «обещаниями», трудно воспринимается. Особенно трудно перейти к риск-ориентированным
формам ЖЦ, подразумевающим пошаговое выделение ресурсов на
основе постоянного пересмотра их выделения на основе непрерывно меняющихся оценок проектной ситуации. Адаптивные методы
ведут к модификациям основных практик СИ, когда планировать
приходится в условиях отсутствия прецедентов (так, идея, что
125
требования должны изменяться в течение всего ЖЦ, воспринимается достаточно трудно, так как в методах «предсказания будущего» все полные и детальные требования должны быть «предсказаны» в самом начале разработки).
Переход от технологического конвейера к заказам-поставкам. Процесс управления ЖЦ нельзя считать «конвейером», простым выполнением серии технологически предписанных работ.
В СИ этот вопрос обсуждается как отдельная группа контрактных
практик, причем самым трудным тут является понимание того факта, что контракты могут быть не только явными между различными юридическими лицами, но и неявными в рамках одной организации. Все это общие подходы (наборы идей), которые применимы
для самых разных типов систем, но на разном материале эти принципы работают по-разному. Можно выделить следующие типы целевых систем, формы жизненных циклов, у которых существенно
различаются: оборудование, программный продукт, организация
(люди). Понятно, что «проектирование сотрудника» или «проектирование организации» по методам существенно отличается от проектирования ПО ИС, а проектирование ПО существенно отличается
от проектирования оборудования. Но, например, переход от идеи
рабочего проектирования к идее обязательной архитектурной (т.е.
без реализационных деталей сущностной «онтологической») проработки конструкции применим ко всем типам, хотя архитектуры
оборудования, программного обеспечения и организации выразимы в абсолютно разных типах описаний, взаимно непонятных для
работающих над созданием оборудования, программного обеспечения и организации специалистов.
Образовательная задача в области информационных технологий
состоит в том, чтобы инсталлировать в головах студентов такой образ
мыслей, который бы позволил гармонизированно применять перечисленные основные подходы СИ к любым системам, не отвлекаясь на
специфику конкретной системы.
126
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Архитектура информационных систем / Б. Я. Советов, А. И. Водяхо, Дубенецкий В. А., Цехановский В.В.: учебник. М.: Изд. центр
«Академия», 2012. 288 с.
2. Батоврин В. К. Системная и программная инженерия. Словарь-справочник: учеб. пособие для вузов. М.: ДМК Пресс, 2010.
280 с.
3. Васильев А. А., Избачков Ю .С., Петров В. Н. Информационные системы. СПб.: Питер, 2011. 544 с.
4. Васильев Р. Б., Калянов Г. Н. Управление развитием информационных систем. М.: Горячая Линия-Телеком, 2009. 350 с.
5. Вдовин В. М., Суркова Л. Е., Валентинов В. А. Теория систем
и системный анализ: учебник. М.: Дашков и Ко, 2012. 639 с.
6. Гаврилов Д. А. Управление производством на базе стандартов
MRP II . СПб.: Питер, 2005. 416 с.
7. Головин Ю. А., Суконщиков А. А., Яковлев С. А. Информационные сети: учебник. М.: Изд. центр «Академия», 2011. 384 с.
8. ГОСТ Р ИСО/МЭК 7498-1-1994 «Информационная технология. Взаимодействие открытых систем. Базовая эталонная модель.
Базовая модель».
9. ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем».
10. ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного
цикла программных средств».
11. Качанова Т. Л., Фомин Б. Ф. Введение в язык систем. СПб.:
Наука, 2009. 148 с.
12. Китова О. В., Абдикеева Н. М. Корпоративные информационные системы управления: учебник. М.: Инфра-М, 2010. 464 с.
13. Косяков А. И., Свит У. Н., Сеймур С. Дж. Системная инженерия. Принципы и практика. М.: ДМК-Пресс, 2014. 624 с.
14. Осипов Л. А., Яковлев С. А. Корпоративные информационные
системы: учеб. пособие. СПб.: ГУАП, 2013. 150 с.
15. Осипов Л. А., Яковлев С. А. Искусственный интеллект и нейронные сети: учеб. пособие. СПб.: ГУАП, 2011. 134 с.
16. Питеркин С. В., Оладов Н. А. Практика применения ERP–
систем. М.: Альпина Паблишер, 2002. 178 с.
17. Попов И. И., Максимов Н. В. Современные информационные
технологии. М.: Форум, 2010. 512 с.
18. Советов Б. Я., Цехановский В. В. Информационные технологии: учебник. М.: Высшая школа, 2008. 263 с.
127
19. Советов Б. Я., Яковлев С. А. Моделирование систем: учебник. 7-е изд. М.: Юрайт, 2014. 343 с.
20. Швецов А. Н., Яковлев С. А. Распределенные интеллектуальные информационные системы. СПб.: СПбГЭТУ «ЛЭТИ», 2003.
318 с.
21. Яковлев С. А. Экспертные системы: учеб. пособие. СПб.: ГУАП,
2011. 142 с.
128
СПИСОК СОКРАЩЕНИЙ
СИ – Системная инженерия
КИС – корпоративная информационная система
ПО – программное обеспечение
СИПО – система инженерного программного обеспечения
ПИ – программная инженерия
ЖЦ – жизненный цикл
ИС – информационно-управляющая система
БД – база данных
БЗ – база знаний
ИАСУ – интегрированная автоматическая система управления
ТПР – типовое проектное решение
ОПП – основной производственный план-график
129
СОДЕРЖАНИЕ
Предисловие.............................................................................
3
Введение...................................................................................
4
1. Системные концепции.............................................................
1.1. Основные термины и определения......................................
1.2. Системная инженерия и современные системы....................
1.3. Концепции жизненного цикла системы..............................
1.3.1. Модели и стадии жизненного цикла.........................
1.3.2. Стадии рассматриваемой системы
и обеспечивающих ее систем............................................
1.4. Концепции процесса........................................................
1.4.1. Процессы жизненного цикла...................................
1.4.2. Ответственность и соглашения внутри
и между организациями..................................................
Ответственность за процесс..............................................
1.4.3. Применение процессов...........................................
13
13
16
22
22
2. Процессы жизненного цикла системы.......................................
2.1. Процессы соглашения......................................................
2.1.1. Процесс приобретения...........................................
2.1.2. Процесс поставки..................................................
2.2. Процессы предприятия....................................................
2.2.1. Процесс управления средой предприятия.................
2.2.2. Процесс управления инвестициями.........................
2.2.3. Процесс управления процессами
жизненного цикла системы.............................................
2.2.4. Процесс управления ресурсами...............................
2.2.5. Процесс управления качеством...............................
2.3. Процессы проекта............................................................
2.3.1. Процесс планирования проекта...............................
2.3.2. Процесс оценки проекта.........................................
2.3.3. Процесс контроля проекта......................................
2.3.4. Процесс принятия решений....................................
2.3.5. Процесс управления рисками..................................
2.3.6. Процесс управления конфигурацией........................
2.3.7. Процесс управления информацией...........................
2.4. Технические процессы.....................................................
2.4.1. Процесс определения требований правообладателей...
2.4.2. Процесс анализа требований...................................
2.4.3. Процесс проектирования архитектуры.....................
2.4.4. Процесс реализации элементов системы...................
2.4.5. Процесс комплексирования....................................
2.4.6. Процесс верификации............................................
2.4.7. Процесс передачи..................................................
2.4.8. Процесс валидации ...............................................
130
24
24
24
26
26
28
31
31
31
32
33
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
50
51
52
53
54
55
2.4.9. Процесс функционирования...................................
2.4.10. Процесс обслуживания.........................................
2.4.11. Процесс изъятия и списания.................................
56
57
58
3. Стадии жизненного цикла системы...........................................
3.1. Модели жизненного цикла................................................
3.2. Стадии жизненного цикла................................................
3.2.1. Стадия замысла.....................................................
3.2.2. Стадия разработки.................................................
3.2.3. Стадия производства..............................................
3.2.4. Стадия применения...............................................
3.2.5. Стадия поддержки применения...............................
3.2.6. Стадия изъятия и списания....................................
61
61
64
65
67
68
69
71
72
4. Применение системной инженерии для реализации
современных корпоративных информационных систем................... 74
4.1. Краткий исторический обзор развития КИС........................ 74
4.2. Основы методологии MRP................................................. 86
4.3. Системы стандарта MRPII................................................ 90
4.4. Системы стандарта ERP................................................... 98
4.5. Системы класса CRM....................................................... 104
4.6. Проблемы внедрения КИС................................................ 110
Заключение.............................................................................. 123
Библиографический список......................................................... 127
Список сокращений.................................................................... 129
131
Учебное издание
Осипов Леонид Андроникович
Яковлев Сергей Алексеевич
ВВЕДЕНИЕ В СИСТЕМНУЮ ИНЖЕНЕРИЮ
Учебное пособие
Редактор В. П. Зуева
Компьютерная верстка М. И. Дударевой
Сдано в набор 01.03.16. Подписано к печати 08.04.16. Формат 60 × 84 1/16.
Бумага офсетная. Усл. печ. л. 7,5. Уч.-изд. л. 8,1.
Тираж 100 экз. Заказ № 160.
Редакционно-издательский центр ГУАП
190000, Санкт-Петербург, Б. Морская ул., 67
Документ
Категория
Без категории
Просмотров
6
Размер файла
2 576 Кб
Теги
osipov, 06ccd291b6
1/--страниц
Пожаловаться на содержимое документа