авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 | 2 || 4 | 5 |

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ Государственное образовательное учреждение высшего профессионального образования «ТОМСКИЙ ПОЛИТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» ЮРГИНСКИЙ ...»

-- [ Страница 3 ] --

1 этап 2 этап 3 этап Рис. 4.1. Схема процесса проектирования УСД При выполнении третьей работы «Разбиение показателей по формам документов» определяется содержание форм результатных до кументов и форм первичных документов. Разбиение показателей по формам осуществляется по семантической близости показателей и по их алгоритмической увязке при расчёте результатных показателей. Если проектировщик разрабатывает формы результатных документов, то критерий алгоритмической увязки показателей является главным. На пример, обоснованным считается включение в один результатный до кумент «Ведомость отпуска товаров со склада за месяц» следующей группы показателей: «количество отпущенных товаров со склада по на кладной», «цена товара», «стоимость отпущенных товаров по наклад ной», «итого стоимость отпущенных товаров по номенклатуре за ме сяц», «итого стоимость отпущенных товаров по каждому складу» и «по всем складам».

Если проектируются формы первичных документов, то основным критерием является семантическая близость показателей, под которой понимается наличие общих типов и значений реквизитного состава этих показателей. Например, в первичный документ «Накладная на отпуск товара» правильным считается включение следующих показателей:

«количество отпущенных товаров определённой номенклатуры со скла да на определённую дату», «цена товара этого вида номенклатуры», «стоимость отпущенных товаров этого вида номенклатуры на опреде лённую дату».

При выполнении четвёртой работы осуществляется «Выбор типа носителя» для документа. Если документы первичные, то носителем является бумага формата А4 или А5. Если проектируются результатные документы, то тип и форма выдачи результатной информации зависят от характера решаемой задачи. Например, если решается прогнозная за дача, при получении результатов которой применяются методы корре ляционного или регрессионного анализа, то основным носителем будет экран ЭВМ, на который будут выданы графики, и бумажный носитель.

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

В качестве критерия выбора носителя можно использовать показатели надёжности хранения информации, достоверности информации и каче ства воспроизведения материала.

При выполнении пятой работы «Определение способа нанесения информации в документы» выбирается способ нанесения информации, который зависит от того, как считывается информация с первичного до кумента: визуальным способом или автоматическим. Если применяется автоматический способ считывания, то необходимо выбрать устройства считывания и типы шрифтов для нанесения информации в документ. В настоящее время существуют следующие виды шрифтов:

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

• стилизованные, в которых изображение символов содержит код;

• нормализованные, например шрифты, применяемые на почто вых конвертах;

• графические отметки.

Содержание выполнения шестой работы «Проектирование форм документов» зависит от типа проектируемого документа и будет рас смотрено ниже.

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

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

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

При проектировании форм первичных документов (рис. 4.2) должны учитываться следующие принципы:

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

• отсутствие дублирования показателей в документах;

• выделение реквизитов, имеющих одно или несколько значений на документ, т.е. выделение однозначных и многозначных реквизитов;

• выделение справочных, группировочных реквизитов и реквизи тов-оснований;

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

• согласование последовательности реквизитов в документе с ма кетами размещения информации на экране ЭВМ и в файлах.

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

1. Определение полного реквизитного состава каждого документа.

2. Классификация реквизитов: однозначные и многозначные;

при знаки и основания;

справочные и группировочные;

переносимые и не переносимые на машинные носители.

3. Установление логической соподчиненности реквизитов пер вичных документов.

4. Выбор какой-либо формы первичного документа.

5. Осуществление размещения реквизитов по выбранной форме в соответствии с проведённой классификацией.

6. Выполнение расчёта размеров документа по вертикали и гори зонтали с учётом размера полей.

7. Выбор формата бумажного носителя.

8. Построение эскиза документа соответствующей формы.

9. Выделение толстой линией реквизитов, переносимых на ма шинный носитель.

10. Редактирование шапок документов в соответствии со слова рём-тезаурусом.

Как правило, используют ряд типовых форм документов (см. рис.

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

Рис. 4.2. Схемы основных форм первичных документов: а – линейная, б – ан кетная, в – табличная форма (для многозначных реквизитов) Как правило, для первичных документов, имеющих однозначные и многозначные реквизиты, применяют комбинированную форму, со стоящую из трёх зон (рис. 4.3):

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

II – содержательная зона, включающая группу многозначных рек визитов, предназначенных для пользователя и для машинной обработки, и включающая группу справочных признаков (1), совокуп ность группировочных признаков (2) и группу реквизитов-оснований (3);

III – оформительная зона, в которой, как правило, располагаются подписи должностных лиц.

Рис. 4.3. Макет первичного документа комбинированной формы 4.2.2. Особенности проектирования форм документов результатной информации В результате решения задачи рассчитываются результатные пока затели, которые требуется выдать на материальный носитель в виде, удобном для пользователя. Так как результатный документ использует ся для осуществления процессов управления, то он должен отвечать следующим требованиям:

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

• количество результатных показателей должно соответствовать количеству группировочных признаков (количество итогов должно быть равно количеству ключей сортировки);

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

• достоверность предоставляемой информации;

• хорошая читаемость (логичность построения форм и наличие хорошо отредактированного текста шапок документов);

• отсутствие показателей, рассчитываемых вручную.

Можно выделить следующие принципы построения результатных документов (рис. 4.4):

• выделение трёх зон в документе;

• разделение реквизитов на однозначные, т.е. имеющие одно зна чение на документ, и многозначные реквизиты, имеющие несколько значений в документе;

• выделение группировочных реквизитов, помещаемых во вторую зону документа, и размещение этих реквизитов в порядке убывания старшинства;

Рис. 4.4. Схема структуры результатного документа • выделение реквизитов-оснований и размещение их в последова тельности, противоположной той, в какой выстраиваются группировоч ные реквизиты, по которым рассчитываются итоги (т.е. от первичных оснований – к результатным, а среди результатных – размещение их в порядке возрастания старшинства итога);

• если документ не размещается на одном стандартном листе, то выполнение разрыва строк и переноса оставшихся строк документа вто рой зоны вместе с реквизитами третьей зоны на другой лист, сохраняя размеры листов стандартными (при таком перенесении строк заголовки таблиц не переносятся, а переносятся только номера колонок).

Построение результатных документов должно выполняться в сле дующей последовательности:

1. Определение полного реквизитного состава документа.

2. Классификация реквизитов-признаков: на справочные и груп пировочные;

реквизитов-оснований – на первичные и результатные, а результатных оснований – по степеням итогов.

3. Выбор формы документа (с одной или несколькими таблицами в содержательной части документа).

4. Размещение реквизитов в форме согласно их логической со подчинённости.

5. Подсчёт длины строки в табличной зоне (Lдок) с учётом пробе лов между реквизитами и разделительных линий граф по формуле Lдок = L1 + L2 +... + Li +... + Ln + k d, где Li – длина i-го реквизита (i = 1,…, n);

k – число колонок в таблице;

d – число пробелов между колонками.

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

• вынос итоговых колонок в итоговые строки;

• перенос не уместившихся в листе колонок на новый лист с про должением нумерации колонок (такие документы затем склеиваются).

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

Вопросы для самопроверки 1. Какие функции выполняет документ в ЭИС?

2. Какие виды документов можно выделить в системе документа ции?

3. Что такое Унифицированная система документации, и каким требованиям она должна отвечать?

4. Какие существуют виды УСД?

5. Перечислите принципы и назовите требования к построению первичных документов.

6. Каковы принципы и требования к построению форм результат ных документов?

7. Каковы особенности построения форм первичных документов?

8. Каков состав операций проектирования форм результатных документов?

Часть 3. ИНДУСТРИАЛЬНОЕ ПРОЕКТИРОВАНИЕ КОРПОРАТИВНЫХ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ Тема 5. РЕИНЖИНИРИНГ БИЗНЕС-ПРОЦЕССОВ И ПРОЕКТИРОВАНИЕ КОРПОРАТИВНОЙ ЭИС 5.1. Реинжиниринг бизнес-процессов на основе корпоративной ЭИС Современные предприятия (корпорации) имеют сложную струк туру, обусловленную многопрофильностью деятельности, территори альной распределенностью подразделений, большим числом коопера тивных связей с партнерами. При этом возрастает динамичность дело вых или бизнес-процессов, связанная с постоянно изменяющимися по требностями рынка, ориентацией производства товаров и услуг на ин дивидуальные потребности заказчиков и клиентов, непрерывным со вершенствованием технических возможностей и сильной конкуренцией.

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

Под бизнес-процессом (БП) будем понимать совокупность взаи мосвязанных операций (работ) по изготовлению готовой продукции или выполнению услуг на основе потребления ресурсов.

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

Менеджмент бизнес-процессов зародился еще в рамках концеп ций всеобщего управления качеством (TQM – Total Quality Management) и непрерывного улучшения процессов (CPI – Continuous Process Im provement), согласно которым предполагается сквозное управление биз нес-процессом как единым целым, выполняющимся взаимосвязанными подразделениями предприятия (компании), например, от момента по ступления заказа клиента до момента его реализации.

Управление бизнес-процессами целесообразно рассматривать и на уровне взаимодействия различных предприятий, когда требуется коор динация деятельности предприятий-партнеров в потоках товародвиже ния или в логистических процессах. Логистика породила методы орга низации поставок по принципу «точно в срок» (JIT – Just In Time), реа лизация которых немыслима без управления бизнес-процессами как единым целым.

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

Согласно определению М. Хаммера и Д.Чемпи [91] реинжиниринг бизнес-процессов (BPR – Business process reengineering) определяется как «фундаментальное переосмысление и радикальное перепроектиро вание бизнес-процессов для достижения коренных улучшений в основ ных показателях деятельности предприятия».

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

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

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

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

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

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

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

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

В соответствии с определением Е.Г. Ойхмана и Э.В. Попова «Ре инжиниринг бизнеса предусматривает новый способ мышления – взгляд на построение компании как на инженерную деятельность. Компания или бизнес рассматривается как нечто, что может быть построено, спро ектировано или перепроектировано в соответствии с инженерными принципами» [71].

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

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

модульность, предполагающая разработку и внедрение ЭИС • по отдельным программным комплексам, которые автоматизируют оп ределенные виды деятельности предприятия и комплексируются между собой;

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

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

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

открытость (переносимость), реализующая сопряжение про • граммных комплексов со стандартными программными приложениями через механизмы OLE, например программами Microsoft Office, и с внешними приложениями других информационных систем через API интерфейс (Application Programming Interface), например INTERNET приложениями;

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

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

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

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

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

На оперативном уровне создаются системы обработки транзакций (OLTP – On-Line Transaction Processing) (см. п. 6.11), которые призваны упростить организацию и управляемость деловыми процессами на ос нове принципов горизонтального и вертикального сжатия процессов, централизации (децентрализации).

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

Вертикальное сжатие процесса – организация и контроль вы полнения делового процесса со стороны менеджеров на основе исполь зования локальных вычислительных сетей с архитектурой «клиент сервер», систем управления потоками работ и распределенных баз дан ных. В частности, через распределенную базу данных работники пред приятия обмениваются между собой информацией, в которой все изме нения отражаются в реальном масштабе времени и становятся доступ ными параллельно для всех заинтересованных участников бизнес процесса. Система управления рабочими потоками (workflow) опера тивно связывает по локальной вычислительной сети операции исполни телей из различных подразделений внутри предприятия и программные приложения в сквозные бизнес-процессы, которые контролируются ру ководством предприятия как единым целым. При этом шаги процесса выполняются в естественном порядке при допустимом распараллелива нии работ.

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

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

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

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

Централизованное (децентрализованное) управление процессом – координация выполнения операций процесса территориально распределенными структурными подразделениями предприятия или предприятиями-партнерами на основе использования глобальной вы числительной сети Intranet/Internet, стандартов электронного обмена данными (EDI – Electronic Data Interchangе) и компонентной технологии программных интерфейсов DCOM, CORBA.

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

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

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

• холдинги с разветвленной сетью филиалов и дочерних предпри ятий, организуемых в соответствии с внутрифирменными видами дея тельности и сервисами;

• консорциумы с интеграцией предприятий по цепочке поставок;

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

На тактическом уровне управления для оптимизации выполнения бизнес-процессов требуется применение автоматизированных систем планирования и управления, которые позволяют своевременно выявлять потребность в ресурсах и обеспечивать ее реализацию. К таким систе мам относят системы управления ресурсами следующих классов:

• MRP I (Material requirements planning) – планирование по требности в материалах под производственную программу или произ водственный заказ;

• MRPII (Manufacturing resource planning) – планирование про изводства, включая определение потребности в материалах, производ ственных мощностях и трудовых ресурсах;

• DRP (Distribution resource planning) – планирование использо вания запасов в сети;

• ERP (Enterprise resource planning) – комплексное планирова ние работы предприятия, включая обеспечение финансовыми ресурсами в соответствии с производственной программой.

К особенностям применения современных ERP-систем относятся:

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

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

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

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

• сокращение горизонта оперативного планирования до недель, дней и даже по мере появления каждого нового заказа.

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

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

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

• повышение оперативности анализа эффективности бизнес процессов и прогнозирование их развития;

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

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

• использование разнообразных методов анализа и прогнозирова ния бизнес-процессов;

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

Для реализации перечисленных требований в настоящее время широко используются информационные хранилища (Data Warehouse), системы оперативного анализа данных (OLAP – Оn-line Analytical Proc essing) и интеллектуального анализа данных (Data Mining). Такие сис темы по сравнению с традиционными системами анализа и прогнозиро вания на основе применения экономико-математических моделей, баз экспертных знаний и статистических методов [63] имеют преимущества в гибкости и скорости составления запроса и получения ответа, доступ ности применения, поэтому они могут применяться не только для обос нования стратегических решений, но и при принятии тактических ре шений.

Так, для руководителей предприятия создаются системы монито ринга эффективности финансово-хозяйственной деятельности – инфор мационные системы руководителей (EIS – Executive Information Systems), которые могут специализироваться по конкретным проблем ным областям, например, в логистике, маркетинге, финансах и т.д. Под робно особенности архитектуры построения и проектирования информа ционных хранилищ и систем оперативного анализа данных рассматрива ются в п. 6.3.

Для реализации перечисленных требований многие методы и средства канонического проектирования ЭИС, предназначенные для ло кальной автоматизации управленческих процессов, становятся непри годными, и только методы и средства индустриального проектирования ЭИС (см. тему 7) на основе применения CASE-, RAD- и компонентной технологий позволяют осуществлять быструю разработку и адаптацию проектных решений в соответствии с динамически изменяющимися по требностями.

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

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

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

Последовательность этапов проведения бизнес-реинжиниринга представлена на рис. 5.2.

Рис. 5.2. Этапы проведения бизнес-реинжиниринга На стадии идентификации выделяются ключевые бизнес процессы, реорганизация которых обеспечивает кардинальное повыше ние эффективности функционирования организационно-экономической системы. На стадии обратного инжиниринга осуществляется моделиро вание существующих деловых процессов с целью формулирования предложений по их реорганизации. Стадия прямого инжиниринга включает построение моделей новой организации деловых процессов и их реализацию в виде рабочего проекта. Модели новой организации де ловых процессов доказывают возможность достижения сформулиро ванных на этапе идентификации критериев эффективности. В дальней шем модели деловых процессов воплощаются в виде положений и инст рукций по организации работ персонала и техно-рабочего проекта ин формационной системы. Внедрение предполагает комплексное тестиро вание разработанных компонентов проекта, обучение персонала и по этапный ввод в действие перепроектированных бизнес-процессов. Рас смотрим этапы проведения реинжиниринга бизнес-процессов (РБП) бо лее подробно.

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

Постановка задач РБП выполняется, как правило, на специальных двухдневных семинарах руководителей предприятия, на которых реша ются следующие задачи.

1. Формулирование (уточнение) миссии предприятия.

2. Определение критических факторов успеха (7–8 факторов) или критериев эффективности организации бизнес-процессов: длительность, издержки, качество, сервисное обслуживание и т.д.

3. Выявление основных видов бизнес-процессов, как существую щих, так и перспективных (10–15 процессов).

4. Неформальное описание отличительных особенностей выяв ленных бизнес-процессов.

5. Оценка важности бизнес-процессов по степени влияния на реа лизацию критических факторов успеха.

6. Определение ограничений, связанных с уровнем квалификации персонала фирмы, технической оснащенности производства, наличием информационных технологий, финансовых ресурсов.

7. Описание возможных сценариев развития предприятия: появ ление новых технологий, ресурсов, изменение поведения клиентов, партнеров, конкурентов.

8. Определение внешних рисков обеспечения финансовыми ре сурсами, надежности партнеров, конъюнктуры рынка.

9. Ранжирование бизнес-процессов для проведения РБП в соот ветствии с полученной оценкой важности, ограничениями, рисками и перспективами.

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

Так, формулирование миссии предполагает решение задач качест венного анализа деловых процессов, связанных с определением страте гии поведения предприятия на рынке в части расширения границ рынка или глубокого проникновения на рынок, диверсификации деятельности или повышения качества товаров и услуг, глобализации или локализа ции деятельности и т.д. В качестве основных методов формирования стратегии предприятия обычно используются методы анализа иерархий Саати, нечеткой логики Заде, а инструментальных средств – статиче ские экспертные системы с возможностью обработки качественных (не четких) оценок, такие, как Expert Choice, Guru, Level5, Nexpert Objects и др.

Выбор бизнес-процессов выполняется на основе анализа сегментов рынка, с помощью которого конкретизируются стратегические цели предприятия для определения регионов, потребителей, каналов распре деления продукции и услуг, а следовательно, и особенности организа ции бизнес-процессов. Основными методами исследований на этом эта пе выступают методы статистического анализа и прогнозирования, ней ронных сетей, интеллектуального анализа данных современных инфор мационных хранилищ. Наиболее мощными инструментальными средст вами анализа и прогнозирования для выявления основных сегментов рынка являются ППП SAS, Oracle Express, Business Objects, SPSS, Neu rOn-Line, BrainMaker, PolyAnalyst и др.

Оценка ограничений и рисков, связанных с проведением РБП, вы полняется в ходе решения задач бизнес-планирования. В частности, для выделенных бизнес-процессов осуществляется оценка возможностей предприятия в плане эффективности распределения капиталовложений по различным проектам. Для решения этой задачи обычно используют ся экономико-математические модели и методы оптимизации. К наибо лее известным программным средствам бизнес-планирования относятся ППП Project Expert, «Альт-Инвест», ТЭО-ИНВЕСТ, COMFAR, PROP SPIN и др.

После принятия решения о проведении РБП выполняется плани рование работ на всех стадиях жизненного цикла проекта. Выделяются материальные, людские, финансовые и временные ресурсы, формиру ются организационная структура проекта и команды РБП, проводится разъяснительная работа с персоналом предприятия по вопросам пред стоящей реорганизации предприятия.

Планирование РБП осуществляется с помощью методов и средств управления проектами. С помощью простейших программных средств управления проектами типа TimeLine, Microsoft Project, Primavery стро ятся сетевые календарные графики выполнения работ. Более сложные программные продукты, такие, например, как Process Engineer (LBMS), позволяют определять ресурсы на выполнение проектных работ, вести библиотеки проектов, осуществлять коллективную разработку и мони торинг состояния проекта на последующих стадиях РБП. Средства пла нирования и управления работами поддерживаются также в комплекс ных технологиях проектирования и внедрения корпоративных ЭИС, на пример CASE Method (Oracle), Accelerated SAP (SAP), Orgware (BAAN).

Обратный инжиниринг Обратный инжиниринг предполагает исследование функциони рующих на предприятии бизнес-процессов. Цель этапа заключается в проведении диагностики «узких мест» в организации существующих бизнес-процессов и формулировании направлений их реорганизации.

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

На этапе обратного инжиниринга постановка задач реорганизации бизнес-процессов уточняется, сформулированные на этапе идентифика ции бизнес-процессов в общем виде цели РБП могут быть скорректиро ваны по результатам исследования существующей системы организации бизнес-процессов.

Обратный инжиниринг, по мнению Якобсона [107, 71], не должен вызывать получение чрезмерно детальной картины существующих биз нес-процессов, ибо в этом случае велика вероятность «потерять за де ревьями лес». На этапе обратного инжиниринг строятся, как правило, только принципиальные модели бизнес-процессов, позволяющие понять сущность функционирования предприятия в целом и выявить направле ния реорганизации бизнес-процессов. При необходимости уточнения деталей каких-либо деловых процессов к обратному инжинирингу мож но итеративно вернуться на этапе прямого инжиниринга.

На этапе обратного инжиниринга для понимания сущности функ ционирующих бизнес-процессов широко используются методы и сред ства структурного анализа деловых и информационных процессов (функционально-ориентированного или объектно-ориентированного моделирования), которые реализованы в таких известных ППП, как, на пример, Design/IDEF, BPWin, ERWin, OOWin, ARIS Toolset, Rational Rose и др.

Для оценки эффективности существующих бизнес-процессов ис пользуются прежде всего методы и средства функционально стоимостного анализа (ABC – Activity Based Costing), поддерживаемые, например, в ППП Design/IDEF, Easy ABC+, ARIS ABC и др. Так, функ ционально-стоимостной анализ позволяет выявить:

• наиболее трудоемкие и затратные функции;

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

• функции с низким коэффициентом использования ресурсов.

Для динамической оценки существующих бизнес-процессов при наличии развитой функционирующей информационной системы и ин формационного хранилища могут использоваться методы анализа ре альной статистики. В противном случае применяются методы и средст ва имитационного моделирования, например, ППП ReThink, РДО, Pil grim, Ithink, Workflow Analyser, Service Model и др.

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

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

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

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

Моделирование проблемной области бизнес-процессов (подробно особенности моделирования проблемной области см. в п. 5.3) выполня ется в два подэтапа:

• во-первых, определяется объективная структура новой организа ции бизнес-процессов: состав объектов, функций и событий;

• во-вторых, объекты и функции бизнес-процессов распределяют ся по структурным подразделениям предприятия, и определяются тре бования к информационной системе.

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

На этапе прямого инжиниринга целесообразно использовать про граммные средства моделирования, которые позволяют отображать ре зультаты моделирования проблемной области в репозитории – храни лище метаинформации о проекте, используемом на всех последующих этапах разработки проекта. К таким программным средствам относятся либо CASE-средства, например Oracle Designer 2000, SilverRun, Natural Engineering Workbench, Rational Rose и др. (см. тему 7), либо модельно ориентированные средства компонентного проектирования, например, Business Engineer (SAP), Enterprise Modeler (Baan), либо специализиро ванные, которые позволяют экспортировать модели в CASE-средства или модельно-ориентированные средства компонентного проектирова ния, например ARIS Toolset.

Достоинство специализированных программных средств модели рования бизнес-процессов заключается в большей ориентированности на собственно бизнес-реинжиниринг и предпроектный для информаци онной системы анализ, в то время как CASE-средства и модельно ориентированные средства компонентного проектирования – на разра ботку информационной системы. В частности, для специализированных программных средств моделирования бизнес-процессов (например, ARIS Toolset, Design/IDEF) характерна поддержка инструментов стати ческого функционально-стоимостного анализа и динамического имита ционного моделирования для оценки заданных критериев эффективно сти бизнес-процессов.

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

Целями проведения имитационного моделирования бизнес процессов могут быть:

1) сравнения средних значений и дисперсий динамических харак теристик различных альтернатив процессов при одинаковых исходных данных (один сценарий моделирования на несколько моделей);

2) отыскание оптимальных значений переменных на некотором множестве возможных значений (несколько сценариев моделирования на одну модель);

3) определение зависимостей между различными факторами про цессов в результате специального анализа полученной статистики.

Развитые средства имитационного моделирования, такие, напри мер, как ReTink (Gensym), позволяют:

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

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

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

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

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

Для изменения структуры организационно-экономической систе мы осуществляются:

• разработка организационно-штатной структуры предприятия;

• разработка должностных инструкций;

• разработка системы стимулирования работников;

• обучение персонала;

• подготовка рабочей документации.

Для создания новой информационной системы осуществляются:

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

• разработка и наполнение базы данных;

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

Для быстрой разработки информационной системы широко ис пользуются CASE-средства автоматизации проектирования (см. тему 7) или средства конфигурации комплексных систем управления ресурсами предприятия (ERP-системы), например R/3, BAAN IV, Oracle Applica tion, «Галактика», БОСС и др. В том и другом случае для разработки оригинального программного обеспечения могут потребоваться средст ва быстрой разработки приложений (RAD-технология) и языки про граммирования 4-го поколения (4GL), например АВАР4, JAM и др. (см.

п. 7.4).

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

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

Внедрение проекта реинжиниринга бизнес-процессов Внедрение проекта РБП, как правило, осуществляется поэтапно в соответствии с приоритетами, установленными на этапе идентификации бизнес-процессов. Большое значение на этапе внедрения отводится комплексному тестированию компонентов проекта, для чего использу ются специальные программные средства.


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

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

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

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

При этом под моделью понимается некоторая система, имитирующая структуру или функционирование исследуемой проблемной области, отвечающей основному требованию – адекватности этой области.

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

К моделям проблемных областей предъявляются следующие тре бования:

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

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

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

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

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

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

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

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

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

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

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

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

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

Главный критерий адекватности структурной модели проблемной области заключается в функциональной полноте разрабатываемой ЭИС.

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

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

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

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

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

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

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

Рассмотрим особенности построения моделей проблемной облас ти на трех уровнях детализации.

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

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

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

На концептуальном уровне построения модели проблемной облас ти уточняется состав классов объектов, определяется их атрибутный со став и взаимосвязи между собой. Таким образом строится обобщенное представление структуры предметной области.

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

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

Функциональная структура Функция (операция) представляет собой некоторый преобразова тель входных объектов в выходные. Последовательность взаимосвязан ных по входам и выходам функций составляет бизнес процесс. Функция бизнес-процесса может порождать объекты любой природы (материаль ные, денежные, информационные). Причем бизнес-процессы и инфор мационные процессы, как правило, неразрывны, то есть функции мате риального процесса не могут осуществляться без информационной под держки. Например, функция отгрузки готовой продукции осуществля ется на основе документа «Заказ», который, в свою очередь, порождает документ «Накладная», сопровождающий партию отгруженного товара.

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


На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15–20.

На концептуальном уровне выделенные функции декомпозируют ся и строятся иерархии взаимосвязанных функций.

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

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

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

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

На концептуальном уровне устанавливаются бизнес-правила оп ределяющие условия вызова функций при возникновении событий и достижении состояний объектов.

На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей.

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

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

На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).

На внутреннем уровне определяются требования к правам доступа персонала к автоматизируемым функциям информационной системы.

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

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

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

На внутреннем уровне строится модель «клиент-серверной» архи тектуры вычислительной сети.

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

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

В функциональных моделях (DFD-диаграммах потоков данных, SADT-диаграммах) главными структурными компонентами являются функции (операции, действия, работы), которые на диаграммах связы ваются между собой потоками объектов (подробное изложение струк турного функционально-ориентированного подхода изложено в п.7.2).

Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ЭИС по принципу «сверху-вниз», когда каждый функциональный блок может быть деком позирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ЭИС. Для функциональных моделей харак терны процедурная строгость декомпозиции ЭИС и наглядность пред ставления.

В функциональном подходе объектные модели данных в виде ER диаграмм «объект – свойство – связь» разрабатываются отдельно. Для проверки корректности моделирования проблемной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи.

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

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

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

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

В объектно-ориентированном подходе изменяется и принцип про ектирования ЭИС. Сначала выделяются классы объектов, далее в зави симости от возможных состояний объектов (жизненного цикла объек тов) определяются методы обработки (функциональные процедуры), что обеспечивает наилучшую реализацию динамического поведения информационной системы. Для объектно-ориентированного подхода разработаны графические методы моделирования проблемной области, обобщенные в языке унифицированного моделирования UML [89] (под робное описание объектно-ориентированного подхода представлено в п.

7.3). Однако по наглядности представления модели пользователю заказчику объектно-ориентированные модели явно уступают функцио нальным моделям.

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

В полной мере комбинированный подход к моделированию про блемной области реализован в инструментальном средстве ARIS-Toolset (Architecture of Integrated Information Systems), содержащем множество различных методологий, соответствующих различным взглядам на про ектируемую систему: объекты, функции, организационная структура [46].

Достоинством данной методологии является то, что она обеспечи вает интегрированный подход к анализу и проектированию систем. В рамках каждого из перечисленных подходов создаются соответствую щие модели. Кроме того, существует подход, комбинирующий все три подхода вместе. Он позволяет увязать организационную структуру с функциями и данными через возникающие события, отражая динамиче скую структуру бизнес-процессов. В последнем взгляде существенно сближаются функциональный и объектно-ориентированный подходы к моделированию проблемной области.

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

В качестве метода построения интегрированной модели бизнес процессов используется метод, основанный на управлении событиями (ЕРС – event-driven process chain method), который предполагает зави симость выполнения операций (функций) процесса от происходящих событий. При этом все операции процесса четко определены по входу и выходу, а также исполнителям по организационной структуре и техни ческим средствам. В ЕРС-модели однозначно определяется характер разветвления и соединения путей модели через логические связки X (AND, OR, XOR). От ЕРС-модели можно переходить в дальнейшем как к функционально-ориентированному, так и к объектно-ориентирован ному программированию системы.

Вопросы для самопроверки 1 Что такое бизнес-процесс и чем управление бизнес-процессами отличается от управления ресурсами?

2. Что такое реинжиниринг бизнес-процессов и чем он отличается от концепции всеобщего управления качеством?

3. Какие задачи решает реинжиниринг бизнес-процессов?

4. Какие требования предъявляются к корпоративной ЭИС?

5. Какие изменения архитектуры КЭИС способствуют реинжини рингу бизнес-процессов?

6. Назовите основные принципы реинжиниринга бизнес процессов.

7. Каковы основные этапы РБП?

8. Как изменяется модель жизненного цикла ЭИС в связи с РБП?

9. Какие классы инструментальных программных средств исполь зуются на различных этапах РБП?

10. Что понимается под моделью проблемной области?

11. Какие требования предъявляются к модели проблемной облас ти?

12. В каких аспектах осуществляется моделирование проблемной области?

13. Какие существуют уровни моделирования проблемной облас ти?

14. Что включает структурный уровень представления модели проблемной области?

15. Какие критерии используются для оценки модели проблемной области?

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

Тема 6. ПРОЕКТИРОВАНИЕ КЛИЕНТ-СЕРВЕРНЫХ КОРПОРАТИВНЫХ ЭИС 6.1. Основные понятия и особенности проектирования клиент серверных экономических информационных систем (КЭИС) Архитектура современных КЭИС базируется на принципах кли ент-серверного взаимодействия программных компонентов информаци онной системы.

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

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

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

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

уровень обработки данных приложением и уровень взаимодействия с базой данных.

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

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

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

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

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

Двухуровневая клиент-серверная архитектура основана на ис пользовании только сервера базы-данных (DB-сервера), когда клиент ская часть содержит уровень представления данных, а на сервере нахо дится база данных вместе с СУБД и прикладными программами.

DB-сервер отличается от файл-сервера тем, что в его оперативной памяти, помимо сетевой операционной системы, функционирует цен трализованная СУБД, которая обеспечивает совместное использование рабочими станциями базы данных, размещенной во внешней памяти этого DB-сервера.

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

Обращение к базе данных осуществляется на языке SQL, который фактически стал стандартом для реляционных баз данных. Отсюда сер вер баз данных часто называют SQL-сервером, который поддерживается всеми реляционными СУБД: Oracle;

Informix, MS SQL, ADABAS D, InterBase, SyBase и др. Клиентское приложение может быть реализовано на языке настольных СУБД (MS Access, FoxPro, Paradox, Clipper и др.).

При этом взаимодействие клиентского приложения с SQL-сервером осуществляется через ODBC-драйвер (Open Data Base Connectivity), ко торый обеспечивает возможность пересылки и преобразования данных из глобальной базы данных в структуру базы данных клиентского при ложения. Применение этой технологии позволило разработчикам не за ботиться о специфике работы с той или иной СУБД и делать свои сис темы переносимыми между базами данных. За время своего существо вания ODBC стал стандартом де-факто на алгоритм доступа к разно родным базам данных, и на сегодняшний день насчитывается более прикладных систем, которые работают с источниками информации че рез драйверы ODBC.

Архитектура “Клиент-сервер” Представление База данных Приложение данных пользователя Централизованная система Архитектура “файл-сервер” Двухуровневая архитектура “клиен т-сервер” Тр ехуровневая архитектура “клиент-сервер” Многоуровневая архитектура “клиент-сервер” Рис. 6.2. Варианты клиент-серверной архитектуры КЭИС Трехуровневая клиент-серверная архитектура позволяет по мешать прикладные программы на отдельные серверы приложений, с которыми через API-интерфейс (Application Program Interface) устанав ливается связь клиентских рабочих станций. Работа клиентской части приложения сводится к вызову необходимых функций сервера прило жения, которые называются «ceрвисами». Прикладные программы в свою очередь обращаются к серверу базы данных с помощью SQL запросов. Такая организация позволяет еще более повысить производи тельность и эффективность КЭИС за счет:

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

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

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



Pages:     | 1 | 2 || 4 | 5 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.