Информационный менеджмент: лабораторный практикум

Размещено на http://www.allbest.ru/

ЛАБОРАТОРНЫЙ ПРАКТИКУМ:

ИНФОРМАЦИОННЫЙ МЕНЕДЖМЕНТ

Минск 2015

УДК 005.591.6 (076.1)

ББК 65.05я73

И66

Информационный менеджмент: лабораторный практикум / В.В. Борботько. - Мн.: Акад. упр. при Президенте Респ. Беларусь, 2015. - 62 с.

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

Предназначено для студентов специальности «Управление информационными ресурсами» Академии управления при Президенте Республики Беларусь, а также всех, кто интересуется формированием сети бизнес-процессов.

Рецензенты:

кандидат физико-математических наук, доцент В.А. Иванюкович

кандидат физико-математических наук, доцент Б.В. Новыш

Печатается по решению редакционно-издательского совета Академии управления при Президенте Республики Беларусь.

Содержание

От автора

Список сокращений и определений

Лабораторная работа № 1 - Анализ объекта управления и составление сети его бизнес-процессов

Лабораторная работа № 2 - Планирование развития информационной системы объекта управления

Лабораторная работа № 3 - Анализ информационных технологий применяемых объектом управления

Лабораторная работа № 4 - Оценка эффективности информационных технологий

Лабораторная работа № 5 - Комплексный анализ информационных технологий объекта управления

Литература

Приложения

От автора

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

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

Данный материал рассчитан на самостоятельную проработку.

Список сокращений и определений

CRM - (Customer Relationship Management) стратегия компании, определяющая взаимодействие с клиентами во всех организационных аспектах: она касается рекламы, продажи, доставки и обслуживания клиентов, дизайна и производства новых продуктов, выставления счетов и т.п.

ERP - (Enterprise Resource Planning) методология эффективного планирования и управления всеми ресурсами предприятия, которые необходимы для осуществления продаж, производства, закупок и учета при исполнении заказов клиентов в сферах производства, дистрибуции и оказания услуг

MRP - (Manufacturing Resource Planning) методология управления производственными ресурсами

OLAP - (On-Line Analytical Processing) технология обработки данных, заключающаяся в подготовке агрегированной информации на основе многомерных структурированных массивов данных

MPS - (Master Production Schedule) главный календарный план производства

CRP - (Capacity Requirements Planning) планирование потребности в мощностях

SOP - (Sales and Operations Planning) план продаж и операций

TCO - (Total Cost of Ownership) совокупная стоимость владения - набор методологий, моделей и средств для изучения совокупных затрат какой-либо ИТ-системы, которая поддерживает выполнение определенной деятельности на качественном уровне обслуживания (уровне услуг)

TVO - (Total Value of Opportunity) совокупная ценность возможностей - стандартная методология на основе метрик для всестороннего инвестиционного анализа любых ИТ-инициатив для бизнеса

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

PDCA - Замкнутый цикл управления известен как цикл Деминга PDCA (Plan-Do-Cheack-Act): Планирование - Выполнение - Контроль выполнения - Воздействие (управление, корректировка). Методологя PDCA представляет собой простейший алгоритм действий руководителя по управлению процессом и достижению его целей

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

EPC - (Event-Driven Process Chain) событийная цепочка процессов используется для описания процессов нижнего уровня. Диаграмма представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её.

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

IDEF - (Integrated DEFinition) методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем

ИС - Информационная система

ИТ - Информационные технологии

ОИ - Обработка информации

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

Лабораторная работа № 1 - Анализ объекта управления и составление сети его бизнес-процессов.

I. Условия и задания работы

1. Краткая характеристика объекта управления

Имеется небольшое производственное предприятие (количество сотрудников до 100 человек) реализующее следующие функции:

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

2. закупка сырья и материалов;

3. производство продукции;

4. контроль качества продукции материалов;

5. входной контроль качества сырья и материалов;

6. приемка, хранение и транспортировка продукции;

7. приемка, хранение и транспортировка сырья;

8. сервисное обслуживание технологического оборудования;

9. энергообеспечение предприятия.

Моно выделить следующие основные субъекты деятельности:

1. поставщик;

2. потребитель;

3. коммерческий отдел;

4. производство;

5. ОТК (отдел технического контроля);

6. складское хозяйство;

7. отдел главного механика;

8. отдел главного электрика.

2. Задания работы:

1. выполнить анализ представленных бизнес-процессов и определить достаточно ли их для описания деятельности производственного предприятия данного типа. Вывод обосновать;

2. выделить сеть бизнес-процессов;

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

4. составляемая модель должна быть выполнена в соответствии циклом PDCA. Уровень детализации должен быть рациональным.

II. Теория работы

1. Общая теория по формированию сети бизнес-процессов.

Составляющие части процесса, которыми управляет владелец, и являются ресурсами. На рисунке 1 они объединены под названием «ресурсы». Все ресурсы, необходимые для проведения процесса, должны быть запланированы и выделены до начала реализации процесса.

Рисунок 1 - схема процесса, управляемого владельцем

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

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

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

Такой замкнутый цикл управления известен как цикл Деминга PDCA (Plan-Do-Cheack-Act): Планирование - Выполнение - Контроль выполнения - Воздействие (управление, корректировка). Методологи PDCA представляет собой простейший алгоритм действий руководителя по управлению процессом и достижению его целей. Цикл управления начинается с планирования.

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

Выполнение - выполнение запланированных работ.

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

Воздействие (управление, корректировка) - принятие мер по установлению причин отклонений от запланированного результата, изменения в планировании и распределении ресурсов.

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

Plan - планирование, разработка корректирующих действий на основе проведенного анализа отклонения.

Do - выполнение, внедрение корректирующих действий.

Check - проверка результативности (эффективности) корректирующих действий.

Act - проведение анализа следствий неудачного устранения причин отклонения и принятия решения о разработке (или не разработке) новых корректирующих действий.

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

Иногда в цикле PDCA каждый шаг разбивают на две части:

Рисунок 2 - два варианта цикла PDCA

Plan - на планирование целей (Plan 1) и планирование способов достижения целей (Plan 2).

Do - на обучение и подготовку персонала (Do 1) и собственно выполнение работы (Do 2).

Chtck - на сбор данных (Check 1) и обработку данных (Check 2).

Act - на анализ данных (Act 1) и принятие решений (Act 2).

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

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

Рисунок 3 - наложение функций процесса на цикл PDCA

Этапы формирования сети бизнес-процессов:

1 Этап. Выделение процессов и назначение их владельцев.

Пример

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

Алгоритм действия данного процесса следующий.



Рисунок 4 - в департаменте выделен один процесс, владелец процесса - начальник департамента

Отдел маркетинга (Отдел 2), проведя исследование рынка, подает в производственные структуры прогноз продаж на планируемый период, а также информацию о планируемых поставках в отдел снабжения (отдел 1).

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

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

2 Этап. Определение выходов и входов процесса, ресурсов процесса.

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

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

1. показатели процесса;

2. показатели продукта;

3. показатели удовлетворенности потребителя.

Несколько сложнее обстоят дела с ресурсами. Даже в стандартах ИСО 9000, в котором широко использован термин «ресурсы», не приведено их описание, однако дается перечень того, что можно считать ресурсами:

1. персонал.

2. инфраструктура (здания, сооружения, оборудование, транспорт, связь и т.д.).

3. производственная среда.

4. поставщики и партнеры.

5. информация.

6. окружающая среда.

7. финансовые ресурсы.

Таблица 1 - Пример описания ресурсов «Процесса закупки»

Название ресурса	Спецификация (документ)	Процесс-поставщик	Владелец
Персонал	Положение о подразделении Должностные инструкции	Подбор и аттестация персонала	Начальник отдела кадров (начальник HR департамента)
Финансовые ресурсы	Бюджет План закупок Финансовый план Реквизиты платежей	Управление финансами	Финансовый директор
Информация	Регламент процесса с требованиями к ПО, информационному и коммуникационному обеспечении	Информационное обеспечение	Начальник информационного отдела
Транспорт	Заявка на транспорт по установленной форме	Транспортирование продукции	Начальник транспортного цеха
Инфраструктура (помещение, ремонт и уборка)	Регламент процесса с требованиями к помещению	Обеспечение жизнедеятельности	Начальник административно-хозяйственного отдела, завхоз

3 Этап. Формирование документов, регламентирующих проведение процесса.

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

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

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

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

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

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

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

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

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

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

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

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

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

4 Этап. Графическое изображение сети бизнес-процессов.

Выделяют следующие стандартные этапы построения графического представления сети бизнес-процессов:

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



Рисунок 5 - пример описания взаимодействия подразделений в документации, регламентирующей процесс

2. определить перечень бизнес-процессов верхнего уровня организации (не более 15);

например: перечень процессов, предложенный Международной бенчмаркинговой палатой (International Benchmarking Clearinghouse). Избыточность и универсальность этой модели, по мысли авторов перечня, позволяет применить ее к организации любой сложности, размера и сферы деятельности. Модель классифицирует бизнес-процессы организации по 13 основным направлениям:

1. маркетинг рыка и пожелания заказчиков;

2. разработка стратегии;

3. разработка продукции (услуги);

4. организация продаж;

5. производство и поставка продукции;

6. организация сервиса (для сервисно-ориентированных организации);

7. обслуживание заказчика и оформление счета-фактуры;

8. управление человеческими ресурсами;

9. управление информационными ресурсами;

10. управление финансовыми и физическими ресурсами;

11. управление экологией;

12. управление внешними связями;

13. управление улучшениями и изменениями.

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

3. определить функции, выполняемые на уровне подразделений (управлений);

4. распределить функции подразделений (управлений) по процессам.

Приведенную процедуру иллюстрирует рисунок 6.

Рисунок 6 - распределение функций, выполняемых в подразделениях, по процессам

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

Рисунок 7 - выделение сети бизнес-процессов (вариант 1)

На рисунке показано, что функции 1, 2, 3 и 4 выполняются в первом процессе, функции 5, 6, 7, 8, и 9 - во втором, функции 10, 11, 12 и 13 - в третьем. В этом примере в организации выделено три процесса. Границы этих процессов четко определены. Ответственность и полномочия владельцев процессов известны. При таком способе структурирования деятельности можно видеть, какие ресурсы находятся в распоряжении каждого владельца процессов и за какие результаты владельцы процессов несут ответственность. Очень часто такие процессы совпадают с границами подразделений. Следует обратить внимание на то, что процессы могут быть выделены и немного другим способом.

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

Рисунок 8- выделение сети бизнес-процессов (вариант 2)

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

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

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

2. Общая теория по технологиям и стандартам, применяемым при формировании сети бизнес-процессов.

Для графического изображения сети бизнес-процессов, могут применяться различные стандарты, например: VAD, EPC, eEPC, при этом применение стандартов семейства IDEF не целесообразно, из-за невозможности данных стандартов отображать все многообразие сложного объекта управления.

Таблица 2 - графические символы нотации EPC

Название	Графический символ	Описание
Функция		Блок представляет собой функцию - действие или набор действий, выполняемых над исходным объектом (документом, ТМЦ и прочим) с целью получения заданного результата. Внутри блока помещается наименование функции. Временная последовательность выполнения функций задается расположением функций на диаграмме процесса сверху вниз.
Событие		Событие - состояние, которое является существенным для целей управления бизнесом и оказывает влияние или контролирует дальнейшее развитие одного или более бизнес-процессов. Элемент отображает события, активизирующие функции или порождаемые функциями. Внутри блока помещается наименование события.
Стрелка		Стрелка отображает связи элементов диаграммы процесса EPC между собой. Связь может быть направленной и ненаправленной в зависимости от соединяемых элементов и типа связи.
Оператор AND («И»)	Рис.9 Рис.10 Рис.11 Рис.12	Оператор «И» используется для обозначения слияния/ветвления как функций, так и событий. Если завершение выполнения функции должно инициировать одновременно несколько событий, то это обозначается с помощью оператора «И», следующего после функции и перед событиями. На рисунке (Рис. 9) завершение выполнения Функции одновременно инициирует события: Событие 1 и Событие 2. Если событие происходит только после обязательного завершения выполнения нескольких функций, то это обозначается с помощью оператора «И», следующего после функций и перед одиночным событием. На рисунке (Рис.10) Событие произойдет только после обязательного завершения Функции 1 и Функции 2. Если функция может начать выполняться только после того, как произойдут несколько событий, то это обозначается с помощью оператора «И», следующего после событий и перед функцией. На рисунке (Рис.11) Функция начнет выполняться только после того, как произойдут Событие 1 и Событие 2. Если одно событие может инициировать одновременное выполнение нескольких функций, то это обозначается с помощью оператора «И», следующего после события и перед функциями. На рисунке (Рис.12) Событие одновременно инициирует выполнение Функции 1 и Функции 2.
Оператор OR («ИЛИ»)	Рис.13 Рис.14 Рис.15	Оператор «ИЛИ» используется для обозначения слияния/ветвления функций и для слияния событий. По правилам нотации EPC после одиночного события не может следовать разветвляющий оператор «ИЛИ». Если завершение выполнения функции может инициировать одно или несколько событий, то это обозначается с помощью оператора «ИЛИ», следующего после функции и перед событиями. На рисунке (Рис.13) завершение выполнения Функции 1 может инициировать 3 вида ситуаций: только Событие 1, только Событие 2, одновременно и Событие 1, и Событие 2. Если событие происходит после завершения выполнения одной или нескольких функций, то это обозначается с помощью оператора «ИЛИ», следующего после функций и перед одиночным событием. На рисунке (Рис.14) Событие может произойти либо после завершения выполнения Функции 1, либо после завершения выполнения Функции 2, либо после завершения выполнения и Функции 1, и Функции 2. Если функция может начать выполняться после того, как произойдет одно или несколько событий, то это обозначается с помощью оператора «ИЛИ», следующего после событий и перед функцией. На рисунке (Рис.15) Функция может начать выполняться либо после того, как произойдет Событие 1, либо после того, как произойдет Событие 2, либо после того, как произойдут оба события: Событие 1, и Событие 2.
Оператор XOR («Исключающее ИЛИ»)	Рис.16 Рис.17 Рис.18	Оператор «Исключающее ИЛИ» используется для обозначения слияния/ветвления функций и для слияния событий. По правилам нотации EPC после одиночного события не может следовать разветвляющий оператор «Исключающее ИЛИ». Если завершение выполнения функции может инициировать только одно из событий в зависимости от условия, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего за функцией и перед событиями. На рисунке (Рис.16) Функция инициирует либо только Событие 1, либо только Событие 2. Если событие происходит сразу после завершения выполнения либо одной функции, либо другой, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего после функций и перед одиночным событием. На рисунке (Рис.17) Событие может произойти либо сразу после завершения выполнения Функции 1, либо сразу после завершения выполнения Функции 2. Если функция может начать выполняться сразу после того, как произойдет либо одно событие, либо другое, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего после нескольких событий и перед функцией. На рисунке (Рис.18) Функция может начать выполняться сразу после того, как произойдет либо Событие 1, либо Событие 2.
Интерфейс процесса	Рис.19 Рис.20 Диаграмма Процесса 1 Рис.21. Диаграмма Процесса 2	Элемент, обозначающий внешний (по отношению к текущей диаграмме) процесс или функцию. Используется для указания взаимосвязи процессов: обозначает предыдущий или следующий процесс по отношению к диаграмме рассматриваемого процесса; обозначает процесс, откуда поступил или куда передается объект. Внутри блока помещается наименование внешнего процесса. На рисунке (Рис.19) показано, что договор является результатом выполнения процесса «Заключение договора». На рисунке (Рис.20) показано, что после окончания Процесса 1 (и наступления Событие 1) начинает выполняться Процесс 2. На диаграмме Процесса 2 (Рис.21) показано, что перед началом Процесса 2 был завершен Процесс 1, инициировавший Событие 1.
Субъект		Используется для отображения на диаграмме организационных единиц (должности, подразделения, роли, внешнего субъекта) - исполнителей, владельцев или участников функций. Внутри блока помещается наименование организационной единицы.
Бумажный документ		Используется для отображения на диаграмме бумажных документов, сопровождающих выполнение функции. Внутри блока помещается наименование бумажного документа.
Электронный документ		Используется для отображения на диаграмме электронных документов, сопровождающих выполнение функции. Внутри блока помещается наименование электронного документа.
ТМЦ		Используется для отображения на диаграмме товарно-материальных ценностей (ТМЦ), сопровождающих выполнение функции. Внутри блока помещается наименование ТМЦ.
Информация		Используется для отображения на диаграмме информационных потоков, сопровождающих выполнение функции. Внутри блока помещается наименование информационного потока.
Информационная система		Используется для отображения на диаграмме информационной системы, поддерживающей выполнение функции. Внутри блока помещается наименование информационной системы.
Модуль информационной системы		Используется для отображения на диаграмме модуля информационной системы, поддерживающего выполнение функции. Внутри блока помещается наименование модуля информационной системы.
Функция информационной системы		Используется для отображения на диаграмме функции информационной системы, поддерживающей выполнение функции. Внутри блока помещается наименование функции информационной системы.
База данных		Используется для отображения на диаграмме базы данных, сопровождающей выполнение функции. Внутри блока помещается наименование базы данных.
Термин	Рис.22	Используется для отображения на диаграмме объектов, сопровождающих выполнение функции. Наименования этих объектов - термины, используемые в организации. Внутри блока помещается наименование термина. Элемент может быть использован для обозначения данных, передаваемых между процессами или обрабатываемых при выполнении процессов. Элемент может быть также использован для обозначения статусов бумажных/электронных документов и других элементов справочника «Объекты деятельности». На рисунке (Рис.22) статус документа «Акт выполненных работ» устанавливается с помощью термина «Подписанный».
Набор объектов		Используется для отображения на диаграмме наборов объектов, сопровождающих выполнение функции, например, «Документация по проекту». Внутри блока помещается наименование набора объектов.
Прочее		Используется для отображения на диаграмме потоков объектов, которые нельзя отнести ни к одной из предопределенных групп справочника «Объекты деятельности». Внутри блока помещается наименование прочего объекта.

Правила моделирования процессов в нотации EPC:

1. Диаграмма EPC должна начинаться как минимум одним стартовым событием (стартовое событие может следовать за интерфейсом процесса) и завершаться как минимум одним конечным событием (конечное событие может предшествовать интерфейсу процесса).

2. События и функции по ходу выполнения процесса должны чередоваться. Решения о дальнейшем ходе выполнения процесса принимаются функциями.

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

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

5. События и операторы, окружавшие функцию на вышележащей диаграмме (Рис. 23), должны быть начальными/результирующими событиями и операторами на диаграмме декомпозиции функции (Рис. 24).

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

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

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

Рисунок 23 _ Диаграмма процесса, на которой встречается Функция 1

Рисунок 24 _ Диаграмма декомпозиции Функции 1

9. За одиночным событием не должны следовать операторы «OR (ИЛИ)» или «XOR (Исключающее ИЛИ)».

10. Операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ветвление функции и события невозможно.

11. Оператор, разветвляющий ветки, и оператор, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда оператор ветвления «И» заменяется оператором объединения - «ИЛИ».

Примеры допустимых ситуаций (рисунки 25-28):



Рисунок 25

Рисунок 26

Рисунок 27



Рисунок 28

Рисунок 29 - пример недопустимой ситуации

Лабораторная работа № 2 - Планирование развития информационной системы объекта управления.

I. Условия и задания работы

1. Задания:

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

2. На основании выполненной работы составить отчет

Примерная структура стратегического плана автоматизации процесса:

1. Цели автоматизации компании.

2. Способ автоматизации компании.

3. Ограничения.

4. Анализ требований к ИС.

5. Способ приобретения ИС.

Примерная структура оперативного плана автоматизации процесса, выполняется в среде MS Project или аналогичной:

1. Структура проекта автоматизации компании (диаграмма Gantt).

2. Ресурсное планирование проекта автоматизации (таблица ресурсов Resource Sheet, отчет Who Does What When).

3. Стоимостный анализ проекта (отчеты Cash Flow, Budget).

2. Пример структуры стратегического плана для случайного процесса разработки информационной технологии

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

2. Выбрать способ автоматизации компании и обосновать свой выбор:

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

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

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

3. Описать ограничения, которые необходимо учитывать при выборе стратегии автоматизации компании (финансовые, временные, трудовые, технические):

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

3.2. Определить временные ограничения.

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

3.4. Описать возможные технические ограничения.

4. Выполнить анализ требований к информационной системе:

4.1. Описать функции, которые должна выполнять будущая система (то, что нужно автоматизировать).

4.2. Выбрать класс информационной системы для автоматизации компании (MRPII, ERP, CRM, OLAP и др.) и обосновать свой выбор, т.е. описать структуру, функциональные возможности, преимущества и недостатки внедрения информационных систем различных классов.

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

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

5.1. Для рассмотрения варианта покупки ИС необходимо:

5.1.1. Описать преимущества и недостатки покупки ИС.

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

5.1.3. В результате обзора составить список ИС, в которых реализованы необходимые функции (3-5 информационных систем).

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

5.1.5. Описать функциональные возможности каждой ИС.

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

5.1.7. Рассчитать стоимость приобретения каждой ИС.

5.1.8. Описать, какие этапы жизненного цикла ИС влияют на совокупную стоимость владения ИС.

5.1.9. Рассчитать совокупную стоимость владения каждой ИС.

5.1.10. Описать перспективы развития, поддержки и интеграции каждой ИС.

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

5.1.12. Описать технические характеристики каждой ИС.

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

5.2. Для рассмотрения варианта самостоятельной разработки ИС необходимо:

5.2.1. Описать преимущества и недостатки самостоятельной разработки ИС.

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

5.2.3. Рассчитать финансовые и временные затраты на разработку и внедрение ИС (проектирование, программирование, тестирование, отладка, внедрение, сопровождение).

5.2.4. Описать перспективы развития, поддержки и интеграции разработанной самостоятельно ИС.

5.3. Для рассмотрения варианта разработки ИС фирмой-разработчиком необходимо:

5.3.1. Выполнить с помощью Интернет обзор фирм-разработчиков ИС, которые занимаются созданием ИС на заказ.

5.3.2. В результате обзора составить список фирм-разработчиков ИС, занимающихся созданием ИС на заказ (3-5 фирм).

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

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

5.3.5. Описать перспективы развития, поддержки и интеграции разработанной ИС по каждой фирме-разработчику ИС.

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

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

5.4. Для рассмотрения варианта покупки и доработки ИС необходимо:

5.4.1. Описать преимущества и недостатки покупки и доработки ИС.

5.4.2. Определить недостатки найденных ИС для покупки для данной конкретной компании.

5.4.3. Описать функции, которые необходимо доработать под потребности бизнеса компании.

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

5.5. Для рассмотрения варианта аутсорсинга ИС:

5.5.1. Описать преимущества и недостатки аутсорсинга ИС.

5.5.2. Выполнить с помощью Интернет обзор фирм, предоставляющих услуги аутсорсинга ИС.

5.5.3. В результате обзора составить список фирм, предоставляющих услуги аутсорсинга ИС (3-5 фирм).

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

5.5.5. Рассчитать совокупную стоимость владения ИС по каждой фирме, предоставляющей услуги аутсорсинга.

5.5.6. Описать перспективы данного способа приобретения.

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

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

5.7. Описать выбранный способ приобретения ИС и обоснование выбора.

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

1. Описать проект автоматизации компании:

1.1. Создать и сохранить в MS Project новый проект (создается автоматически после запуска приложения).

1.2. Установить параметры проекта автоматизации в целом (окно Project Information, которое появляется при создании нового проекта или выбирается в меню Project/ Project Information).

1.3. Описать структуру проекта автоматизации компании, т.е. описать этапы автоматизации компании (столбец Task Name в Gantt Chart) и установить взаимосвязи между ними.

1.4. Детализировать этапы работ по автоматизации на подэтапы (кнопки Indent и Outdent).

1.5. Установить параметры работ проекта автоматизации (окно Task Information).

2. Провести ресурсное планирование проекта автоматизации:

2.1. Внести все виды ресурсов в таблицу ресурсов Resource Sheet с указанием располагаемого объема.

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

2.3. Определить имеются ли перегруженные ресурсы (Resource Sheet).

2.4. Определить и описать причины перегрузки ресурсов.

2.5. Устранить перегрузки ресурсов.

2.6. Сформировать план по кадрам (отчет Who Does What When из меню View/Report/Assignment).

3. Выполнить стоимостный анализ проекта с помощью таблицы затрат Table Cost (меню View/Table/Cost). Сформировать финансовый план проекта (отчет Cash Flow, содержащий информацию о распределении стоимости работ во времени, отчет Budget из меню View/Report/Costs). Сделать выводы по данным отчетам.

II. Теория работы

Можно выделить следующие уровни планирования:

· стратегическое планирование;

· бюджетирование и операционное планирование, включающее формирование плана продаж и операций (Sales and Operations Plan, SOP) и основного производственного плана (Master Production Schedule, MPS);

· планирование материалов и мощностей, включающее планирование необходимых материалов (Material Requirements Planning, MRP) и планирование необходимых мощностей (Capacity Resource Planning, CRP);

· оперативное управление деятельностью предприятия.

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

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

· горизонтом планирования (интервал времени от текущего момента до некоторой даты в будущем, для которого данный план разрабатывается);

· степенью детализации плана;

· частотой, с которой план пересматривается и корректируется.

Схематически соотношение глубины детализации и плановых горизонтов различных планов предприятия представлено на рисунке 30

Рисунок 30 - уровни планирования и управления

Планирование развития информационной среды предприятия и применения ИТ основывается на тех же общих принципах и методах, что и традиционное планирование.

В настоящее время общеприняты, пять основных принципов планирования:

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

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

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

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

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

Для процесса стратегического планирования информационных систем (далее СПИС) характерны следующие типичные фазы или этапы.

· Постановка задач СПИС. На данной стадии определяется для какой части предприятия должно проводиться планирование, в каком именно виде и кем, а также, что от этого должно получить предприятие и когда?

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

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

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

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

Рисунок 31 - Фазы стратегического планирования информационных систем

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

Результаты СПИС излагаются в итоговом докладе, содержащем следующие данные:

· основополагающие решения, цели и принципы организации ОИ;

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

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