close

Вход

Забыли?

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

?

OsipovYakovlev 05F123B1B5

код для вставкиСкачать
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ
Л. А. Осипов, С. А. Яковлев
КОРПОРАТИВНЫЕ
ИНФОРМАЦИОННЫЕ СИСТЕМЫ
Учебное пособие
Допущено Учебно-методическим объединением вузов
по университетскому политехническому образованию
в качестве учебного пособия для студентов
высших учебных заведений, обучающихся по направлению
подготовки 230400 – Информационные системы и технологии
Санкт-Петербург
2013
УДК005.9
ББК 32.98
О-74
Рецензенты:
кафедра информационных систем и компьютерных технологий
Балтийского государственного университета «Военмех»
им. Д. Ф. Устинова (зав. кафедрой профессор Н. Н. Смирнова);
доктор технических наук О. И. Кутузов
(профессор кафедры автоматизированных систем
обработки информации и управления Санкт-Петербургского
государственного электротехнического университета «ЛЭТИ»)
Утверждено
редакционно-издательским советом университета
в качестве учебного пособия
Осипов, Л. А.
О-74 Корпоративные информационные системы: учеб. пособие/
Л. А. Осипов, С. А. Яковлев. – СПб.: ГУАП, 2013. – 150 с.: ил.
ISBN 978-5-8088-0858-4
Рассматриваются проблемы автоматизации управленческого
труда. Корпоративные информационные системы (КИС) рассматриваются как современные средства поддержки принятия управленческих решений. Дается краткий исторический обзор развития
информационно-управляющих систем от автоматизированных систем управления предприятиями до современных КИС, приводятся
основные понятия данной предметной области. Основное внимание уделяется архитектурным решениям КИС, MRP- методологии
и программно-технологическим средствам специального класса:
MRPII-, ERP- и CRM- систем.
Для подготовки бакалавров, дипломированных специалистов и
магистров по направлению 230400 – Информационные системы и
технологии.
УДК 005.9
ББК 32.98
ISBN 978-5-8088-0858-4
© Санкт-Петербургский государственный
университет аэрокосмического
приборостроения (ГУАП), 2013
© Л. А. Осипов, С. А. Яковлев, 2013
ПРЕДИСЛОВИЕ
Современный этап развития человечества отличается тем, что
на смену энергетике пришла информатика, характеризующаяся
интенсивным внедрением новых информационных технологий во
все сферы человеческой деятельности. На данном этапе встает реальная проблема перехода в информационное общество, для которого приоритетным должно стать развитие образования.
Поэтому дисциплина «Корпоративные информационные системы» стала основной в структуре подготовки бакалавров и дипломированных специалистов по направлению высшего профессионального образования 230400 – «Информационные системы и технологии».
Содержание учебного пособия соответствует профессиональным
компетенциям дисциплины «Корпоративные информационные системы» вариативной части профессионального цикла дисциплин
примерной основной образовательной программы Федерального
государственного образовательного стандарта высшего профессионального образования по направлению подготовки 230400 – Информационные системы и технологии (утвержден приказом Минобрнауки России от 14 января 2010 г. № 25).
В данном учебном пособии решены следующие основные задачи дисциплины: изучение архитектуры построения и стандартов
управления, реализованных в КИС; изучение рынка программных
средств КИС отечественного и зарубежного производства; освоение
информационных технологий КИС.
Авторы благодарны заведующей кафедрой информационных
систем и компьютерных технологий Балтийского государственного
технического университета «Военмех» профессору Н. Н. Смирновой и профессору кафедры автоматизированных систем обработки
информации и управления» Санкт-Петербургского государственного электротехнического университета «ЛЭТИ», доктору технических наук О. И. Кутузову за ценные замечания, сделанные при
рецензировании рукописи учебного пособия.
3
ВВЕДЕНИЕ
Управление предприятием, а тем более корпорацией, или говоря
современным языком, управление бизнесом, с тех пор как появились первые предприятия, претерпело существенные изменения,
но суть этого процесса осталась та же. Руководитель принимает
решения на основании той информации, которая ему доступна на
момент принятия решения, а подчиненные принимаются с той или
иной степенью прилежания исполнять это решение, как только им
станет оно известно. Очевидно, что эффективность системы управления в целом зависит от следующих аспектов:
− насколько быстро информация о состоянии дел и событиях попадает к руководителю;
− насколько эта информация правильная и своевременная (адекватна и актуальна);
− насколько быстро и достоверно принятое решение будет доведено до исполнителей;
− насколько действен контроль со стороны руководителя над исполнением им же принятых решений.
Невозможно дать общее определение корпоративной информационной системы (КИС) как набору функциональных признаков
исходя из каких-либо общих требований, стандартов. Сформулировать определение КИС возможно только применительно к конкретной компании, которая использует или собирается ее строить.
В общем виде можно дать только некоторые основные признаки
КИС: 1) соответствие потребностям предприятия (корпорации),
2) интегрированность, 3) открытость и масштабируемость.
В первом признаке и скрыты все функциональные признаки
КИС конкретной компании, они строго индивидуальны для каждой компании. Например, для одной компании КИС должна иметь
класс не ниже ERP, а для другой – система такого класса совершенно не оптимальна и только увеличит издержки. Второй и третий
признаки общие, но весьма конкретные.
Корпоративная информационная система – это не совокупность
программ автоматизации бизнес-процессов компании (управления
производством, ресурсами и компанией), это сквозная интегрированная автоматизированная система, в которой каждому отдельному модулю системы (отвечающему за свой бизнес-процесс) в реальном времени (или близком к реальному) доступна вся необходимая
информация, вырабатываемая другими модулями (без дополнительного и, тем более, двойного ввода информации).
4
Корпоративная информационная система должна быть открытой для включения дополнительных модулей и расширения системы как по масштабам и функциям, так и по охватываемым территориям.
Исходя из сказанного можно дать следующее определение КИС.
Корпоративная информационная система – это открытая интегрированная автоматизированная система реального времени
по автоматизации бизнес-процессов компании всех уровней, в том
числе, и бизнес-процессов принятия управленческих решений.
При этом степень автоматизации бизнес-процессов определяется
исходя из обеспечения максимальной прибыли компании.
Для групповых и корпоративных систем существенно повышаются требования к надежности функционирования и сохранности
данных. Эти свойства обеспечиваются поддержкой целостности
данных, ссылок и транзакций в серверах баз.
Наиболее существенной чертой комплексной информационной
системы должно стать расширение контура автоматизации для получения замкнутой, саморегулирующейся системы, способной гибко и
оперативно перестраивать принципы своего функционирования.
В состав КИС должны войти средства для документационного
обеспечения управления, информационной поддержки предметных областей, коммуникационное программное обеспечение (ПО),
средства организации коллективной работы сотрудников и другие
вспомогательные (технологические) продукты. Из этого, в частности, следует, что обязательным требованием к КИС является интеграция большого числа программных продуктов.
Под КИС следует понимать в первую очередь систему и затем
только ПО. Но часто этот термин используется IT-специалистами
в качестве объединяющего названия программных систем семейства CASE, ERP, CRM, MRP и др.
Отметим основные факторы, влияющие на развитие КИС. В последнее время все больше руководителей начинают отчетливо
осознавать важность построения на предприятии КИС как необходимого инструментария для успешного управления бизнесом в современных условиях. Для того чтобы выбрать перспективное ПО
для построения КИС, необходимо осознавать все аспекты развития
основных методологий и технологий разработки.
Существуют три наиболее весомых фактора, которые существенно влияют на развитие КИС.
1. Развитие методик управления предприятием. Теория управления предприятием представляет собой довольно обширный пред5
мет для изучения и совершенствования. Это обусловлено широким
спектром постоянных изменений ситуации на мировом рынке.
Постоянно растущий уровень конкуренции вынуждает руководителей компаний искать новые методы сохранения своего присутствия на рынке и удержания рентабельности своей деятельности.
Такими методами могут быть диверсификация, децентралицация,
управление качеством и многое другое. Современная КИС должна
отвечать всем нововведениям в теории и практике менеджмента.
Несомненно, это самый главный фактор, так как построение продвинутой в техническом отношении системы, которая не отвечает
требованиям по функциональности, не имеет смысла.
2. Развитие общих возможностей и производительности компьютерных систем. Прогресс в области наращивания мощности и
производительности компьютерных систем, развитие сетевых технологий и систем передачи данных, широкие возможности интеграции компьютерной техники с самым разнообразным оборудованием позволяют постоянно наращивать производительность КИС и
их функциональность.
3. Развитие подходов к технической и программной реализации
элементов КИС. На протяжении последних десяти лет параллельно
с развитием «железа» происходит постоянный поиск новых более
удобных и универсальных методов программно-технологической
реализации КИС. Во-первых, изменяется общий подход к программированию: с начала 90-х годов объектно-ориентированное программирование фактически вытеснило модульное, сейчас непрерывно совершенствуются методы построения объектных моделей.
Во-вторых, в связи с развитием сетевых технологий локальные бухгалтерские системы уступают своё место клиент-серверным реализациям. Кроме того, в связи с активным развитием сетей Интернет,
появляются все большие возможности работы с удаленными подразделениями, открываются широкие перспективы электронной
коммерции, обслуживания покупателей через Интернет и многое
другое. Оказалось, что использование Интернет-технологий в интрасетях предприятия также дает очевидные преимущества. Использование определенных технологий при построении информационных систем (ИС) не является самоцелью разработчика, а наибольшее развитие получают те технологии, которые в наибольшей
степени соответствуют существующим потребностям.
Говоря о назначении КИС, необходимо отметить, что их основная
цель – повышение прибыли компании за счет наиболее эффективного
использования всех ресурсов компании и повышения качества при6
нимаемых управленческих решений. Целью проектирования и внедрения КИС является комплексная деятельность по решению бизнесзадач средствами современных информационных технологий.
Корпоративная информационная система как корпоративная
интегрированная информационная система управления предприятия обеспечивает его качественный рост и позволяет:
− визуализировать деятельность предприятия, обеспечив руководству возможность правильно оценить имеющиеся недостатки и отыскать источники потенциала и направления усовершенствования;
− сократить время настройки ИСУ под специфические особенности предприятия;
− отобразить и зафиксировать в готовом для последующего развертывания виде варианты реализации ИСУ, каждый из которых
может быть выбран при переходе на очередную ступень развития
предприятия.
При этом необходимо учитывать совокупную стоимость проекта, включающую стоимость компьютерной техники и коммуникационного оборудования; стоимость лицензий на использование
КИС; стоимость системного ПО и сервера баз данных (СУБД); стоимость обследования и проектирования внедрения и стоимость эксплуатации КИС.
Наиболее часто встречаются следующие виды (классы) КИС.
ERP-системы (Enterprise Resource Planning System). Современные ERP-системы появились в результате почти сорокалетней
эволюции управленческих и информационных технологий. Предназначены они главным образом для построения единого информационного пространства предприятия (объединение всех отделов и
функций), эффективного управления всеми ресурсами компании,
связанными с продажами, производством, учетом заказов. Строится ERP-система по модульному принципу и, как правило, включает в себя модуль безопасности для предотвращения как внутренних, так и внешних краж информации.
Проблемы же возникают в основном из-за неправильности работы или изначального построения плана внедрения системы. Например, урезанные инвестиции в обучение персонала работе в системе существенно снижают эффективность. Поэтому внедряют
ERP-системы, как правило, не сразу в полном объеме, а отдельными модулями (особенно на начальной стадии).
CRM-системы (Customer Relationship Management System).
Широко распространенным в последнее время стал класс систем
по управлению взаимоотношениями с клиентами. CRM-система
7
помогает автоматизировать работу предприятия с клиентами, создать клиентскую базу и использовать ее в целях эффективности
своего дела. Ведь успех любой компании зависит от способности
глубже понимать потребности покупателей и тенденции рынка,
а также реализовать возможности, возникающие на различных
этапах взаимодействия с клиентами. Такие функции, как автоматизация бизнес-процессов по взаимоотношению с клиентом, контроль абсолютно всех сделок (здесь важно отследить наиболее важные и сложные сделки), постоянный сбор информации о клиентах
и анализ всех этапов реализации сделок, являются главными обязанностями систем этого класса.
CRM-системы – не новинка для российского рынка, и ее использование становится обычным бизнес-проектом компании. Большинство экспертов оценивают российский рынок CRM-систем в
120–150 млн долл. и говорят о его постоянном росте. Нынешний
отечественный рынок характеризует фаза накопления компаниями опыта по применению CRM в своем бизнесе. Наиболее активно
CRM применяют компании финансового, телекоммуникационного
и страхового рынков.
Корпоративная информационная система включает компьютерную инфраструктуру организации и базирующиеся на ней взаимосвязанные подсистемы, обеспечивающие решение задач организации. В качестве таких подсистем могут быть:
− информационно-справочные системы, в том числе гипертекстовые и геоинформационные;
− система управления документооборотом;
− система обработки транзакций (действия по изменению информации в базах данных – БД);
− система поддержки принятия решений.
По способу организации КИС делятся:
− на системы файл-сервер;
− системы клиент-сервер;
− трехзвенные системы;
− системы на основе интернет/интранет-технологий.
Под сервером понимается любая система (отдельный компьютер
с соответствующим ПО или отдельная программная система в его
составе), предназначенная для предоставления некоторых вычислительных ресурсов другим системам (компьютерам или программам), называемым клиентами.
Локальные системы предназначены, в основном, для автоматизации учета по одному или нескольким направлениям (бухгалте8
рия, сбыт, склады, учет кадров и т. д.). Стоимость локальных систем колеблется от 5 000 до 50 000 долл.
Финансово-управленческие системы гибко настраиваются на
нужды конкретного предприятия, хорошо интегрируют деятельность предприятия и предназначены, в первую очередь, для учета и
управления ресурсами непроизводственных компаний. Стоимость
финансово-управленческих систем можно условно определить в
диапазоне от 50 000 до 200 000 долл.
Средние интегрированные системы предназначены для управления производственным предприятием и интегрированного планирования производственного процесса. Они по многим параметрам значительно жёстче, чем финансово-управленческие.
Производственное предприятие должно, в первую очередь, работать, как хорошо отлаженные часы, где основными механизмами
управления являются планирование и оптимальное управление запасами и производственным процессом, а не учет количества счетов-фактур за период.
Стоимость внедрения средних систем начинается, как и у финансово-управленческих систем, с 50 000 долл., но, в зависимости
от охвата проекта, может достигать 500 000 долл. и более.
Крупные интегрированные системы отличаются от средних
набором вертикальных рынков и глубиной поддержки процессов
управления большими многофункциональными группами предприятий (холдингов или финансово-промышленных групп). Системы имеют наибольшую функциональность, включая управление
производством, управление сложными финансовыми потоками,
корпоративную консолидацию, глобальное планирование, бюджетирование и пр. Стоимость проекта – более 500 000 долл.
Остановимся на особенностях внедрения КИС. После этапа выбора КИС наступает этап внедрения, важность которого трудно
переоценить. Действительно, все декларируемые разработчиками
корпоративного ПО выгоды и преимущества, получаемые в результате приобретения конкретной КИС, проявятся только в случае ее
успешного внедрения.
Основные трудности при внедрении КИС:
− недостаточная формализация процессов управления на предприятии;
− отсутствие полного понимания у руководителей механизмов
реализации решений и того, как работают исполнители;
− необходимость реорганизации предприятия в ИС;
− необходимость изменения технологии бизнес-процесса;
9
− потребность в привлечении новых специалистов для управления
ИС и переучивание собственных специалистов для работы в системе;
− сопротивление работников и руководителей (в настоящее время играет не малую роль, так как люди еще не привыкли к интеграции в предприятие компьютерных технологий);
− необходимость формирования квалифицированной «команды
внедренцев», в которую включаются сотрудники предприятия и
один из высокопоставленных руководителей предприятия, заинтересованный во внедрении (при отсутствии заинтересованности
прагматический аспект внедрения КИС сводится к минимуму).
Факторами успешного внедрения КИС являются: участие руководства во внедрении; наличие и соблюдение плана внедрения; наличие у менеджеров чётких целей и требований к проекту; участие
во внедрении специалистов компании-клиента (заказчика); качество КИС и команды поставщика решения; проведение реинжиниринга бизнес-процессов до внедрения; наличие у предприятия выработанной стратегии.
Основные сложности в компании при внедрении КИС сводятся к следующим моментам: невнимание руководства к проекту;
отсутствие чётко сформулированных целей проекта; неформализованность бизнес-процессов; неготовность к изменениям; нестабильность законодательства; коррупция; низкая квалификация
кадров; недостаточное финансирование проектов.
Положительными результатами внедрения КИС являются:
− повышение внутренней управляемости компании, гибкости и
устойчивости к внешним воздействиям,
− увеличение эффективности компании, её конкурентоспособности, а в конечном счёте – прибыльность,
− увеличение объёмов продаж,
− снижение себестоимости,
− уменьшение складских запасов,
− сокращение сроков выполнения заказов,
− улучшение взаимодействия с поставщиками.
Преимущества внедрения КИС сводятся к следующим факторам:
− получение достоверной и оперативной информации о деятельности всех подразделений компании;
− повышение эффективности управления компанией;
− сокращение затрат рабочего времени на выполнение рабочих
операций;
− повышение общей результативности работы за счет более рациональной ее организации.
10
1. ОСНОВНЫЕ ПРИНЦИПЫ СОЗДАНИЯ КОРПОРАТИВНЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ
1.1. Описание предметной области КИС
Корпорация должна контролировать и планировать свои расходы и доходы и быть конкурентоспособной на рынке. Современный
рынок требует, чтобы вся продукция удовлетворяла общепризнанным стандартам качества, которые касаются не только качества
конечного продукта, выставляемого на рынке, но и всего процесса
производства этого продукта, начиная от выбора поставщиков и заканчивая сервисным обслуживанием.
В настоящее время всемирное распространение получил комплекс стандартов на систему качества предприятия, разработанный ISO (International Standards Organization), точнее, техническим комитетом ISO/TC 176 (ИСО/ТК 176). Этот комплекс стандартов имеет общее название ISO 9000 (ИСО 9000).
Внедрение и поддержание на предприятии системы качества
в соответствии со стандартами семейства ИСО 9000 предполагает
использование программных продуктов, по крайней мере, трех
классов:
− комплексные системы управления предприятием (автоматизированные информационные системы поддержки принятия
управленческих решений) – АИСППР;
− системы электронного документооборота;
− продукты, позволяющие создавать модели функционирования организации, проводить анализ и оптимизацию ее деятельности (в том числе, системы нижнего уровня класса АСУТП и САПР,
продукты интеллектуального анализа данных, а также ПО, ориентированное исключительно на подготовку и поддержание функционирования систем качества в соответствии со стандартом ИСО
9000).
Это не значит, что любое предприятие, претендующее на соответствие системе качества ИСО 9000, должно обязательно иметь у
себя КИС. Скорее, это значит, что управление огромными объемами данных, которые циркулируют на предприятии, без КИС будет
сопряжено с большими сложностями. Наличие же КИС позволяет
поддерживать требуемый ИСО 9000 уровень качества с меньшими
затратами на ведение документации и принятие решений.
Как считают многие аналитики, опираясь, в частности, на зарубежный опыт, предприятиям с числом работающих более 800 че11
ловек в принципе невозможно обойтись без информационной поддержки при внедрении систем качества.
Таким образом, внедрение системы качества ИСО 9000 и внедрение КИС на предприятии взаимосвязаны. Это позволяет дать следующее (функциональное) определение КИС:
Корпоративная информационная система – это совокупность
ИС отдельных подразделений предприятия, объединенных общим
документооборотом, таких, что каждая из систем выполняет
часть задач по управлению принятием решений, а все системы
вместе обеспечивают функционирование предприятия в соответствии со стандартами качества ИСО 9000.
1.2. Требования к КИС
Исторически сложился ряд требований, предъявляемых к КИС:
− системность;
− комплексность;
− модульность;
− открытость;
− адаптивность;
− надежность;
− безопасность;
− масштабируемость;
− мобильность;
− простота в изучении;
− поддержка внедрения и сопровождения со стороны разработчика.
Рассмотрим эти требования подробнее.
В современных условиях производство не может существовать
и развиваться без высоко эффективной системы управления, базирующейся на самых современных информационных технологиях.
Постоянно изменяющиеся требования рынка, огромные потоки информации научно-технического, технологического и маркетингового характера требуют от персонала предприятия, отвечающего за
стратегию и тактику развития высокотехнологического предприятия, быстроты и точности принимаемых решений, направленных
на получение максимальной прибыли при минимальных издержках. Оптимизация затрат, повышение реактивности производства
в соответствии со все возрастающими требованиями потребителей
в условиях жесткой рыночной конкуренции не могут базировать12
ся только на умозрительных заключениях и интуиции даже самых
опытных сотрудников. Необходим всесторонний контроль над всеми центрами затрат на предприятии, сложные математические методы анализа, прогнозирования и планирования, основанные на
учете огромного количества параметров и критериев и стройной системе сбора, накопления и обработки информации. Экстенсивные
пути решения этой проблемы, связанные с непомерным разрастанием управленческого аппарата, даже при самой хорошей организации его работы не могут дать положительный результат. Переход
на современные технологии, реорганизация производства не могут
обойти и такой ключевой аспект, как управление. И путь здесь может быть только один – создание КИС, отвечающей ряду жестких
требований.
Корпоративная информационная система, прежде всего, должна
отвечать требованиям с и с т е м н о с т и и к о м п л е к с н о с т и. Она
должна охватывать все уровни управления – от корпорации в целом
(с учетом филиалов, дочерних фирм, сервисных центров и представительств) до цеха, участка и конкретного рабочего места и работника. Весь процесс производства с точки зрения информатики
представляет собой непрерывный процесс порождения, обработки, изменения, хранения и распространения информации. Каждое рабочее место – будь то рабочее место сборщика на конвейере,
бухгалтера, менеджера, кладовщика, специалиста по маркетингу
или технолога – это узел, потребляющий и порождающий определенную информацию. Все такие узлы связаны между собой потоками информации, овеществленными в виде документов, сообщений, приказов, действий и т. п. Таким образом, функционирующее
предприятие можно представить в виде информационно-логической модели, состоящей из узлов и связей между ними. Такая модель должна охватывать все аспекты деятельности предприятия,
должна быть логически обоснована и направлена на выявление
механизмов достижения основной цели в условиях рынка – максимальной прибыли, что и подразумевает требование системности.
Достаточно эффективное решение этой задачи возможно только на
базе строгого учета максимально возможного обоснованного множества параметров и возможности многокритериальных поливариантных анализа, оптимизации и прогнозирования, то есть комплексности системы.
Информация в такой модели носит распределенный характер и
может быть достаточно строго структурирована на каждом узле и
в каждом потоке. Узлы и потоки могут быть условно сгруппиро13
ваны в подсистемы, что выдвигает еще одно важное требование к
КИС – м о д у л ь н о с т ь построения. Это требование также очень
важно с точки зрения внедрения системы, поскольку позволяет
распараллелить, облегчить и, соответственно, ускорить процесс
инсталляции, подготовки персонала и запуска системы в промышленную эксплуатацию. Кроме того, если система не создается под
конкретное производство, а приобретается на рынке готовых систем, модульность позволяет исключить из поставки компоненты,
которые не вписываются в инфологическую модель конкретного
предприятия или без которых на начальном этапе можно обойтись,
что позволяет сэкономить средства.
Поскольку ни одна реальная система, даже если она создается
по специальному заказу, не может быть исчерпывающе полной
(нельзя объять необъятное) и в процессе эксплуатации может возникнуть необходимость в дополнениях, а также в силу того, что на
функционирующем предприятии могут быть уже работающие и
доказавшие свою полезность компоненты КИС, следующим определяющим требованием является о т к р ы т о с т ь. Это требование
приобретает особую важность, если учесть, что автоматизация не
исчерпывается только управлением, но охватывает и такие задачи,
как конструкторское проектирование и сопровождение, технологические процессы, внутренний и внешний документооборот, связь
с внешними информационными системами (например, Интернет),
системы безопасности и т. п.
Любое предприятие существует не в замкнутом пространстве, а
в мире постоянно меняющегося спроса и предложения, требующем
гибко реагировать на рыночную ситуацию, что может быть связано
иногда с существенным изменением структуры предприятия и номенклатуры выпускаемых изделий или оказываемых услуг. Кроме
того, в условиях переходной экономики законодательство имеет
неустоявшийся, динамично меняющийся характер. У крупных
корпораций к тому же могут быть экстерриториальные подразделения, находящиеся в зоне юрисдикции других стран или свободных
экономических зон. Это означает, что КИС должна обладать свойством а д а п т и в н о с т и, то есть гибко настраиваться на разное
законодательство, иметь разноязыковые интерфейсы, уметь работать с различными валютами одновременно. Не обладающая свойством адаптивности система обречена на очень непродолжительное
существование, в течение которого вряд ли удастся окупить затраты на ее внедрение. Желательно, чтобы кроме средств настройки
система обладала и средствами развития – инструментарием, при
14
помощи которого программисты и наиболее квалифицированные
пользователи предприятия могли бы самостоятельно создавать необходимые им компоненты, которые органично встраивались бы в
систему.
Когда КИС эксплуатируется в промышленном режиме, она становится незаменимым компонентом функционирующего предприятия, способным в случае аварийной остановки застопорить весь
процесс производства и нанести громадные убытки. Поэтому одним из важнейших требований к такой системе является н а д е ж н о с т ь ее функционирования, подразумевающая непрерывность
функционирования системы в целом даже в условиях частичного
выхода из строя отдельных ее элементов вследствие непредвиденных и непреодолимых причин.
Чрезвычайно большое значение для любой крупномасштабной
системы, содержащей большое количество информации, имеет
б е з о п а с н о с т ь. Требование безопасности включает в себя следующие аспекты:
1. Защита данных от потери. Это требование реализуется, в основном, на организационном, аппаратном и системном уровнях.
Прикладная система, какой является, например, АСУ, не обязательно должна содержать средства резервного копирования и восстановления данных. Эти вопросы решаются на уровне операционной среды.
2. Сохранение целостности и непротиворечивости данных, а
также предотвращение несанкционированного доступа к данным
внутри системы.
3. Прикладная система должна отслеживать изменения во взаимозависимых документах и обеспечивать управление версиями и
поколениями наборов данных.
Эти задачи решаются комплексно как организационными мероприятиями, так и на уровне операционных и прикладных систем.
В частности, прикладные компоненты должны иметь развитые
средства администрирования, позволяющие ограничивать доступ
к данным и функциональным возможностям системы в зависимости от статуса пользователя, а также вести мониторинг действий
пользователей в системе. Предотвращение несанкционированного
доступа к данным извне ложится в основном на аппаратную и операционную среды функционирования КИС и требует ряда административно-организационных мероприятий.
Предприятие, успешно функционирующее и получающее достаточную прибыль, имеет тенденцию к росту, образованию дочерних
15
фирм и филиалов, что в процессе эксплуатации КИС может потребовать увеличения количества автоматизированных рабочих мест,
увеличения объема хранимой и обрабатываемой информации.
Кроме того, для компаний типа холдингов и крупных корпораций
должна быть возможность использовать одну и ту же технологию
управления как на уровне головного предприятия, так и на уровне
любой, даже небольшой входящей в него фирмы. Такой подход выдвигает требование м а с ш т а б и р у е м о с т и.
На определенном этапе развития предприятия рост требований
к производительности и ресурсам системы может потребовать перехода на более производительную программно-аппаратную платформу. Чтобы такой переход не повлек за собой кардинальной ломки управленческого процесса и неоправданных капиталовложений
на приобретение более мощных прикладных компонентов, необходимо выполнение требования мобильности.
П р о с т о т а в и з у ч е н и и – это требование, включающее в
себя не только наличие интуитивно понятного интерфейса программ, но и наличие подробной и хорошо структурированной документации, возможности обучения персонала на специализированных курсах и прохождения ответственными специалистами стажировки на предприятиях родственного профиля, где данная система
уже эксплуатируется.
П о д д е р ж к а со стороны разработчика включает в себя целый
ряд возможностей, таких как получение новых версий ПО бесплатно или с существенной скидкой, получение дополнительной методической литературы, консультации по горячей линии, получение
информации о других программных продуктах разработчика, возможность участия в семинарах, научно-практических конференциях пользователей и других мероприятиях, проводимых разработчиком или группами пользователей и т. д. Естественно, что обеспечить такую поддержку пользователю способна только серьезная
фирма, устойчиво работающая на рынке программных продуктов и
имеющая довольно ясную перспективу на будущее.
В процессе эксплуатации сложных программно-технических
комплексов могут возникать ситуации, требующие оперативного
вмешательства квалифицированного персонала фирмы-разработчика или ее представителя на месте. Сопровождение включает в
себя выезд специалиста на объект заказчика для устранения последствий аварийных ситуаций, техническое обучение на объекте
заказчика, методическую и практическую помощь при необходимости внести изменения в систему, не носящие характер радикаль16
ной реструктуризации или новой разработки. Подразумевается
также установка новых релизов ПО, получаемого от разработчика
бесплатно силами уполномоченной разработчиком сопровождающей организации или силами самого разработчика.
В свою очередь, подсистемы КИС, то есть прикладные системы,
выдвигают ряд требований к среде, в которой они функционируют.
Средой функционирования прикладной системы являются сетевая
операционная система, операционные системы на рабочих станциях, система управления БД и ряд вспомогательных подсистем,
обеспечивающих функции безопасности, архивации и т. п. Как
правило, список этих требований и указания по конкретному набору системного ПО содержатся в документации по конкретной прикладной системе.
1.3. Краткая история развития КИС
Периоды развития взглядов на функции КИС и характерные
названия типов систем в рамках каждого периода показаны на
рис. 1.1. В дальнейшем мы рассмотрим каждый тип систем подробнее. Следует отметить, что система любого типа включает в себя
Сложность
CSRP
ERP
+
Процессы
внешнего и
Управление:
внутреннего
– материальными и
сотрудничества
финансовыми ресурпредприятия
сами,
– закупками и сбытом, Операционные
и
– заказами и поставфинансовые
ками,
процессы
– кадрами,
– основными фондами,
(Customer
– складами
Synchronized
ERP
MRPII
Планирование:
MRP
– материальных
Планирование потребностей,
материальных – продаж и
производства,
потребностей
– потребностей
(Material
в ресурсах
Requirements
(Manufacturing
Planning)
Resources
Planning II)
(Manufacturing
Resources
Planning)
Resources
Planning)
Время
Рис. 1.1. История развития КИС
17
системы более ранних типов. Это значит, что системы всех типов
мирно сосуществуют и ныне.
Рассмотрим основные этапы становления ИС в целом и этапы
развития КИС в частности.
В традиционном понимании ИС – это системы обработки данных
о какой-либо предметной области со средствами накопления, хранения, обновления, поиска и выдачи данных. По средствам выполнения информационной задачи различают ручные, механизированные и механические, электронные и вычислительные системы.
По выполняемым функциям выделяют информационно-поисковые
системы, управляющие, моделирующие, обучающие и многие другие, которые широко применяются во всех отраслях современного
производства и управления.
Рассматривая диапазон возможных значений слов «информация»
и «система», можно предложить ряд более широких толкований термина «информационная система». Можно считать, что он относится
ко всем автоматизированным системам или, в еще более широком
смысле, ко многим системам, в состав которых входят ЭВМ.
Информационные системы предназначены для решения задач обработки данных (Data Processing), автоматизации офисных
работ (Office Automation), а также задач, характерных для экспертных систем. Системы, основной функцией которых является
информационное обеспечение процесса управления, называются
управляющими ИС (Management Information System). Трудности
их разработки обусловлены следующими особенностями:
1) среда, в которой работают ИС, весьма сложна, не полностью
определена и с трудом поддается моделированию;
2) системы имеют сложное сопряжение со средой, выполняющей множество входных и выходных целей;
3) функциональные взаимосвязи входных и выходных сигналов
сложны в структурном, а иногда и в алгоритмическом отношении;
4) обычно включают в себя большие и сложные БД (в перспективе – базы знаний – БЗ);
5) организации-заказчики весьма заинтересованы в постоянной
и продолжительной работоспособности ИС, причем сроки первоначального ввода их в эксплуатацию и последующих модернизаций
устанавливаются крайне сжатыми.
Анализ определений и подходов к понятию «информационная
система» показывает, что это понятие является чрезвычайно широким, охватывающим весьма различные классы систем. Поэтому
авторы данного пособия сосредоточили внимание на более узком
18
классе ИС – «информационно-управляющих системах» (ИУС),
в основном, корпоративного типа, функционирующих на предприятиях или в структурах организационного управления.
Начало практической реализации концепции ИУС (единое информационное пространство, однократный ввод и многократное
использование информации, уменьшение количества бумажных
документов и дублирования информации в них, автоматические
бухгалтерские проводки и т. д.) стало возможным только с появлением компьютеров третьего поколения с такими базовыми элементами, как средства хранения информации большого объема и
средства интерактивного доступа к хранимой информации.
Такие средства появились в начале 70-х годов с выходом на рынок системы IBM/360. Поскольку эти средства стоили дорого, реализацию ИУС могли позволить себе только крупные предприятия.
Например, в 70-х годах ИУС были созданы в United States Steel
Corporation (USX) и British Steel, при этом штаб-квартира и заводы
последней были расположены в нескольких городах, количество
интерактивных терминалов составляло около 2 тысяч, общий объем дисковой памяти – около 750 Gb.
В ИУС первого поколения практически все ПО было создано на
самих предприятиях, приспособлено либо к конкретному предприятию, либо к узкому кругу родственных компаний и требовало
значительных трудозатрат на поддержку силами высококлассных
программистов.
Дальнейшая эволюция ИУС была связана прежде всего с совершенствованием инструмента, обеспечивающего уменьшение трудозатрат на его создание и сопровождение путем углубления специализации, стандартизации и кооперации, а также с появлением
новых средств хранения, переработки и передачи информации.
В конце 70-х – начале 80-х годов появились фирмы, специализирующиеся на разработке и внедрении ИУС. Естественно, перспективными были признаны те, которые использовали типовые бизнес-модели, пригодные для широкого круга предприятий. К этому времени уже существовали методологические проработки таких моделей,
а базовой моделью для ИУС второго, третьего и четвертого поколений стало направление MRP (Material Resource Planning) – MRPII
(Manufacturing Resource Planning) – ERP (Enterprise Resource
Planning).
В основе методологии MRP лежат следующие положения:
− фундаментом таких систем является полная инвентаризация
всех видов ресурсов предприятия в «едином информационном про19
странстве» c обеспечением автоматической поддержки «уникальных идентификаторов» для всех элементов и их использованием во
всех подсистемах ИУС;
− все виды регистрации хозяйственных операций максимально
приближаются к местам их возникновения и обязательно используют общую БД инвентаризации с уникальными идентификаторами;
− базовые понятия в MRP-системах обобщаются и типизируются для любого предприятия (рабочие центры, запасы, центры затрат, маршруты, операции, планирование мощностей и т. п.);
− разработана типовая методология согласования планов и отчетов разных уровней от предприятия и до участков производства;
− MRP-системы унаследовали функциональные возможности
ИУС первого поколения, например автоматическое формирование
бухгалтерских проводок.
Каждый производитель систем класса MRP использовал в основном собственные средства поддержки БД и собственные средства разработки приложений. Впоследствии начали использоваться коммерческие иерархические и сетевые СУБД. Лидерами по
разработке ИУС на основе мэйнфреймов IBM и методологии MRP
стали Computer Associates (CA) и SAР.
В СССР в 80-х годах также активно велись методологические
работы по типизации и стандартизации методов разработки АСУ.
На предприятиях СССР функционировало более трех тысяч АСУ,
которые охватывали технологические процессы, участки и цехи
производства, автоматизировали организационно-экономическую,
технологическую, конструкторскую и научно-исследовательскую
деятельность предприятий.
Существовавшие в то время АСУ автоматизировали лишь часть
функций управления производственными системами, поэтому и была поставлена задача перехода к интегрированным системам управления (ИАСУ). ИАСУ должны были на основе совершенствования
организационных структур управления, рационального использования вычислительных ресурсов и увеличения числа решаемых оптимизационных задач обеспечить интегральную автоматизацию производства на всех уровнях управления, автоматизировать проектирование АСУ на базе унификации и типизации проектных решений.
Типовые проектные решения делились на три уровня реализации: элементные – ориентированные на решение отдельных задач
и функций управления; подсистемные – охватывающие комплекс
задач, связанных по функциональному или производственному
принципу, системные – включающие типовые проекты АСУ.
20
Многие полученные в то время результаты и разработанные интегрированные АСУ опирались на серьезный научный фундамент
и по качеству технических решений не уступали зарубежным аналогам. Но в условиях жесткого централизованного управления
предприятиями, технического отставания средств отечественной
вычислительной техники не мог сформироваться рынок ИС и не
произошло массового перехода предприятий к подлинным ИАСУ.
В конце 80-х годов начали появляться производители нового поколения MRP-систем, чему способствовали следующие предпосылки:
− в компаниях, специализирующихся на создании типовых реляционных СУБД, основанных на стандартах SQL, началось бурное
развитие соответствующих средств разработки, при этом появилось
некоторое количество коммерческих продуктов ведущих компаний;
− произошел спад интереса к мэйнфреймам при одновременном
расцвете открытых систем на основе UNIX, TCP/IP и технологии
клиент/сервер.
Новые поставщики MRP/ERP-систем начали использовать появившиеся на рынке коммерческие реляционные СУБД и средства
разработки от ведущих производителей, ориентированные на SQL
(естественно при этом был сделан акцент на новый уровень открытости и стандартизации технологии клиент/сервер). Это позволяло новым поставщикам, с одной стороны, не тратить ресурсы на
собственные инструментальные средства, а с другой, – оперативно
отслеживать и использовать новые достижения информационных
технологий. Пользователям при внедрении новых систем не требовалось дополнительно изучать новые инструментальные средства,
отличные от стандартно поставляемых на рынок.
Ведущие поставщики MRP/ERP-систем второго поколения (CA,
SAP) и ряд новых производителей (например, BAAN, ICL) также
начали переходить на технологию клиент/cервер, но использовали собственные средства разработки. При этом, с одной стороны,
они могли применять СУБД нескольких фирм (Oracle, Informix,
Sybase, Ingres), но с другой – им было гораздо труднее воспользоваться новыми возможностями очередных версий СУБД.
Системы управления отношений с заказчиками CRM (Customer
Relationship Management) обычно являются внутренними приложениями систем ERP. Целью CRM-систем является предоставление точной оперативной информации о заказчиках и выработка
на ее основе стратегии управления ресурсами предприятия. В подмножество CRM-систем входят системы автоматизации «мощностей продаж» SFA (Sales Force Automation), задача которых – пре21
доставление отделам сбыта в онлайновом режиме свежей информации о клиентах, ассортименте товара, договорах, поставках и т. д.
(со всеми необходимыми документами). Компонентами систем SFA
могут служить так называемые системы электронной коммерции
(E-Purchasing), отвечающие только за сбор заявок от заказчиков.
Если процессы закупки товаров выходят за рамки одного предприятия и охватывают также его поставщиков (логистическую
цепочку), то возникают так называемые отношения Business-toBusiness (B2B). В качестве среды передачи информации между
предприятиями чаще всего используется глобальная сеть Интернет,
а взаимодействие различных программных систем предприятий
обеспечивается связующим ПО промежуточного слоя (middle ware).
Управление расширенной производственной цепочкой обеспечивают системы SCM (Supply Chain Management), то есть управление не только внутренними ресурсами предприятия, но и важнейшими внешними (например, учет заказчиков и поставщиков).
SCM-системы реализуют новейшую технологию управления,
описываемую стандартом CSRP (Customer Synchronized Resource
Planing), который предполагает наличие в системе возможностей
по управлению внешними по отношению к предприятию элементами производственной цепочки. Целью стандарта является управление полным циклом выпуска продукции.
К четвертому поколению ИУС (с точки зрения использования
новых инструментальных средств и дальнейшей специализации)
можно отнести системы со следующими характеристиками:
− активное использование типовых процедур и функций, выполняемых на уровне СУБД;
− использование CASE-средств для поддержки программных систем на всех этапах жизненного цикла ERP-системы;
− применение стандартных средств графического пользовательского интерфейса (в том числе и Web-технологии);
− выделение в подсистемы и типизация аналитических средств
поддержки принятия решений по технологии Data Warehouse,
OLAP-поддержка библиотек типовых бизнес-функций для удобства их реорганизации в процессе эксплуатации.
Информационно-управляющие системы четвертого поколения
получили название КИС, так как в 90-е годы концепция традиционных автоматизированных систем управления (АСУ, АСУП,
ИАСУ) претерпела существенные изменения.
Корпоративные информационные системы (явились результатом эволюционного развития АСУ предприятием. Новые экономи22
ческие условия привели к изменению задач управления предприятиями, поэтому возникли и новые требования к АСУ, главными
из которых являются:
− повышение качества управления за счёт более оперативного и
полного использования информации о ходе производственного процесса, о материальных, финансовых, энергетических потоках, о запасах сырья и материалов;
− определение и эффективное использование комплексных показателей в системах управленческого и бухгалтерского учёта,
улучшающих информационное обеспечение оперативного управления;
− наличие комплексной системы управления финансовым состоянием предприятия, объединённой с информационными БД;
− наличие единого информационного пространства всего предприятия, в состав которого входят фактографические БД, базы
документов, предметно-ориентированные хранилища данных, позволяющие использовать всю накопленную информацию для принятия управленческих решений;
Современная КИС – это «человеко-машинная» система, которая
непосредственно осуществляет организационные, управленческие
и производственные функции предприятия.
Для того чтобы оперативно и обоснованно выработать правильное управляющее воздействие, руководству необходим более глубокий управленческий учёт с точки зрения управления подразделением и предприятием в целом. Управленческий учёт позволяет
анализировать внутренние производственные и хозяйственные
операции более точно, оперативно, вплоть до масштаба реального
времени, определять издержки всего предприятия.
Корпоративные информационные системы – как западные, так
и российские – различаются принципами построения, набором реализованных функций, инструментальными средствами проектирования, способами настройки параметров.
К общим тенденциям создания и развития КИС можно отнести
следующие:
− организация или реорганизация бизнес-процессов;
− разработка системного проекта КИС, ориентированной на поддержку рациональных бизнес-процессов;
− наличие фактически стандартного набора функциональных
подсистем;
− переход на архитектуру клиент-сервер как более эффективную
и перспективную;
23
− широкое использование в качестве основы их функционирования мощных универсальных СУБД типа ORACLE, INFORMIX.
В результате анализа разработок КИС следует выделить типовой
набор функциональных подсистем, который охватывает основные
сферы и уровни управления предприятием, включая в себя полный
комплекс информационных процессов – от учёта выработки на рабочем месте производственного участка до расчёта и предоставления
экономических показателей руководству в целях принятия решений.
Наиболее типичный состав подсистем КИС промышленного предприятия и их функций выглядит следующим образом (табл. 1.1).
Таблица 1.1
Типичный состав подсистем ИС промышленного предприятия
и их функций
Подсистема
Планирование
Анализ
Финансы
Бухгалтерия
Производство
Техобслуживание
Запасы
24
Функции
Маркетинг
Определение потребностей в ресурсах и материалах
Планирование производственных мощностей
Ценообразование
Проектирование
Составление бюджетов
Определение показателей деятельности предприятия
Создание пультов управления
Ведение расчётного счёта
Выполнение кассовых операций
Отслеживание денежных потоков
Ведение платёжных календарей
Составление финансового плана
Ведение главной книги
Бухгалтерия дебиторов
Бухгалтерия кредиторов
Учёт основных средств
Материальный учёт
Начисление заработной платы
Распределение затрат
Ведение отчётности
Учёт выпуска продукции
Оперативное планирование
Планирование ремонта оборудования
Управление заказами на ремонт
Складской учёт
Учёт закупки сырья и комплектующих
Окончание табл. 1.1
Подсистема
Сбыт
Качество
Персонал
Дилерская сеть
Функции
Учёт заказов
Планирование и учёт отгрузки
Фактурирование
Отслеживание качества продукции
Ведение статистического учёта
Анализ качества
Ведение штатного расписания
Определение штатной расстановки
Отслеживание приёма – увольнения персонала
Ведение личных дел
Учёт рабочего времени
Определение затрат на персонал
Составление отчётов
Планирование дилерской сети
Контроль за работой дилеров
Ведение статистического учёта
Анализ деятельности дилеров
Одним из новых уровней специализации в КИС стало выделение
автономных типовых средств OLAP (On Line Analytical Processing).
Ранее аналитические функции типа принятия решений (DSS) включались в MRP/ERP-приложения на уровне модулей. Новые OLAPпродукты реализовались уже на уровне инструментальных средств.
Так, например, Oracle, используя свои инструментальные средства
типа OLAP, создала на прикладном уровне специализированные
подсистемы «Финансовый анализатор» и «Анализатор продаж».
Характерной особенностью новых OLAP-средств является возможность использовать данные из разных систем (разного типа
MRP/ERP- модулей или из собственных систем предприятий), которые могут быть реализованы в различных СУБД. Наряду с появлением новых фирм-поставщиков, сразу ориентированных на
новые средства, важную роль на рынке ERP систем четвертого поколения начали играть производители систем третьего поколения,
которые естественно следовали за эволюцией инструментальных
средств ведущих поставщиков. Так, ESI/Technology перешла на
Oracle Designer/2000 и средства разработки (в GUI) Developer/2000,
а фирма IFS, наряду с новыми возможностями переноса типовых
программ на уровень СУБД, начала использовать объектно-ориентированные CASE-средства фирмы Rational Rose.
25
Из перечисленных основных типовых решений КИС поставщики MRP/ERP систем, ориентированные на собственные нестандартные средства, использовали в основном средства GUI и OLAP,
которые могли быть взяты из других фирм. Что касается таких новых возможностей, как улучшение логической структуры системы
за счет переноса поддержки ограничений целостности БД и типовых программ на уровень СУБД, а также поддержки электронного проекта системы CASE-средствами, то их использование было
принципиально ограничено – требовалась значительная переделка
собственных средств. Кроме того, над поставщиками довлела необходимость поддержки уже внедренных MRP/ERP-систем старого
образца, количество которых значительно превышало долю систем
нового поколения.
Необходимость создания и внедрения КИС обусловлена тем, что:
− они стали необходимым средством успешного функционирования современного предприятия в условиях рынка, так как резко
возрастает спрос на оперативную информацию и требуется высокая
приспособляемость к изменяющимся условиям внутри и вне предприятия;
− происходит переход к единому информационному пространству предприятий, распределенных корпораций и агентов рынка
(Supply Chain Management, Virtual Enterprise, Electronic Company).
В настоящее время на российских предприятиях начинают использоваться системы типа ERP и SCM.
Системы ERP (Enterprise Resource Planning) обеспечивают
управление всеми ресурсами предприятия (производственными,
финансовыми, заказами и т. д.) и являются фактическим стандартом современных интегрированных производственных систем
управления.
Главная задача ERP-систем – добиться оптимизации (по времени и ресурсам) всех перечисленных процессов. Довольно часто вся
присущая концепции ERP совокупность задач реализуется не одной интегрированной системой, а некоторым комплектом ПО. В основе такого комплекта, как правило, лежит базовый ERP-пакет, к
которому через соответствующие интерфейсы подключены специализированные продукты третьих фирм (отвечающие за электронную коммерцию, OLAP, автоматизацию продаж и пр.).
Системы SCM (Supply Chain Management) обеспечивают управление расширенной производственной цепочкой, то есть управление не только внутренними ресурсами предприятия, но и важнейшими внешними (например, учет заказчиков и поставщиков). Си26
стемы SCM реализует новейшую технологию управления, описываемую стандартом CSRP (Customer Synchronized Resource Planning),
который предполагает наличие в системе возможностей по управлению внешними по отношению к предприятию элементами производственной цепочки. Целью стандарта является управление
полным циклом выпуска продукции от проектирования до гарантийного и сервисного обслуживания после продажи.
С точки зрения базовых принципов, заложенных в разработку
представленных на российском рынке программных продуктов,
можно выделить два направления их разработки и развития:
− первое направление берет свое начало в автоматизации учетных бухгалтерских функций, что было актуально в конце 80-х годов и позволяло без больших затрат создавать коммерческие продукты. «Интегрированная система управления» создавалась путем
постепенной разработки и подключения новых модулей к системе
автоматизации бухгалтерии;
− второе направление основано на автоматизации производственных функций. Новые модули системы интегрировались с
производственным ядром «естественным путем», исходя из необходимости обеспечения производства материалами, компонентами, оборудованием, финансами, заказами и т. д. Финансовый учет
и финансовый анализ являются логичным завершением интегрированного решения всех задач при управлении производственным
предприятием.
Основное отличие представленных на российском рынке интегрированных систем управления предприятием друг от друга
заключается в том, что одни из них созданы с учетом требований
стандарта ERP, а другие не отвечают этим требованиям.
К продуктам первого направления относятся практически все
российские системы управления предприятием и некоторые западные системы, которые разрабатывались исходя из автоматизации
финансовых функций («Галактика», «Парус», «Босс», ACPlus,
V-Trade). Объединение различных модулей в системе, спроектированной «в обратном порядке», не позволяет обеспечить подлинную
интеграцию в соответствии со стандартом ERP.
Продуктов второго направления на российском рынке немного. К ним относятся такие известные системы, как SAP/R3, Baan,
Oracle Applications, Renaissance CS, Platinum, Axapta и некоторые
другие.
Причины одновременного существования систем обоих направлений заключаются в следующем:
27
− объективно существует множество предприятий, которым
требуется автоматизация ограниченного числа функций, например финансово-учетных (производственные функции либо вообще
отсутствуют, либо не отличаются сложностью);
− отсутствие у разработчиков средств, достаточных для создания
интегрированной производственной системы современного уровня;
− высокие затраты на покупку и внедрение производственных
систем ERP-класса;
− непонимание руководителями предприятий того, что внедрение современной интегрированной производственной системы имеет не меньшее значение, чем покупка новой автоматической линии
или строительство нового цеха;
− отсутствие у предприятий средств, достаточных для закупки и
внедрения интегрированных производственных систем;
− отсутствие у предприятий детального представления о том,
как они действительно работают, и непонимание существенных отличий одних систем от других.
В первую очередь среди всех ИС выделим два класса (табл. 1.2):
− системы, созданные в соответствии с требованиями стандарта
ERP (ERP-системы);
− системы, не соответствующие требованиям ERP.
Для каждого из этих классов в свою очередь можно выделить
несколько категорий, аналогичных классификации Deloitte &
Touche, когда все автоматизированные ИС, представленные на
рынке в России, могут быть разделены на четыре группы: локальные, малые интегрированные, средние интегрированные и крупные интегрированные.
При выборе КИС первым решением, которое должен принять
руководитель, является решение о том, какого класса система ему
необходима. Это решение зависит от размера компании, характера
ее деятельности и ее возможностей. Например, экономически неоправданно применение ERP-систем для небольших предприятий,
компаний и организаций, которые имеют простой производственный процесс, несложную организационную структуру; консервативны к изменениям.
Для автоматизации управления такими компаниями, как правило, успешно используются локальные или малые системы не
ERP-класса.
Предприятия (крупные и средние), для которых первоочередное
значение имеет управление производством, фактически не имеют
альтернативы ERP-системам. Настоящая интегрируемость, четкая
28
производственная ориентация дают возможность организовать эффективное управление предприятием. Выбор конкретной системы
управления необходимо выполнять внутри ERP-класса.
Таблица. 1.2
Классы КИС (с учетом поддержки ERP-стандарта)
Поддерживающие ERP
Не поддерживающие ERP
Крупные холдинговые промышленМалые предприятия и организаные предприятия, ФПГ, управляющие ции без производства
компании, крупные организации
Небольшие торговые компании
Средние и малые производственные
Небольшие производственные
предприятия
предприятия с простым производПредприятия, организации, компаственным процессом
нии, имеющие сложную распределенную структуру
Развивающиеся предприятия, организации, компании
Для небольших, но развивающихся компаний использование
ERP-систем также эффективно. В этом случае, по мере открытия
новых направлений деятельности, предприятия не будут иметь
проблем с интеграцией автоматизированной системы.
За последние годы со стороны основных производителей корпоративных систем (SAP, Baan, PeopleSoft и Oracle) наметилась тенденция к формированию массового рынка ERP-систем, ориентированного, помимо гигантских корпораций, на средние предприятия.
Существуют также ERP-системы (iRenaissance), специально разработанные для автоматизации средних и малых производственных
предприятий.
В последнее время российские IT-компании создают достаточно
эффективные продукты для автоматизации средних и малых производственных предприятий. Так, например, получает широкое
распространение система «1С: Предприятие» и, в частности, конфигурация «ИТРП: Производственное предприятие 2001 Стандарт».
Кроме того, на практике уже сейчас наблюдается широкое применение отдельных модулей и групп модулей ERP-систем для
управления непроизводственными компаниями и организациями
в областях здравоохранения, энергетики, транспорта, для общественных, учебных организаций, дистрибьюторских и некоторых
других компаний.
Можно прогнозировать в ближайшее время рост интереса со стороны крупных, средних и малых российских предприятий к ERP29
системам. В этих условиях актуальными становятся проблемы выбора конкретной ERP-системы и разработки новых систем такого
класса, учитывающих специфику современного российского производства.
1.4. Основные понятия КИС
Термин «корпорация» (от лат. corporatio – объединение) обозначает группу предприятий, работающих под централизованным
управлением и решающих общие задачи. Как правило, корпорации включают предприятия, расположенные в разных регионах
и даже в различных государствах (транснациональные корпорации).
Корпорация является сложной, многопрофильной структурой
и вследствие этого имеет распределенную иерархическую систему
управления.
Корпоративное управление определяется как система взаимоотношений между акционерами, советом директоров и правлением,
определенных уставом, регламентом и официальной политикой
компании, а также принципом главенства права на основе принятой бизнес-модели.
Б и з н е с - м о д е л ь – это описание предприятия как сложной
системы с заданной точностью. В рамках бизнес-модели отображаются все объекты (сущности), процессы, правила выполнения
операций, существующая стратегия развития, а также критерии
оценки эффективности функционирования системы. Форма представления бизнес-модели и уровень её детализации определяются
целями моделирования и принятой точкой зрения.
И н ф о р м а ц и о н н а я м о д е л ь – подмножество бизнес-модели, описывающее все существующие (в том числе не формализованные в документальном виде) информационные потоки на предприятии, правила обработки и алгоритмы маршрутизации всех
элементов информационного поля.
Предприятия, отделения и административные офисы, входящие в корпорацию, как правило, расположены на достаточном удалении друг от друга. Их информационная связь друг с другом образует коммуникационную структуру корпорации, основой которой
является информационная система.
И н ф о р м а ц и о н н а я с и с т е м а – это вся инфраструктура
предприятия, задействованная в процессе управления всеми ин30
формационно-документальными потоками. В нее входят следующие обязательные элементы:
− информационная модель, представляющая собой совокупность
правил и алгоритмов функционирования ИС и включающая в себя
все формы документов, структуру справочников и данных, и т. д.;
− регламент развития информационной модели и правила внесения в неё изменений;
− кадровые ресурсы (департамент развития, привлекаемые консультанты), отвечающие за формирование и развитие информационной модели;
− программное обеспечение, конфигурация которого соответствует требованиям информационной модели (ПО является основным движителем и одновременно механизмом управления ИС).
Кроме того, всегда существуют требования к поставщику ПО, регламентирующие процедуру технической и пользовательской поддержки на протяжении всего жизненного цикла (ЖЦ);
− кадровые ресурсы, отвечающие за настройку, адаптацию ПО
и его соответствие утвержденной информационной модели;
− регламент внесения изменений в настраиваемые структуры
(специфические настройки, структуры БД и т. д.) и конфигурацию
ПО и состав его функциональных модулей;
− аппаратно-техническая база, соответствующая требованиям
по эксплуатации ПО (компьютеры на рабочих местах, периферия,
каналы телекоммуникаций, системное ПО и СУБД);
− эксплуатационно-технические кадровые ресурсы, включая
персонал по обслуживанию аппаратно-технической базы;
− правила использования ПО и пользовательские инструкции,
регламент обучения и сертификацию пользователей.
Ресурсы корпораций включают: материальные ресурсы (материалы, готовая продукция, основные средства), финансовые ресурсы, людские ресурсы (персонал), знания (ноу-хау), корпоративную
информационную систему.
Комплексная автоматизация бизнес-процессов предприятия на
базе современной аппаратной и программной поддержки может называться по-разному. В настоящее время наряду с названием «корпоративные информационные системы» иногда употребляются,
например, следующие названия:
1) автоматизированные системы управления (АСУ);
2) интегрированные системы управления (ИСУ);
3) интегрированные информационные системы (ИИС);
4) информационные системы управления предприятием (ИСУП).
31
Главная задача КИС – эффективное управление всеми ресурсами предприятия (материально-техническими, финансовыми, технологическими и интеллектуальными) для получения максимальной прибыли и удовлетворения материальных и профессиональных потребностей всех сотрудников предприятия.
Корпоративная информационная система по своему составу –
это совокупность различных программно-аппаратных платформ,
универсальных и специализированных приложений различных
разработчиков, интегрированных в единую информационно-однородную систему, которая наилучшим образом решает в некотором
роде уникальную задачу каждого конкретного предприятия. То
есть КИС – человеко-машинная система и инструмент поддержки
интеллектуальной деятельности человека, которая под его воздействием должна:
− накапливать определенный опыт и формализованные знания;
− постоянно совершенствоваться и развиваться;
− быстро адаптироваться к изменяющимся условиям внешней
среды и новым потребностям предприятия.
Комплексная автоматизация предприятия подразумевает перевод в плоскость компьютерных технологий всех основных деловых процессов организации. И использование специальных программных средств, обеспечивающих информационную поддержку
бизнес-процессов в качестве основы КИС представляется наиболее
оправданным и эффективным. Современные системы управления
деловыми процессами позволяют интегрировать вокруг себя различное ПО, формируя единую информационную систему. Тем самым решаются проблемы координации деятельности сотрудников
и подразделений, обеспечения их необходимой информацией и
контроля исполнительской дисциплины, а руководство получает
своевременный доступ к достоверным данным о ходе производственного процесса и имеет средства для оперативного принятия и
воплощения в жизнь своих решений. И, что самое главное, полученный автоматизированный комплекс представляет собой гибкую
открытую структуру, которую можно перестраивать на ходу и дополнять новыми модулями или внешним ПО.
Под КИС будем понимать информационную систему организации, отвечающую следующему минимальному перечню требований:
1. Функциональная полнота системы:
− выполнение международных стандартов MRP II, ERP, CSRP;
− автоматизация в рамках системы решения задач планирования, бюджетирования, прогнозирования, оперативного (управлен32
ческого) учета, бухгалтерского учета, статистического учета и финансового-экономического анализа;
− формирование и ведение учета одновременно по российским и
международным стандартам:
− количество однократно учитываемых параметров деятельности организации от 200 до 1000, количество формируемых таблиц
баз данных – от 800 до 3000.
2. Надежная система защиты информации:
− парольная система разграничения доступа к данным и реализуемым функциям управления;
− многоуровневая система защиты данных (средства авторизации вводимой и корректируемой информации, регистрация времени ввода и модификации данных).
3. Наличие инструментальных средств адаптации и сопровождения системы:
− изменение структуры и функций бизнес-процессов;
− изменение информационного пространства;
− изменение интерфейсов ввода, просмотра и корректировки информации;
− изменение организационного и функционального наполнения
рабочего места пользователя;
− генератор произвольных отчетов;
− генератор сложных хозяйственных операций;
− генератор стандартных форм.
4. Реализация удаленного доступа и работы в распределенных
информационных сетях.
5. Обеспечение обмена данными между разработанными ИС и
другими программными продуктами, функционирующими в организации.
6. Возможность консолидации информации:
− на уровне организации – объединение информации филиалов,
холдингов, дочерних компаний и т. д.;
− на уровне отдельных задач (планирование, учет, контроль);
− на уровне временных периодов – для выполнения анализа финансово-экономических показателей за период, превышающий отчетный период.
7. Наличие специальных средств анализа состояния системы в
процессе эксплуатации:
− анализ архитектуры БД;
− анализ алгоритмов;
− анализ статистики количества обработанной информации;
33
− журнал выполненных операций;
− список работающих станций-серверов;
− анализ внутрисистемной почты.
Наиболее развитые КИС предназначены для автоматизации
всех функций управления корпорацией: от научно-технической и
маркетинговой подготовки ее деятельности до реализации ее продукции и услуг. В настоящее время КИС имеют в основном экономическую и производственную направленность.
1.5. Особенности разработки
и внедрения КИС
Для повышения эффективности и минимизации издержек
управления (временных, ресурсных и финансовых), разрабатываются и применяются КИС, помогающие осуществлять контроль
бюджетных процессов, рабочего времени сотрудников, выполненных ими работ, хода реализации проектов, документооборота и
других управленческих функций. Доступ к подобного рода данным
может быть осуществлён как в локальной сети, так и через Интернет. С помощью эффективной КИС можно значительно упростить
процессы контроля и управления на предприятии любого уровня.
Разработка и реализация ИС – одно из основных направлений деятельности предприятия. Этот процесс начинается с анализа деятельности предприятия и заканчивается внедрением разработанной системы. Основные этапы этого процесса:
1) проведение предпроектного обследования,
2) формулирование целей и ограничений проекта, разработка
стратегии реализации проекта,
3) инжиниринг и реинжиниринг бизнес-процессов заказчика,
консалтинг в различных областях,
4) выбор платформы, разработка системы, интеграция с используемым ПО,
5) поставка оборудования и ПО,
6) пусконаладочные работы по вводу системы в эксплуатацию,
7) сопровождение созданной системы в процессе эксплуатации,
работы по ее дальнейшему развитию.
Корпоративные информационные системы являются важнейшим инструментом внедрения новых методов управления и реструктуризации предприятий и корпораций. Обусловлено это не
только положительной динамикой развития экономики, но и тем,
34
что сегодня предприятия уже обладают значительным опытом использования программных продуктов различного класса.
Основная задача проектирования и внедрения КИС как результата системной интеграции – комплексная деятельность по решению бизнес-задач средствами современных информационных технологий. Разработка проекта ИС ведется совместно с клиентом, что
позволяет создать успешно работающую и удовлетворяющую все
потребности заказчика КИС.
Спектр бизнес-процессов, реализованных в различных КИС,
может быть достаточно широк. Среди прочего это и управление
продажами в различных формах, например продажа в кредит или
продажа с оплатой встречным обязательством, разнообразные бизнес-процессы, связанные с планированием, закупками, производством, хранением, персоналом и многое-многое другое.
Информационная система может строиться с применением послойного принципа. Так, в отдельные слои можно выделить специализированное ПО (офисное, прикладное), систему управления
документами, программы поточного ввода документов, а также
вспомогательное ПО для связи с внешним миром и обеспечения
доступа к функционалу системы через коммуникационные средства (e-mail, Internet/Intranet). Среди преимуществ такого подхода следует отметить возможность внесения изменений в отдельные программные компоненты, расположенные в одном слое, без
необходимости коренных переделок на других слоях, обеспечить
формальную спецификацию интерфейсов между слоями, поддерживающих независимое развитие информационных технологий и
реализующих их программных средств. Причем применение открытых стандартов позволит безболезненно осуществлять переход
с программных модулей одного производителя на программы другого (например, замена почтового сервера или СУБД). Кроме того,
послойный подход позволит повысить надежность и устойчивость
к сбоям системы в целом.
Если представить предприятие в качестве живого организма, то
КИС лучше всего подходит на роль его нервной системы, пронизывающей все органы, все частички корпоративного организма.
Как отмечалось ранее, повышение внутренней управляемости,
гибкости и устойчивости к внешним воздействиям увеличивает эффективность компании, её конкурентоспособность, а в конечном
счёте – прибыльность. Вследствие внедрения КИС увеличиваются
объёмы продаж, снижается себестоимость, уменьшаются складские запасы, сокращаются сроки выполнения заказов, улучшается
35
взаимодействие с поставщиками. Но, несмотря на привлекательность приведённых утверждений, вопрос об окупаемости инвестиций в КИС не теряет свою актуальность. Соотношение выгоды от
использования системы и ее стоимости является одним из наиболее
важных факторов, оказывающих влияние на решение «покупать
или не покупать». Любой инвестиционный проект, а внедрение
КИС, несомненно, нужно рассматривать как инвестиционный проект, представляет собой своего рода «покупку» и, соответственно,
требует оценки его стоимости и ожидаемой выгоды.
Прямую окупаемость КИС посчитать непросто, поскольку в результате внедрения оптимизируется внутренняя структура компании, снижаются трудноизмеримые транзакционные издержки.
Сложно определить, например, в какой степени увеличение доходов компании явилось следствием работы КИС (иначе – программной системы), а в какой – результатом настройки бизнес-процессов,
то есть плодом управленческих технологий. Однако в некоторых
аспектах деятельности компании оценка вполне реальна. В первую очередь это касается логистики, где внедрение КИС приводит
к оптимизации материальных потоков и к снижению потребности
в оборотных средствах. Постановка на базе КИС системы финансового контроллинга приводит к снижению накладных затрат компании, ликвидации убыточных подразделений и исключению из
ассортимента нерентабельных продуктов.
Совсем трудно оценить эффект от ликвидации хаоса. Для того
чтобы это сделать, нужно чётко представлять масштабы хаоса,
что в силу самой природы беспорядка невозможно. Действительно, можно ли сказать, сколько денег компания не зарабатывает
(то есть теряет) из-за перекосов в ассортименте или, скажем, из-за
срыва сроков исполнения заказов? Какие ресурсы компании оказываются выведенными из оборота вследствие «посмертного» учёта и нестыковки данных в бухгалтерии, на складе и в цехах? А как
оценить объём воровства и разбазаривания ресурсов?
В настоящее время для оценки эффективности IT-проектов применяется метод инвестиционного анализа (Cost Benefit Analysis –
CBA), в основе названия которого лежит оценка и сравнение выгод
от осуществления проекта, с затратами на его реализацию.
Глобальная цель внедрения КИС – повышение эффективности
компании. Каждая компания определяет ключевые сферы, влияющие на ее эффективность, так называемые «критические факторы
успеха» (Critical Success Factor – CSF). Повышение эффективности
происходит за счет реализации задач в каждой из ключевых обла36
стей. Поэтому в основе СВА лежат именно бизнес-цели компании,
определенные на этапе стратегического планирования.
Но достигнуть цели можно несколькими путями, поэтому второй краеугольный камень СВА – сравнение альтернативных вариантов. При этом одним из возможных является вариант «без КИС»,
то есть рассматривается развитие во времени текущей ситуации без
внесения в нее каких-либо изменений. Сравнение альтернативных
вариантов производится на основании измерения приносимых ими
выгод и требуемых для этого затрат. Учитываются как количественные, так и качественные показатели. Анализу качественных
показателей в последнее время уделяется особое внимание. Помимо соотношения выгод и затрат, альтернативные варианты также
отличаются степенью риска и факторами, которые эти риски определяют. Поэтому анализ влияния таких факторов на соотношение
выгод и затрат является еще одной сферой внимания СВА.
1.6. Принципы и этапы построения КИС
Концепция построения КИС предусматривает наличие следующих типовых компонентов:
1) ядро системы, обеспечивающее комплексную автоматизацию
совокупности бизнес-приложений, содержит полный набор функциональных модулей для автоматизации задач управления;
2) система автоматизации документооборота в рамках корпорации;
3) вспомогательные инструментальные системы обработки информации (экспертные системы, системы подготовки и принятия
решений и др.) на базе хранилищ данных КИС;
4) программно-технические средства системы безопасности КИС;
5) сервисные коммуникационные приложения (электронная почта, ПО удаленного доступа);
6) компоненты интернет/интранет для доступа к разнородным
БД и информационным ресурсам, сервисным услугам;
7) офисные программы – текстовый редактор, электронные таблицы, СУБД настольного класса и др;
8) системы специального назначения – САПР, АСУТП, банковские системы и др.
Ядром каждой производственной системы являются воплощенные в ней рекомендации по управлению производством. На данный
момент существует несколько сводов таких рекомендаций. Они
37
представляют собой описание общих правил, по которым должны
производиться планирование и контроль различных стадий деятельности корпорации. Далее рассмотрим некоторые из существующих технологий управления.
К основным принципам построения КИС относятся следующие.
1. Принцип интеграции, заключающийся в том, что обрабатываемые данные вводятся в систему только один раз и затем многократно используются для решения возможно большего числа задач.
2. Принцип системности, заключающийся в обработке данных
в различных разрезах, чтобы получить информацию, необходимую
для принятия решений на всех уровнях и во всех функциональных
подсистемах и подразделениях корпорации; внимание не только
к подсистемам, но и к связям между ними; эволюционный аспект –
все стадии эволюции продукта, в фундаменте КИС должна лежать
способность к развитию.
3. Принцип комплексности, подразумевающий автоматизацию
процедур преобразования данных на всех стадиях продвижения
продуктов корпорации.
К основным этапам проектирования КИС относятся:
− анализ: обследование и создание моделей деятельности организации, анализ (моделей) существующих КИС, анализ моделей и
формирование требований к КИС, разработка плана создания КИС;
− проектирование: концептуальное проектирование, разработка
архитектуры КИС, проектирование общей модели данных, формирование требований к приложениям;
− разработка: разработка, прототипирование и тестирование
приложений, разработка интеграционных тестов, разработка пользовательской документации;
− интеграция и тестирование: интеграция и тестирование приложений в составе системы, оптимизация приложений и БД, подготовка эксплуатационной документации, тестирование системы;
− внедрение: обучение пользователей, развертывание системы
на месте эксплуатации, инсталляция баз данных, эксплуатация;
− сопровождение: регистрация, диагностика и локализация
ошибок, внесение изменений и тестирование, управление режимами работы КИС.
Одной из старейших последовательностей шагов разработки ПО
является классический ЖЦ. Чаще его называют каскадной или
водопадной моделью, подчеркивая, что разработка рассматривается как последовательность этапов, причем переход на следующий
иерархически нижний этап происходит только после полного за38
вершения работ на текущем этапе и возврата к пройденным этапам
не предусматривается.
Приведем краткое описание основных этапов разработки КИС.
Ее создание начинается на системном уровне и проходит через анализ, проектирование, кодирование (реализация), тестирование и
сопровождение. При этом моделируются действия стандартного
инженерного цикла.
Системный анализ определяет роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Анализ начинается с определения требований и назначения подмножества этих требований программному элементу.
На этом этапе начинается решение задачи планирования проекта ПО. В ходе планирования проекта определяются: объем проектных работ, риск проектных работ, необходимые трудозатраты,
формируются рабочие задачи и план-график работ.
Анализ требований, относящийся к программному элементу,
то есть к ПО, уточняет и детализирует: функции, характеристики,
интерфейс ПО. Все определения документируются в спецификации
анализа.
Проектирование создает представления: архитектуры, модульной структуры, алгоритмической структуры ПО, структуры
данных, входного и выходного интерфейсов (входных и выходных
форм данных).
Кодирование (реализация) состоит в переводе результатов проектирования в текст на языке программирования.
Тестирование – это выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.
Сопровождение – это внесение изменений в эксплуатируемое
ПО. Цели изменений: исправление ошибок, адаптация к изменениям внешней для ПО среды, усовершенствование ПО по требованию
заказчика. Сопровождение ПО состоит в повторном применении
каждого из предшествующих шагов (этапов) ЖЦ, то есть системного анализа, анализа требований, проектирования и т. д., к существующей программе, но не разработке новой программы.
Каждая стадия (этап) завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла
быть продолжена другой командой разработчиков.
Достоинствами классического ЖЦ являются: получение плана
и временного графика по всем этапам проекта, упорядочение хода
разработки.
39
К недостаткам классического ЖЦ относятся: частое отклонение реальных проектов от стандартной последовательности шагов,
ориентация цикла на точной формулировке исходных требований
к ПО, тогда как реально в начале проекта требования заказчика
определены лишь частично, доступность результатов проекта заказчику лишь в конце работы.
Рассмотрим особенности макетирования (прототипирования).
На начальной стадии проекта полностью и точно сформулировать
все требования к будущей модели невозможно, поскольку пользователи, как правило, не в состоянии изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки,
и, кроме того, за время разработки могут произойти изменения во
внешней среде, которые могут повлиять на требования к системе.
Поэтому процесс создания ПО носит скорее итерационный характер, когда результаты очередной стадии разработки могут вызвать
необходимость возврата к предыдущим разработкам.
Поэтому ПО создается не сразу, как в случае каскадного подхода, а постепенно с использованием макетирования (прототипирования), когда создается модель требуемого программного продукта.
Под прототипом понимается действующий программный компонент, реализующий отдельные функции.
Модель может принимать одну из трех форм: бумажный макет
или макет на основе компьютера (изображает или рисует человеко-машинный диалог); работающий макет (выполняет некоторую
часть требуемых функций); программа, характеристики которой
затем должны быть улучшены.
Макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик. Поскольку
часто заказчик не может определиться в своих требованиях по разрабатываемому продукту, а проектировщик сомневается в полноте и целесообразности требований заказчика, то прототипирование
(макетирование) начинается со сбора и уточнения требований к
создаваемому ПО.
Совместными усилиями разработчик и заказчик определяют
все цели ПО, устанавливают, какие требования известны, а какие
предстоит доопределить. Следующим шагом является быстрое проектирование, внимание в котором сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю. Макет (прототип), построенный на этапе быстрого проектирования,
оценивается заказчиком и используется для уточнения требований
к ПО. Итерации повторяются до тех пор, пока макет не выявит все
40
требования заказчика и не даст возможности разработчику понять,
что должно быть сделано.
Достоинством макетирования является обеспечение определения полных требований к ПО. К недостаткам макетирования относится возможность принятия заказчиком и/или разработчиком
макета за продукт.
Заказчик, получивший предварительную версию (макет) и удостоверившийся в ее работоспособности, может перестать видеть
недостатки и нерешенные вопросы ПО и перестать соглашаться
на дальнейшее усовершенствование, требуя скорейшего преобразования макета в рабочий продукт. В то же время для экономии
времени разработки макета, а также возможности показать работающий вариант разработчик может использовать неэффективные
средства. Забывая о причинах, побудивших использовать эти средства, разработчик может интегрировать неэффективный вариант
в систему.
Стратегии разработки ПО можно подразделить на три группы:
1. Линейная последовательность этапов разработки – однократный проход (водопадная стратегия).
2. Инкрементная стратегия, когда сначала определяются все
требования (пользовательские и системные), а затем оставшаяся
часть разработки выполняется в виде последовательности версий,
первая из которых реализует часть запланированных возможностей, а все последующие версии – дополнительные возможности до
тех пор, пока не будет получена полная система.
3. Эволюционная стратегия, при которой начальный этап не содержит полного объема требования, они уточняются в ходе разработки новых последовательных версий.
И н к р е м е н т н а я модель является классическим примером
инкрементной стратегии разработки ПО, объединяя элементы последовательной водопадной модели с итерационной философией макетирования. Она представляет собой несколько поставок
(инкрементов), включающих последовательность анализа, проектирования, кодирования и тестирования. Разработка первого
инкремента позволяет получить базовый продукт, реализующий
базовые требования, при этом многие вспомогательные требования остаются нереализованными. План следующих инкрементов предусматривает последовательную модификацию базового
продукта, обеспечивающую дополнительные характеристики
и функциональность. По своей природе инкрементный процесс
итеративен, но в отличие от макетирования инкрементная мо41
дель обеспечивает в конце инкрементной итерации работающий
продукт.
Эволюционную стратегию рассмотрим на примерах спиральной
и компонентно-ориентированной моделей и тяжеловесных и облегченных процессов проектирования.
С п и р а л ь н а я модель опирается на лучшие свойства классического ЖЦ и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих шагах разработки. Она
определяет планирование (определение целей, вариантов, ограничений), анализ риска (анализ вариантов и распознавание/выбор
риска), конструирование (разработка продукта следующего уровня), оценивание (оценка заказчиком текущих результатов разработки). С каждой итерацией по спирали (продвижением от центра
к периферии) строятся все более полные версии ПО. В первом витке
спирали определяются:
− начальные цели, варианты и ограничения;
− распознавание и анализ риска;
− необходимость использования макетирования;
− оценка заказчиком конструктивной работы и внесение предложения по модификации;
− следующая фаза планирования и анализа риска, базируемая
на предложениях заказчика.
В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком
велик, проект может быть остановлен. В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование, которое может быть реализовано
классическим ЖЦ или макетированием.
К достоинствам спиральной модели относится: наиболее реальное (в виде эволюции) отображение разработки ПО; возможность
явно учитывать риск на каждом витке эволюционной разработки;
включение шага системного подхода в итерационную структуру
разработки; использование моделирования для уменьшения риска
и совершенствования программного изделия.
Недостатками спиральной модели являются: повышенные требования к заказчику и трудности контроля и управления временем
разработки.
К о м п о н е н т н о - о р и е н т и р о в а н н а я модель является развитием спиральной модели и основывается на эволюционной стратегии разработки ПО. В этой модели конкретизируется содержание
42
конструирования: оно отображает тот факт, что в современных
условиях новая разработка должна основываться на повторном использовании существующих программных компонентов.
К достоинствам компонентно-ориентированной модели относятся: уменьшение времени разработки ПО; снижение стоимости
программной разработки; повышение производительности разработки.
Традиционно для упорядочения и ускорения программных разработок использовались строго упорядочивающие так называемые
тяжеловесные процессы. В этих процессах прогнозируется весь
объем предстоящих работ, поэтому они называются прогнозирующимися процессами. Порядок, который должен выполнять при
этом человек-разработчик, чрезвычайно строг.
В последние годы появилась группа новых облегченных процессов разработки ПО – так называемых подвижных процессов. Эти
процессы привлекательны отсутствием бюрократизма, характерного для тяжеловесных (прогнозирующих) процессов. Облегченные процессы разработки ПО воплощают разумный компромисс
между строгой дисциплиной и ее отсутствием.
Подвижные процессы требуют меньшего объема документации
и ориентированы на человека, учитывают особенности современного заказчика, а именно частые изменения его требований к ПО.
Подвижные процессы адаптируют изменения требований (адаптивная природа).
43
2. КЛАССИФИКАЦИЯ И ХАРАКТЕРИСТИКИ
КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
2.1. Классификация КИС
Корпоративные информационные системы можно разделить на
два класса: финансово-управленческие и производственные.
1. Финансово-управленческие системы включают подкласс малых интегрированных систем. Такие системы предназначены для
ведения учета по одному или нескольким направлениям (бухгалтерия, сбыт, склад, кадры и т. д.). Системами этой группы может
воспользоваться практически любое предприятие. Системы этого
класса обычно универсальны, цикл их внедрения невелик, иногда
можно воспользоваться «коробочным» вариантом, купив программу и самостоятельно установив ее на ПК.
2. Производственные системы (также называемые системами
производственного управления) включают подклассы средних и
крупных интегрированных систем. Они предназначены в первую
очередь для управления и планирования производственного процесса. Учетные функции, хотя и глубоко проработаны, играют
вспомогательную роль, и порой невозможно выделить модуль бухгалтерского учета, так как информация в бухгалтерию поступает
автоматически из других модулей.
Финансово-управленческие системы (особенно системы российских разработчиков) значительно более гибкие в адаптации
к нуждам конкретного предприятия. Часто предлагаются «конструкторы», с помощью которых можно практически полностью
перестроить исходную систему, самостоятельно или с помощью поставщика установив связи между таблицами БД или отдельными
модулями.
Эти системы функционально различны: в одной может быть хорошо развит производственный модуль, в другой – финансовый.
Сравнительный анализ систем такого уровня и их применимости
к конкретному случаю может вылиться в значительную работу.
А для внедрения системы нужна целая команда из финансовых,
управленческих и технических экспертов. Производственные системы значительно более сложны в установке (цикл внедрения может занимать от 6–9 месяцев до полутора лет и более). Это обусловлено тем, что система покрывает потребности всего предприятия,
что требует значительных совместных усилий сотрудников предприятия и поставщиков программ.
44
Производственные системы часто ориентированы на одну или
несколько отраслей и/или типов производства: серийное сборочное
(электроника, машиностроение), мелкосерийное и опытное (авиация, тяжелое машиностроение), дискретное (металлургия, химия,
упаковка), непрерывное (нефтедобыча, газодобыча).
Специализация отражается как в наборе функций системы, так
и в существовании бизнес-моделей данного типа производства. Наличие встроенных моделей для определенного типа производства
отличает производственные системы друг от друга. У каждой из
них есть глубоко проработанные направления и функции, разработка которых только начинается или вообще не ведется.
Производственные системы по многим параметрам значительно
более жестки, чем финансово-управленческие. Основное внимание
уделяется планированию и оптимальному управлению производством. Эффект от внедрения производственных систем проявляется
на верхних эшелонах управления предприятием, когда становится
видна вся картина его работы, включая планирование, закупки,
производство, сбыт, запасы, финансовые потоки и другие аспекты.
При увеличении сложности и широты охвата функций предприятия системой возрастают требования к технической инфраструктуре и программно-технической платформе. Все производственные
системы разработаны с помощью промышленных БД. В большинстве случаев используются технология клиент-сервер или интернет-технологии.
Для автоматизации больших предприятий в мировой практике
часто используется смешанное решение из классов крупных, средних и малых интегрированных систем. Наличие электронных интерфейсов упрощает взаимодействие между системами и позволяет
избежать двойного ввода данных.
При этом различают виды КИС, такие как заказные (уникальные) и тиражируемые системы.
Под з а к а з н ы м и КИС обычно понимают системы, создаваемые для конкретного предприятия, не имеющего аналогов и не
подлежащие в дальнейшем тиражированию. Подобные КИС используются либо для автоматизации деятельности предприятий с
уникальными характеристиками либо для решения крайне ограниченного круга специальных задач. Заказные КИС, как правило,
либо вообще не имеют прототипов, либо использование прототипов
требует значительных его изменений, имеющих качественный характер. Разработка заказной КИС характеризуется повышенным
риском в плане получения требуемых результатов.
45
Суть проблемы адаптации т и р а ж и р у е м ы х КИС, то есть приспособления к условиям работы на конкретном предприятии в том,
что в конечном итоге каждая система уникальна, но вместе с тем
ей присущи и общие, типовые свойства. Требования к адаптации
и сложность их реализации существенно зависят от проблемной
области, масштабов системы. Даже первые программы, решавшие
отдельные задачи автоматизации, создавались с учетом необходимости их настройки по параметрам.
Разработка КИС на предприятии может вестись как «от нуля»,
так и на основе референционной модели. Референционная модель
представляет собой описание облика системы, функций, организованных структур и процессов, типовых в каком-то смысле (отрасль,
тип производства и т. д.). В ней отражаются типовые особенности,
присущие определенному классу предприятий. Ряд компанийпроизводителей, адаптируемых (тиражируемых) КИС совместно
с крупными консалтинговыми фирмами, в течение ряда лет ведет
разработку референционных моделей для предприятий автомобильной, авиационной и других отраслей.
Возможности адаптации и референционные модели входят в состав многих систем класса MRPII/ERP, что позволяет значительно
сократить сроки их внедрения на предприятия.
Референционная модель в начале работы по автоматизации
предприятия может представлять собой описание существующей
системы IT-IS (как есть) и служит точкой отсчета, с которой начинаются работы по совершенствованию КИС.
Используется также следующая классификация, согласно которой КИС делятся на три большие группы: простые («коробочные»);
среднего класса; высшего класса.
Простые («коробочные») КИС реализуют небольшое число бизнес-процессов организации. Типичным примером систем подобного типа являются бухгалтерские, складские и небольшие торговые
системы, наиболее широко представленные на российском рынке.
Например, системы таких фирм, как 1С, Инфин и т. д. Отличительной особенностью этих продуктов является относительная легкость
в усвоении, что в сочетании с низкой ценой, соответствием российскому законодательству и возможностью выбрать систему «на свой
вкус» приносит им широкую популярность.
Системы среднего класса отличаются большей глубиной и широтой охвата функций. Данные КИС предлагают российские и зарубежные компании. Как правило, это системы, которые позволяют
вести учет деятельности предприятия по многим или нескольким
46
направлениям: финансы, логистика, персонал, сбыт. Они нуждаются в настройке, которую в большинстве случаев осуществляют
специалисты фирмы-разработчика, а также в обучении пользователей. Эти КИС больше всего подходят для средних и некоторых
крупных предприятий в силу своей функциональности и более высокой, по сравнению с первым классом, стоимости. Из российских
систем данного класса можно выделить, например, продукцию
компаний «Галактика», ТБ СОФТ.
К высшему классу относятся КИС, которые отличаются высоким уровнем детализации хозяйственной деятельности предприятия. Современные версии таких систем обеспечивают планирование и управление всеми ресурсами организации (ERP-системы).
Как правило, при внедрении таких систем производится моделирование существующих на предприятии бизнес-процессов и настройка параметров системы под требования бизнеса.
Однако значительная избыточность и большое количество настраиваемых параметров КИС обусловливают длительный срок ее
внедрения и также необходимость наличия на предприятии специального подразделения или группы специалистов, которые должны осуществлять перенастройку системы в соответствии с изменениями бизнес-процессов.
На российском рынке имеется большой выбор КИС высшего класса, и их число растет. Признанными мировыми лидерами являются,
например, R/3 фирмы SAP, Oracle Application компании Oracle.
2.2. Классификация автоматизированных систем
Классификацию автоматизированных систем (АС) различают
по масштабу применения и режиму использования.
По масштабу применения различают АС:
− локальные (в рамках одного рабочего места);
− местные (в пределах одной организации);
− территориальные (в пределах административной территории);
− отраслевые.
По режиму использования различают:
− системы пакетной обработки (первые варианты организационных АСУ, системы информационного обслуживания, учебные системы);
− запросно-ответные системы (АИС продажи билетов, информационно-поисковые системы, библиотечные системы);
47
− диалоговые системы (САПР, АСНИ, обучающие системы);
− системы реального времени (управление технологическими
процессами, подвижными объектами, роботами-манипуляторами,
испытательными стендами и др.).
Автоматизированные информационные системы (АИС) предназначены для накопления, хранения, актуализации и обработки систематизированной информации в каких-то предметных областях
и предоставления требуемой информации по запросам пользователей. АИС может функционировать самостоятельно либо являться
компонентой более сложной системы (например, АСУ или САПР).
По характеру информационных ресурсов АИС делятся на два
вида: фактографические и документальные (хотя возможны и комбинированные АИС). Ф а к т о г р а ф и ч е с к и е системы характеризуются тем, что они оперируют фактическими сведениями,
представленными в виде специальным образом организованных
совокупностей формализованных записей данных. Эти записи образуют БД системы. Существует специальный класс программных
средств для создания и обеспечения функционирования таких фактографических БД – системы управления БД.
Д о к у м е н т а л ь н ы е АИС оперируют неформализованными
документами произвольной структуры с использованием естественного языка (ЕЯ). Среди таких систем наиболее распространенными
являются информационно-поисковые системы, которые включают
программные средства для организации ввода и хранения информации, поддержки общения с пользователем, обработки запросов
и поисковый массив документов. Этот массив часто содержит не
тексты документов, а только их библиографическое описание, иногда рефераты или аннотации. Для работы системы используются
поисковые образы документов (ПОД) – формализованные объекты,
отражающие содержание документов. Запрос преобразуется системой в поисковый образ запроса (ПОЗ), который затем сопоставляется с ПОД по критерию смыслового соответствия. Вариантом информационно-поисковых систем являются библиотечные системы,
с помощью которых создаются электронные каталоги библиотек.
Активно развивающейся в настоящее время разновидностью
АИС являются географические информационные системы (ГИС),
предназначенные для обработки пространственно-временных данных, основой интеграции которых служит географическая информация. ГИС позволяет упорядочивать информацию о данной местности или городе как комплекте карт. В каждой карте представлена
информация об одной характеристике местности. Каждая из этих
48
отдельных карт называется слоем. Самый нижний слой представляет сетку координатной системы, в которой все карты зарегистрированы. Это позволяет анализировать и сравнивать информацию во
всех слоях или в некоторой их комбинации.
Возможность разделить информацию на слои и дальнейшее их
комбинирование определяет большой потенциал ГИС как научного инструментария и средства для принятия решения, так как обеспечивается возможность интеграции самой разной информации
об окружающей среде и обеспечивается аналитический инструментарий использования этих данных. В ГИС могут быть десятки
и сотни слоев карт, которые выстроены в определённом порядке и
показывают информацию о транспортной сети, гидрографии, характеристиках населения, экономической активности, политической юрисдикции и других характеристиках природной и социальной сред.
Такая система может быть полезной в широком диапазоне ситуаций, включающих анализ и управление природными ресурсами,
планирование землепользования, инфраструктуры и градостроительства, управление чрезвычайными ситуациями, анализ местоположения и т. д.
Как уже отмечалось во введении, в настоящее время термин «информационная система» (подразумевается автоматизированная
система) часто используют в более широком смысле, замещая им,
в частности, и термин АСУ. При этом под информационной системой понимается любая АС, используемая как средство сбора, накопления, хранения, обработки, передачи и представления информации в целях сопровождения и поддержки какого-либо вида профессиональной деятельности.
Системы автоматизированного проектирования предназначены
для проектирования определенного вида изделий или процессов.
Они используются для подготовки и обработки проектных данных, выбора рациональных вариантов технических решений, выполнения расчетных работ и подготовки проектной документации
(в частности, чертежей). В процессе функционирования системы
могут использоваться накапливаемые в ней библиотеки стандартов, нормативов, типовых элементов и модулей, а также оптимизационные процедуры.
Результатом работы САПР является соответствующий стандартам и нормативам комплект проектной документации, в котором
зафиксированы проектные решения по созданию нового или модернизации существующего технического объекта. Наиболее широко
49
такие системы используются в электронике, машиностроении,
строительстве.
Автоматизированные системы научных исследований (АСНИ)
в настоящее время, как правило, используются для развития научных исследований в наиболее сложных областях физики, химии, механики и других. В первую очередь – это системы для измерения, регистрации, накопления и обработки опытных данных,
получаемых при проведении экспериментальных исследований,
а также для управления ходом эксперимента, регистрирующей
аппаратурой и т. д. Во многих случаях для таких систем важной
является функция планирования эксперимента; Цель такого планирования – уменьшение затрат ресурсов и времени на получение
необходимого результата.
Кроме того, желательным свойством АСНИ является возможность создания и хранения БД первичных результатов экспериментальных исследований (особенно, если это дорогостоящие и трудно
повторяемые исследования). Впоследствии могут появиться более
совершенные методы их обработки, которые позволят получить новую информацию из старого экспериментального материала.
Как разновидность задачи автоматизации эксперимента можно
рассматривать задачу автоматизации испытаний какого-либо технического объекта. Отличие состоит в том, что управляющие воздействия, влияющие на условия эксперимента, направлены на создание наихудших условий функционирования управляемого объекта, не исключая в случае необходимости и аварийных ситуаций.
Второе направление – это компьютерная реализация сложных
математических моделей и проведение на этой основе имитационных экспериментов, дополняющих, или даже заменяющих эксперименты с реальными объектами или процессами в тех случаях,
когда проведение натурных исследований дорого или вообще невозможно. Технологическая схема вычислительного эксперимента
состоит из нескольких циклически повторяемых этапов: построение математической модели, разработка алгоритма решения, программная реализация алгоритма, проведение расчетов и анализ
результатов. Вычислительный эксперимент представляет собой
новую методологию научных исследований, соединяющую характерные черты традиционных теоретических и экспериментальных
методов.
Автоматизированная система управления предназначена для автоматизированной обработки информации и частичной подготовки
управленческих решений с целью увеличения эффективности дея50
тельности специалистов и руководителей за счет повышения уровня оперативности и обоснованности принимаемых решений.
Различают два основных типа таких систем: системы управления технологическими процессами (АСУТП) и системы организационного управления (АСОУ). Их главные отличия заключаются
в характере объекта управления (в первом случае – это технические объекты: машины, аппараты, устройства, во втором – объекты экономической или социальной природы, то есть в конечном
счете коллективы людей) и, как следствие, в формах передачи информации (сигналы различной физической природы и документы
соответственно).
Следует отметить, что наряду с автоматизированными существуют и системы автоматического управления (САУ). Такие системы после наладки могут некоторое время функционировать без
участия человека. САУ применяются только для управления техническими объектами или отдельными технологическими процессами. Системы же организационного управления, как следует из их
описания, не могут в принципе быть полностью автоматическими.
Люди в таких системах осуществляют постановку и корректировку
целей и критериев управления, структурную адаптацию системы в
случае необходимости, выбор окончательного решения и придание
ему юридической силы.
Как правило, АСОУ создаются для решения комплекса взаимосвязанных основных задач управления производственно-хозяйственной деятельностью организаций (предприятий) или их основных структурных подразделений. Для крупных систем АСОУ могут
иметь иерархический характер, включать в свой состав в качестве
отдельных подсистем АСУТП, АСОДУ (автоматизированная система оперативно-диспетчерского управления), автоматизированные
системы управления запасами, оперативно-календарного и объемно-календарного планирования и АСУП (автоматизированная
система управления производством на уровне крупного цеха или
отдельного завода в составе комбината).
Самостоятельное значение имеют автоматизированные системы диспетчерского управления (АСДУ), предназначенные для
управления сложными человеко-машинными системами в реальном масштабе времени. К ним относятся системы диспетчерского
управления в энергосистемах, на железнодорожном и воздушном
транспорте, в химическом производстве и другие. В системах диспетчерского управления (и некоторых других типах АСУ) используются подсистемы автоматизированного контроля оборудования.
51
Задачами этой подсистемы является измерение и фиксация значений параметров, характеризующих состояние контролируемого
оборудования, а сравнение этих значений с заданными границами
и информирование об отклонениях.
Отдельный класс АСУ составляют системы управления подвижными объектами, такими как поезда, суда, самолеты, космические
аппараты и АС управления системами вооружения.
2.3. Характеристики и архитектура КИС
Наиболее значимыми характеристиками КИС являются.
− архитектура КИС – состав элементов и их взаимодействие;
− сетевые технологии, их масштабы и топология сети;
− функциональная структура управления, реализованная в КИС
(состав подсистем, комплексов задач);
− организационная форма хранения информации (централизованная или распределенная БД);
− пропускная способность системы – скорость обработки транзакций;
− объем информационного хранилища данных;
− системы документов и документооборот;
− количество пользователей КИС;
− пользовательский интерфейс и его возможности;
− типовые информационные технологии процессов сбора, передачи, обработки, хранения, извлечения, распространения информации;
− обеспечение полного цикла управления в масштабах корпорации: нормирование, планирование, учет, анализ, регулирование
на основе обратной связи в условиях информационной и функциональной интеграции;
− территориальная распределенность и значительные масштабы
объекта управления и, соответственно, системы управления;
− неоднородность составляющих технического и программного
обеспечения структурных компонентов системы управления;
− единое информационное пространство для выработки управленческих решений, объединяющее управление финансами, персоналом, снабжением, сбытом и процесс управления производством;
− функционирование в неоднородной вычислительной среде на
разных вычислительных платформах;
− реализация управления в реальном масштабе времени;
52
− высокая надежность, безопасность, открытость и масштабируемость информационных компонентов.
Опыт последних лет разработки ПО показывает, что архитектура КИС должна выбираться с учетом нужд бизнеса, а не личных
пристрастий разработчиков. Далее рассматриваются существующие клиент-серверные архитектуры построения КИС.
Правильная и четкая организация информационных бизнесрешений является слагающим фактором успеха любой компании.
Особенно важным этот фактор является для предприятий среднего
и малого бизнеса, которым необходима система, которая способна
предоставить весь объем бизнес-логики для решения задач компании. В то же время такие системы для компаний со средним и
малым масштабом сетей часто попадают под критерий «цена – качество», то есть должны обладать максимальной производительностью и надежностью при доступной цене.
Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре. Данная
архитектура характеризуется наличием двух взаимодействующих
самостоятельных модулей – автоматизированного рабочего места
(АРМ) и сервера БД, в качестве которого может выступать Microsoft
SQL Server, Oracle, Sybase и др. Сервер БД отвечает за хранение,
управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть представлена так называемым «толстым» клиентом, то
есть приложением и АРМ, на котором сконцентрированы основные
правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры она обладает множеством недостатков, наиболее существенные
из которых – это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления ПО из-за «размазанной» бизнес-логики между АРМ и сервером
БД. Кроме того, при большом количестве АРМ возрастают требования к аппаратному обеспечению сервера БД, а это, как известно,
самый дорогостоящий узел в любой информационной системе.
Как видим, минусов у такой архитектуры достаточно, а решение
тривиально: нужно отделить бизнес-логику от клиентской части и
СУБД, выделив ее в отдельный слой. Так и поступили разработчики, и следующим шагом развития клиент-серверной архитектуры
стало внедрение среднего уровня, реализующего задачи бизнес-логики и управления механизмами доступа к БД, то есть переход к
трехуровневой клиент-серверной архитектуре.
53
Плюсы данной архитектуры очевидны. Благодаря концентрации
бизнес-логики на сервере приложений, стало возможно подключать
различные БД. Теперь сервер БД освобожден от задач распараллеливания работы между различными пользователями, что существенно
снижает его аппаратные требования. Также снизились требования
к клиентским машинам за счет выполнения ресурсоемких операций
сервером приложений и решающих теперь только задачи визуализации данных. Именно поэтому такую схему построения информационных систем часто называют архитектурой «тонкого» клиента.
Но тем не менее «узким местом», как и в двухуровневой клиентсерверной архитектуре, остаются повышенные требования к пропускной способности сети, что в свою очередь накладывает жесткие
ограничения на использование таких систем в сетях с неустойчивой связью и малой пропускной способностью (Интернет, GPRS, мобильная связь).
Существует еще один важный момент использования систем, построенных на такой архитектуре. Самый верхний уровень (АРМ),
в целом обладающий огромной вычислительной мощностью, на
самом деле простаивает, занимаясь лишь выводом информации на
экран пользователя.
Рассмотрим распределенную архитектуру системы, которая позволяет решить эту задачу. Еще недавно реализация такой архитектуры системы для среднего и малого бизнеса была бы невозможна
из-за отсутствия соответствующих недорогих аппаратных средств.
Сегодня хороший ноутбук обладает мощностью, которой несколько
лет назад обладал сервер крупной корпорации и позволял рассчитывать множество важных и судьбоносных отчетов для всех сотрудников этой корпорации.
Более 95 % данных, используемых в управлении предприятием,
могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы. Поток исправлений и
дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому если
хранить непрерывно используемые данные на самих компьютерах
и организовать обмен между ними исправлениями и дополнениями
к хранящимся данным, то суммарный передаваемый трафик резко
снизится. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, благодаря чему создавать надежно функционирующие распределенные
ИС, использующие для связи отдельных элементов неустойчивую
связь типа Интернета, мобильную связь, коммерческие спутнико54
вые каналы. А минимизация трафика между элементами сделает
вполне доступной стоимость эксплуатации такой связи. Конечно,
реализация этой системы не элементарна и требует решения ряда
проблем, одна из которых – своевременная синхронизация данных.
Каждый АРМ независим, содержит только ту информацию, с
которой должен работать, а актуальность данных во всей системе
обеспечивается благодаря непрерывному обмену сообщениями с
другими АРМ. Обмен сообщениями между АРМ может быть реализован различными способами, от отправки данных по электронной
почте до передачи данных по сетям.
Еще одним из преимуществ такой схемы эксплуатации и архитектуры системы является обеспечение возможности персональной
ответственности за сохранность данных. Так как данные, доступные на конкретном рабочем месте, находятся только на этом компьютере, при использовании средств шифрования и личных аппаратных ключей исключается доступ к данным посторонних, в том
числе и IT-администраторов.
Такая архитектура системы также позволяет организовать распределенные вычисления между клиентскими машинами. Например, расчет какой-либо задачи, требующей больших вычислений,
можно распределить между соседними АРМами благодаря тому,
что они, как правило, обладают одной информацией в своих БД, и
тем самым добиться максимальной производительности системы.
Таким образом, предложенная модель построения распределенных систем вполне способна решить и реализовать функции
современного ПО для предприятий среднего и малого бизнеса. Построенные на основе данной архитектуры системы будут обладать
надежностью, безопасностью информации и высокой скоростью
вычислений, что от них в первую очередь и требуется.
2.4. Требования, предъявляемые к КИС
Корпоративные информационные системы должны отвечать целому набору обязательных требований, включая следующие:
1. Использование архитектуры клиент-сервер с возможностью
применения большинства промышленных СУБД.
2. Поддержка распределенной обработки информации.
3. Модульный принцип построения из оперативно-независимых
функциональных блоков с расширением за счет открытых стандартов (API, COM+, CORBA и др.).
55
4. Поддержка технологий Интернет/Интранет.
5. Гибкость, под которой понимается способность к адаптации
и дальнейшему развитию, означает возможность приспособления
КИС к новым условиям, новым потребностям предприятия. Выполнение этих условий возможно, если на этапе разработки КИС
использовались общепринятые средства и методы документирования, так что по прошествии определенного времени сохранится
возможность разобраться в структуре системы и внести в нее соответствующие изменения, даже если все разработчики или их часть
по каким-либо причинам не смогут продолжить работу.
Следует иметь в виду, что психологически легче разобраться
в собственных разработках, пусть даже созданных давно, чем в чужих решениях, не всегда на первый взгляд логичных. Поэтому рекомендуется фазу сопровождения системы доверять лицам, которые ее проектировали.
Любая ИС рано или поздно морально устаревает, и встает вопрос
о ее модернизации или полной замене. Разработчики ИС, как правило, не являются специалистами в прикладной области, для которой разрабатывается система. Участие той же группы проектировщиков в модернизации или создании новой системы существенно
сокращает сроки модернизации.
Вместе с тем возникает риск применения устаревших решений
при модернизации системы. Рекомендация в таком случае одна –
внимательнее относиться к подбору разработчиков КИС.
6. Надежность КИС подразумевает ее функционирование без
искажения информации, потери данных по «техническим причинам». Требование надежности обеспечивается созданием резервных копий хранимой информации, выполнения операций протоколирования, поддержанием качества каналов связи› и физических
носителей информации, использованием современных программных и аппаратных средств. Сюда же следует отнести защиту от случайных потерь информации в силу недостаточной квалификации
персонала.
7. Эффективность: система является эффективной, если с учетом выделенных ей ресурсов она позволяет решать возложенные на
нее задачи в минимальные сроки. В любом случае оценка эффективности будет производиться заказчиком, исходя из вложенных
в разработку средств и соответствия представленной КИС его ожиданиям.
Негативной оценки эффективности КИС со стороны заказчика
можно избежать, если представители заказчика будут привлекать56
ся к проектированию системы на всех его стадиях. Такой подход
позволяет многим конечным пользователям уже на этапе проектирования адаптироваться к изменениям условий работы, которые
иначе были бы приняты враждебно.
Активное сотрудничество с заказчиком с ранних этапов проектирования позволяет уточнить потребности заказчика. Часто
встречается ситуация, когда заказчик чего-то хочет, но сам не знает чего именно. Чем раньше будут учтены дополнения заказчика,
тем с меньшими затратами и в более короткие сроки система будет
создана.
Кроме того, заказчик, не являясь специалистом в области разработки КИС, может не знать о новых информационных технологиях. Контакты с заказчиком во время разработки для него ИС могут
подтолкнуть заказчика к модернизации его аппаратных средств,
применению новых методов ведения бизнеса, что отвечает потребностям как заказчика, так и проектировщика. Заказчик получает
рост эффективности своего предприятия, проектировщик – расширение возможностей, применяемых при проектировании ИС.
Эффективность системы обеспечивается оптимизацией данных
и методов их обработки, применением оригинальных разработок,
идей, методов проектирования (в частности, спиральной модели
проектирования КИС).
Не следует забывать и о том, что работать с системой придется
обычным людям, являющимся специалистами в своей предметной
области, но зачастую обладающим весьма средними навыками в работе с компьютерами. Интерфейс КИС должен быть им интуитивно
понятен. В свою очередь, разработчик-программист должен понимать характер выполняемых конечным пользователем операций.
Рекомендациями в этом случае могут служить повышение эффективности управления разработкой КИС, улучшение информированности разработчиков о предметной области.
Имеет смысл еще до сдачи КИС в эксплуатацию предоставить
разработчикам возможность попробовать себя в роли конечных
пользователей. Встречались случаи, когда такой подход приводил
к отказу от использования на рабочем месте оператора манипулятора типа «мышь», что, в свою очередь, приводило к многократному повышению производительности оператора.
8. Безопасность, под которой, прежде всего, подразумевается свойство системы, в силу которого посторонние лица не имеют
доступа к информационным ресурсам организации, кроме тех,
которые для них предназначены, что достигается с помощью раз57
личных методов контроля и разграничения доступа к информационным ресурсам.
Защита информации от постороннего доступа обеспечивается
управлением доступом к ресурсам системы, использованием современных программных средств защиты информации. В крупных организациях целесообразно создавать подразделения, основным направлением деятельности которых было бы обеспечение информационной безопасности, в менее крупных организациях назначать
сотрудника, ответственного за данный участок работы. Система, не
отвечающая требованиям безопасности, может причинить ущерб
интересам заказчика, прежде всего имущественным.
В этой связи следует отметить, что согласно действующему в РФ
законодательству ответственность за вред, причиненный ненадлежащим качеством работ или услуг, несет исполнитель, то есть в нашем случае разработчик КИС. Поэтому ненадлежащее обеспечение
безопасности КИС заказчика в худшем случае обернется для исполнителя судебным преследованием, в лучшем – потерей клиента и
утратой деловой репутации.
Помимо злого умысла, при обеспечении безопасности КИС приходится сталкиваться еще с несколькими факторами. В частности, современные информационные системы являются достаточно
сложными программными продуктами. При их проектировании
с высокой вероятностью возможны ошибки, вызванные большим
объемом программного кода, несовершенством компиляторов, человеческим фактором, несовместимостью с используемыми программами сторонних разработчиков в случае модификации этих
программ и т. п. Поэтому за фазой разработки КИС неизбежно следует фаза ее сопровождения в процессе эксплуатации, в которой
происходит выявление скрытых ошибок и их исправление.
Например, при проектировании КИС курс доллара США в одной
из процедур разработчики обозначили константой. На момент ввода в эксплуатацию этой системы курс доллара был стабилен, поэтому ошибка никак себя не проявляла, а была выявлена только через
некоторое время в период изменения курса.
Требование безопасности обеспечивается современными средствами разработки КИС, современной аппаратурой, методами защиты информации, применением паролей и протоколированием,
постоянным мониторингом состояния безопасности операционных
систем и средств их защиты.
И наконец, самый важный фактор, влияющий на процесс разработки, – это знания и опыт коллектива разработчиков КИС.
58
3. МЕТОДОЛОГИЯ РЕАЛИЗАЦИИ КОРПОРАТИВНЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ
3.1. Основы методологии MRP
Как уже отмечалось, любая производственная компания, в том
числе и корпорация, борется за конкурентоспособность своих товаров на рынке. Основными целями производственных компаний
являются:
− снижение реальной себестоимости продукции;
− повышение производительности производства за счет эффективного планирования производственных мощностей и ресурсов.
С начала 70-х годов, когда появилась возможность хранения и
анализа больших объемов данных (время первых операционных
систем и вычислительных комплексов для предприятий), стала
развиваться отрасль разработки ПО для предприятий. Задача планирования потребностей в материалах (Materials Requirements
Planning – MRP) оказалась той первой задачей, которая привела
к созданию целой индустрии ПО для управления предприятием.
Решение задачи планирования потребностей в материалах
реализуется с помощью алгоритма, который называется MRPалгоритмом. MRP-алгоритм – это алгоритм оптимального управления заказами на готовую продукцию, производством и запасами
сырья и материалов, а MRP-методология – это идеологическая основа реализация MRP-алгоритма с помощью компьютерной системы.
Реализация ИС, работающей по этой методологии, представляет
собой комплекс ПО, позволяющий оптимально регулировать поставки комплектующих в производственный процесс, контролируя запасы на складе и саму технологию производства. Главной задачей MRPсистемы является обеспечение гарантии наличия необходимого количества требуемых материалов и комплектующих в любой момент
времени в рамках срока планирования, наряду с возможным уменьшением постоянных запасов, а следовательно, разгрузкой склада.
В настоящее время MRP-системы присутствуют практически
во всех интегрированных информационных системах управления
предприятием.
Первоначально MRP-системы разрабатывались для использования на производственных предприятиях с дискретным типом
производства, например: «Сборка на заказ» (Assembly-To-Order –
ATO), «Изготовление на заказ» (Make-To-Order – MTO), «Изготовление на склад» (Make-To-Stock – MTS).
59
Если предприятие имеет процессное производство (Process Industry, Continuous-Batch Processing), то применение MRP-методологии оправдано в случае длительного производственного цикла.
MRP-системы редко используются для планирования материальных потребностей в сервисных, транспортных, торговых и других
организациях непроизводственного профиля, хотя потенциально
идеи MRP-систем могут быть с некоторыми допущениями применены и для непроизводственных предприятий, деятельность которых требует планирования материалов в относительно длительном
интервале времени.
MRP-системы базируются на планировании материалов для оптимальной организации производства и включают непосредственно функциональность MRP, функциональность по описанию и планированию загрузки производственных мощностей CRP (Capacity
Resources Planning) и имеют своей целью создание оптимальных
условий для реализации производственного плана выпуска продукции.
Рассмотрим структуру MRP-системы и используемую терминологию.
М а т е р и а л ы – все сырье и отдельные комплектующие, составляющие конечный продукт. В дальнейшем мы не будем делать различий между понятиями «материал» и «комплектующий».
MRP-с и с т е м а, MRP-п р о г р а м м а – компьютерная программа, работающая по MRP-алгоритму.
С т а т у с м а т е р и а л а – указатель на текущее состояние материала. Каждый отдельный материал в каждый момент времени
имеет статус в рамках MRP-системы, например:
− материал есть в наличии на складе;
− материал есть на складе, но зарезервирован для других целей;
− материал присутствует в текущих заказах;
− заказ на материал планируется.
Как видно, статус материала отражает степень готовности этого
материала быть пущенным в производственный процесс.
С т р а х о в о й з а п а с материала необходим для поддержания
процесса производства в случае возникновения непредвиденных
и неустранимых задержек в его поставках. По сути, в идеальном
случае, если механизм поставок полагать безупречным, MRPметодология не постулирует обязательное наличие страхового запаса, и его объемы устанавливаются различными для каждого конкретного случая, в зависимости от сложившейся ситуации с поступлением материалов. (Подробнее об этом будет рассказано ниже.)
60
П о т р е б н о с т ь в м а т е р и а л е в MRP-программе представляет собой определенную количественную единицу, отображающую возникшую в некоторой момент времени в течение периода
планирования необходимость в заказе данного материала.
Различают понятия полной потребности в материале, которая
отображает то количество, которое требуется пустить в производство, и чистой потребности, при вычислении которой учитывается
наличие всех страховых и зарезервированных запасов данного материала. Заказ в системе автоматически создается по возникновению отличной от нуля чистой потребности.
Формула вычисления чистой потребности такова:
«Чистая потребность = полная потребность –
инвентаризовано на руках – страховой запас –
зарезервировано для других заказов».
Концептуально с позиций кибернетики MRP-систему можно
рассматривать как «черный ящик». Основные элементы MRPсистемы можно разделить на элементы, предоставляющие информацию, программную реализацию алгоритмической основы MRPметодологии, и элементы, представляющие результат функционирования программной реализации MRP-системы.
Входными данными MRP-системы являются следующие.
Программа производства – (основной производственный планграфик – ОПП (Master Production Schedule – MPS). ООП, как правило, формируется для пополнения запаса готовой продукции
или удовлетворения заказов потребителей. На практике разработка ОПП представляется петлей планирования. Первоначально формируется черновой вариант для оценки возможности обеспечения реализации по материальным ресурсам и мощностям.
Система MRP осуществляет детализацию ОПП в разрезе материальных составляющих. Если необходимая номенклатура и ее количественный состав не присутствуют в свободном или заказанном ранее запасе или в случае неудовлетворительных по времени
планируемых поставок материалов и комплектующих, ОПП должен быть соответствующим образом скорректирован. После проведения необходимых итераций ОПП утверждается как действующий и на его основе осуществляется запуск производственных
заказов.
Перечень составляющих конечного продукта (ведомость материалов – ВМ и состав изделия (Bill Of Materials – BOM). ВМ представляет собой номенклатурный перечень материалов и их коли61
чества для производства некоторого узла или конечного изделия.
Совместно с составом изделия ВМ обеспечивает формирование полного перечня готовой продукции, количества материалов и комплектующих для каждого изделия и описание структуры изделия
(узлы, детали, комплектующие, материалы и их взаимосвязи). ВМ
и состав изделия представляют собой таблицы БД, информация которых корректно отражает соответствующие данные, при изменении физического состава изделия или ВМ состояние таблиц должно
быть своевременно скорректировано.
Описание состояния материалов (состояние запасов, Stock/
Requirement List). Текущее состояние запасов с указанием всех
необходимых характеристик учетных единиц отражается в соответствующих таблицах БД. Каждая учетная единица, вне зависимости от вариантов ее использования в одном изделии или многих
готовых изделиях, должна иметь только одну идентифицирующую
запись с уникальным кодом. Как правило, идентификационная запись учетной единицы содержит большое количество параметров и
характеристик, используемых MRP-системой.
Выходными данными MRP-системы являются следующие.
План-график снабжения материальными ресурсами производства – количество каждой учетной единицы материалов и комплектующих для каждого периода времени для обеспечения ОПП.
Для реализации плана-графика снабжения система порождает план-график заказов в привязке к периодам времени, который
используется для размещения заказов поставщикам материалов и
комплектующих или для планирования самостоятельного изготовления.
Кроме того, на выходе MRP-системы имеются изменения плана-графика снабжения (внесение корректировок в ранее сформированный план-график снабжения производства) и ряд отчетов,
необходимых для управления процессом снабжения производства.
Одной из составляющих интегрированных ИС управления предприятием класса MRP является система планирования производственных мощностей, основной задачей которой является проверка выполнимости ОПП с точки зрения загрузки оборудования по
производственным технологическим маршрутам с учетом времени
переналадки, вынужденных простоев, субподрядных работ и т. д.
Входными данными для системы планирования являются планграфик производственных заказов и заказов на поставку материалов и комплектующих, а выходными данными – график загрузки
оборудования и рабочего персонала.
62
3.2. Стандарт MRPII
После появления концепции MRP, казалось бы, все основные
проблемы производства были решены, активно создавались и продавались компьютерные программы, реализующие ее нехитрые принципы. Однако в процессе дальнейшего анализа существующей ситуации в мировом бизнесе и ее развития выяснилось, что основную
составляющую себестоимости продукции занимают затраты, напрямую не связанные с процессом и объемом производства. В связи с растущей от года к году конкуренцией конечные потребители
продукции становятся более «избалованными», ощутимо увеличиваются затраты на рекламу и маркетинг, уменьшается ЖЦ изделий. Всё это требует пересмотра взглядов на планирование коммерческой деятельности. Отныне нужно не «что-то производить
и стараться потом продать», а «стараться производить то, что продается». Таким образом, маркетинг и планирование продаж должны быть непосредственно связаны с планированием производства.
Исходя из этих предпосылок и зародилась новая концепция корпоративного планирования.
Рассмотрим концепцию систем класса MRPII (Manufacturing
Resource Planning).
Очевидно, на любом производственном предприятии существует
набор стандартных принципов планирования, контроля и управления функциональными элементами. Такими элементами являются
производственные цехи, функциональные отделы, аппарат руководства и т. д. Попытаемся на основании этих принципов создать
замкнутую логическую систему, которая позволяет отвечать на
следующие тривиальные вопросы:
Что мы собираемся производить?
Что для этого нужно?
Что мы имеем в данный момент?
Что мы должны получить в итоге?
Эти, на первый взгляд простые, вопросы всегда должны иметь
ясные ответы для руководящего состава любого коммерческого
(производственного и непроизводственного) предприятия. Одной
из основ эффективной деятельности любого предприятия является
правильно поставленная система планирования. Собственно, она и
призвана содействовать ответам на эти вопросы.
Эта система планирования должна чётко отвечать на вопрос:
«Что нам конкретно нужно в тот или иной момент времени в будущем?» Для этого она должна планировать потребности в материале,
63
производственные мощности, финансовые потоки, складские помещения и т. д., принимая во внимание текущий план производства
продукции (или услуг – здесь и далее) на предприятии. Такая система называется системой планирования ресурсов предприятия, или
MRPII-системой (Manufacturing Resource Planning System.
Таким образом, MRPII-система должна состоять из следующих
функциональных модулей:
− планирование развития бизнеса (составление бизнес-плана),
− планирование деятельности предприятия,
− планирование продаж,
− планирование потребностей в сырье и материалах,
− планирование производственных мощностей,
− планирование закупок,
− выполнение плана производственных мощностей,
− выполнение плана потребности в материалах,
− осуществление обратной связи.
Модуль планирования развития бизнеса MRPII-системы определяет миссию компании: её нишу на рынке, оценку и определение
прибылей, финансовые ресурсы. Фактически он утверждает, что
компания собирается произвести и продать, и оценивает, какое количество средств необходимо инвестировать в разработку и развитие продукта, чтобы выйти на планируемый уровень прибыли. Таким образом, выходным элементом этого модуля является бизнесплан.
Модуль планирования продаж MRPII-системы оценивает (обычно в единицах готового изделия), какими должны быть объем и динамика продаж, чтобы был выполнен установленный бизнес-план.
Изменения плана продаж, несомненно, влекут за собой изменения
в результатах других модулей.
Модуль планирования производства MRPII-системы утверждает план производства всех видов готовых изделий и их характеристики. Для каждого вида изделия в рамках выпускаемой линии
продукции существует своя собственная программа производства.
Таким образом, совокупность производственных программ для
всех видов выпускаемых изделий представляет собой производственный план предприятия в целом.
Модуль планирования потребности в материалах MRPIIсистемы на основе производственной программы для каждого вида
готового изделия определяет требуемое расписание закупки и/или
внутреннего производства всех материалов комплектующих этого
изделия и, соответственно, их сборку.
64
Модуль планирования производственных мощностей MRPIIсистемы преобразует план производства в конечные единицы загрузки рабочих мощностей (станков, рабочих, лабораторий и т. д.)
Модуль обратной связи MRPII-системы позволяет обсуждать
и решать возникающие проблемы с поставщиками комплектующих материалов, дилерами и партнерами. Тем самым этот модуль,
собственно, и реализует знаменитый «принцип замкнутой петли»
(closed loop principle) в системе. Обратная связь особенно необходима при изменении отдельных планов, оказавшихся невыполнимыми и подлежащих пересмотру.
Рассмотрим коротко механизм работы MRPII-системы. Началом
является составление производственного плана (Master Production
Schedule – MPS) и общего плана деятельности (Production Plan –
PP). На самом деле логика работы MRPII-системы достаточно
проста.
Следующим шагом является планирование потребностей в материалах. Модуль планирования потребностей в материалах (Materials Requirements Planning – MRP) исторически является тем самым зерном, из которого выросла концепция MRPII (Manufacturing
Resources Planning, римская цифра II появилась на конце ввиду
аналогичности аббревиатур с MRP). Цель этого модуля – так спланировать поставку всех комплектующих, чтобы исключить простои
производства и минимизировать запасы на складе. Уменьшение
запасов материалов-комплектующих, кроме очевидной разгрузки
складов и уменьшения затрат на хранение, дает ряд неоспоримых
преимуществ, главное из которых – минимизация замороженных
средств, вложенных в закупку материалов, не сразу идущих на
конвейер, а подолгу дожидающихся своей участи.
Входными элементами MRP-модуля являются следующие.
Описание состояния материалов (Inventory Status File). Этот
элемент является основным входным элементом MRP-модуля.
В нем должна быть отражена максимально полная информация
о всех типах сырья и материалах-комплектующих, необходимых
для производства конечного продукта. В этом элементе должен
быть указан статус каждого материала, определяющий, имеется
ли он на руках, на складе, в текущих заказах или его заказ только
планируется, а также описания его запасов, расположения, цены,
возможных задержек поставок, реквизитов поставщиков. Информация по всем вышеперечисленным позициям должна быть заложена отдельно по каждому материалу, участвующему в производственном процессе.
65
Программа производства (Master Production Schedule). Этот
элемент представляет собой оптимизированный график распределения времени для производства необходимой партии готовой продукции за планируемый период или диапазон периодов.
Перечень составляющих конечного продукта (Bills of Material
File). Этот элемент представляет собой список материалов и их количество, требуемое для производства конечного продукта. Таким
образом, каждый конечный продукт имеет свой перечень составляющих. Кроме того, здесь содержится описание структуры конечного продукта, то есть он содержит в себе полную информацию о
последовательности его сборки. Чрезвычайно важно поддерживать
точность всех записей в этом элементе и соответственно корректировать их всякий раз при внесении изменений в структуру и\или
технологию производства конечного продукта.
Принцип работы MRP-модуля состоит в следующем: для каждого отрезка времени (обычно таким отрезком являются неделя или
сутки) в течение всего периода планирования на основании инвентарных списков, плана производства и текущих запасов на складе
создаётся полная потребность в материалах. Она представляет собой интегрированную таблицу, выражающую потребность в каждом материале (суть элементов списка) в каждый конкретный момент времени.
Затем вычисляется чистая потребность. Это делается путем вычитания из полной потребности тех материалов-комплектующих,
которые имеются в текущих запасах или занесены в качестве позиций в активные заказы. Другими словами, чистая потребность
определяет: какое количество материалов нужно заказать (или
произвести, в случае внутреннего производства комплектующих)
в каждый конкретный момент времени, чтобы удовлетворить текущие потребности производственного процесса.
Последний этап работы заключается в том, что чистая потребность в материалах конвертируется в соответствующий план заказов на требуемые материалы и, в случае необходимости, вносятся
поправки в уже действующие планы. При этом строго учитывается
время выполнения каждого заказа, другими словами, MRP-система,
автоматически составляя план заказов, руководствуется известным
временем выполнения каждого из них (lead time). Это время, как
правило, определяется поставщиком данного материала. Этот план
заказов является руководящим документом отдела закупок.
Результатами работы MRP-модуля являются следующие основные элементы.
66
План заказов (Planned Order Schedule). Этот элемент определяет, какое количество каждого материала должно быть заказано
в каждый рассматриваемый период времени в течение срока планирования. План заказов является руководством для дальнейшей
работы с поставщиками и, в частности, определяет производственную программу для внутреннего производства комплектующих
при наличии такового.
Изменения к плану заказов (changes in planned orders). Этот
элемент несёт в себе модификации к ранее спланированным заказам. Некоторые заказы могут быть отменены, изменены или задержаны, а также перенесены на другой период.
Планирование потребностей в производственных мощностях
(Capacity Requirements Planning – CRP). Для того чтобы производственная программа была осуществима, необходимо, чтобы имеющиеся в наличии производственные мощности смогли обработать
то количество сырья и материалов-комплектующих, которое предписывает составленный MRP-модулем план заказов, и изготовить из них изделия. Собственно, MRP-план является основным
входным элементом модуля планирования потребностей в производственных мощностях (CRP-модуля). Другим немаловажным
входным элементом является технологическая схема обработки/
сборки конечного готового изделия (routing plan). Эта схема является определенной таблицей, аналогичной инвентарному списку, только с точки зрения этапов обработки и их длительности,
а не комплектующих и их количества. Обычно производственные
мощности предприятия классифицируются на производственные
единицы (work center). Такой производственной единицей может быть станок, инструмент, рабочий и т. д. Результатом работы
CRP-модуля является план потребности в производственных мощностях (Capacity Requirements Plan). Этот план определяет, какое
количество стандартных часов должна работать каждая производственная единица, чтобы обработать необходимое количество
материалов.
Также очень важно заметить, что модули MRPII-системы являются четко и однозначно взаимосвязанными (lock step principle).
Это в свою очередь означает собой тот факт, что в любом случае,
если потребности в материалах (MRP-план, являющийся следствием изначально составленной программы производства (MPS)) не
могут быть удовлетворены ни за счет внутреннего производства, ни
за счет закупок на стороне, в план производства, очевидно, должны
быть внесены изменения. Однако подобные явления должны быть
67
исключениями. Одной из основных задач является составление
успешного производственного плана с самого начала.
Таким образом, если в результате работы CRP-модуля установлено, что MRP-план неосуществим, то производственная программа (MPS) должна быть пересмотрена, более того, вероятно, необходимо пересмотреть весь план деятельности. Однако важно осознавать, что такой шаг должен быть сделан в самом крайнем случае,
так как планировщик, работающий с CRP-системой, должен быть
компетентен и осознавать производственные возможности своего
предприятия, понимая, что задача компьютера – лишь оптимально распределить загрузку производственных мощностей на период
планирования. Тем самым планировщик должен стараться определить и опротестовать заведомо неосуществимый MRP-план до отправления его в CRP-систему или найти пути для расширения производственных мощностей до необходимого уровня.
Контроль выполнения производственного плана отражается в контрольных отчётах по производительности и потреблению
(Input/Output Reports). В тот момент, когда определено, что план
потребностей в производственных мощностях может быть осуществлен, начинает функционировать контроль поддержания установленной производительности. Для этого в течение всего срока планирования системой регулярно создаются контрольные отчеты по
производительности (Output Control Reports).
Для адекватной работы системы необходимо определить величину допустимого отклонения от плана производства. В тот момент,
когда величина реального отклонения превышает конкретное количество часов, система сигнализирует о необходимости немедленного вмешательства в работу данной производительной единицы и
принятия мер к повышению ее производительности, вплоть её выхода на плановый уровень. Такими мерами может быть привлечение дополнительных рабочих, допустимое увеличение общего времени её работы и т. д.
Кроме контрольных отчетов производительности для каждой
производительной единицы существуют контрольные отчеты потребления материалов-комплектующих. Эти отчеты существуют
для быстрого определения ситуаций, когда та или иная производительная единица не развивает плановой мощности из-за недостаточного снабжения материалами. Еще одним необходимым документом, регулярно (как правило, ежедневно) создаваемым MRPIIсистемой, является список операций (Operation Lists). Списки операций обычно формируются в начале дня и передаются (или пере68
сылаются) мастерам соответствующих производственных цехов.
В этих документах отображена последовательность проведения
рабочих операций над сырьем и комплектующими материалами на
каждой производственной единице и их длительность. Списки операций позволяют каждому мастеру получать актуальную информацию и фактически делают его частью MRPII-системы.
Чрезвычайно важно обратить внимание на функции обратной
связи (feedback) в MRPII-системе. Например, если поставщики не
способны поставить материалы-комплектующие в оговоренные
сроки, они должны послать отчет о задержках сразу, как только
они узнают о существовании этой проблемы. Обычно стандартная
компания имеет большое количество просроченных заказов с поставщиками. Но, как правило, даты этих заказов не отражают в достаточной степени дат реальной потребности в этих материалах.
На предприятиях же, управляемых системами класса MRPII, даты
поставки являются максимально близкими к времени реальной
потребности в поставляемых материалах. Поэтому крайне важно
заранее поставить систему в известность о возможных проблемах
с заказами. В этом случае система должна сгенерировать новый
план работы производственных мощностей в соответствии с новым планом заказов. В ряде случаев, когда задержка заказов далеко не является исключением, в MRPII-системе задаётся объем
минимального поддержания запасов «ненадежных» материалов на
складе (safety stock).
В настоящее время системы MRPII класса прочно входят
в жизнь крупных и средних производственных организаций. Основной и эффективной чертой этих систем является возможность
планировать потребности предприятия на короткие промежутки
времени (недели и даже дни) и осуществлять обратную связь (например, автоматически изменять ранее построенные планы производства при сбоях поставок или поломке оборудования), внося
в систему данные о проблемах в реальном времени.
Алгоритм работы MRPII-системы нацелен на внутреннее моделирование всей области деятельности предприятия. Его основная
цель – учитывать и с помощью компьютера анализировать все внутрикоммерческие и внутрипроизводственные события: все те, что
происходят в данный момент, и все те, что запланированы на будущее. Как только в производстве допущен брак, как только изменена
программа производства, как только в производстве утверждены
новые технологические требования, MRPII-система мгновенно реагирует на происшедшее, указывает на проблемы, которые могут
69
быть результатом этого, и определяет, какие изменения надо внести
в производственный план, чтобы избежать этих проблем или свести
их к минимуму. Разумеется, далеко не всегда реально полностью
устранить последствия того или иного сбоя в производственном
процессе, однако MRPII-система информирует о них за максимально длительный промежуток времени до момента их возникновения.
Таким образом, предвидя возможные проблемы заранее и создавая руководству предприятия условия для предварительного их
анализа, MRPII-система является надежным средством прогнозирования и оценки последствий внесения тех или иных изменений в
производственный цикл.
Любая MRPII-система обладает определенным инструментарием для проведения планирования. Нижеперечисленные системные
методологии являются фундаментальными рычагами управления
любой MRPII-системы:
− методология расчёта и пересчета MRP- и CRP-планов;
− принцип хранения данных о внутрипроизводственных и внутрикоммерческих событиях, которые необходимы для планирования;
− методология описания рабочих и нерабочих дней для планирования ресурсов;
− установление горизонта планирования (planning horizon).
Эти методологии и принципы не являются универсальными и
определяются исходя из постановки конкретной задачи, применительно к конкретному коммерческому предприятию.
Перечислим преимущества использования MRPII- систем. Применение систем MRP-II позволяет:
− улучшить обслуживание заказчиков за счет своевременного
исполнения поставок;
− сократить цикл производства и цикл выполнения заказа, следовательно, бизнес будет более гибко реагировать на спрос;
− сократить незавершенное производство: работа не будет выдаваться, пока не потребуется «точно ко времени» для удовлетворения конечного спроса;
− значительно сократить запасы, что позволит более экономно
использовать складские помещения и потребуется меньше средств
на его хранение;
− сбалансировать запасы: будет меньше дефицита и меньше
устаревших запасов;
− повысить производительность: людские ресурсы и материалы
будут использоваться в соответствии с заказами с меньшими по70
терями; можно использовать анализ «что-если», чтобы проверить,
соответствует ли производство задачам предприятия по получению
прибыли;
− создать скоординированную группу управления, которая сможет решать стратегические и оперативные вопросы и организовать
работу в соответствии с выработанным основным планом производства.
3.3. Системы класса ERP
Основные понятия производственного менеджмента (в том числе и термин «ERP») можно считать вполне устоявшимися. В этой
области признанным «стандартом де-факто» служит терминология
Американской ассоциации по управлению запасами и производством (American Production and Inventory Control Society – APICS).
Основные термины и определения приводятся в Словаре APICS, который регулярно обновляется по мере развития теории и практики
управления. Именно в этом издании содержится наиболее полное и
точное определение ERP-системы.
В соответствии со Словарем APICS термин «ERP-система»
(Enterprise Resource Planning – управление ресурсами предприятия) может употребляться в двух значениях:
− ERP-система – ИС для идентификации и планирования всех
ресурсов предприятия, которые необходимы для осуществления
продаж, производства, закупок и учета в процессе выполнения
клиентских заказов;
− ERP-методология – это методология эффективного планирования и управления всеми ресурсами предприятия, которые необходимы для осуществления продаж, производства, закупок и учета
при исполнении заказов клиентов в сферах производства, дистрибьюции и оказания услуг.
Таким образом, термин «ERP» может означать не только ИС, но
и соответствующую методологию управления, реализуемую и поддерживаемую этой КИС.
Рассмотрим основные отличия ERP от MRPII.
В настоящее время практически все разработчики MRPII/ERPсистем относят свои системы к классу ERP. ERP – очень модная
аббревиатура, способная увеличить продажи системы, по сути не
принадлежащей к этому классу. Дело доходит до того, что начинают позиционировать финансово-управленческие системы со сла71
бым производственным блоком как «полноценные ERP-системы»,
вводя потребителей в заблуждение. Эта путаница усугубляется отсутствием ERP-стандарта.
Проведем сравнительную характеристику систем двух классов –
ERP и MRPII. Сразу следует отметить, что и для MRPII-систем, и
для ERP-систем основным является производство. Они, безусловно, развиваются в связи с запросами рынка: добавляются новые
функциональности, решения переносятся на новые технологические платформы. Однако производственные подсистемы остаются
центральными для рассматриваемых систем, и различия между
MRPII- и ERP-системами лежат именно в области планирования
производства. Связаны эти различия с глубиной реализации планирования, что обусловлено ориентацией этих систем на различные сегменты рынка.
ERP-системы создаются для больших многофункциональных и
территориально распределенных производственных корпораций
(например, холдингов, ТНК, ФПГ и т. д.). MRPII-системы ориентированы на рынок средних предприятий, которым не требуется вся
мощность ERP-систем.
Собственно, различие MRPII- и ERP-систем понятно уже из их
названия: с одной стороны, планирование корпоративных ресурсов
(Enterprise Resources Planning), а с другой – планирование производственных ресурсов (Manufacturing Resources Planning).
Существенные же отличия ERP от MRPII можно выразить следующей формулой:
«ERP = MRPII + реализация всех типов производства +
интегрирование планирования ресурсов
по направлениям деятельности + многозвенное планирование».
Безусловно, многие MRPII-системы развиваются с позиций глубины планирования и по некоторым параметрам приближаются
к ERP-системам. Однако «по некоторым» не значит «по всем», поэтому с употреблением термина «ERP» нужно обращаться осторожно.
В то же время среди ERP-, MRPII-систем не все могут предложить решения по системе планирования и управления производством процессного типа.
Современный рынок ИУС состоит из трех (по другим оценкам –
пяти) систем-лидеров, которые, собственно, и относятся к классу
ERP, и множества «продвинутых» систем класса MRPII.
Безусловными лидерами являются системы SAP R/3 немецкой компании SAP AG, Oracle Applications американской компа72
нии Oracle и Baan, разработанная нидерландской компанией Baan.
Иногда к этому «элитному» списку добавляют One World компании
J. D. Edwards и People Soft, выпускаемую одноименной компанией.
Что же касается MRPII-систем, то тут наблюдается большее
количество решений, каждое из которых несет в себе уникальное
сочетание функциональных и технологических особенностей. Все
они отличаются различной степенью проработки производственных, финансовых и иных функций, поэтому с помощью консультантов предприятия могут подобрать систему, более всего отвечающую их запросам. Поэтому «MRPII» – это не признак ущербности
системы, а показатель того, что система ориентирована на рынок
средних предприятий.
Главная цель концепции ERP – распространить принципы
MRPII (Manufactory Resource Planning – планирование производственных ресурсов) на управление современными корпорациями.
Концепция ERP представляет собой надстройку над методологией
MRPII. Не внося никаких изменений в механизм планирования
производственных ресурсов, она позволяет решить ряд дополнительных задач, связанных с усложнением структуры компании.
Концепция ERP до сих пор не стандартизована. Когда возникает вопрос об отнесении конкретной ИУС к классу развитых
MRPII-систем или к классу ERP, специалисты расходятся во мнениях, поскольку выделяют различные критерии принадлежности
системы классу ERP. Однако, суммируя различные точки зрения,
можно указать основные черты, которыми должны обладать ERPсистемы:
− универсальность с точки зрения типов производств;
− поддержка многозвенного производственного планирования;
− более широкая (по сравнению с MRPII) сфера интегрированного планирования ресурсов;
− включение в систему мощного блока планирования и учета
корпоративных финансов;
− внедрение в систему средств поддержки принятия решений.
Рассмотрим возможность планирования производства всех типов в рамках одной системы. Даже на обычном предприятии (не
говоря уже о корпорации) могут сосуществовать производства
различных типов – проектного, дискретного, непрерывного (процессного). К предприятиям, работающим по непрерывному процессному производству, можно отнести предприятия пищевой,
химической, фармацевтической, нефтехимической, нефтяной, металлургической промышленности. Предприятия, работающие по
73
дискретному циклу, принадлежат к машиностроительной, легковой промышленности.
Для поддержки планирования и управления всем предприятием
в целом информационная система должна «уметь» работать с каждым из этих типов производств. Системы класса ERP содержат набор модулей, каждый из которых специализирован на определенном типе производства.
Большие производственные объединения, распределенные территориально, могут состоять из обособленных структурных подразделений или филиалов (звеньев). Каждый филиал, как правило,
имеет отдельный законченный производственный процесс. Однако
зачастую подразделения связаны между собой цепочкой поставок некоторых единиц продукции. Это усложняет процесс планирования деятельности как отдельных подразделений, так и всего
производственного объединения. Чтобы предотвратить простои и
перегрузки отдельных производств из-за не поставленных вовремя
деталей, план-графики закупок различных производственных подразделений компании должны быть согласованы между собой.
Логика работы заложенных в ERP-системы средств агрегирования планов проста. Сначала формируются собственные планы закупок/поставок и производства для каждого предприятия-звена
единой организационной структуры. По каждой номенклатурной
единице, входящей во внутрипроизводственную сеть поставок,
указывается источник (потребитель) и приоритетность поставки
этой единицы. Затем ERP-система создает многозвенный (агрегированный) план. Прежде чем представить эти планы для утверждения, система проводит сценарную оценку их выполнимости. Как и
в обычных MRPII-системах, оценка выполнимости планов происходит путем создания системой потока заказов зависимого спроса
на уровне всего производственного объединения. При выявлении
критических состояний планы корректируются и лишь затем поступают на утверждение.
В классических MRPII-системах интегрированное планирование ресурсов охватывало лишь производственные, складские, снабженческие и сбытовые подразделения предприятия. Действия других тесно связанных с производственным процессом подразделений
и служб (например, ремонтных, транспортных) не вовлекались в
планирование. Точно так же исключались и проектные работы.
ERP-системы позволяют вовлечь в сферу интегрированного планирования ресурсов все подразделения предприятия, так или иначе эти ресурсы использующие. Это позволяет достичь оптимизации
74
бизнес-операций предприятия, а также координации действий всех
служб и подразделений для обеспечения их эффективной работы.
В связи с этим в ERP-системах появляются следующие дополнительные подсистемы.
1. Планирование и управление реализацией производственных
проектов. В этой подсистеме ведется анализ проекта (разработка
его структуры, выделение подпроектов, разбиение подпроектов на
отдельные работы), формирование сетевых графиков работ, планирование материальных и трудовых ресурсов, оборудования, финансовых затрат для выполнения этих работ, управление ходом их
выполнения.
2. Планирование работы сервисно-технических служб. Подсистема позволяет планировать ресурсы и оптимизировать выполнение работ по техническому обслуживанию производственных объектов. Подсистема оказывает сильное влияние на работу модуля
планирования производства. Если проводится аварийный или плановый ремонт некоторой единицы производственных мощностей,
то подсистема должна оповестить модуль планирования производства о блокировке данной единицы производственных мощностей
на определенный период и указать на этот период альтернативный
производственный маршрут.
3. Планирование и управление распределенными ресурсами
(Distribution Resources Planning). Такая подсистема предоставляет
возможность работать со сложной многозвенной структурой сбытовых подразделений и складов. В частности, в ее компетенцию
входит и планирование работы транспортных служб. С помощью
подсистемы можно:
– минимизировать транспортные затраты на доставку сырья и
комплектующих;
– организовать сбалансированное распределение материалов и
продукции по складам компании;
– выбрать оптимальные транспортные маршруты при проведении межскладских перемещений (когда есть несколько складов)
или перемещений между сбытовыми подразделениями (когда есть
сеть дилерских организаций).
4. Планирование и управление послепродажным и специальным обслуживанием. Как следует из названия, подсистема предназначена для управления всеми видами сервисных услуг.
Во многих современных MRPII-системах появляются подсистемы «Проект», «Сервис», «Транспорт» и т. д. Однако, хотя в этих
подсистемах и ведется учет затрат и доходов, бюджетирование,
75
зачастую в них нет необходимой для ERP функциональности по
созданию потока заказов, порождающей интегрированное планирование потребностей в ресурсах и мощностях в масштабах всего
предприятия.
Несмотря на довольно широкую функциональность, ERP-системы не являются полностью интегрированными системами управления: на многих предприятиях существуют подразделения, деятельность которых хотя и связана с производственным процессом,
однако не укладывается в существующую идеологию MRPII- и
ERP-систем. Для автоматизации работы таких подразделений используются свои системы. Речь идет, например, о САПР, системах конструкторской и технологической подготовки производства
(PDM-системы – Product Data Management). Поэтому реально ERPсистемы (так же как и MRPII-системы) практически всегда используются совместно с подобными подсистемами.
Реализация в ERP-системах поддержки планирования ресурсов
разветвленной корпорации влечет необходимость усиления финансового блока, реализации управления сложными финансовыми
потоками и возможности корпоративной консолидации. Поэтому
в ERP-системы входят мощные системы управления корпоративными финансами, характеризующиеся следующими особенностями.
Управленческие решения принимаются людьми. Сама по себе
ERP-система не является инструментом для принятия управленческих решений, она лишь поставляет необходимую для этого информацию. Реальную же поддержку принятия управленческих
решений оказывают специальные аналитические средства, вводимые в ERP-системы (обычно эти средства называют OLAP – On-Line
Analysis Processing).
Приведем некоторые возможности систем поддержки принятия
решений:
− отслеживание эффективности работы различных участков и
служб для выявления и устранения слабых звеньев, а также для
совершенствования структуры бизнес-процессов и организационных единиц;
− анализ деятельности отдельных подразделений;
− агрегирование данных из различных подразделений;
− анализ показателей различных направлений финансово-хозяйственной деятельности предприятия для выделения перспективных и убыточных направлений бизнеса;
− выявление тенденций, развивающихся как внутри предприятия, так и на рынке.
76
3.4. Системы CRM
Последнее десятилетие ХХ века явилось началом отсчета нового поколения продуктов, относящихся к КИС. Несмотря на то, что
передовые предприятия для укрепления на рынке внедряют мощнейшие системы класса ERP, этого уже оказывается недостаточно
для повышения доходов предприятия.
Причины такой ситуации лежат в области, казалось бы, далекой от производства, а именно в области человеческих отношений
и психологии. Обратимся к теории менеджмента, успешно впитавшей в себя законы психологии, и к рыночной экономике.
В настоящее время усиливается конкуренция на мировом рынке
товаров и услуг. С одной стороны, доходность бизнеса снижается
из-за перенасыщенности внутренних рынков сходными товарами и
услугами, а также из-за сложностей при организации экспорта на
другие региональные рынки. С другой стороны, владельцы бизнеса
требуют от менеджмента повышения прибыли, объемов продаж.
Широко используемое в настоящее время решение состоит в согласованных действиях «всего предприятия», а не только отдела маркетинга по поиску, привлечению и, главное, удержанию клиента.
Управление отношениями с клиентами (Customer Relations
Management – CRM) – это стратегия, основанная на применении
таких управленческих и информационных технологий, с помощью
которых компании аккумулируют знания о клиентах для выстраивания взаимовыгодных отношений с ними. Подобные отношения
способствуют увеличению прибыли, так как привлекают новых
клиентов и помогают удержать старых.
CRM – это клиент-ориентированная стратегия, с одной стороны,
формирования наценки «выше рыночной» за счет обеспечения индивидуального обслуживания каждого клиента, а с другой – ориентации на долгосрочные отношения, в том числе и в ущерб краткосрочным экономическим задачам. Обе стороны «CRM-медали»
требуют создания и поддержания долгосрочных отношений с клиентами на качественно более высоком, чем простая декларация
«клиент всегда прав», уровне. Целью CRM является не просто увеличение объема продаж, а прибыльное «увязывание» потребностей
клиента с возможностями продавца, что и требует совместной коллективной работы на клиента различных функциональных подразделений организации.
Таким образом, CRM «в большом» – это стратегия «отличительного» ведения бизнеса. CRM «в малом» – собственно информацион77
ные технологии, позволяющие формализовать и автоматизировать
различные аспекты взаимодействия с клиентами подразделений
маркетинга, продаж и сервисного сопровождения на основе автоматических/автоматизированных процессов (в том числе сбытовых) и единого «информационного пространства» организации, то
есть происходит консолидация всей информации о каждом клиенте путем обмена данными с другими информационными системами. Объединяя ключевые блоки информации о контактах, организациях, сделках, заказах/проектах и связях между этими «сущностями», CRM-система позволяет, опираясь на факты, узнать все
о поведении клиентов и подобрать экономически целесообразный
способ их обслуживания, ведя бизнес «проактивно».
Рынок CRM можно условно разделить на две части – средний и
крупный. Все западные поставщики CRM-решений позиционируют свои продукты для компаний среднего или крупного бизнеса.
К среднему бизнесу относят компании, минимальный оборот которых составляет 25–500 млн долл., а максимальный колеблется
в диапазоне от 500 млн долл. до 1 млрд долл. К крупному бизнесу,
соответственно, относятся компании с оборотом свыше 1 млрд долл.
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 – техническая поддержка пользователей.
На рынке присутствуют как продукты, обеспечивающие определенную узкую функциональность (например, управление контактами), так и полнофункциональные интегрированные CRMсистемы, объединяющие в себе несколько модулей (в частности,
модули продаж, маркетинга, сервисного сопровождения, проектного управления и электронной коммерции).
78
Основное отличие CRM-систем от всех остальных ИС предприятия состоит в следующем. Прочие системы (ERP, документооборот) минимизируют расходы и/или «наводят порядок», а значит,
работают на экономичность и экономию (снижение цены покупки),
тогда как CRM-системы призваны наращивать эффективность бизнеса отбором правильных клиентов и корректным выстраиванием
отношений с первого раза.
Основой CRM-системы являются приложения автоматизации
продаж (Sales Force Automation – SFA). На них возлагаются следующие функции:
− ведение календаря событий и планирование работы;
− управление контактами (благодаря ему ни один важный звонок или личное обращение не будут пропущены);
− работа с клиентами (каждый клиент будет обслужен на высочайшем уровне, благодаря зафиксированной истории взаимодействия с ним);
− мониторинг потенциальных продаж (ни одна потенциальная
возможность не будет упущена, каким бы плотным ни было расписание сотрудника);
− поточная организация продаж (эффективное управление циклом продаж);
− повышение точности прогнозов продаж;
− автоматическая подготовка коммерческих предложений (освобождает сотрудников от рутинной работы);
− предоставление информации о ценах;
− автоматическое обновление данных о размере бонуса в зависимости от выполнения поставленных задач;
− предоставление актуальной информации о состоянии дел в региональных представительствах;
− формирование отчетов (эффективный инструментарий автоматического создания отчетов по результатам деятельности);
− организация продаж по телефону (создание и распределение
списка потенциальных клиентов, автоматический набор номера,
регистрация звонков, прием заказов).
В современных CRM-системах SFA-приложения дополняются
средствами автоматизации маркетинга (Marketing Automation –
MA). Эти приложения позволяют:
– организовывать маркетинговые кампании (предусмотрены
инструменты планирования, разработки, проведения и анализа результатов маркетинговых акций, как традиционных, так и через
Интернет);
79
− создавать маркетинговые материалы и управлять ими (в том
числе заниматься автоматической рассылкой);
− генерировать список целевой аудитории (создание списков потенциальных клиентов и их распределение между торговыми представителями);
− отслеживать бюджетирование и прогнозирование результатов
маркетинговых кампаний;
− вести маркетинговую энциклопедию (репозиторий информации о продуктах, ценах и конкурентах).
Приложения МА предоставляют менеджерам по маркетингу
мощный инструмент для разработки, проведения и анализа маркетинговых кампаний, а также осуществления других маркетинговых функций. С помощью совместно используемых MA- и SFAприложений можно формировать рабочие планы продавцов и отслеживать их выполнение.
Приложения
автоматизации
обслуживания
клиентов
(Customer Service Automation & Support – CSA/CSS) в последнее
время приобрели первостепенное значение, так как в условиях
жесткой конкуренции удержать прибыльного клиента можно, прежде всего, благодаря высокому качеству обслуживания.
Как правило, к этой категории приложений относятся средства
обработки вызовов и самообслуживания через Интернет. Приложения CSS позволяют удовлетворять индивидуальные потребности
заказчиков быстро, точно и эффективно, обеспечивая выполнение
следующих функций:
− мониторинг потребностей клиента (сотрудники отдела обслуживания всегда в курсе проблем и предпочтений того или иного покупателя услуг);
− мониторинг прохождения заявок (процесс отслеживается автоматически);
− мониторинг мобильных продаж (в любой момент времени
можно получить информацию о качестве выполнения услуги, ее
стоимости, удовлетворенности клиентов, сроках выполнения заявки и др.);
− ведение БЗ (эффективный инструмент снижения себестоимости услуг – большинство проблем могут быть решены во время первого звонка клиента);
− контроль над исполнением сервисных соглашений (автоматическое отслеживание сроков и условий);
− управление запросами клиентов с помощью присвоения приоритетов.
80
Приложения CSS превращают отделы обслуживания клиентов
из затратных в прибыльные. Будучи интегрированными с приложениями SFA и МА, они способствуют тому, чтобы каждый контакт клиента с компанией был использован для продажи дополнительных услуг (cross-sell) и более дорогих продуктов (up-sell).
Прочие функции CSS:
− составление отчетов для высшего руководства;
− интеграция с ERP (с бэк-офисом, Интернетом, внешними данными);
− синхронизация данных (включая данные, хранящиеся в многочисленных портативных устройствах, серверах приложений и
в различных базах);
− электронная торговля (управление закупками B2B и B2C через
систему EDI, Web-сервер и другие средства);
− мобильные продажи (генерация заказов, передача информации торговым представителям вне офиса в режиме реального времени через мобильные устройства).
Call-центры позволяют персонализировать отношения компании со своими клиентами, предоставлять им широкий спектр услуг
и, конечно, экономить дорогостоящее время как самого клиента,
так и персонала компании. Сall-центр – это место, куда поступают
или откуда совершается большое количество телефонных звонков.
Многие современные организации, выполняющие задачи callцентров, уже не вписываются в это определение. Теперь call-центр
способен не только принимать и обрабатывать запросы, поступающие по телефону, но использовать для контактов с клиентами
обычную почту, факсимильную и мобильную связь, Интернет и
т. д. Крупный call-центр может быть распределенным и связывать
call-центры в разных концах страны.
Такие современные центры обслуживания вызовов, использующие одновременно различные виды коммуникаций, принято называть контакт-центрами (Contact Center). Контакт-центр способен
работать по запросу клиента 24 часа в сутки. Интенсивность может
достигать нескольких сотен звонков в минуту. При этом система
активно использует информационные ресурсы, хранящиеся в БД,
обрабатывает и запоминает поступающую информацию, а также
автоматически контролирует свою деятельность.
Организация единого контакт-центра позволяет:
− сократить время обслуживания клиентов и обеспечить единство работы по всем видам коммуникаций, избегая дублирования
функций различных подразделений компании;
81
− поднять обслуживание заказчиков на новый качественный
высокотехнологичный уровень, эффективно используя процедуры
персонифицированного управления контактами с абонентами;
− увеличить объем продаж за счет роста количества и качества
контактов за единицу времени, при одновременном снижении на
порядок финансовых затрат на поддержку ресурсов;
− усилить контроль за работой сотрудников и повысить уровень
управляемости коллективом.
Системы управления сервисным обслуживанием проданной
продукции (Field Service Management – FSM) предназначены для
управления гарантийным и постгарантийным обслуживанием продукции, ведения и контроля сервисных заявок и договоров, планирования ресурсов предприятия.
Использование FSM-системы позволяет существенно снизить
затраты, связанные с обслуживанием продукции, и повысить качество обслуживания заказчиков, благодаря оперативному наличию
информации по каждой единице изделия (серийные номера), использованию БЗ и точности календарного планирования сервисного персонала.
Управление взаимоотношениями с партнерами (Partner Relationship Management – PRM) – это системы повышения эффективности процессов взаимодействия с партнерами в области продаж,
маркетинга, поставок и обслуживания за счет интеграции различных аспектов партнерской деятельности в единую систему.
Данные системы реализуются в различных приложениях для
автоматизации и оптимизации указанных процессов.
В современной ситуации эффективность деятельности компании
во многом зависит от взаимодействия с партнерами на различных
сегментах рынка. Однако организовать эффективное взаимодействие с партнерами не так просто: вокруг лучших каналов сбыта
развернута острейшая борьба между поставщиками, которые часто
переманивают партнеров друг у друга.
PRM-системы – корпоративные приложения нового класса,
цель которых – оптимизировать взаимоотношения компании
с партнерами.
Функции PRM-систем:
− повышение эффективности каналов сбыта благодаря более
оперативному ознакомлению партнеров с новыми инициативами и
другой информацией, имеющей отношение к партнерской деятельности; координация продаж продуктов и оптимальное перераспределение их между различными каналами сбыта;
82
− определение дилеров-партнеров, приносящих наибольшую
прибыль, для их поощрения, а также партнеров, генерирующих
наибольшее количество заказов, для предоставления им наилучших условий;
− упрощение и стандартизация процессов сотрудничества с партнерами (поиск новых партнеров, учет, оценка деятельности партнеров и определение их специализации).
− проведение тренингов для партнеров в режиме онлайн.
Преимущества PRM-систем:
− предоставление компаниям эффективного средства коммуникации с партнерами и обеспечения всех сотрудничающих сторон
необходимой информацией и навыками для достижения максимально высокой прибыли и высококачественного обслуживания
их общих клиентов;
− объединенный потенциал компаний-партнеров, использующих PRM-систему, позволяет обеспечить их взаимодействие и согласовать финансовые потоки за счет интеграции информации о заказах с маркетингом партнеров, продажами и производством;
− PRM-системы обеспечивают владельцев брендов мощными
возможностями управления и универсальными аналитическими
инструментами, предоставляющими всестороннюю информацию
по деятельности отдельных партнеров, сегментам их деятельности
и всех партнеров вместе. Многие системы включают до нескольких
сотен встроенных отчетов и аналитических инструментов, которые
позволяют руководителям компаний быстро оценить эффективность совместных продаж, услуг и маркетинговой деятельности.
Системы класса CRM зачастую интегрируют с системами управления предприятием (такими, как MRPII, ERP), однако даже такое
детальное ведение всей маркетинговой информации может не дать
того эффекта, который ожидается со стороны топ-менеджмента
предприятия.
Более современной концепцией управления ресурсами предприятия является планирование ресурсов, синхронизированное с клиентом (Customer Synchronized Resource Planning – CSRP), охватывающее почти весь ЖЦ товара. Такой подход позволяет управлять
стомостью товара, учитывая производство, продвижение и обслуживание товара данного типа, а также все элементы его функционального ЖЦ, а не только производства, как во всех стандартных
системах предыдущих поколений.
Сущность концепции CSRP состоит в том, что при планировании
и управлении компанией можно и нужно учитывать пожелания ко83
нечных пользователей непосредственно при оформлении заказа, то
есть ориентироваться в большей степени на производство индивидуальных конфигураций товаров «под заказ». Такой подход дает
большие преимущества в конкурентоспособности предприятия
в отраслях, где ЖЦ товара невелик и требуется более оперативно
реагировать на изменение желаний потребителя.
Исключительно важным следствием данной концепции явилась реализация задачи тонкого управления производственными
графиками в условиях ограниченных мощностей (так называемой
APS-задачи – Advanced Planning and Scheduling – расширенного управления производственными графиками). Автономные решения такого класса были известны и раньше, однако в систему
управления ресурсами предприятия впервые были интегрированы фирмой SYMIX в ее флагманском продукте Syte Line. Системы
типа APS позволяют решать такие задачи, как «проталкивание»
срочного заказа в производственные графики, распределение заданий с учетом приоритетов и ограничений, перепланирование с использованием полноценного графического интерфейса. Благодаря
принципиально новой «математике» расчет типовых задач MRP
осуществляется значительно быстрее, чем раньше.
3.5. Проблемы внедрения КИС
В основе деятельности по созданию и использованию ПО любого
типа лежит понятие его ЖЦ. Жизненный цикл является моделью
создания и использования ПО, отражающей его различные состояния, начиная с момента возникновения необходимости в данном
ПО и заканчивая моментом его полного выхода из употребления
у всех пользователей.
Традиционно выделяются следующие основные этапы ЖЦ:
− анализ требований,
− проектирование,
− кодирование (программирование),
− тестирование и отладка,
− эксплуатация и сопровождение.
Жизненный цикл образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итеративный характер: реализованные этапы, начиная с самых ранних, циклически
повторяются в соответствии с изменениями требований и внешних
условий, введением ограничений и т. п. На каждом этапе ЖЦ по84
рождается определенный набор документов и технических решений, при этом для каждого этапа исходными являются документы
и решения, полученные на предыдущем этапе.
Каждый этап завершается верификацией порожденных документов и решений с целью проверки их соответствия исходным документам.
Существующие модели ЖЦ определяют порядок исполнения
этапов в ходе разработки, а также критерии перехода от этапа к
этапу. Как уже отмечалось, наибольшее распространение получили три модели ЖЦ.
1. Каскадная модель – предполагается переход на следующий
этап после полного окончания работ по предыдущему этапу.
2. Поэтапная модель с промежуточным контролем – итерационная модель разработки ПО с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по
сравнению с каскадной моделью, однако время жизни каждого из
этапов растягивается на весь период разработки.
3. Спиральная модель – делается упор на начальные этапы ЖЦ:
анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется
и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапно
модели создания фрагмента или версии программного изделия, на
нем уточняются цели и характеристики проекта, определяется его
качество, планируются работы следующего витка спирали. Таким
образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Главная особенность индустрии ПО состоит в концентрации
сложности на начальных этапах ЖЦ (анализ, проектирование) при
относительно невысокой сложности и трудоемкости последующих
этапов. Более того, нерешенные вопросы и ошибки, допущенные
на этапах анализа и проектирования, порождают на более поздних
этапах трудные, часто уже неразрешимые проблемы, и приводят к
неуспеху всего проекта.  Рассмотрим этапы ЖЦ более подробно.
Анализ требований: требования заказчика уточняются, формализуются и документируются. На этом этапе дается ответ на вопрос: «Что должна делать система?». 
Список требований к разрабатываемой системе должен включать:
85
− совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы,
внешние условия функционирования, состав людей и работ, имеющих отношение к системе);
− описание функций системы;
− ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные
процедуры и мероприятия, обеспечивающие защиту информации).
Целью анализа является преобразование общих, неясных знаний о требованиях к будущей системе в точные (по возможности)
определения. На этом этапе определяются:
− архитектура системы, ее функции, внешние условия, распределение функций между аппаратным и программным обеспечением;
− интерфейсы и распределение функций между человеком и системой;
− требования к программным и информационным компонентам
ПО, необходимые аппаратные ресурсы, требования к БД, физические характеристики компонентов ПО, их интерфейсы.
Этап проектирования дает ответ на вопрос: «Как (каким образом) система будет соответствовать предъявленным требованиям?». Задачей этого этапа является исследование структуры системы и логических взаимосвязей ее элементов, причем без внимания
к вопросам реализации.
Обычно этот этап разбивают на два подэтапа:
− проектирование архитектуры ПО, то есть разработка структуры и интерфейсов компонентов, согласование функций и технических требований к компонентам, стандартам проектирования, производство отчетных документов;
− детальное проектирование, то есть разработка спецификаций
каждого компонента, интерфейсов между компонентами, разработка требований к тестам и плана интеграции компонентов.
В результате деятельности на этапах анализа и проектирования
должен быть получен проект системы, содержащий достаточно информации для реализации системы на его основе в рамках бюджета
выделенных ресурсов и времени.
Процесс разработки и внедрения КИС исполняется по следующему сценарию:
1. Анализ существующих систем или разработка требований
к создаваемой системе.
2. Типовой процесс внедрения.
2.1. Разработка стратегии автоматизации.
86
2.2. Анализ деятельности предприятия.
2.3. Реорганизация деятельности.
2.4. Выбор системы.
2.5. Внедрение системы.
2.6. Эксплуатация.
К типичным проблемам при внедрении КИС относят: подготовку предприятия к автоматизации и выбор системы.
В табл. 3.1 приведены примерные функции системы и их характеристики. При разработке технического задания на разработку
системы или при сравнительном анализе сопоставимых альтернативных систем желательно составить подобную таблицу и заполнить её для альтернативных систем.
Таблица 3.1
Функции системы и преимущества использования
Функция системы
Характеристика
деятельности
Качественный выигрыш
Блок проектирования
Item Part Number Control Управляет структу(управление структурой рой изделия с точноизделия)
стью до комплектующих (узлов и агрегатов)
Повышение точности
данных для планирования производственной
деятельности, обеспечение стыка с системами проектирования
Bill of Materials Control
Контролирует весь
Повышение точности
(управление специфика- перечень материаданных для планировациями продуктов)
лов, требуемых для
ния производственной
производства конеч- деятельности, обеспеного изделия (как
чение стыка с системаколичественно, так и ми проектирования
в финансовом эквиваленте)
Блок контроля инженерной документации
Routings (маршрутизаУправляет распреОптимальная загрузка
ция)
делением потока
цехов (оборудования)
заказов по цехам
(рабочим местам)
Estimating (смета)
Оценка влияния из- Точный учет затрат,
менений
связанных с изменениями
Design Engineering (раз- Подготавливает
Оптимальная техноработка технологии)
технологию выпуска логия выпуска пропродукции
дукции
87
Продолжение табл. 3.1
Функция системы
Характеристика
деятельности
Качественный выигрыш
Блок управления закупками
Vendor Performance (ис- Учет исполнения
Точный учет запасов,
полненные поставки)
запланированных по- повышение достоверступлений
ности планирования
Purchase Order
Планирование и ввод Сокращение материManagement (управление заказов на закупку
альных запасов за счет
заказами на закупку)
обеспечения поставок в
требуемый срок
Subcontract Purchase
Планирование и ввод Сокращение материOrders (заказы на закуп- заказов на закупку,
альных запасов за счет
ку по субконтрактам)
выполняемых субпо- обеспечения поставок в
дрядчиками
требуемый срок
Блок управления материальными запасами
Inventory Control (управ- Планирование и учет Сокращение материление запасами)
запасов
альных запасов за счет
планирования поставок к требуемому сроку
Master Production
Среднесрочный объ- Выпуск продукции к
Scheduling (план-график емно-календарный
требуемому сроку, совыпуска продукции)
план выпуска прокращение издержек на
дукции
хранение продукции
Material Requirements
Планирование неСокращение времени
Planning (планирование обходимых материа- простоя из-за нехватки
потребностей в материа- лов по количеству и
материалов, сокралах)
срокам
щение материальных
запасов
Lot/Serial Tracking (отУчет выпуска партий Повышение точности
слеживание партий/
продукции
планирования продаж,
серий)
сокращение материальных запасов
Rough-Cut Capacity
Планирование необ- Оптимальная загрузка
Planning (укрупненное
ходимых мощностей критических ресурсов
планирование мощнона основании требу- под виды продукции
стей)
емых для выпуска
видов продукции
ресурсов
Производственный блок
Shop Floor Control (управ- Составление операОптимальная загрузление на уровне произтивных (дни-месяц) ка цеха, детальное
водственного цеха)
план-графиков
планирование выпуска
продукции
88
Продолжение табл. 3.1
Функция системы
Capacity Requirements
Planning (планирование
потребностей в мощностях)
Project Control (управление проектом)
Характеристика
деятельности
Детальное планирование потребных
мощностей до уровня
рабочих центров
Управление проектами предприятия
Качественный выигрыш
Оптимальная загрузка
всех рабочих мест
Выполнение проектов с
требуемым качеством в
заданные сроки
Блок управления издержками
Job Costing (трудовые из- Рассчитывает трудо- Выделение затрат,
держки)
затраты
связанных с работой
персонала
Cash Flow Analysis (ана- Анализ всех денежОптимальное регулилиз наличных потоков)
ных потоков предрование денежных
приятия
потоков
Actual Costs (действиРасчет реальной себе- Выявление неэффектельные издержки)
стоимости
тивных участков и
технологий
Standard Costs (нормаРасчет плановой себе- Поддержка процесса
тивная стоимость)
стоимости
снижения издержек
Work Breakdown
Расчет себестоимости Поддержка процесса
Structure (стоимость
работ по отдельным
снижения издержек
этапов работ)
этапам
Блок управления финансами
Accounts Receivable (вы- Выставление счетов Учет выставленных
ставленные счета)
к оплате
счетов
Accounts Payable (оплаРегистрация оплаты Учет реальной оплаты
ченные счета)
счетов
выставленных счетов
General Ledger (главная Учет всех бухгалтер- Реальная картина
книга)
ских операций
текущего баланса
Multi-Company ConsoliОбъединение баланса Реальная картина
dation (консолидация
нескольких дочерних баланса нескольких
баланса от многих комкомпаний
компаний
паний)
Foreign Currency Conver- Работа с несколькими Возможность осущестsion (конвертизация
валютами
вления расчетов в невалют)
скольких валютах
Блок маркетинга/продаж
Sales Order Management Учет заказов на про- Оптимальная загрузка
(управление заказами на дукцию
производства
продажу)
89
Окончание табл. 3.1
Функция системы
Order Configurator (конфигурация заказов)
Характеристика
деятельности
Качественный выигрыш
Планирование последовательности
заказов
Оптимальная загрузка
складов, поддержка
процесса оптимизации
денежных потоков
Billing/Invoicing (выстав- Ведение книги проСоответствие законодаление счетов-фактур)
даж/покупок
тельству, сокращение
затрат
Full Sales Analysis (полАнализ всех аспектов Повышение достоверный анализ продаж)
продаж
ности прогнозирования/ планирования
Commission Calculation/ Расчет скидок/коГибкая работа с поReporting (расчет комис- миссионных
ставщиками и потребисионных/ отчетность)
телями
Sales Forecasting/Rollups Подготовка исходных Повышение достовер(прогнозирование проданных для произности планирования
даж)
водственых планов
верхнего уровня
Quoting (квотирование)
Квотирование проПовышение прибыли
даж
за счет управления
спросом
Понятие «стратегия автоматизации» включает в себя базовые
принципы, используемые при автоматизации предприятия. В ее
состав входят следующие компоненты:
− цели: области деятельности предприятия и последовательность, в которой они будут автоматизированы;
− способ автоматизации: по участкам, направлениям, комплексная автоматизация;
− долгосрочная техническая политика: комплекс внутренних
стандартов, поддерживаемых на предприятии;
− ограничения: финансовые, временные и т. д.;
− процедура управления изменениями плана.
Стратегия автоматизации в первую очередь должна соответствовать приоритетам и стратегии (задачам) бизнеса. В понятие стратегии также должны входить пути достижения этого соответствия.
Стратегический план автоматизации должен составляться с учетом следующих факторов:
− средний период между сменой технологий основного производства,
− среднее время жизни выпускаемых предприятием продуктов
и его модификаций,
90
− анонсированные долгосрочные планы поставщиков технических решений в плане их развития,
− срок амортизации используемых систем,
− стратегический план развития предприятия, включая планы
слияния и разделения, изменение численности и номенклатуры
выпускаемой продукции,
− планируемые изменения функций персонала.
Автоматизация – лишь один из способов достижения стратегических бизнес-целей, а не процесс, развивающийся по своим
внутренним законам. Во главе стратегии автоматизации должна
лежать стратегия бизнеса предприятия: миссия предприятия, направления и модель бизнеса.
Таким образом, стратегия автоматизации представляет собой
план, согласованный по срокам и целям со стратегией организации.
Второй важной особенностью является степень соответствия
приоритетов автоматизации и стратегии бизнеса, а именно какие цели должны быть достигнуты:
− снижение стоимости продукции,
− увеличение количества или ассортимент,
− сокращение цикла: разработка новых товаров и услуг – выход
на рынок,
− переход от производства на склад к производству под конкретного заказчика с учетом индивидуальных требований и т. д.
Стратегические цели бизнеса с учетом ограничений (финансовых, временных и технических) конвертируются в стратегический
план автоматизации предприятия.
При этом следует помнить, что автоматизация предприятия
является инвестиционной деятельностью, и к ней применимы все
подходы, используемые при оценке эффективности инвестиций.
К основным ограничениям, которые необходимо учитывать при
выборе стратегии автоматизации, относятся следующие: финансовые, временные, ограничения, связанные с влиянием человеческого фактора, и технические.
Ф и н а н с о в ы е ограничения определяются величиной инвестиций, которые предприятие способно вложить в развитие автоматизации. Этот тип ограничений наиболее универсален, так как
остальные три вида могут быть частично конвертированы в финансовые.
В р е м е н н ы е ограничения обычно связаны со следующими
факторами:
− сменой технологий основного производства,
91
− рыночной стратегией предприятия,
− государственным регулированием экономики.
К ограничениям, связанным с в л и я н и е м ч е л о в е ч е с к о г о
ф а к т о р а, относятся следующие ограничения:
− корпоративная культура – отношение персонала к автоматизации,
− особенности рынка труда, трудовое законодательство.
Типичные проблемы, которые возникают при разработке стратегии автоматизации, как правило, связаны со следующими факторами:
− состояние рынка информационных технологий,
− определение эффективности инвестиций в информационные
технологии,
− необходимость реорганизации деятельности предприятия при
внедрении информационных технологий.
Анализ и реорганизация деятельности предприятия – довольно
общее понятие. Под анализом деятельности предприятия понимается следующее: сбор и представление информации о деятельности
предприятия в формализованном виде, пригодном для выбора и
дальнейшего внедрения КИС.
В зависимости от выбранной стратегии автоматизации предприятия технологии сбора и представления информации могут быть
различными.
Итоговое представление информации на этапе анализа деятельности играет одну из ключевых ролей во всей дальнейшей работе.
Желательно, чтобы анализ предприятия закончился построением
моделей, соответствующих стандартам IDEF.
Реорганизация деятельности преследует, как правило, цель
повышения эффективности деятельности предприятия в целом.
В понятиях бизнес-процессов она предполагает реорганизацию полученной модели деятельности предприятия «как есть» (IT-IS) в
оптимизированную с точки зрения стоимости, исключения дублирования функций и т. д., модель «как будет» (TO-BE) с использованием, например, схем стандарта IDEF0.
Функционально ориентированное управление предприятием
имеет такие отличительные черты, как:
− разобщенность целей подразделений, несовпадение частных
интересов подразделений с целевыми задачами предприятия;
− потенциальная конфликтность взаимоотношений.
Одной из ключевых проблем сложившихся систем управления
является доминирование функционального управления в органи92
зациях, что порождает множество трудностей. Функциональные
структурные подразделения прямо не заинтересованы в общих результатах, поскольку система оценки их деятельности традиционно оторвана от результативности работы предприятия в целом. Разрушительная конкуренция между ними – результат обособленного
положения каждого подразделения внутри предприятия. На практике это переходит в постоянные конфликты между сотрудниками
бухгалтерии, финансового и планово-экономического отделов, между отделом сбыта и производством, между производством и инженерными службами, между конструкторами и технологами и т. д.
В функционально ориентированных организационных структурах чрезмерно усложнен обмен информацией между различными
подразделениями. А, как известно, актуальная информация является базовым фактором принятия эффективного управленческого
решения.
Наконец, в функционально ориентированных структурах сотрудники подразделений не ориентированы на целевые задачи
предприятия. Этот подход жив до сих пор, и многие руководители
предприятий убеждены, что альтернативы ему не существует.
Вместе с тем реальная работа не движется вдоль линейно-функциональной иерархии (такой маршрут имеют поручения руководства, информация по принятию решений и приказы). Она пронизывает предприятия в виде набора деловых процессов, которые в большинстве своем никем не управляются и никто за них не отвечает.
Деловой процесс (бизнес-процесс, business process) – это логически завершенный набор этапов работы, поддерживающий деятельность предприятия и реализующий его политику, направленную
на достижение поставленных целей.
Как правило, набор деловых процессов для каждого предприятия своеобразен. Такие процессы, так или иначе, существуют на
каждом предприятии. Проблема заключается в их упорядочении и
организации управления.
Большие потенциальные преимущества управления деловыми
процессами заключаются в том, что работа становится более эффективной, поскольку переходит от одного специалиста к другому, от
одного подразделения к другому с меньшим количеством ошибок и
задержек, а требования клиента удовлетворяются вовремя (чего никак не скажешь о функционально ориентированной организации).
Среди других преимуществ перехода на процессно-ориентированную организацию деятельности можно выделить простоту
проведения оптимизации как самих процессов, с точки зрения их
93
организации, синхронизации, взаимной согласованности, так и ресурсов, потребляемых процессами, особенно это касается человеческих ресурсов.
Очевидно, что одним из важнейших факторов успеха предприятия является наличие на нем единой и мощной «управленческой
команды», владеющей ситуацией и работающей согласованно на
достижение общей цели. Процессная организация управления в
сочетании с другими методами позволяет сформировать команду,
ориентированную на единые цели предприятия.
Таким образом, внедрение процессного подхода требует осознанной реорганизации деятельности предприятия на основе принципов процессно-ориентированного управления. Подобная реорганизация требует определенной технологии перехода от существующей системы к новой, соответствующей поставленным целям. На
отечественном рынке услуг большое значение приобретают услуги,
связанные с консалтингом, направленным на совершенствование
систем управления предприятий. Вторым важным составляющим
такого совершенствования, помимо внедрения процессно-ориентированного управления, является внедрение современных информационных технологий, в том числе построенных на основе автоматизированных систем.
Существует также матричный подход, который сочетает в себе
функционально ориентированный и процессно-ориентированный
подходы. Ответственность за выполнение задания возложена на исполнителей бизнес-процесса, а ответственность за контроль качества, за своевременность этапов этого бизнес-процесса берут на себя
участники различных функциональных групп. Матричный подход
предполагает дополнительные расходы на согласование всех этапов
бизнес-процесса, поэтому может быть использован в критических
секциях управления предприятием, в случаях, когда ошибочное
решение управления приводит к катастрофическим последствиям.
Таким образом, можно выделить следующие направления совершенствования системы управления предприятия: переход на
процессно-ориентированное управление и внедрение современных
информационных технологий управления.
Выбор системы – многокритериальная задача. Задание объективных критериев, по которым будет осуществляться выбор конкретной системы, напрямую связано с качеством и полнотой проработки всех предшествующих этапов цепочки выбора.
Практически все объективные соображения, которыми руководствуются при выборе системы (функциональные возможности,
94
стоимость системы и совокупная стоимость владения, перспективы
развития, поддержки и интеграции, технические характеристики
системы и т. п.), выводятся на предыдущих этапах. При тщательной проработке всех предшествующих этапов выбор системы перестает быть проблемой.
Существуют следующие основные стратегии внедрения системы:
1. Параллельная стратегия – когда одновременно работают старая (ручная) и новая система, и их выходные документы сравниваются. Если они согласуются длительное время, осуществляется
переход на новую систему.
2. «Скачок» – эта стратегия привлекательна, но не рекомендуется.
3. «Пилотный проект» – это наиболее часто используемая стратегия. «Пилотный проект» – это тактика «скачка», но применяемая к ограниченному числу процессов. Область применения стратегии – небольшой участок деятельности. Такой подход снижает
риск и наиболее надежен. Практически все предприятия применяют эту тактику сегодня.
4. «Узкое место» – это малая часть производственного процесса.
При использовании подхода «узкое место» план внедрения выполняется только для «узкого места» и для людей, работающих в нем.
Точность данных повышается только для изделий в этом «узком
месте»; переподготовка – только для людей, работающих в нем;
анализ эффекта затрат делается только для него и т. д.
Этап эксплуатации или сопровождения системы в динамично
меняющемся предприятии представляет собой довольно сложную
задачу. Модернизация программно-аппаратной части, вызванная
физическим и моральным старением компонентов АСУ; отслеживание изменений в законодательстве; необходимость доработки
системы под новые требования ее пользователей; обеспечение безопасности информации в процессе эксплуатации – эти и многие другие вопросы постоянно встают перед персоналом, ответственным за
процесс эксплуатации системы.
Затраты на эксплуатацию системы в рамках предприятия могут
и должны быть снижены за счет качественной проработки предшествующих этапов, в основном – за счет разработки стратегии автоматизации и осуществления выбора системы.
Основные проблемы при внедрении КИС начинаются с этапа
подготовки предприятия к автоматизации. Типичный вариант,
при котором работы начинаются с выбора системы, после чего специалисты поставщика АС проводят анализ деятельности предпри95
ятия (чаще принято говорить об «обследовании» предприятия) на
выявление некоторых проблем в области управления и формирования соответствующих рекомендаций. Поставщик программного
решения может дать конкретные рекомендации по изменению деятельности предприятия, однако существует большая вероятность,
что эти рекомендации будут отталкиваться от возможностей самого поставщика. И с еще большей вероятностью все они в конечном
итоге будут направлены на изменение схемы ведения бизнеса предприятия таким образом, чтобы на нее лучше «легла» их система.
96
4. ЗАДАЧИ ИНТЕГРАЦИИ
В ГЕТЕРОГЕННОЙ ИНФОРМАЦИОННОЙ СРЕДЕ
СОВРЕМЕННОГО ПРЕДПРИЯТИЯ
4.1. Особенности выбора архитектуры КИС
Для современных корпораций и крупных предприятий характерны такие особенности управления, как стохастический характер информационных потоков, которые часто необходимо обрабатывать в реальном масштабе времени; большое число разнородных производственных объектов; территориальная разобщенность источников и приемников информации; высокие требования
к надежности систем управления. В таких условиях становится необходимым построение распределенных КИС, которые согласуют
взаимодействие всех компонентов производственной структуры
с использованием корпоративных информационных сетей.
Как показывает опыт различных предприятий, ни одна ERPили SCM-система не могут охватить все разнообразие бизнес-процессов предприятия. Отдельные цехи, участки, отделы предприятия или фирмы чаще всего имеют свои специфические особенности, используют прикладные системы разных типов. При этом необходимо учесть, что построение КИС есть процесс исторический,
подразделения оснащаются вычислительной техникой не одновременно, отсюда возникают разные типы программно-аппаратных
платформ и разные вычислительные мощности.
С целью повышения эффективности производства, улучшения
конкурентоспособности предприятия возникает необходимость обработки информации в масштабах всего предприятия. Внедрение
КИС должно соответствующим образом организовывать информационные потоки, обеспечивать сопровождение, размещение, установление соотношений, получение результатов и итоговых документов, воспроизведение требуемой информации в определенные
моменты времени, причем быстродействие КИС должно удовлетворять требованиям бизнес-процессов предприятия.
В этой ситуации вступают в противоречие два основных принципа
построения ИС: принцип централизации (локальности) и принцип
децентрализации (распределенности). Известно, что для повышения
быстродействия необходимо сближение всех совместно используемых компонентов. Степень этой близости (компактности) можно рассматривать как пространственную (физическое расстояние между
компонентами), временную (функционирование в один период време97
ни, временные задержки и запаздывание), по вычислительной мощности, по выполняемым функциям (целесообразность и эффективность объединения). Поэтому для КИС необходимы максимальная
связность и минимальная взаимозаменяемость компонентов.
Современное приложение в КИС содержит пять основных функциональных уровней:
− менеджер представления (операционная среда – Windows,
Linux и т. п.);
− уровень логики представления для обслуживания интерфейса
пользователя;
− уровень логики приложений (логики управления), обеспечивающий корректное функционирование приложения;
− уровень логики данных (сохранение и извлечение данных при
помощи процессора БД);
− процессор баз данных (Oracle, SQL Server, MySQL и т. п.).
Если менеджер представления и процессор БД – стандартные
системные средства, то логические уровни проектируются разработчиком ИС в условиях многообразия вариантов в гетерогенной
распределенной среде. При этом возникают сложные задачи правильного размещения связанных компонентов на рабочих станциях и серверах корпоративной системы и организации эффективного обмена данными между ними.
На выбор такого размещения влияют такие составляющие, как
различие в быстродействии компонентов, конкуренция за разделяемые ресурсы, неодновременность доступа, неравномерная загруженность компонентов. Применение традиционного структурного
подхода к разработке распределенных информационных систем
приводит к тому, что сложность разработки таких систем нарастает лавинообразно: незначительные изменения функциональных
характеристик, которые затрагивают самый верхний уровень, влекут за собой необходимость перестройки нижних уровней, то есть
практически к проведению анализа и проектирования, заново.
В этом случае при использовании структурных методологий получаются трудно модифицируемые системы.
При создании ИС часто не уделяется достаточно внимания проектированию архитектуры. Интеграция различных компонентов системы проводится стихийным образом и в индивидуальном порядке.
Архитектурные решения таких разработок являются уникальными.
Подобная реализация затрудняет расширение системы, требует привлечения разработчиков ПО и/или поставщиков программных компонентов, что резко увеличивает стоимость разработки.
98
Под проектированием архитектуры информационной системы
понимается выделение базовых компонентов, разработка их интерфейсов, а также определение правил и принципов взаимодействия
этих компонентов.
Хорошо спроектированная архитектура системы – ключевое
качество для обеспечения адаптируемости. Это качество позволяет
уменьшить затраты на модернизацию и, соответственно, снизить
стоимость всей информационной системы.
Обычные интеграционные решения, где топология взаимодействия компонентов «каждый с каждым», не позволяют легко наращивать систему дополнительными функциональными возможностями. В то время как одна из основных целей интеграции – обеспечить легкость адаптации системы к новым требованиям в течение ее ЖЦ. В идеале интеграция программных компонентов в ИС
должна быть максимально простой, то есть подчиняться принципу
«plug and play». На практике такие возможности следует предусматривать при разработке архитектуры взаимодействия приложений.
При проектировании архитектуры системы в ее основу можно
заложить три принципиально отличных способа взаимодействия
распределенных компонент:
− вертикальный – каждый компонент имеет свой уникальный
в рамках этой ИС интерфейс;
− горизонтальный – все компоненты имеют один и тот же универсальный интерфейс для взаимодействия;
− гибридный – все компоненты имеют универсальный базовый
интерфейс, при этом каждый компонент специфицирует дополнительные операции для работы со своим доменом предметной области.
Достоинства и недостатки этих способов легко проследить на
примере интеграции новой задачи в ИС, состоящую из нескольких
компонентов.
В случае использования вертикального способа взаимодействия
распределенных компонентов количество программного кода, необходимого для интеграции, будет определяться количеством компонентов системы. Обычно такое решение является результатом
недостаточного внимания, уделяемого разработке архитектуры.
Количество интерфейсов в этом случае будет примерно N×N, где
N – число компонентов. Для внедрения новой задачи потребуется
2N раз разрабатывать новые связующие программы.
В случае горизонтально построенной системы количество интерфейсов (интеграционного кода) будет минимальным. Добавле99
ние нового компонента потребует реализации дополнительно всего
двух интерфейсов.
При реальной разработке чрезвычайно трудно создать одинаковые интерфейсы для всех подсистем, поэтому наиболее предпочтительным для создания распределенной системы является гибридный способ взаимодействия компонентов. В этом случае построенная архитектура сохраняет свойство универсальности интерфейсов, но позволяет добавлять специфичные для данного приложения операции. Количество кода, необходимого для интеграции
новой задачи, при такой архитектуре изменяется в зависимости от
проекта от 2 (горизонтальная архитектура) до 2N (вертикальная
архитектура).
Общие интерфейсы компонентов – ключ к проектированию архитектуры, обеспечивающей успешное развитие и поддержку системы на протяжении длительного периода.
4.2. Интеллектуализация
информационной среды КИС
Что же следует понимать под «интеллектуальной системой»?
Системы, ядром которых являются базы знаний или модель предметной области, описанные на языке сверхвысокого уровня, приближенном к естественному языку (ЕЯ), называют интеллектуальными. Такой ЕЯ называется языком представления знаний
(ЯПЗ). Чаще всего КИС применяется для решения сложных задач,
где основная сложность решения связана с использованием слабоформализованных знаний специалистов-практиков и где логическая (или символьная) обработка информации превалирует над
вычислительной. Например, понимание ЕЯ, поддержка принятия
решений в сложных ситуациях, постановка диагноза и рекомендации по методам лечения, анализ визуальной информации, управление диспетчерскими пунктами и др.
Считается, что переход к интеллектуальным системам целесообразен лишь там, где объектами управления являются плохо
определенные объекты, не позволяющие применять к ним классические методы современной теории управления. Следует отметить, что в определении понятия «интеллектуальная система» нет
единства мнений, поскольку ведущие ученые в этой области трактуют это понятие, исходя из своего опыта и убеждений. Так, интеллектуальную систему (ИНС) иногда определяют как систему по100
становки (выбора) задачи из допустимого для данной ИНС класса,
определяющего ее специализацию, решение такой задачи, закрепление опыта решения и, если необходимо, изменение допустимого
класса задач.
Не останавливаясь на том, что такое знания и каковы модели их
представления, заметим, что именно БЗ являются главным компонентом интеллектуальных систем, отражающим опыт управления
технологической установкой квалифицированного эксперта (или
группы экспертов), накопленный им в процессе многолетней деятельности.
Опираясь на анализ многих работ, определим ИНС как АИС, использующую формальные модели предметной области (и другие),
содержащую БЗ и оснащенную механизмом (средствами) логического (формального) вывода.
Допустим, что эти термины понятны хотя бы на интуитивном
уровне.
Прикладные ИНС в настоящее время широко используются во
всех индустриально развитых странах. Чем же вызывается необходимость использования ИНС в управлении современным производством? Отвечая на этот вопрос, следует выделить такие моменты.
Сложность действующих систем, предприятий и корпораций
постоянно возрастает. Такие системы, для которых закрепился
термин «сложные», или «большие», имеют множественные (различные) составные цели, требуют многоаспектного рассмотрения и
некоторой совокупности математических и языковых средств для
их адекватного описания.
Проблема анализа сложных систем состоит в большой размерности задачи, невозможности охвата логических связей одним человеком, чревата ошибками на этапе системного анализа. В процессе
управления предприятием необходимо делать выбор из множества
возможных альтернативных решений на различных стадиях производственного процесса. Эта задача усложняется с ростом динамики бизнес-процессов, с ускорением реинжиниринга, с увеличением
доли гибких производственных систем.
В процессе управления предприятием приходится обрабатывать
большие объемы информации, при этом необходимо выделить ту
часть информационного потока, которая действительно необходима для лиц, принимающих решения (ЛПР), и в то же время сохранить полноту и достоверность информации: сокращение избыточности и сохранение полноты (адекватности) информации. По мере
усложнения производства происходит сокращение времени на
101
принятие решений и возрастает потребность в интеллектуальном
анализе данных (ИАД), который позволяет выявить скрытые (неявные) изменения в состоянии производственных объектов, определить тенденции в поведении тех или иных показателей, установить закономерности функционирования сложных систем, не определяемые при обычном системном анализе.
Все большую роль играет и необходимость сохранения, распределения и накопления корпоративных знаний, объединяющих
в себе как различные информационные базы предприятия, так и
многолетний опыт экспертов и специалистов-практиков.
Слово «интеллектуальный» стало модным не только в узких научных кругах (ученым, как говорится, по должности положено его
употреблять), но и среди руководителей компаний, менеджеров
и других специалистов. Названия многих конференций, совещаний, публикаций, программных продуктов пополнились прилагательным «интеллектуальный» («интеллектуальное предприятие»,
«интеллектуальное управление» и пр.). Поэтому очень важно не
попасться на «крючок» красивого названия, а суметь различить
стоящее за ним содержание, если таковое имеется.
4.3. Распределенные объектные архитектуры
Традиционный структурный подход к проектированию КИС
предполагает последовательную реализацию основных этапов разработки системы: системный анализ, построение функциональных
моделей, системный проект, проектирование программных модулей, отладка программных модулей и объединение в целостную систему, тестирование и внедрение программного продукта.
Применение CASE-технологий и средств позволяет значительно
сократить сроки разработки КИС и снизить вероятность появления
ошибок за счет автоматического контроля создаваемых диаграмм,
автоматической генерации структуры сервера БД и программного
кода клиентских приложений.
В то же время обнаруживаются следующие недостатки таких
технологий и средств:
− программные коды клиентских приложений генерируются на
основе реляционной структуры БД;
− возникают проблемы перехода от табличных структур БД к
требуемым экранным формам приложений, что затрудняет разработку программ со сложной бизнес-логикой;
102
− сохраняются недостатки традиционного структурного подхода при обнаружении ошибок на заключительных стадиях проектирования.
Обозначенные выше проблемы позволяют решить объектноориентированные методы разработки КИС.
Данные методы обладают следующими преимуществами:
− возможно эффективное построение гетерогенных распределенных АИС вследствие того, что реализуется технология клиент-сервера;
− объектно-ориентированные КИС могут развиваться эволюционно, путем модернизации отдельных объектов, не затрагивая
остальные части системы, что снижает затраты на сопровождение
и риск капиталовложений;
− использование механизма унаследованных приложений позволяет включать разработанные ранее приложения в распределенную среду через объекты-оболочки;
− объектно-ориентированные КИС обладают свойством независимости объектов от размещения, вызов объектов осуществляется
стандартным образом и не зависит от коммуникационного ПО;
− обеспечивается масштабируемость КИС и возрастает их отказоустойчивость за счет репликации объектов;
− использование открытых стандартов обеспечивает независимость КИС от конкретных платформ, программных продуктов и
фирм-производителей.
Корпоративная информационная система, включающая в себя
множество взаимосвязанных удалённых программных объектов,
называется распределённой объектной системой.
К настоящему времени сложились три основные конкурирующие технологии их создания:
− архитектура группы управления объектами (Object Management Group – OMG), определяется как «Общая архитектура брокера
объектных запросов» (Common object request Broker Architecture –
CORBA);
− система вызовов удалённых методов Java (Remove Method
Invocation – RMI);
− модель распределённых компонентных объектов Microsoft
(Distributed Component Object Model – DCOM).
В 90-х годах был создан консорциум Object Management Group
(OMG), членами которого сейчас являются ведущие компьютерные
компании, такие как Sun, DEC, IBM, HP, Motorola и т. д. Задачей
консорциума стала разработка спецификаций и стандартов, позволяющих строить распределенные объектные системы в гетероген103
ных средах. Появление такого стандарта должно облегчить процесс
внедрения распределенных объектных технологий в разработку
приложений для различных отраслей производства. Необходимая
спецификация была разработана OMG и получила название Object
Management Architecture (OMA).
Данная спецификация состоит из четырех основных компонентов, представляющих собой спецификации различных уровней
поддержки приложений:
− архитектура брокера запросов объектов (Common Object
Request Broker Architecture – CORBA) устанавливает базовые механизмы взаимодействия объектов в гетерогенной сети;
− сервисы объектов (Object services) являются основными системными службами, используемыми разработчиками для создания приложений;
− универсальные средства (Common Facilities) ориентированы
на поддержку пользовательских приложений, таких как электронная почта, средства печати и т. д.;
− объекты приложений (Application Objects) предназначены для
решения конкретных прикладных задач.
Спецификация CORBA лежит в основе любого компонента, разработанного OMG. Она определяет механизм, обеспечивающий взаимодействие приложений в распределенной среде.
Главными компонентами стандарта CORBA являются:
– объектный брокер запросов (Object Request Broker);
– язык определения интерфейсов (Interface Definition Language);
– объектный адаптер (Object Adapter);
– репозиторий интерфейсов (Interface Repository).
Наличие большого количества сетевых протоколов в разных
операционных системах потребовало разработки спецификации
сетевых соединений. Семиуровневая модель Open System Interсonnection (OSI) обеспечивает описание сервисов, которые каждый
уровень должен предоставлять для реализации соединения. Низший уровень – физический – определяет доступ к физической линии. Уровень данных обеспечивает достоверную передачу данных
по физической линии. Сетевой уровень имеет дело с установкой
соединения и маршрутизацией. Транспортный уровень отвечает
за достоверную передачу до точки назначения. Уровень сессий обеспечивает управление соединением. Уровень представлений описывает синтаксис данных и обеспечивает прозрачность для приложений. Последний уровень – уровень приложений – обеспечивает
соответствующие сетевые функции для конечного пользователя.
104
Концептуально спецификация CORBA относится к уровням
приложений и представлений. Она обеспечивает возможность построения распределенных систем и приложений на самом высоком
уровне абстракции в рамках стандарта OSI. С её помощью возможно изолировать клиентские программы от низкоуровневых гетерогенных характеристик ИС. Характерные особенности разработки
по технологии CORBA заключаются в следующем.
Язык описания интерфейсов OMG IDL позволяет определить интерфейс, независимый от языка программирования, используемого для реализации. Высокий уровень абстракции CORBA в семиуровневой модели OSI позволяет программисту не работать с низкоуровневыми протоколами. Ему не требуется информация о реальном
месте расположения сервера и способе его активации. Разработка
клиентской программы не зависит от серверной операционной системы и аппаратной платформы.
Объектная модель CORBA определяет взаимодействие между
клиентами и серверами. Клиенты – приложения, которые запрашивают сервис. Серверы – приложения, предоставляющие сервисы. Объекты-серверы содержат набор сервисов, разделяемых
между многими клиентами. Операция указывает запрашиваемый
сервис объекта-сервера. Интерфейсы объектов есть описание множества операций, которые могут быть вызваны клиентами данного
объекта. Реализации объектов – приложения, реально исполняющие сервисы, запрашиваемые клиентами.
Спецификация CORBA разработана для обеспечения возможности интеграции совершенно различных объектных систем. Задачей
объектного брокера является предоставление механизма выполнения запроса, сделанного клиентом: поиск объекта, к которому относится данный запрос, передача необходимых данных, подготовка объекта к обработке. Интерфейс, с помощью которого клиент
может запрашивать выполнение необходимых операций, не зависит от местонахождения объекта и языка программирования, с помощью которого он реализован.
Спецификация OMG CORBA определяет базовый объектный
адаптер, который должен быть реализован во всех брокерах запросов.
Basic Object Adapter (BOA) – это набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активизации приложений.
В настоящее время OMG приняты или находятся в процессе формирования спецификации следующих служб.
105
Служба уведомления объектов о событии (Event Notification
Service) обеспечивает извещение заинтересованных объектов о происходящих в системе событиях. Объект может выступать в качестве «производителя» или «потребителя» некоторого события. Для
обеспечения асинхронного взаимодействия множества производителей событий с множеством их потребителей используются специальные объекты – «каналы событий», которые являются стандартными объектами CORBA.
Служба ЖЦ объектов (Object Lifecycle Service) поддерживает
создание, удаление, копирование и перемещение объектов. Для
создания объектов используются специальные объекты «фабрики
объектов» (object factories). Для определения положения таких
объектов используется понятие локатора фабрики (factory finder).
Для локаторов определена операция поиска, которая возвращает
последовательность соответствующих фабрик. Клиенты задают локатор фабрик как параметр в операциях создания, копирования и
перемещения. Такой подход к копированию и перемещению объектов обеспечивает независимость от ORB и механизма хранения.
Операция удаления определяется для любого объекта, поддерживающего базовый интерфейс службы ЖЦ.
Служба именования объектов (Name Service) обеспечивает отображение между именами и объектами (связывание имен). Связывание имени всегда определяется относительно некоторого контекста именования. Контекст именования – это объект, который
содержит множество связываний имен, и каждое имя в нем уникально. Несколько имен могут связываться с объектом в одном или
различных контекстах одновременно. Необязательно, однако, чтобы все объекты были именованными. Поскольку контекст подобен
другим объектам, он также может быть связан с именем в некотором контексте именования. При этом формируется направленный
граф именования с узлами, представляющими контексты.
Служба долговременного хранения объектов (Persistent Object
Service) обеспечивает сохранение объекта независимо от времени
жизни клиентов, осуществляющих доступ к объекту, и от реализации, обеспечивающей выполнение методов объекта. Состояние
объекта представляется динамической частью (определяет представление в оперативной памяти и может не поддерживаться в течение всего периода жизни объекта), и статической частью, которая используется для реконструкции динамической части. Служба
предоставляет общие интерфейсы к механизмам, обеспечивающим
сохранение статического состояния объекта и управление этим со106
стоянием. Ключевой идеей объектных систем, критической для
службы хранения, является возможность интеграции в данной архитектуре новых и уже существующих систем хранения.
Служба управления конкурентным доступом (Concurrency
Control Service) поддерживает конкурентный доступ к одному или
более объектам со стороны одного или более объектов. Интерфейс
службы позволяет выполнять вычисления в рамках транзакции
(автоматическое освобождение блокировок по завершении транзакции), либо нетранзакционно (ответственность за своевременное
разблокирование ложится на пользователя). Служба управления
конкурентным доступом гарантирует правильную последовательность транзакционных и нетранзакционных вызовов по отношению друг к другу.
Служба внешнего представления объектов (Externalization
Service). Спецификация службы определяет протоколы и соглашения по внешнему и внутреннему представлению объектов. Внешнее представление используется при записи объекта в поток передачи данных. Объекты, которые поддерживают соответствующие
интерфейсы и чьи реализации удовлетворяют соответствующим
соглашениям, могут быть направлены в поток (в память, в дисковый файл, через сеть и т. д.) и впоследствии преобразованы в новый
объект в том же или в другом процессе.
Служба объектных связей (Relationships Service) обеспечивает
средства для создания, удаления, навигации и управления связями между объектами. Служба определяет два новых вида объектов:
связь и роль. Роль представляет CORBA-объект в некоторой связи.
Объект-связь создается на основании множества ролей, передаваемого в фабрику связей. На связях можно задавать и проверять ограничения типа и кардинальности, при нарушении которых возникают исключительные ситуации.
Служба транзакций (Transaction Service) предоставляет гарантию того, что вычисления поддерживают некоторые или все присущие транзакциям ACID свойства (атомарность, непротиворечивость,
изолированность, постоянство). Транзакционная служба поддерживает два вида транзакций: плоские (flat) и гнездовые (nested). Клиент может посылать заявки к множеству объектов, размещенных в
различных узлах сети в рамках области действия транзакции. Поддержка таких распределенных транзакций требует от ORB возможности передачи «контекста транзакции» с каждой заявкой.
Служба изменения объектов (Change Management Service) поддерживает идентификацию и согласованную эволюцию объектов.
107
Сюда входит управление версиями существующих объектов, связанными наборами или конфигурациями объектов и преобразованиями между соответствующими представлениями объектов.
Служба лицензирования (Licensing Service) обеспечивает среду
для спецификации и управления лицензионной политикой.
Служба объектных свойств (Properties Service) позволяет связывать с объектом динамически создаваемые атрибуты. Посредством
интерфейса, определенного службой, информация может быть связана с состоянием объекта (например, его заголовком или датой). Свойства являются динамическими эквивалентами атрибутов CORBA.
Служба объектных запросов (Object Query Service) осуществляет операции над наборами объектов. Операции имеют основанную
на предикатах декларативную спецификацию и могут возвращать
наборы объектов как результат. Служба запросов не должна нарушать инкапсуляцию объектов. Далее служба запросов рассматривается детальнее.
Служба безопасности объектов (Object Security Service) контролирует доступ к объектам. Данная служба действует в пределах
всей распределенной системы. Безопасность имеет дело с такими
понятиями, как конфиденциальность и целостность информации,
ответственность пользователей за свои действия, доступность информации.
Служба объектного времени (Time Service) поддерживает механизм синхронизации в распределенной системе.
Помимо рассмотренных выше, имеется также ряд служб, которые впоследствии были связаны с другими компонентами OMA.
Начиная со стандарта CORBA 2.0, вводятся механизмы одновременного сосуществования в распределённой объектной среде
нескольких (возможно, разнотипных) объектных брокеров и определяются механизмы их взаимодействия.
Для связи между брокерами в гетерогенной сети был разработан
протокол General Inter ORB Protocol (GIOP), стандартизирующий
низкоуровневое представление данных и множество форматов сообщений. Этот протокол предоставляет возможность портировать
приложения, обеспечивая минимальную зависимость от транспортного уровня передачи данных. Internet Inter ORB Protocol (IIOP)
определяет обмен сообщениями в формате GIOP, используя TCP/IPсоединения. Этот протокол разработан для использования любыми
объектными брокерами, реализованными на основе протокола IP.
Однако при необходимости они могут содержать и другие реализации протокола GIOP, например на основе протокола IPX/SPX.
108
В стандарте CORBA3 произошли существенные изменения
в архитектуре объектных брокеров. Впервые введенный в стандарте CORBA 2.2 портируемый объектный адаптер (Portable Object
Adapter – POA ) стал одним из основных усовершенствованных элементов серверной части.
Разработчиками стандарта был определен ряд новых понятий,
связанных с ЖЦ объектов.
CORBA-о б ъ е к т – виртуальный объект, расположенный на брокере объектных запросов, посылающий запросы к другим CORBAобъектам – серверным объектам и получающий запросы от других
CORBA-объектов – клиентов. В контексте запроса от клиента такой
объект называют целевым (target object). Обращение к нему осуществляется по объектной ссылке (object reference).
И д е н т и ф и к а т о р о б ъ е к т а – уникальное имя объекта внутри его объектного адаптера. Он представляет собой последовательность байт, которая ассоциируется с объектом в момент его создания и обеспечивается либо программным приложением, либо РОА.
Идентификатор объекта не обязан быть уникальным для сервера,
так как на сервере объект известен под своей объектной ссылкой.
С е р в а н т – серверная программа, написанная на каком-либо из
языков программирования и реализующая CORBA-объект. Это может быть набор функций, представляющих состояние объекта или
реализации определенных классов серверного приложения (на C++
или Java). Сервант написан на том же программном языке, что и
приложение, и является программной реализацией объекта CORBA.
С к е л е т о н – серверная программа, которая связывает сервант
с объектным адаптером, позволяя объектному адаптеру перенаправлять запросы к соответствующему серванту. В языке С скелетон – набор указателей на функции серванта, в С++ скелетон –
родительский класс для всех классов сервантов. При статических
методах вызова скелетон формируется при компиляции IDL-кода,
при динамических – не используется.
А к т и в и з а ц и я – запуск существующего CORBA-объекта для
обработки клиентских запросов. Активизация предполагает, что
интересующий клиента объект имеет подходящий сервант. Создание серванта может входить в процесс активизации. В отличие от
сервантов создание объектов не является предметом активизации и
чаще всего осуществляется с помощью объектов-фабрик, которые
относятся к службе ЖЦ.
Д е а к т и в и з а ц и я – действие, обратное активизации, останов
CORBA-объекта, разрыв связки между объектом и сервантом, в об109
щем случае без разрушения объекта. В дальнейшем CORBA-объект
может быть вновь активизирован. Разрушение CORBA-объекта
обязательно вызывает деактивизацию.
И н к а р н а ц и я – это связывание серванта с CORBA-объектом
для обработки клиентского запроса. Инкарнация материализует в
серванте виртуальный CORBA-объект. В отличие от активизации
инкарнация относится не к объекту, а к его серванту.
Э ф е м е р и з а ц и я – в противоположность инкарнации разрушение связки CORBA-объект – сервант со стороны серванта. Так
же как инкарнация, эфемеризация является операцией серванта.
К а р т а а к т и в н ы х о б ъ е к т о в (Active Object Map) – таблица
объектного адаптера, в которой он ведет реестр активных CORBAобъектов и связанных с ними сервантов. Первые представлены
в карте своими идентификаторами.
Объектный адаптер должен выполнять следующие операции:
− создавать CORBA-объекты и их объектные ссылки;
− демультиплексировать запросы на каждый серверный CORBAобъект;
− коммутировать запросы к соответствующему серванту, который обеспечивает реализацию серверного CORBA-объекта;
− активизировать и деактивизировать CORBA-объекты и, соответственно, выполнять инкарнацию и эфемеризацию соответствующих сервантов.
110
5. СТАНДАРТЫ ОПИСАНИЯ, АНАЛИЗА
И РЕОРГАНИЗАЦИИ БИЗНЕС-ПРОЦЕССОВ
КОРПОРАТИВНОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
5.1. Особенности разработки архитектурных решений КИС
При проектировании архитектуры приложений первым шагом должен быть выбор используемых стандартов. С увеличением
сложности ИС важность соответствия ПО международным стандартам возрастает.
Стандарты используются для достижения следующих целей:
– портируемость приложений – перенос приложений на различные
аппаратные платформы, операционные системы, сетевые протоколы;
– интероперабельность – определение общих форматов и интерфейсов взаимодействия программных систем;
– снижение стоимости системы – уменьшение стоимости приложений для конечного пользователя за счет интеграции программных систем, поддерживающих общепринятые стандарты;
– снижение риска выбора программного продукта – освобождение разработчика от привязанности к конкретному программному
продукту;
– увеличение времени жизни системы – уменьшение риска быстрого устаревания системы.
Информатизация предприятия происходит неравномерно. Различные производства, цехи и участки оснащаются техническими
средствами в разное время, поэтому неизбежно возникает разнородность (гетерогенность) используемых ИС, различие в операционных средах и технических средствах (аппаратное обеспечение).
Рассмотрим информационную и реализационную неоднородность КИС, компонентами которых являются различные информационные ресурсы. Последними являются исполняемые программы, БД и БЗ, файловые системы, рассматриваемые независимо от
аппаратно-программных платформ, реализации и топологии их
размещения в информационно-вычислительной сети.
Информационная неоднородность ресурсов КИС заключается
в разнообразии их прикладных контекстов (используемых онтологических средств – понятий, словарей; отображаемых реальных
объектов, составляющих «поверхность соприкосновения» различных реальных миров и их (объектов) абстракций в ИС; семантических правил, определяющих адекватность совокупности моделируемых объектов реальности; моделируемых деятельностей; видов
111
данных, способов их сбора и обработки; интерфейсов пользователей и т. д.).
Реализационная неоднородность ресурсов КИС проявляется
в использовании разнообразных компьютерных платформ, средств
управления БД, моделей данных и знаний, систем программирования, операционных систем и т. п.
Системы эволюционируют от простых, автономных подсистем
к более сложным, интегрированным системам, основанным на интероперабельном взаимодействии компонентов. Усложнение бизнес-процессов и процедур управления – это непрерывный процесс,
который является неотъемлемой составляющей деятельности организаций. Соответственно, создание системы и её реконструкция
(реинжиниринг) – непрерывный процесс формирования, уточнения требований и конструирования. Реконструкция систем осуществляется постепенно, причем система должна быть сконструирована так, чтобы произвольные её составляющие могли быть реконструированы при сохранении целостности системы.
Любая система после создания противодействует изменениям и
имеет тенденцию быстрого превращения в бремя организации – так
называемые унаследованные системы (legacy systems), использующие «уставшие» технологии, архитектуры, платформы, а также
собственное программное и информационное обеспечение, при проектировании которых не были предусмотрены нужные меры по их
пошаговой миграции в новые системы, соответствующие новым
требованиям деловых процессов и технологии). Существенно, что
в процессе миграции необходимо, чтобы мигрировавшие составляющие системы и оставшиеся компоненты унаследованных систем
сохраняли интероперабельность.
Технология разработки ИС должна позволять крупномасштабно применять технологию повторного использования информационных ресурсов, перехода от технологии программирования,
основанной на интенсивном индивидуальном труде по созданию
изделий, удовлетворяющих специфическим требованиям одного
конкретного применения, к технологии, основанной на планируемых капиталовложениях в разработку повторно используемых
компонентов, которые могут быть «соединены» (то есть образованы
их интероперабельные сообщества) для производства серий стандартизованных продуктов в определённой прикладной области.
В условиях исключительно быстрого технологического развития требуются специальные меры, обеспечивающие необходимую
продолжительность ЖЦ.
112
Мировой опыт свидетельствует, что внедрению КИС должно
предшествовать серьезное функционально-информационное обследование предприятия с целью определения оптимальности бизнеспроцессов, распределения ресурсов между функциями и т. д.
Понятие «моделирование бизнес-процессов» пришло в обиход
большинства аналитиков одновременно с появлением на рынке
сложных программных продуктов, предназначенных для систем
комплексной автоматизации управления предприятием. Подобные
системы всегда подразумевают проведение глубокого предпроектного обследования деятельности.
Результатом этого обследования является экспертное заключение, в котором отдельными пунктами выносятся рекомендации
по устранению «узких мест» в управлении деятельностью. На основании данного заключения, непосредственно перед проектом
внедрения системы автоматизации проводится так называемая
реорганизация бизнес-процессов, иногда достаточно серьезная и болезненная для компании. Это и естественно, сложившийся годами
коллектив всегда сложно заставить «думать по-новому». Подобные
комплексные обследования предприятий являются сложными и
существенно отличающимися от случая к случаю задачами.
Для решения подобных задач моделирования сложных систем
существуют хорошо обкатанные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF. С их помощью можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе
определяется самим разработчиком, что позволяет не перегружать
создаваемую модель излишними данными. В настоящий момент к
семейству IDEF можно отнести следующие стандарты:
1) IDEF0 – методология функционального моделирования (Руководящий документ Госстандарта РФ «Методология функционального моделирования IDEF0»). Метод IDEF0 предназначен для функционального моделирования 260.6, то есть моделирования выполнения
функций объекта путем создания описательной графической модели, показывающей что, как и кем делается в рамках функционирования предприятия. Функциональная модель представляет собой
структурированное изображение функций производственной системы или среды, информации и объектов, связывающих эти функции;
2) IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их
структуру и взаимосвязи;
113
3) IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий «Сущность-взаимосвязь» (Entity-Relationship – ER) и, как правило, используется для моделирования реляционных БД, имеющих отношение к рассматриваемой системе;
4) IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа
динамических систем от этого стандарта практически отказались
и его развитие приостановилось на самом начальном этапе. Однако
в настоящее время применяются алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм
IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (Color Petri Nets – CPN);
5) IDEF3 – методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью
IDEF3 описываются сценарий и последовательность операций для
каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функция (функциональный блок) может быть
представлена в виде отдельного процесса средствами IDEF3;
6) IDEF4 – методология построения объектно-ориентированных
систем. Средства IDEF4 наглядно отображают структуру объектов
и заложенные принципы их взаимодействия, тем самым позволяя
анализировать и оптимизировать сложные объектно-ориентированные системы;
7) IDEF5 – методология онтологического исследования сложных
систем. С помощью методологии IDEF5 онтология системы может
быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные
утверждения о состоянии рассматриваемой системы в некоторый
момент времени. На основе этих утверждений формируются выводы
о дальнейшем развитии системы и производится ее оптимизация.
5.2. Функциональное моделирование
Рассмотрим типовые методы построения функциональных моделей, используемые в функционально ориентированных методологиях
проектирования КИС. Как упоминалось ранее, достоинством функционально ориентированных методологий является реализация
структурного подхода к проектированию КИС «сверху-вниз», когда
114
каждый функциональный блок может быть декомпозирован на множество подфункций и т. д. Для таких моделей характерна строгость
декомпозиции и наглядность графического представления. Проектирование при использовании функционально-ориентированной методологии начинается с построения функциональных моделей (схем).
В функциональной модели главными структурными компонентами являются функции (операции, работы, действия), которые
связываются между собой потоками информационных и материальных объектов.
В качестве примеров методов построения функциональных моделей ниже рассмотрим метод функционального моделирования
IDEF0, метод построения графических моделей информационных
процессов предприятия IDEF3 и диаграммы потоков данных DFD.
Как известно, IDEF0 и IDEF3 входят в семейство стандартов
IDEF (Integrated Definition), разработанных в США в рамках программы Integrated Computer-Aided Manufacturing (ICAM).
IDEF0 – это классический метод функционального моделирования, представляющий собой переработанный метод SADT (Structured Analysis and Design Technique). Метод SADT был создан компанией SofTech в конце 60-х годов как набор рекомендаций по разработке сложных систем, предполагающих активное взаимодействие механизмов и обслуживающего персонала. В конце 70-х годов ядро SADT было принято ВВС США как часть программы ICAM
(Integrated Computer-Aided Manufacturing – интегрированная
компьютерная поддержка производства) и стало основой IDEF0.
Довольно быстро IDEF0 стал стандартом моделирования деятельности в рамках министерства обороны США. В 1993 году был создан документированный открытый стандарт для IDEF0, опубликованный как федеральный стандарт обработки информации (Federal
Information Processing Standard – FIPS).
IDEF3 – это метод описания бизнес-процессов, который был специально разработан для проекта ВВС США. Метод ориентирован на
получение описания деталей процесса от экспертов в предметной
области и разработки схем таких процессов, для которых важно
понять последовательность выполнения действий и взаимозависимости между ними. Метод может быть также использован при проектировании бизнес-процессов и анализе систем имитационными
методами. IDEF3 получил широкое распространение как средство
детализации схем IDEF0.
Метод DFD (Data Flow Diagrams – диаграммы потоков данных)
получил популярность как структурное средство для разработки
115
проектов КИС. Диаграммы потоков данных схожи с IDEF0 и IDEF3
и могут быть использованы в сочетании с ними, но обеспечивают
возможность одновременного проектирования функций и данных.
IDEF0 – это метод описания системы в целом как множества взаимозависимых функций (действий). Функции системы исследуются независимо от объектов, обеспечивающих их выполнение. Такая
сугубо «функциональная» точка зрения позволяет четко отделить
аспекты назначения системы от вопросов ее реализации. IDEF0 часто используется как способ исследования и проектирования систем
на логическом уровне. Результаты анализа с помощью IDEF0 могут
применяться при проектировании с использованием IDEF3 и DFD.
IDEF0 содержит очень небольшую по объему графическую нотацию в сочетании с четкими правилами и рекомендациями по построению качественной и понятной схемы системы.
IDEF0 определяет два графических объекта:
1) блок, с помощью которого обозначается некоторая функция
(действие);
2) стрелка, с помощью которой указываются информационные
или материальные объекты.
Функция обрабатывает входные объекты и преобразует их в выходные. Функциональный блок обозначается, как это показано на
рис. 5.1, где «Формирование отчета» – наименование функции,
«1» – номер функции. Наименование функции должно характеризовать процесс и состоять из глагола или отглагольного существительного с дополнением. Наименование должно соответствовать
выбранной точке зрения моделирования. Для функционального
блока обязательно должно быть указано наименование.
Описание любого функционального блока должно как минимум включать описание объектов, которые создаются в результате выполнения функции («выход»), и объектов, воздействующих
на способ преобразования входа в выход (управляющих объектов,
управления). Так же практически всегда описываются объекты,
Формирование
отчета
1
Рис. 5.1. Обозначение
функционального блока в IDEF0
116
преобразуемые или потребляемые при выполнении функции, то
есть «вход».
На IDEF0-диаграммах с помощью стрелок можно показывать до
четырех типов объектов:
1) вход (Input, I),
2) управление, или контроль (Control, C),
3) выход (Output, O),
4) исполняющий механизм (Mechanism – M) – то, что используется непосредственно для выполнения процесса, но остается неизменным (либо изменения незначимы и являются побочным результатом).
Каждый тип жестко привязан к определенной стороне функционального блока, что, собственно, и обеспечивает возможность
различения стрелок разных типов. Одновременно может использоваться произвольное количество стрелок любого типа.
Как и для функций, стрелкам должны быть присвоены наименования, иначе возникает существенная возможность неправильного истолкования сути диаграммы. Для наименования стрелок
обычно используются имена существительные, поскольку стрелки
обозначают объекты. Различают стрелки входа, стрелки управления и стрелки выхода (рис. 5.2).
Стрелка
управления
(Control)
Стрелка
входа
(Input)
Стрелка
выхода
(Output)
Функция
0
Стрелка
механизма
исполнения
(Mechanism)
Рис. 5.2. Стрелки в IDEF0
117
Стрелки входа. Вход – это информация или сырье, потребляемое или преобразуемое функциональным блоком для производства
выхода. Стрелки входа всегда направлены в левую сторону прямоугольника функционального блока. Наличие у некоторого блока
входных стрелок не является обязательным, так как возможно, что
некоторые блоки ничего явным образом не изменяют и не преобразуют.
Стрелки управления. Определяют, чем регулируется выполнение функции. Стрелки управления всегда входят в функциональный блок сверху. Управление контролирует поведение функционального блока для обеспечения получения желаемого выхода.
Поэтому каждый блок должен иметь как минимум одну стрелку
управления. Управление обычно представляет собой правила, инструкции, стандарты и т. п. Управление можно рассматривать как
специфический вид входа.
Стрелки выхода. Выход – информация или продукция, получаемая в результате выполнения функционального блока. Каждый
блок должен иметь как минимум одну стрелку выхода. Важно,
чтобы наименования входных и выходных стрелок различались.
Например, если блок «Проверить оформление документов» имеет
вход «Документы», то выходную стрелку можно обозначить как
«Проверенные документы» (или: «Правильно оформленные документы», «Неправильно оформленные документы»).
Стрелки механизма исполнения. Механизм – это объект, с помощью которого и посредством которого непосредственно выполняется моделируемое действие. Пример механизма исполнения:
персонал, оборудование. Стрелки механизма исполнения часто могут не указываться, если их отображение не способствует достижению цели моделирования.
В IDEF0 существует пять основных типов соединения функциональных блоков.
Выход-вход. Комбинированная стрелка (соединение) «выходвход» применяется, когда один блок должен полностью завершить
работу перед началом работы второго (рис. 5.3).
Принять заказ
1
Пункты
заказа
Выписать счет
на оплату
2
Рис. 5.3. Комбинированная стрелка «выход-вход» в IDEF0
118
Выход-управление. Используется, когда один блок управляет работой другого, или иначе, один блок преобладает над другим
(рис. 5.4).
Выход-механизм исполнения. Используется редко и отражает
ситуацию, когда выход одного блока является инструментом, обеспечивающим выполнение другого (рис. 5.5).
Выход-обратная связь на вход. Обычно используется для описания циклов повторной обработки чего-либо (рис. 5.6).
Сформировать
план реферата
План реферата
1
Собрать литературу
2
Рис. 5.4. Выход-управление в IDEF0
Напечатать реферат
2
Собрать компьютер
Компьютер
1
Рис. 5.5. Выход-механизм исполнения в IDEF0
Некорректно
заполненная форма
Заполнить форму
1
Заполненная
форма
Проверка формы
2
Корректно
заполненная
форма
Рис. 5.6. Выход-обратная связь на вход в IDEF0
119
Выход-обратная связь на управление. Используется для описания обратной связи между управляемым и управляющим блоками
(рис. 5.7).
Возможно соединение и разъединение стрелок на диаграмме.
Разъединенные стрелки могут иметь наименования, отличные от
наименования исходной стрелки. Обычно разъединение применяется для отражения факта использования только части информации
или сырья, помеченного исходной стрелкой. Аналогично обстоит
дело с объединением стрелок. В узлах разъединения и объединения стрелки скругляются, то есть они не образуют прямых углов
(рис. 5.8).
Модель IDEF0 представляет собой набор взаимоувязанных диаграмм. Каждая диаграмма является описанием системы или ее отдельных функциональных блоков в рамках некоторого уровня детализации.
Текущее
положение
в пространстве
Выбрать курс
полета
Курс
1
Скорректировать
курс
2
Рис. 5.7. Выход-обратная связь на управление в IDEF0
Информация А, Б
Информация А
Функция 1
1
Функция 2
Функция 3
2
3
Рис. 5.8. Пример разъединения стрелок на диаграмме IDEF0
120
Контекстная диаграмма (КД) – диаграмма самого верхнего уровня иерархии – дает общее представление о системе. На контекстной
диаграмме отображается только один функциональный блок (контекстная функция).
Далее контекстная функция декомпозируется на основные
функции системы с помощью отдельной диаграммы. В свою очередь каждая такая функция может быть разложена на более мелкие и т. д. При построении модели нужно соотнести каждый функциональный блок более низкого уровня с функциональным блоком
более высокого уровня.
Следует всегда помнить, что некоторый функциональный блок
и диаграмма его декомпозиции суть одно и то же, но рассматриваемое с разной степенью детализации. Отсюда следует, что все
стрелки, связанные с рассматриваемым функциональным блоком,
должны присутствовать на декомпозирующей его диаграмме (если
таковая имеется). Исключения из этого правила взаимоувязывания стрелок возможно только в случае использования механизма
туннелирования, рассматриваемого ниже.
На рис. 5.9 показана типовая модель IDEF0: контекстная диаграмма (рис. 5.9), а на рис. 5.10 – диаграмма детализации контекстной функции (диаграмма первого уровня детализации), цель
которой показать основные складские операции и их взаимосвязь.
Точка зрения: работник склада.
Нормативы
складского
учета
Товар
Выходные
документы
Организация учета
движения товаров
на складе
Первичные
документы
0
Оформленный
товар
АРМ
работника
склада
Рис. 5.9. Контекстная диаграмма IDEF0
121
Нормативы
складского
учета
Товарно-сопроводительные
документы
Первичные
документы
Товар
Приемка
товара
1
Приказ
об инвентаризации
Приходный
ордер
Данные
о приемке
товара
Принятый
товар
Расходная
накладная
Отпуск
товара
Накладные,
требования
2
Данные
об отгрузке
товара
Выходные
документы
Отгруженный
товар
Ведение
БД
Оформленный
товар
Оборотная
ведомость
движения
3 товаров
Ведомость
инвентаризации
Товарные
остатки
Инвентарный
контроль 4
АРМ работника склада
Рис. 5.10. Диаграмма детализации контекстной функции IDEF0
Порядок построения модели следующий:
1. Определение цели моделирования.
2. Определение точки зрения (непосредственный исполнитель
процесса, управленец, внешний аналитик и т. п.).
Модель должна разрабатываться исходя из единственной и заранее определенной точки зрения. Это обеспечивает внутреннюю
целостность и в значительной степени предотвращает постоянное
изменение структуры.
Определение цели моделирования и точки зрения позволяют
выявить границы моделирования: ширину и глубину охвата.
Часто строится целый набор моделей для разных точек зрения.
Общие рекомендации по построению модели:
1. На каждом уровне представлять не более 3–6 функциональных блоков.
2. Не загромождать диаграмму несущественными на текущем
уровне функциями и объектами.
3. Одновременно вести декомпозицию функций и объектов.
122
4. При определении связанных блоком стрелок сначала следует
описать стрелки выходов и управления, поскольку их наличие обязательно. Если не ясно, относить ли стрелку к входу или управлению, то выбирают последнее. При этом необходимо помнить, что
управление можно рассматривать как особый вид входа.
5. Следует выбирать ясные и полные наименования элементов.
Все блоки нумеруются. Номер имеет вид: <префикс><цифра>.
Префикс представляет совокупность некоторой строки (обычно
символ «A») и номера родительского блока. Для блоков первого
уровня детализации номер родительского блока не указывается.
Контекстная функция обозначается как A0, декомпозирующие ее
блоки – A1, A2, A3,... Далее, блок A1 может декомпозироваться на
A1.1, A1.2,...; A1.1 – на A1.1.1, A1.1.2,... Точки обычно не ставятся, поскольку на грамотно построенной диаграмме не бывает больше 6–7 блоков, то есть: A0, A1, A11, A111,...
Если необходимо нарушить правило взаимоувязывания стрелок
на родительской диаграмме и диаграмме декомпозиции, то следует
воспользоваться механизмом туннелирования. Туннели позволяют
избавиться от загромождения родительских диаграмм стрелками,
не существенными для их уровня. Аналогично, при построении диаграмм декомпозиции иногда неудобна необходимость изображения некоторых стрелок, связанных с декомпозируемой функцией.
Туннель обозначается с помощью скобок у начала или конца стрелки. Если скобки ставятся у конца стрелки (то есть около блока), то
это значит, что данная стрелка не показывается на диаграмме декомпозиции.
Кроме контекстной диаграммы и диаграмм декомпозиции при
представлении моделей IDEF0 могут использоваться презентационные диаграммы и диаграммы дерева модели.
Презентационная диаграмма (For Exposition Only – FEO) допускает любые нарушения синтаксиса IDEF0. Фактически, это
любая иллюстрация. Обычно такие диаграммы используются для
более полного описания функциональных блоков и их совокупностей.
Дерево модели – это обзорная диаграмма, показывающая иерархическую структуру модели (рис. 5.11).
Узел дерева модели – это функциональный блок. Обычно вершина соответствует контекстному блоку
Аналогично IDEF0 диаграммы потоков данных (Data Flow
Diagrams – DFD) позволяют моделировать систему как набор функций (действий, операций и т. п.), соединенных стрелками.
123
A0
A1
A2
A21
A3
A22
A23
Рис. 5.11. Дерево модели (обзорная диаграмма) IDEF0
Для метода DFD модель системы – это иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования
информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии – КД – определяют основные
функции, или подсистемы КИС с внешними входами и выходами.
КД детализируются при помощи диаграмм нижних уровней.
Имеются два основных варианта DFD: метод Гейна – Сарсона
(Gane – Sarson) и метод Йордана – Де Марко (Yourdon – De Marco).
Нотации этих методов различаются.
В DFD имеются два типа элементов, не имеющих аналогов
в IDEF0. Это накопители данных – объекты, в которые собирается и
в которых хранится информация, и внешние сущности – объекты,
с помощью которых моделируется взаимодействие с частями системы,
выходящими за границы моделирования, или с другими системами.
Основными элементами DFD являются:
− внешние сущности;
− системы и подсистемы;
− процессы;
− накопители (хранилища) данных (data store);
− потоки данных.
Внешняя сущность – материальный предмет или физическое
лицо, представляющее собой источник или приемник информации. Внешняя сущность находится за пределами анализируемой
части системы (или системы целиком).
В процессе анализа некоторые внешние сущности могут переноситься внутрь диаграммы анализируемой системы. Или, наоборот,
часть процессов КИС может переноситься за границы моделирования и представляться как внешние сущности.
124
Система и подсистема. При построении модели сложной КИС
она может быть представлена на КД в виде одного блока (то есть
системы), либо декомпозирована на ряд подсистем. Система и подсистема – это частный случай процесса.
Наименование системы и подсистемы представляет собой существительное или некоторое предложение с подлежащим.
Процесс. Под процессом понимается преобразование входных
потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может реализовываться посредством
персонала организации, аппаратуры, программы и т. п.
Наименование процесса: активный глагол в неопределенной
форме, за которым следует дополнение в виде существительного
в винительном падеже («вычислить квадратный корень» и т. п.).
Накопитель данных – абстрактное устройство для хранения
информации. Накопитель данных часто является прообразом будущей БД. Наименование накопителя данных представляет собой
существительное.
Поток данных – информация, передаваемая от источника
к приемнику по некоторому каналу (соединению).
В зависимости от нотации, элементы DFD могут обозначаться
по-разному (табл. 5.1).
Таблица 5.1
Обозначения элементов DFD в разных нотациях
Элемент
Нотация Гейна – Сарсона Нотация Йордана – Де Марко
Внешняя сущность
Наименование
Наименование
Процесс
Номер
Наименование
Накопитель данных
№
Наименование
Поток данных
Наименование
Наименование, номер
Наименование
Наименование
125
В некоторых модификациях метода Гейна – Сарсона для процессов могут быть показаны ресурсы, аналогичные механизмам исполнения IDEF0 (рис. 5.12).
Простейший фрагмент диаграмм – два процесса, связываемых
потоком данных, – показаны на рис. 5.13.
Потоки данных могут разбиваться (разветвляться) и соединяться (рис. 5.14). При разбиении каждая новая ветвь может быть переименована. Таким образом в DFD обеспечивается возможность декомпозиции данных.
В самом общем случае порядок построения иерархии DFD следующий.
1. Создание контекстной диаграммы; обычно для простой КИС
строится одна диаграмма со звездообразной топологией: центр
звезды – система, углы – внешние сущности.
2. Детализация системы и процессов. При этом должно соблюдаться правило балансировки: на диаграмме детализации могут
указываться только те источники и приемники информации, коНомер
Наименование
Ресурсы
Рис. 5.12. Модификация метода
Гейна – Сарсона для процессов DFD
A
B
Рис. 5.13. Фрагмент диаграммы
для двух процессов DFD
Рис. 5.14. Разветвление и соединение потоков данных в DFD
126
торые показаны для детализируемой системы (процесса). Правило
нумерации процессов: номер имеет вид типа X, Y, где Y – порядковый номер процесса, детализирующего процесс X.
3. Завершение детализации. Детализация процесса не выполняется в следующих случаях:
− наличие небольшого числа входных и выходных потоков данных (2-3 потока);
− возможность описания процесса преобразования данных последовательным алгоритмом;
− описание преобразования входной информации в выходную
единственной логической функцией;
− описание логики процесса с помощью так называемой миниспецификации – текста объемом 20–30 строк на ЕЯ, в котором четко определяется функция преобразования.
4. Верификация (проверка на корректность). Должно выполняться правило сохранения информации: все поступающие данные
должны быть считаны, все считываемые – записаны.
Внешние сущности и накопители данных также обычно нумеруются. Номер накопителя данных состоит из префикса D (Data
store) и уникального порядкового номера накопителя во всей модели DFD. Номер внешней сущности состоит из префикса E (External
entity) и ее уникального порядкового номера в модели.
Применение DFD предполагает, что структуры потоков данных
и накопителей данных должны быть описаны отдельно. Диаграммы потоков данных обеспечивают удобный инструмент описания
функционирования компонентов системы, но не позволяют указать, какая именно информация преобразуется процессами и как
она преобразуется. Для решения первой задачи предназначены
текстовые средства, служащие для описания структуры преобразуемой информации и получившие название словарей данных.
Словарь данных представляет собой определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям
пользователей (от системного аналитика до программиста) иметь
общее понимание всех входных и выходных потоков и компонентов накопителей. Для решения второй задачи используются миниспецификации.
При построении диаграмм DFD полезно придерживаться следующих принципов:
− размещать на одной диаграмме 3–7 процессов (меньше 3 – малоосмысленная детализация, больше 7 – излишне сложная схема);
127
− декомпозировать потоки совместно с детализацией процессов;
− давать емкие и недвусмысленные наименования, избегать сокращений и аббревиатур; при наличии вариантов возможных декомпозиций выбирать самый простой.
При построении диаграмм DFD удобно придерживаться такой
последовательности действий:
1) разложить множество требований в крупные группы по функциональному признаку, получить в результате основные функциональные группы;
2) выявить все важные внешние объекты;
3) определить основные виды передаваемой информации;
4) разработать предварительную КД. Основные функциональные группы станут процессами, внешние объекты – внешними
сущностями, основные виды информации – потоками данных;
5) изучить предварительную КД, внести требуемые изменения;
6) построить КД путем объединения всех процессов предварительной диаграммы в один процесс, который станет системой, и
группирования потоков данных;
7) сформировать диаграмму первого уровня детализации на базе
процессов предварительной КД;
8) проверить корректность DFD первого уровня;
9) описать каждый процесс текущей диаграммы с помощью детализирующей диаграммы или миниспецификации;
10) параллельно с детализацией процессов выполнить декомпозицию потоков, занести определения новых потоков в словарь данных;
11) проверить соблюдения основных требований для текущей
диаграммы;
12) писать миниспецификацию в тех случаях, если функцию
сложно или невозможно выразить через комбинацию процессов.
Диаграммы потоков данных обеспечивают удобный способ описания передаваемой информации как между отдельными компонентами системы, так и между системой и внешними объектами.
DFD обеспечивает возможность одновременного моделирования
функционального и информационного аспектов системы. Поэтому
DFD активно используются при проектировании КИС, а также для
создания моделей информационного обмена предприятия.
IDEF3 – это способ описания процесса как упорядоченной последовательности событий вместе с описанием объектов, имеющих
отношение к этому процессу. IDEF3 был специально разработан
для закрытого проекта ВВС США. Метод ориентирован на полу128
чение описания деталей процесса от экспертов в предметной области и разработки схем таких процессов, для которых важно понять
последовательность выполнения действий и взаимозависимости
между ними. Метод может быть также использован при проектировании бизнес-процессов и анализе систем имитационными методами. IDEF3 получил широкое распространение как средство детализации схем IDEF0.
Метод достаточно прост, не имеет жестких ограничений по синтаксису и семантике.
Он позволяет описывать:
− объекты;
− роли, выполняемые объектами;
− отношения между объектами в ходе выполнения процесса;
− состояния объектов;
− изменения, которым подвергаются объекты;
− время выполнения работ, контрольные точки синхронизации
работ;
− ресурсы, необходимые для выполнения работ.
В IDEF3 определены два типа взаимосвязанных схем (моделей):
1) Process Flow Description Diagrams – описание процесса как
логической последовательности действий;
2) Object State Transition Network – сеть переходов состояний
объекта.
На практике схемы первого типа используются значительно
чаще. Именно это подмножество IDEF3 рассматривается ниже,
и под моделью IDEF3 будет пониматься Process Flow Description
Diagrams.
Главной структурной единицей модели IDEF3 является диаграмма. Совокупность диаграмм образует модель. На диаграмме
графически показывается исследуемый процесс или его фрагмент
как набор взаимосвязанных компонентов.
Основным компонентом IDEF3 является действие, или, следуя
терминологии IDEF3, единица поведения (Unit of Behavior – UOB).
Смысл этого компонента соответствует смыслу функционального
блока IDEF0 и процессу DFD, то есть это отображение некоторой
функции, переводящей входные параметры в выходные.
Действие обозначается посредством прямоугольника. Именуется с помощью глагола или отглагольного существительного. Каждое действие имеет уникальный в границах всей модели номер.
Причем этот номер не используется вновь даже в том случае, когда
действие исключается из схемы в процессе ее разработки или об129
новления. Обычно перед собственно номером действия указывается
номер родительского действия, например: X, Y, где X – уникальный номер родительского действия; Y – уникальный номер рассматриваемого действия; Y входит в декомпозицию X (рис. 5.15).
Обычно на действие с номером X, Y ссылаются как на действие
AX.Y, где префикс ‘A’ указывает на то, что данный объект – действие. Например, A1.2 – это действие с уникальным номером 2, родительское действие которого имеет уникальный номер 1.
С помощью связи (link) показывается значимое взаимоотношение между действиями. Все связи однонаправленны. Связь обозначается как стрелка (
).
Стрелка может начинаться и заканчиваться на любой стороне прямоугольника, символизирующего действие. Но обычно
диаграмма строится так, что стрелка начинается на правой стороне исходного блока, а заканчивается на левой конечного блока
(рис. 5.16).
Основные типы связей в IDEF3:
1) временное предшествование (temporal precedence) показывает, что исходное действие должно завершиться до начала выполнения конечного действия; это связь типа «строгая зависимость»;
обозначается как обычная стрелка (
);
2) нечеткое отношение (relational link) – вид взаимодействия, не
укладывающийся в рамки первых двух; смысл такой связи обязательно должен быть раскрыт с помощью развернутого наименования, так как стрелка такого типа сама по себе говорит лишь о наНаименование
действия
1.2
Рис. 5.15. Обозначение действия
в IDEF3
Действие 1
1.2
Действие 2
1.3
Рис. 5.16. Пример построения диаграммы в IDEF3
130
личии некоторого отношения, никоим образом не указывая на его
суть; объяснение смысла связи также может быть выполнено с помощью ссылки; обозначается как пунктирная стрелка (
).
В случае связи типа «временное предшествование», изображенном на рис. 5.16, A1.2 должно завершиться до начала выполнения
A1.3. Пример временной диаграммы выполнения процесса, соответствующего такой схеме, показан на рис. 5.17.
Следует помнить, что практически всегда заданному фрагменту
модели соответствует множество допустимых реализаций процесса.
Таким образом, IDEF3 позволяет решать следующие задачи:
− документирование имеющихся данных о порядке выполнения
процесса;
− анализ и реорганизацию существующих процессов и разработку новых;
− определение и анализ точек влияния потоков сопутствующих
процессов;
− разработки имитационной модели технологических процессов.
Таким образом, при решении практических задач построения
функциональных моделей, предназначенных как для проектирования КИС, так и для анализа некоторых процессов, обычно используют несколько методов. Если говорить о рассмотренных выше
подходах, то наибольшее распространение получила трехступенчатая схема разработки и представления функциональных моделей.
Внешний (концептуальный) уровень создается с помощью IDEF0.
На этом этапе определяются базовые функции, основные передаваемые и используемые объекты (как информационные, так и материальные). Дальнейшая детализация производится с помощью
средств DFD. На этом уровне большее внимание уделяется структуре передаваемых и хранимых данных, топологии сети инфорДействие
1.2
1.3
Время
Рис. 5.17. Пример временной диаграммы
выполнения процесса в IDEF3
131
мационного обмена. Детальная спецификация состава и порядка
выполнения отдельных функций производится с помощью IDEF3.
Если разрабатываемая модель предназначена для нужд проектирования и разработки КИС, то вместо IDEF3 часто используют такие визуальные средства спецификации передач управления, как
блок-схемы и FLOW-формы.
В качестве CASE-средства, поддерживающего создание гибридных моделей IDEF0 + DFD + IDEF3, можно указать пакет BPWin
(текущее официальное наименование – AllFusion Process Modeler).
5.3. Моделирование данных
Цель моделирования данных состоит в обеспечении разработчика КИС схемой БД. Схема может состоять из одной или нескольких моделей данных. Наиболее распространенным способом моделирования данных является подход с использованием диаграмм
«сущность-связь» (Entity Relationship Diagrams – ERD), ориентированных на разработку реляционных БД.
Существуют несколько методов построения ERD, различающихся нотацией, описательными возможностями и функциональным
предназначением. Рассмотрим построение ERD на примере метода
IDEF1X.
Метод IDEF1X первоначально был разработан для министерства
обороны США и ныне широко используется как в государственных
учреждениях, так и в частных фирмах США. Метод отличается ясной и недвусмысленной графической нотацией.
Основными элементами диаграмм «сущность-связь» являются:
− сущности;
− свойства сущностей (атрибуты);
− отношения (связи) между сущностями.
В общем случае разработка модели по IDEF1X включает следующие шаги:
− определяются и детализируются цели проекта, составляется
план сбора информации, необходимой для модели;
− выявляются и описываются основные сущности; в дальнейшем сущности будут представлены как таблицы распределенной
базы данных (РБД), хранящие значимые для системы данные;
− выявляются и описываются основные отношения; основные
сущности и отношения отображаются на так называемой концептуальном – наименее детальном – уровне модели;
132
− раскрываются нестандартные отношения (типа «многие ко
многим»), определяются ключевые и наиболее важные с функциональной точки зрения атрибуты сущностей; данная информация отображается на логическом уровне модели (или, в терминах
IDEF1X, «key-based view»);
− полностью определяются все атрибуты сущностей, все элементы модели получают непротиворечивые физические имена;
получаемый в результате физический уровень модели (в терминах
IDEF1X «fully attributed view») может быть отображен в РБД с точно соответствующей ему структурой.
Таким образом, первый этап собственно моделирования состоит
в извлечении информации из данных обследования (интервью) и
выделении сущностей.
Сущность (entity) – это описание множества реальных или воображаемых объектов, сходных между собой и имеющих существенное значение для рассматриваемой предметной области, так что информация об объектах подлежит хранению.
Отдельное свойство объекта выражает а т р и б у т. Сущность
включает определение одного и более атрибутов. Каждая сущность
должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данной сущности.
Под э к з е м п л я р о м сущности понимается индивидуальный
объект, описываемый совокупностью значений всех атрибутов
сущности. Все экземпляры сущности имеют одинаковый набор
атрибутов, но отличаются значениями атрибутов. Иначе говоря,
если проводить параллели с программированием, сущность можно
рассматривать как класс, а экземпляр сущности – как экземпляр
класса, или объект.
Если рассматривать эти элементы с точки зрения конечной РБД,
то сущности соответствует таблица, экземпляру сущности – строка, атрибуту – колонка таблицы.
Основные свойства сущности:
− наличие уникального имени и одинаковой семантики (смысла)
во всей модели, то есть, например, сущность «Чек» должна иметь
одинаковый смысл на всех диаграммах модели – описание информационного объекта, хранящего параметры кассового чека;
− наличие одного или нескольких атрибутов;
− наличие одного или нескольких атрибутов, однозначно идентифицирующих любой экземпляр сущности; эти атрибуты составляют
уникальный идентификатор, или первичный ключ (primary key);
133
− сущность может иметь любое количество отношений с другими сущностями.
В IDEF1X сущность отображается в виде прямоугольника. На
концептуальном уровне представления модели прямоугольник дополняется только наименованием сущности, надписываемым непосредственно внутри прямоугольника. На логическом и физическом
уровнях прямоугольник делится горизонтальной чертой на две части. В верхней части перечисляются в столбик атрибуты, входящие
в состав первичного ключа. В нижней части также в столбик указываются все прочие атрибуты. Наименование сущности пишется
над прямоугольником. Наименование дается в единственном числе, что облегчает чтение диаграмм. Фактически сущность именуется исходя из наименования ее экземпляра.
Пример отображения сущности «Сотрудник» на разных уровнях модели: а – концептуальный; б – логический; в – физический (рис. 5.18).
В IDEF1X атрибут (attribute) – любая характеристика сущности,
значимая для рассматриваемой проблемной области и предназначенная для квалификации, идентификации, классификации количественной оценки характеристики или выражения состояния сущности. Экземпляр атрибута – это значение атрибута. С позиции конечного представления в РБД атрибуту соответствует колонка таблицы.
Атрибуты бывают обязательными и необязательными. Если
атрибут необязателен, то он может принимать неопределенное значение (null).
Атрибуты также бывают описательными и ключевыми, то есть
входящими в состав первичного ключа – уникального идентификатора. Все ключевые атрибуты являются обязательными.
Атрибуты изображаются в виде списка имен внутри блока сущности, при этом каждый атрибут занимает отдельную строку. Атриа
Сотрудник
б
в
Сотрудник
Сотрудник
Табельный номер
Табельный номер
Номер отдела (FK)
Номер отдела (FK)
ФИО
Должность
Адрес
Телефон
Дата рождения
Рис. 5.18. Пример отображения сущности «Сотрудник»
на уровнях модели IDEF1X
134
буты, входящие в первичный ключ, размещаются в верхней части
прямоугольника. Например, для сущности «Сотрудник» первичный ключ состоит из атрибута «Табельный номер» (см. рис. 5.18).
Необязательные атрибуты помечаются буквой «O» (optional).
Если, кроме первичного ключа, для сущности можно указать
еще несколько атрибутов (групп атрибутов), уникально определяющих экземпляр сущности, то такие атрибуты называются альтернативными ключами. Альтернативные ключи помечаются аббревиатурой AK (alternate key):
Основные свойства атрибута:
− принадлежит только одной сущности;
− имеет уникальное имя в пределах своей сущности;
− первичный ключ не может принимать неопределенные значения;
− атрибут принимает одно конкретное значение для каждого экземпляра сущности.
В IDEF1X связь (отношение, relation ship) – поименованная ассоциация между двумя сущностями, определяющая некоторое логическое соотношение между сущностями. Каждая связь может
именоваться глаголом или глагольной конструкцией (рис. 5.19).
Связь определяет логическое ограничение или бизнес-правило.
Наименование связи уникально для связываемых сущностей и состоит обычно из глагола. Наименование формируется с точки зрения родителя (например, «группа–состоит<из>–студентов»). Смысл
наименования связи определяет ролевое имя внешних ключей.
В зависимости от характера связи, соединяющей сущности, в
IDEF1X выделяются зависимые и независимые сущности. С этой
точки зрения связи делятся на идентифицирующие и неидентифицирующие.
Полная идентификация: каждый экземпляр полностью идентифицируется своими собственными ключевыми атрибутами.
Можно указать следующее правило определения типа связи и
зависимости сущности: если внешний ключ полностью входит в соСтудент
Группа
Номер группы
Номер в ведомости
Состоит /
ФИО
Номер группы (FK)
Рис. 5.19. Пример связи в IDEF1X
135
став первичного ключа, то сущность зависимая; если только часть
внешнего ключа состоит из внешних атрибутов или такие атрибуты отсутствуют, то сущность независимая.
В случае связи «один ко многим» экземпляру родительской сущности соответствует произвольное, в том числе нулевое, количество
экземпляров потомков, а экземпляр сущности-потомка ассоциирован с одним экземпляром родительской сущности.
При использовании отношения «один ко многим» может устанавливаться идентифицирующая (identifying) связь между одной
независимой (родительской) и одной зависимой (дочерней) сущностью. Это означает, что экземпляр дочерней сущности не может
существовать, если нет соответствующего ему экземпляра родительской сущности. Это достигается путем так называемой миграции атрибутов первичного ключа родительской сущности в состав
первичного ключа дочерней сущности. Первичный ключ родительской сущности становится так называемым внешним ключом
(foreign key) для дочерней сущности. При этом атрибуты первичного ключа родительской сущности становятся связанными с соответствующими им атрибутами первичного ключа дочерней сущности: удалением экземпляра родительской сущности приводит
к принятию атрибутами внешнего ключа неопределенных значений и, соответственно, фактическому удалению тех экземпляров
дочерней сущности, которые были связаны с удаленным экземпляром родительской. Действительно, внешний ключ входит в состав
первичного ключа дочерней сущности и его атрибуты не могут принимать неопределенные значения без потери свойства однозначной
идентифицируемости сущности.
Таким образом, идентифицирующая связь (рис. 5.20) обязательно делает дочернюю сущность зависимой.
Команда
Наименование
Лига
Игрок
Номер
Наименование (FK)
ФИО
Дата рождения
Рис. 5.20. Пример идентифицирующей связи
в IDEF1X
136
Идентифицирующая связь показывается как сплошная линия,
при этом на конце линии, соответствующем дочерней сущности,
показывается жирная точка. Зависимая дочерняя сущность изображается прямоугольником со скругленными углами.
Еще раз следует отметить, что при использовании идентифицирующей связи атрибуты первичного ключа родительской сущности
переносятся в состав первичного ключа дочерней сущности.
Все мигрировавшие атрибуты помечаются аббревиатурой FK
(foreign key). Например, из отображения сущности «Игрок» видно,
что атрибут «Наименование» является внешним ключом.
Сущность может иметь произвольное количество внешних ключей. Внешние ключи должны быть частью первичного ключа родительской или родовой сущности. Например, сущность «Заказ»
может идентифицироваться сущностями «Клиент» и «Товар», при
этом у последней сущности первичный ключ составной (рис. 5.21).
Наименование внешнего ключа его должно соответствовать его
наименованию в родительской, или родовой, сущности, либо необходимо использовать так называемое ролевое имя (role name).
Ролевое имя (рис. 5.22) отражает отношение между дочерней и родительской сущностью с точки зрения дочерней. Ролевое имя логически обратно наименованию связи, которое формируется с точки
зрения родителя.
Заказ
Клиент
ИНН
Наименование
Номер заказа
ИНН (FK)
Код товара (FK)
Код поставщика (FK)
Товар
Код товара
Код поставщика
Наименование
Количество
Рис. 5.21. Пример составного первичного ключа в IDEF1X
Заказ
Клиент
Номер заказа
Заказан.ИНН (FK)
ИНН
Заказал / Состоит.Код товара (FK)
Состоит.Код поставщика (FK)
Наименование
Товар
Код товара
Входит / Код поставщика
Наименование
Количество
Рис. 5.22. Пример использования ролевого имени в IDEF1X
137
При использовании отношения «один ко многим» неидентифицирующая (non-identifying) связь позволяет оставить дочернюю
сущность независимой. В этом случае атрибуты первичного ключа родительской сущности мигрируют в состав описательных (неключевых) атрибутов дочерней сущности. Неидентифицирующая
связь показывается пунктиром, и, как и для идентифицирующей,
на дочернем конце связи рисуется жирная точка (рис. 5.23).
Это случай обязательной (mandatory) неидентифицирующей
связи, когда каждый экземпляр дочерней сущности обязательно
должен соответствовать одному экземпляру родительской. Поэтому с практической точки зрения ограничения, накладываемые
идентифицирующей и обязательной неидентифицирующей связями, часто одинаковы.
Значение необязательной (optional) неидентифицирующей связи принципиально отличается от значения обязательной: экземпляр дочерней сущности должен соответствовать одному экземпляру родительской только тогда, когда соответствующие внешние
ключи имеют определенное значение (не NULL).
Изображение необязательной неидентифицирующей связи отличается наличием ромба на родительском конце связи (рис. 5.24).
Команда
Игрок
Наименование
ФИО
Дата рождения
Лига (O)
Наименование (FK)
Рис. 5.23. Пример неидентифицирующей связи
в IDEF1X
Команда
Игрок
Наименование
ФИО
Дата рождения
Лига (O)
Наименование (FK)
Рис. 5.24. Пример необязательной неидентифицирующей связи
в IDEF1X
138
Такая диаграмма означает, что экземпляр сущности «Игрок»
может существовать вне зависимости от наличия какого-либо экземпляра «Команда». Иначе говоря, игрок может не числиться
в составе ни одной команды.
В принципе, в случае неидентифицирующей связи допустимо,
если часть атрибутов первичного ключа родителя входит в состав
первичного ключа дочерней сущности.
Для более точного описания отношения «один ко многим» можно указывать число экземпляров дочерней сущности, соответствующих экземпляру родительской. Это соотношение называется
мощностью (cardinality) связи.
В зависимости от вида отношений зависимая сущность может
быть следующих типов:
− характеристическая – зависимая дочерняя сущность, которая
связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности;
− ассоциативная – сущность, связанная с несколькими родительскими сущностями; эта сущность хранит информацию о связях сущностей и обычно служит для разрешения отношения «многие ко многим»;
− именующая – частный случай ассоциативной сущности, не
имеющей своих собственных атрибутов, то есть все атрибуты являются внешними ключами, мигрировавшими из родительских сущностей;
− категориальная – дочерняя сущность в иерархии наследования; понятие категориальной сущности связано с отношением типа
«наследование», принципиально отличающимся от отношений
«один ко многим» и «многие ко многим».
Не следует ставить нормализацию структуры хранения данных
самоцелью. В реальных системах активно используются денормализованные структуры. Это диктуется требованиями к скорости обработки запросов и удобством работы с базой на программном уровне.
Часто целесообразно денормализовать БД и, соответственно, усложнить специализированное ПО, поддерживающее БД в непротиворечивом состоянии, но тем самым одновременно облегчить формирование SQL-запросов, упростить их и увеличить скорость обработки.
Например, сама концепция БД типа «хранилище данных» (data
warehouse), ориентированных на накопление и анализ информации,
предполагает использование простых избыточных структур.
Оригинальная документация на IDEF1X содержит не только
описание визуального языка, но рекомендации по моделированию.
139
В частности, разработчики предлагают придерживаться описываемой ниже последовательности действий.
Весь процесс построения условно делится на пять фаз:
1) подготовка;
2) определение сущностей;
3) определение отношений;
4) определение ключей;
5) определение атрибутов.
Каждая фаза состоит из нескольких шагов, отличающихся друг
от друга по содержанию (табл. 5.2).
Таблица 5.2
Шаги и описания фаз последовательности действий по IDEF1X
Фаза
1
2
140
Шаг
Описание
1.1. ОпредеДолжны быть определены назначение модели и граление целей
ницы моделирования (очерчена область моделиромоделирования вания). Например, необходимо определиться, будет
ли это модель типа «как есть» на самом деле (as is),
или типа «как должно быть» (should be)
1.2. Разработ- Необходимо установить состав и последователька плана моде- ность выполнения работ, участие персонала, а таклирования
же оценить затраты
1.3. Организа- Участники команды должны совместно выполнять
ция команды по крайней мере пять основных ролей: руководитель, поставщик информации, эксперт в предметной области, участник группы приемочного контроля. Назначение каждому участнику команды одной
основной роли позволит распределить ответственность
1.4. Сбор инСбор материала для моделирования на основе сфорформации
мулированных целей
1.5. Утвержде- Согласование условных соглашений, форм предние условных ставления информации, например правил формисоглашений
рования наименований сущностей
2.1. ВыявлеПоиск объектов, которые могут стать сущностями.
ние сущностей При выявлении сущностей может быть полезно отвечать на такой набор вопросов относительно каждого объекта-кандидата:
– имеет ли объект различимые характеристики?
– существует ли несколько экземпляров объекта?
– отличим ли один экземпляр от другого?
– ссылается ли он на что-то или характеризует чтото?
Продолжение табл. 5.2
Фаза
Шаг
2.2. Определение сущностей
3.1. Выявление
взаимосвязанных сущностей
3
3.2. Определение отношений
3.3. Построение концептуального уровня
модели
4.1. Устранение неопределенных отношений
4
4.2. Формирование функциональных
представлений
Описание
Положительные ответы на первые три вопроса идут
в пользу того, что объект надо рассматривать как
сущность, положительный ответ на последний вопрос свидетельствует в пользу варианта атрибутного характера
Составление словаря сущностей, включающего:
наименование сущности, пояснение смысла сущности (собственно определение), синонимы наименования сущности
Определение пар сущностей, между которыми может существовать связь. Новичкам может быть полезно воспользоваться матрицей связей, в которой
строки и столбцы помечены наименованиями сущностей, а факт возможной связи между сущностьюстрокой и сущностью-столбцом показывается крестом в ячейке пересечения этих строки и столбца
Для каждой выявленной связи указывается вид зависимости сущностей, наименование и развернутое
словесное описание. Естественно, в процессе определения отношений могут быть отвергнуты одни
выявленные связи и/или добавлены другие
Изображается концептуальный уровень модели, содержащий определенные ранее сущности и отношения, при этом допустимо использовать связи «многие ко многим»
Все неопределенные отношения заменяются на совокупность связей «один ко многим» и/или связей
типа «наследование», при этом обычно формируются новые сущности. Как правило, новые сущности
абстрактны, имеют вспомогательный характер и
отражают взаимодействие исходных сущностей.
Наименования новых сущностей часто сложные,
например: сущность «Поставщик-склад» описывает некоторое отношение между сущностью «Поставщик» и сущностью «Склад»
Поскольку модель становится сложна, то эффективной работы с ней, в частности рецензирования,
целесообразно нарисовать некоторое количество
фрагментов, соответствующих определенной точке
зрения, – так называемых функциональных представлений. Каждое представление изображается на
одной диаграмме
141
Продолжение табл. 5.2
Фаза
5
142
Шаг
Описание
4.3. ВыявлеВыявляются все кандидаты на роль первичного
ние первичных ключа, из них выбирается первичный ключ. Оставключей
шиеся ключи помечаются как альтернативные первичные ключи (alternate key)
4.4. Миграция Первичный ключ родительской (родовой) сущности
первичных
добавляется в состав атрибутов дочерней (категориключей
альной) сущности. Он становится так называемым
внешним ключом (foreign key). В зависимости от
вида связи ключ может войти в состав как первичного ключа, так и описательных атрибутов
4.5. Проверка Модель должна удовлетворять следующим основключей и отным требованиям:
ношений
– отсутствие отношений «многие ко многим»;
– осуществлено добавление (миграция) внешних
ключей в соответствии с имеющимися отношениями;
– все атрибуты атомарны, то есть атрибут любого
экземпляра сущности может иметь только одно значение;
– никакой атрибут первичного ключа не может принимать неопределенное значение;
– сущности со сложным (многоатрибутным) первичным ключом не могут быть разделены на несколько сущностей с более простыми уникальными
ключами;
– нет дублирования отношений, когда пара сущностей связывается одинаковыми отношениями,
но по различным путям, обычно с использованием
промежуточных сущностей
4.6. Определе- Для каждого ключа указывается наименование,
ние ключей
определение, синонимы
4.7. Формиро- Функциональные представления модели изображавание логиче- ются на логическом уровне, то есть они включают
ского уровня
сущности, отношения, первичные и внешние ключи
модели
5.1. ВыявлеПроцесс аналогичен вычленению сущностей, но тение неключе- перь отбираются характеристики
вых атрибутов
5.2. Привязка Каждый атрибут должен быть помещен в состав одатрибутов к
ной из сущностей
сущностям
5.3. Определе- Для каждого атрибута указывается наименование,
ние атрибутов определение, синонимы
Окончание табл. 5.2
Фаза
Шаг
5.4. Усовершенствование
модели
5.5. Формирование физического уровня
модели
Описание
Анализ и улучшение структуры модели, нормализация
Функциональные представления модели изображаются на физическом уровне, то есть они включают
полные описания сущностей, всех атрибутов и отношений. На основе словарей сущностей, атрибутов и
отношений формируется документация
143
ЗАКЛЮЧЕНИЕ
Стандарты управления корпорациями постоянно совершенствуются. Корпоративная культура и изменяющиеся принципы
ведения бизнеса обусловливают создание новых концепций управления, а новые стандарты задают темп для неустанного развития
корпораций. Тем не менее эти стандарты работают и способствуют
более эффективной деятельности организаций. Достаточно упомянуть концепцию MRPII, которая является инструментом, методом
и системой, предназначенной для усовершенствования всех сфер
деятельности производственного предприятия.
За более чем тридцатилетнюю историю развития систем автоматизации управленческой деятельности были выработаны подходы
к решению практически всех основных задач, которые должны решать руководители разных уровней.
Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности КИС, создаваемых в различных областях экономики. Современные крупные
проекты КИС характеризуются, как правило, следующими особенностями:
− сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между
ними), требующая тщательного моделирования и анализа данных
и процессов;
− наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с
обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений),
использующих нерегламентированные запросы к данным большого объема);
− отсутствие прямых аналогов, ограничивающее возможность
использования каких-либо типовых проектных решений и прикладных систем;
− необходимость интеграции существующих и вновь разрабатываемых приложений;
− функционирование в неоднородной среде на нескольких аппаратных платформах;
− разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
144
− существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива
разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению КИС.
Для успешной реализации проекта объект проектирования должен быть прежде всего адекватно описан, должны быть построены
полные и непротиворечивые функциональные и информационные
модели КИС. Накопленный к настоящему времени опыт проектирования КИС показывает, что это логически сложная, трудоемкая
и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Однако до недавнего времени проектирование КИС выполнялось в основном на интуитивном
уровне с применением неформализованных методов, основанных
на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования КИС. Кроме того, в процессе функционирования КИС информационные потребности пользователей могут изменяться или
уточняться, что еще более усложняет разработку и сопровождение
таких систем.
В 80-х годах при разработке КИС достаточно широко применялась структурная методология, предоставляющая в распоряжение
разработчиков строгие формализованные методы описания КИС
и принимаемых технических решений. Она основана на наглядной графической технике: для описания различного рода моделей
КИС используются схемы и диаграммы. Наглядность и строгость
средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных
технических решений. Однако широкое применение этой методологии и следование ее рекомендациям при разработке конкретных
КИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить
их на полноту и непротиворечивость, и тем более изменить. Ручная
разработка обычно порождала следующие проблемы: неадекватная
спецификация требований; неспособность обнаруживать ошибки в
проектных решениях; низкое качество документации, снижающее
эксплуатационные качества; затяжной цикл и неудовлетворительные результаты тестирования.
145
Перечисленные факторы способствовали появлению MRP- методологий и программно-технологических средств специального
класса: MRPII-, ERP- и CRM- систем.
Дисциплина «Корпоративные информационные системы» обеспечивает формирование общекультурных и профессиональных
компетенций в части изучения функциональной архитектуры построения КИС, аппаратно-программных платформ и типовых проектных решений по их созданию.
146
Библиографический список
Архитектура информационных систем / Б. Я. Советов, А. И. Водяхо, В. А. Дубенецкий, В. В. Цехановский: учебник. М.: Изд.
центр «Академия», 2012. 288 с.
Балдин К. В., Уткин В. Б. Информационные системы в экономике. М.: «Дашков и К°», 2010. 395 с.
Васильев А. А., Избачков Ю. С., Петров В. Н. Информационные
системы. СПб.: Питер, 2011. 544 с.
Васильев Р. Б. и др. Управление развитием информационных систем. М.: Горячая Линия-Телеком, 2009. 350 с.
Гаврилов Д. А. Управление производством на базе стандартов
MRP II. СПб.: Питер, 2005. 416 с.
Головин Ю. А., Суконщиков А. А., Яковлев С. А. Информационные сети: учебник. М.: Изд. центр «Академия», 2011. 384 с.
Информационные системы и технологии в экономике и управлении: учебник / под ред. В. В. Трофимова. М.: Высш. образование,
2009. 528 с.
Китова О. В., Абдикеева Н. М. Корпоративные информационные системы управления: учебник. М.: Инфра-М, 2010. 464 с.
Олейник П. П. Корпоративные информационные системы: учебник. СПб: Питер, 2012. 176 с.
Осипов Л. А., Яковлев С. А. Искусственный интеллект и нейронные сети. СПб.: ГУАП, 2011. 134 с.
Петров В. Н. Информационные системы: учебник. СПб.: Питер,
2002. 688 с.
Питеркин С. В., Оладов Н. А., Исаев Д. В. Практика применения ERP-систем. М.: Альпина Паблишер, 2002. 178 с.
Попов И. И., Максимов Н. В., Партыка Т. Л. Современные информационные технологии. М.: Форум, 2010. 512 с.
Советов Б. Я., Цехановский В. В. Информационные технологии: учебник. М.: Высш. шк., 2008. 263 с.
Советов Б. Я., Яковлев С. А. Моделирование систем: учебник.
7-е изд. М.: Юрайт, 2012. 343 с.
Швецов А. Н., Яковлев С. А. Распределенные интеллектуальные
информационные системы. СПб.: Изд-во СПбГЭТУ «ЛЭТИ», 2003.
318 с.
Яковлев С. А. Основы автоматизированного управления. Ч. 1 /
Ин-т управления. Ухта, 2004. 202 с.
Яковлев С. А. Основы автоматизированного управления. Ч. 2/
Ин-т управления. Ухта, 2005. 198 с.
147
Яковлев С. А. Основы автоматизированного управления. Ч. 3/
Ин-т управления. Ухта, 2005. 197 с.
Яковлев С. А. Экспертные системы. СПб.: ГУАП, 2011. 142 с.
Яковлев С. А., Канина Т. В., Белобородова Н. А. Моделирование информационных процессов в экономических системах/ Ин-т
управления. Ухта, 2005. 398 с.
148
СОДЕРЖАНИЕ
Предисловие..................................................................... 3
Введение........................................................................... 4
1. Основные принципы создания корпоративных информационных систем ................................................................ 11
1.1. Описание предметной области КИС............................ 11
1.2. Требования к КИС.................................................... 12
1.3. Краткая история развития КИС................................. 17
1.4. Основные понятия КИС............................................ 30
1.5. Особенности разработки и внедрения КИС................... 34
1.6. Принципы и этапы построения КИС........................... 37
2. Классификация и характеристики корпоративных информационных систем............................................................. 44
2.1. Классификация КИС................................................ 44
2.2. Классификация автоматизированных систем............... 47
2.3. Характеристики и архитектура КИС.......................... 52
2.4. Требования, предъявляемые к КИС............................ 55
3. Методология реализации корпоративных информационных
систем.............................................................................. 59
3.1. Основы методологии MRP......................................... 59
3.2. Стандарт MRPII ...................................................... 63
3.3. Системы класса ERP................................................ 71
3.4. Системы CRM.......................................................... 77
3.5. Проблемы внедрения КИС......................................... 84
4. Задачи интеграции в гетерогенной информационной среде
современного предприятия.................................................. 97
4.1. Особенности выбора архитектуры КИС ....................... 97
4.2. Интеллектуализация информационной среды КИС....... 100
4.3. Распределенные объектные архитектуры.................... 102
5. Стандарты описания, анализа и реорганизации бизнеспроцессов корпоративной информационной системы.............. 111
5.1. Особенности разработки архитектурных решений КИС. 111
5.2. Функциональное моделирование................................ 114
5.3. Моделирование данных............................................ 132
Заключение...................................................................... 144
Библиографический список................................................. 147
149
Учебное издание
Осипов Леонид Андроникович
Яковлев Сергей Алексеевич
КОРПОРАТИВНЫЕ
ИНФОРМАЦИОННЫЕ СИСТЕМЫ
Учебное пособие
Редактор Г. Д. Бакастова
Верстальщик С. Б. Мацапура
Сдано в набор 7.06.13. Подписано к печати 12.11.13.
Формат 60×84 1/16. Бумага офсетная. Усл. печ. л. 8,7.
Уч.-изд. л. 9,7. Тираж 100 экз. Заказ № 568.
Редакционно-издательский центр ГУАП
190000, Санкт-Петербург, Б. Морская ул., 67
Документ
Категория
Без категории
Просмотров
4
Размер файла
3 218 Кб
Теги
osipovyakovlev, 05f123b1b5
1/--страниц
Пожаловаться на содержимое документа