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

Решение задач и выполнение научно-исследовательских разработок: Отправьте запрос сейчас: irina@bodrenko.org    
математика, IT, информатика, программирование, статистика, биостатистика, экономика, психология
Пришлите по e-mail: irina@bodrenko.org описание вашего задания, срок выполнения, стоимость





Информационные технологии в менеджменте

 

Лекция 2

 

Тема лекции: «Моделирование и оптимизация бизнес-процессов»

  1. Основные понятия  моделирования бизнес-процессов.
  2. Основные методики описания бизнес-процессов.
  3. Технологии бизнес-моделирования. Анализ и оптимизация бизнес-процессов.

1.          ОСНОВНЫЕ ПОНЯТИЯ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ.  

 

1.1.  Понятие бизнес-процесса.

1.1.

Существуют различные определения понятия «бизнес-процесса» в зависимости от взгляда и точки зрения, ниже приведены некоторые из них:

1)   Процесс — устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя /клиента (ИСО 9000:2000).

1)

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

2)

3)   Бизнес-процесс — структурированный набор действий, охватывающий различные сущности предприятия и подчиненный определенной цели (ISO/CD 15531-1).

 

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

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

 

1.2.  Проекты.

 

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

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

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

Другое определение гласит:

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

Успешному решению всех этих задач способствует то, что «управление проектами» — достаточно хорошо проработанная и стандартизированная область менеджмента. Наиболее известные стандарты управления проектами — это разработанный PMI (Project Management Institute)  стандарт PMBOK (Project Management Body of Knowledge) и, разработанный на его основе, стандарт ISO 10006:1997.

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

1.3.     Кейсы и управление ими.

 

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

 

Информация по кейсу — полное собрание относящихся к кейсу документов, содержащих информацию любого типа и соответствующих любому формату, например данные в формах, электронных документах, сканированные с твердых копий изображения, аудио- и видеофайлы, фотографии и т. д. Часто это не case file, а case folder, документ-центрический подход пока преобладает, отчего и путаница с системами электронного документооборота (вплоть до попыток выдать старинный электронный документооборот за настоящее управление кейсами). Дальше в этой предметной области просто: говоря «кейс», подразумеваем «информацию по кейсу», а говоря «информация по кейсу» — сам «кейс».

 

В настоящее время работа с кейсами идет в рамках направления «адаптивное управление кейсами» (ACM, Adaptive Case Management).

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

Сейчас говорят все чаще не просто case management, а adaptive case management — адаптивное управление кейсами. «Адаптивный» — это не просто планирование в фиксированной структуре, а адаптация к изменению структуры: включение по ходу дела новых участников работ, новых видов работ, новых маршрутов прохождения работ и т. д., планирование кейсов в ходе исполнения (run-time, а не design-time).

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

 

Можно предложить еще одно сравнение — правила получения звуков на музыкальных инструментах при коллективной игре в «традиционном симфоническом оркестре» и в джазовом ансамбле. Важно, что в джазе импровизируют не совсем на 100%: есть четкое понимание стиля, и есть джазовые стандарты. Это повторяет и адаптивное управление кейсами: про деятельность по разрешению кейса кое-что известно в design-time, например, какие-то паттерны/шаблоны из предыдущего опыта работы с подобными кейсами — это просто то, что известно про кейсы из прошлого опыта, в том числе и те работы, которые с ними проводятся. Также в управлении кейсом используются библиотеки правил — движение адаптивного  управления кейсами считает себя наследником движения экспертных систем.

1.4.  Бизнес-правила.

1.4.

Хотя бизнес-правила сами по себе не являются разновидностью действий, в некоторых случаях они более удобны для представления логики действий, чем, например, модели бизнес-процессов. Для пояснения данного тезиса необходимо дать определение понятию «бизнес-правило» и кратко описать это понятие:

1)   Бизнес-правила — набор условий, которые управляют деловым событием, чтобы оно происходило так, как нужно для предприятия (или клиента).

1)

2)    Бизнес-правила — это положения, определяющие или ограничивающие какие-либо стороны бизнеса. Их назначение — защитить структуру бизнеса, контролировать или влиять на его операции.

2)

Правила играют важную роль в определении бизнес-семантики: они могут влиять на поведение «игроков», поддерживать политики, реагировать на ситуации и события окружающей среды. Таким образом, правила являются значимым способом управления операционной деятельностью с учетом целей, политик, ограничений и пр. Подход на основе правил (rule-based approach) затрагивает два типа пользователей (заинтересованных сторон):

  1. Бизнес-пользователи (предоставить им формализованный подход управления бизнес-правилами);
  2. ИТ-специалисты (предоставить им понимание бизнес-правил и инструментов их моделирования)

 

ПРИМЕРЫ.

 

Примерами бизнес-правил  являются:

«Доставка заказа оплачивается клиентом»,

«При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру»,

«Если заказанный товар отсутствует на складе, то заказ передается в производственный отдел»,

«Если оплата по счету не поступила в течение 15 дней, заказ считается отмененным»,

«Если сумма заказа составляет от 100 руб. до 200 руб., скидка составляет 10%».

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

 

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

Для программного исполнения бизнес-правил используются специальные системы управления бизнес-правилами (англ. Business Rule Engine).

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

1.5.    Бизнес-способности (business capability).

1.5.

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

Способности компании — это элемент ресурсного подхода (resource-based view), популярного в современном стратегическом менеджменте. Данный подход направлен на изучение источников устойчивых конкурентных и сформировался в конце 1980-х годов.

Акцент в нем сделан не на рынке продуктов, а на рынке ресурсов фирмы. Была высказана мысль о том, что все фирмы неоднородны по своим ресурсам, следовательно, при выборе конкурентной стратегии нужно исходить из конкретных ресурсов фирмы. Кроме того, только редкие и ценные ресурсы, которые не могут быть воспроизведены конкурентами, можно использовать для получения прибыли выше средней в длительном периоде. Для более точного описания ресурсов, которые могут стать источником конкурентных преимуществ, была разработана концепция ценного, редкого, неимитируемого и незаменимого — в английской аббревиатуре VRIN (valuable, rare, inimitable,on-substitutable) — ресурса. Таким может быть практически любой ресурс компании: технология, работники, местоположение и т. п.

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

 

2.       ОСНОВНЫЕ МЕТОДИКИ ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ.

 

2.1.  Подходы к моделированию бизнес-процессов.

2.1.

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

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

 

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

 

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

• информационные связи между объектами и с внешней средой;

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

• объемы передаваемой информации и частоту сеансов обмена;

• классификацию и кодирование в системе.

 

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

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

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

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

• полноту классификации (по всем существенным свойствам);

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

• использование международных стандартов;

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

Процессный подход позволил выделить процессы как объект управления, что легло в основу дисциплины «управление бизнес-процессами» (Business Process Management, BPM), в основе которой, в свою очередь, лежит цикл Деминга-Шухарда и идея непрерывного совершенствования.

 

ЭТАПЫ ЦИКЛА:

 

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

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

- Проверка (Check): сбор информации и контроль результата, выявление и анализ отклонений, установление причин отклонений.

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

Цикл PDCA обычно представляют в виде колеса с целью подчеркнуть постоянный, циклический характер процесса улучшения.

Внимание к бизнес-процессам и BPM обусловлено синхронной эволюцией со стороны менеджмента и со стороны информационных технологий.

 

2.2.  Бизнес-модели как способ формализации бизнес-стратегии.

2.2.

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

 

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

 

Одним из распространенных методов представления бизнес-моделей является предложенный Александром Остервальдером. Популярность и широкое распространение метод получил после публикации в 2010 году книги «Построение бизнес-моделей» (Business Model Generation). За несколько лет книга была переведена на 18 языков и продана в количестве более 500 000 экземпляров.

БИЗНЕС-МОДЕЛЬ — ЭТО ПРЕДСТАВЛЕНИЕ БИЗНЕС-СИСТЕМЫ В ВИДЕ СОВОКУПНОСТИ 9 СТРУКТУРНЫХ БЛОКОВ, ИМЕЮЩИХ КЛЮЧЕВОЕ ЗНАЧЕНИЕ ДЛЯ БИЗНЕСА:

 

Элементы бизнес-модели.

1)   Потребительские сегменты (кто является потребителями, на кого ориентирован бизнес?)

1)

2)   Ценностное предложение (что уникального мы предоставляем нашим клиентам, каковы наши отличительные особенности?)

2)

3)   Каналы сбыта (каким образом мы доставляем наше предложение клиентам?)

3)

4)   Взаимоотношения с клиентами (как мы осуществляем коммуникации с клиентами и поддержку?)

 

5)   Потоки поступления доходов (какие основные каналы поступления доходов?)

5)

6)   Ключевые ресурсы (какими ключевыми ресурсами необходимо обладать, чтобы предоставить ценностное предложение ключевым потребителям?)

6)

7)   Ключевые виды деятельности (какая деятельность является ключевой для того чтобы все остальное работало?)

7)

8)    Ключевые партнеры (кто является ключевыми партнерами?)

8)

9)   Структура издержек (на что направлены основные издержки?)

9)

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

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

Александр Остервальдер уделяет значительное внимание организации совместного творческого процесса и предлагает набор практик и методов для разработки и анализа бизнес-модели, таких как: метод мозгового штурма, визуализация с помощью стикеров и рисунков, рассказы («storytelling»), разыгрывание сценариев и др.

Автор предлагает метод управления на основе бизнес-модели, включающий следующие шаги: мобилизация (вовлечение сотрудников); понимание (освоение методов и подходов); дизайн (создание бизнес-модели «as is», анализ, проектирование «to be»); применение (проверка прототипа «to be» в реальных условиях); управление (адаптация и постоянное совершенствование модели на основе реакции рынка).

Существуют приложения (в том числе и на планшетные ПК) для создания бизнес-моделей. Например, приложение «Strategyzer» позволяет не только создавать и редактировать модели, но и производить первичные расчеты (получается упрощенный аналог бизнес-плана).

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

 

Модели бывают различных типов: модели процессов/потоков работ, функциональные модели, организационные модели, модели данных/ресурсов, временные модели типа диаграмм Ганта, модели причинно-следственных связей. Факт заключается в том, что нет «одной, самой лучшей» модели для описания бизнес-процессов. Можно провести аналогию с графиками, которые используются для иллюстраций. Круговая диаграмма с сегментами, пропорциональными по размеру проценту чего-либо целого, отлично подходит для определенных задач, но ее нельзя использовать для иллюстрации и анализа всех типов данных (например, изменений каких-то данных во времени). Точно также при анализе бизнес-процессов выбранный метод моделирования должен отражать цели анализа. Оптимизация процесса по времени и четкий анализ взаимодействия между участниками процесса могут потребовать разных моделей.

 

2.3.  Методологии моделирования структуры организации.

 

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

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

 

Существует определенный набор ключевых мероприятий, обязательное проведение которых может повысить вероятность успеха проекта. Уже на стадии постановки задачи должны быть определены цели этапов проекта и самого проекта, включая критерии их выполнения. При этом данные цели должны быть сформулированы предельно четко и ясно, по возможности, удовлетворяя критериям SMART: КОНКРЕТНОСТЬ, ИЗМЕРИМОСТЬ, ДОСТИЖИМОСТЬ, АКТУАЛЬНОСТЬ, УСТАНОВКА КОНКРЕТНОГО СРОКА.

 

ПРИМЕР.

 

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

 

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

 

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

 

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

 

При анализе предметной области принято выделять три этапа:

 

Этап 1. АНАЛИЗ ТРЕБОВАНИЙ И ИНФОРМАЦИОННЫХ ПОТРЕБНОСТЕЙ.

 

Этап 2. ОПРЕДЕЛЕНИЕ ИНФОРМАЦИОННЫХ ОБЪЕКТОВ И СВЯЗЕЙ МЕЖДУ НИМИ.

 

Этап 3. КОНСТРУИРОВАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ.

 

Этап анализа требований и информационных потребностей включает следующие задачи:

 

1)   определение перечня задач по извлечению, обработке,  хранению, транспортировке и представлению (в том числе  документированию) информации;

 

2)   определение требований к составу, структуре, формам  представления информации;

 

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

 

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

 

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

 

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

 

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

 

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

 

Объектно-ориентированный подход основан на объектной  декомпозиции с описанием поведения системы в терминах  взаимодействия объектов.

 

2.4.  Формирование модели предметной области.

 

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

 

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

 

Факты — результат наблюдения за состоянием предметной  области.

 

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

 

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

 

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

 

Основными направлениями формализации информации о предметной области являются:

 

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

 

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

 

семиотика, изучающая знаковые системы с точки зрения синтактики, семантики и прагматики.

 

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

 

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

 

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

 

Способы абстрагирования:

 

абстракция через параметризацию;

 

абстракция через спецификацию.

 

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

 

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

 

Модель данных — модель, используемая при абстрагировании.

 

Концептуальная модель — абстрагированное описание предметной области.

 

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

 

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

 

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

 

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

 

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

 

упрощение разработки и модернизации ИС в результате  специализации групп проектировщиков по подсистемам;

 

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

 

упрощение эксплуатации ИС вследствие специализации  работников предметной области.

 

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

 

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

 

Функциональные подсистемы ИС могут строиться по различным принципам:

 

предметному;

 

функциональному;

 

проблемному;

 

смешанному (предметно-функциональному).

 

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

 

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

 

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

 

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

 

Функциональный принцип:

 

стратегическое развитие;

 

технико-экономическое планирование;

 

бухгалтерский учет и анализ хозяйственной деятельности.

 

Предметный принцип (подсистемы управления ресурсами):

 

техническая подготовка производства;

 

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

 

качество продукции;

 

логистика;

 

маркетинг;

 

кадры.

 

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

 

3.          ТЕХНОЛОГИИ БИЗНЕС-МОДЕЛИРОВАНИЯ. АНАЛИЗ И ОПТИМИЗАЦИЯ БИЗНЕС-ПРОЦЕССОВ.

 

3.1.  Функционально — модульный (структурный) метод проектирования.

 

Широкое развитие получили методы проектирования, основанные на CASE-технологиях (Computer Aided System Engineering - компьютерное проектирование программных систем).

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

Структурный подход к  проектированию  предполагает разработку  следующих моделей:

- диаграмм потоков данных (DFD — Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть  реализованы в системе;

 

- диаграмм «сущность—связь» (ERD - Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы;

- диаграмм переходов состояний (STD — State Transition Diagrams), характеризующих поведение системы во  времени;

- функциональных диаграмм (методология SADT);

- спецификаций процессов;

- словаря терминов.

 

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

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

 

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

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

• при начальных попытках формирования модели, когда все по­нятное еще далеко впереди.

Чаще встречается значительно более сложная ситуация, зани­мающая промежуточную позицию между этими крайностями: все вроде бы понятно, но при попытках формализовать взаимоотношения возникает «сплошной туман». В этом случае действенную помощь может оказать хорошо разработанное семейство методологий IDEF, являющееся государственным стандартом в США. Оно состоит из методологии функционального моделирования IDEF0 и методологии IDEF1(X). Предполагалось создание стандарта на методологию ди­намического моделирования IDEF2, однако стандарт так и не был создан (тем не менее,  существуют системы динамического моделиро­вания, преобразующие статические модели семейства IDEF0 в моде­ли на базе «раскрашенных сетей Петри»).

МЕТОДОЛОГИЯ SADT.

 

В качестве примера рассмотрим методологию SADT (Structured Analysis and Design Technique), предложенную Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition).

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

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

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

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

 

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

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

 

Основные элементы методологии SADT основываются на следующих концепциях:

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

- строгость и точность отображения.

Правила SADT включают:

1)   уникальность меток и наименований;

1)

2)   ограничение количества блоков на каждом уровне  декомпозиции;

2)

3)   синтаксические правила для графики;

3)

4)   связность диаграмм;

4)

5)   отделение организации от функции;

5)

6)   разделение входов и управлений.

6)

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

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

 

IDEF-методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности - ICAM, в хо­де реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промыш­ленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффек­тивного обмена информацией между специалистами – участниками программы ICAM, что определило название самой методологии Icam DEFinition, т.е. IDEF. После опубликования стандарта он был успеш­но применен в самых различных областях бизнеса, показав себя эф­фективным средством анализа, конструирования и отображения биз­нес-процессов.

 

Более того, с широким применением как IDEF, так и предшествующей методологии - SADT - связано возникновение ос­новных идей понятия BPR (Business Process Reengineering).

К особенностям этого семейства методологий можно отнести:

• уникальную способность «задавать вопросы» в процессе моде­лирования;

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

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

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

 

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

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

Рисунок 1. Функциональный блок и интерфейсные дуги.

 

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

 

В функциональных диаграммах SADT различают пять типов влияний блоков друг на друга:

- вход-выход блока подается на вход блока с меньшим  доминированием, т. е. следующего (рисунок 2, а);

- управление. Выход блока используется как управление для блока с меньшим доминированием (рисунок 2, б),

- обратная связь по входу. Выход блока подается на вход блока с большим доминированием (рисунок 2, в);

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

-  выход-исполнитель. Выход блока используется как  механизм для другого блока (рисунок 2, д).

Рисунок 2. Типы влияний блоков: а — вход; б — управление; в — обратная связь по входу; г – обратная связь по управлению; д — выход-исполнитель.

 

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

 

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

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

 

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

3.2.  Диаграммы сущность—связь.

3.2.

Методология IDEF1(X) является разновидностью методологии ER-диаграмм (Entity-Relationship, т.е. модель «сущность – связь»). Она строго фор­мализована и адаптирована для совместного использования с IDEF0 как «дуальная» (двойственная) к ней в рамках единой технологии мо­делирования. Двойственность методологии проявляется в том, что в рамках IDEF0 детализируются функциональные блоки, а в IDEF1(X) подлежат детализации потоки, взаимодействующие с функциями.

Первый вариант модели «сущность—связь» был предложен в 1976 г. Питером Пин-Шэн Ченом. В дальнейшем многими  авторами были разработаны свои варианты подобных моделей  (нотация Мартина, нотация IDEF1(X), нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. Все  варианты диаграмм «сущность—связь» исходят из одной идеи — рисунок всегда нагляднее текстового описания. Все такие  диаграммы используют графическое изображение сущностей  предметной области, их свойств (атрибутов) и взаимосвязей между сущностями. Поскольку нотация Баркера является наиболее  распространенной, в дальнейшем будем придерживаться именно ее.

Основные понятия ER-диаграмм.

Базовыми понятиями ER-модели данных (ER — Entity-Relationship) являются сущность, атрибут и связь.

Сущность — это класс однотипных объектов, информация о которых должна быть учтена в модели.

 

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

Рисунок 3. Обозначения сущности в нотации Баркера: а –  без атрибутов; б — с указанием атрибутов; в — с ключевым атрибутом.

Экземпляр сущности — это конкретный представитель  данной сущности.

 

Например, конкретный представитель сущности «Студент» — «Макаров». Причем сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности, для того чтобы различать экземпляры.

Атрибут сущности — это именованная характеристика,  являющаяся некоторым свойством сущности.

 

Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с описательными оборотами или прилагательными).

Примерами атрибутов сущности «Студент» могут быть такие  атрибуты: «Номер зачетной книжки», «Фамилия», «Имя», «Пол», «Возраст», «Средний балл» и т. п.

 

Атрибуты изображаются в прямоугольнике, обозначающем сущность (рисунок 3, б).

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

 

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

Связь — это отношение одной сущности к другой или к  самой себе.

 

Имеется возможность по одной сущности находить другие,  связанные с ней. Например, связи между сущностями могут  выражаться следующими фразами — «СОТРУДНИК может иметь несколько ДЕТЕЙ», «СОТРУДНИК обязан числиться точно в одном ОТДЕЛЕ». Графически связь изображается линией,  соединяющей две сущности (рисунок 4).

 

Рисунок 4. Пример связи между сущностями.

 

Каждая связь имеет одно или два наименования.

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

Связь может иметь один из следующих типов — рисунок 5.

Рисунок 5. Типы связей.

 

Связь типа один-к-одному означает, что один экземпляр  первой сущности связан точно с одним экземпляром второй сущности. Такая связь чаще всего свидетельствует о том, что мы  неправильно разделили одну сущность на две.

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

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

Каждая связь может иметь одну из двух модальностей связи (рисунок 6).

 

Рисунок 6. Модальности связей.

Связь может иметь разную модальность с разных концов, как на рисунке 4. Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на рисунке 4 читается так: слева направо: «Сотрудник может иметь несколько детей»; справа налево: «Ребенок должен принадлежать точно одному сотруднику».

3.3.  Объектно-ориентированная технология проектирования.

 

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

 

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

 

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

 

Объектно-ориентированная технология проектирования ИС включает в себя следующие компоненты:

 

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

 

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

 

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

 

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

 

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

 

Концептуальная объектно-ориентированная модель предметной области является основой проекта и реализации системы и  обеспечивает:

 

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

 

высокий уровень абстрагирования, типизации и  параметризации проектных решений;

 

компактность описания;

 

удобство сопровождения готовой системы.

 

Отличительными чертами объектно-ориентированной методологии являются:

 

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

 

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

 

Отличительными чертами объектно-ориентированной технологии являются:

 

совместное рассмотрение информационных, материальных и финансовых потоков;

 

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

 

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

 

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

 

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

 

3.4.  Программные средства автоматизации моделирования бизнес-процессов.

 

Успешное внедрение процессного подхода во многом зависит от использования профессиональных инструментальных средств, позволяющих описывать и проводить анализ бизнес-процессов, делать их более прозрачными и управляемыми. Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architeсt, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно.

ПРИМЕР.

 

Одним из примеров подобных программных сред является семейство продуктов ARIS (Architecture  of  Integrated Information Systems), разработанных компанией IDS Scheer AG и предназначенных для структурированного описания, анализа и последующего совершенствования бизнес-процессов предприятия, а также для подготовки к внедрению сложных информационных систем.

Методология ARIS рассматривает структуру предприятия в че­тырех аспектах:

• организационная структура предприятия;

• структура функций объектов управления;

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

• структура протекающих процессов.

Каждый из этих аспектов включает три подуровня: описания тре­бований, спецификации и внедрения.

 

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

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

 

Среди большого количества возмож­ных методов описания наиболее востребованными оказались:

• ЕРС (Event-driven Process Chain) - метод описания процессов по событиям, нашедший применение, в частности, для описания процес­сов системы SAP R/3;

• ERM (Entity Relationship Model) - модель «сущность – связь» для описания структуры данных;

• UML (Unified Modeling Language) - объектно-ориентированный язык моделирования.

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

Семейство продуктов ARIS состоит из двух основных продуктов (ARIS Easy Design и ARIS Toolset) и ряда функциональных модулей.

 

Комплекс ARIS представляет собой единую среду моделирова­ния, объединяющую четыре основных компонента: Explorer (провод­ник), Designer (средство для графического описания моделей), Тables (таблицы для ввода различных параметров и атрибутов) и Wizards (мастера). Различие двух продуктов заключается не в методологиче­ской части (ARIS Easy Design входит в AR1S Toolset), а лишь в функ­ционале. Продукт ARIS Easy Design ориентирован на сбор информа­ции и документирование, а ARIS Toolset - на комплексный анализ и семантические проверки информации.

Преимуществом ARIS перед другими средствами описания бизнес-процессов является отсутствие необходимости взаимодействия функ­циональных модулей (АВС-анализ, динамическое моделирование, на­стройка и генерация отчетов) через какие-либо программные интер­фейсы.  АВС-анализ (Activity-Based Costing - пооперационное исчис­ление стоимости) позволяет рассчитать стоимость выполнения отдельных операций при реализации бизнес-процессов и тем самым определить потребности для всей совокупности процессов. Все дан­ные, используемые основными продуктами и дополнительными функциональными модулями, хранятся в едином репозитории и не требуют проведения операций по экспорту или импорту используемых данных.

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

 

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

 

3.5.  Анализ и оптимизация бизнес-процессов.

 

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

 

Дальнейшая детализация выполняется с использованием таких инструментов, как:

- декомпозиция функций/процессов;

- анализ бизнес-событий;

- моделирование местоположений выполнения функций/процессов;

- модель интеграции функций/процессов.

 

ДЕКОМПОЗИЦИЯ БИЗНЕС-ПРОЦЕССОВ состоит в идентификации подпроцессов, которые составляют основу выполнения бизнес-функций, определении границ основных организационных единиц и определении вклада каждой функции в цепочку создания добавочной стоимости.

 

Декомпозиция функций/процессов должна:

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

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

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

- идентифицировать пересечения и излишние функции/процессы.

 

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

 

АНАЛИЗ БИЗНЕС-СОБЫТИЙ позволяет понять, как инициируются бизнес-события (например, оформление заказа) и какие связанные с ними процессы происходят в цепочке создания добавочной стоимости предприятия, что включает контакты с клиентами и поставщиками. При этом берется конкретное событие, документируется текущий процесс его обработки, и оцениваются возможности по его совершенствованию.

 

МОДЕЛЬ МЕСТОПОЛОЖЕНИЙ идентифицирует в географическом плане то место, где выполняются функции бизнеса, и обеспечивает логистический взгляд на функции, выполняемые организацией. Одним из очевидных преимуществ использования этой модели является идентификация архитектурных требований, которые предъявляются, в частности, к технологической архитектуре с точки зрения обеспечения информационного взаимодействия между различными местами расположения бизнеса. Однако целью моделирования местоположений является визуализация организационных единиц, определение мест, где выполняются функции и связей между ними.

 

МОДЕЛЬ ИНТЕГРАЦИИ отражает высокоуровневые требования к интерфейсам между процессами и бизнес-событиями, требования, предъявляемые к информации новыми шаблонами процессов, и временные требования. Эта модель служит основой для построения архитектуры информации и архитектуры прикладных систем, а также содержит общие требования к архитектуре предприятия с точки зрения бизнес-информации и интеграции.

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

 

  1. Анализ цепочек создания добавочной стоимости (А нужно ли вообще выполнять этот шаг?)
  2. Динамическое моделирование (Как эта модель выполнения бизнес-функций будет себя вести при различных значениях на входе и доступных ресурсах, и как со временем будет меняться поведение процесса?)
  3. Анализ пересечений и непокрытых областей (Gap-overlap analysis) (Будет ли наша бизнес-архитектура иметь избыточные элементы, и есть ли в ней «пробелы»?)
  4. Соотнесение затрат с активностями (Activity-based costing) (На каких процессах, каналах продаж и заказчиках мы реально зарабатываем или теряем деньги?)
  5. Обучение (Как эти бизнес-процессы соотносятся с другими?)
  6. Общая стоимость владения (Сколько стоит этот процесс?)
  7. Возврат инвестиций (ROI) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)

 

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

 

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

 

Мы уже отмечали, что показатели эффективности являются важной составляющей бизнес-архитектуры. Например, в методике FEAF Федеральной Архитектуры США имеется отдельная, явно выделенная модель показателей эффективности.

 

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

 

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

 

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

 

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

 

В связи с развитием принципов сервис-ориентированной архитектуры SOA и появлением технологически нейтрального, платформенно-независимого языка описания и выполнения бизнес-процессов BPEL (Business Process Execution Language) появилась возможность не только моделировать бизнес-процессы, но и делать их целиком или частично доступными другим системам и организациям в виде сервисов. К этому можно добавить также возможности еще одного стандарта XML Metadata Interchange (XMI) для обмена (экспорта/импорта) данных практически в любые интеграционные продукты. В совокупности это дает возможность создавать модели и репозитории бизнес-процессов для их эффективной интеграции. (Более подробную информацию о новых стандартах для моделирования процессов можно найти на сайте www.bpmi.org).

 

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

 

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

 

[1] Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки программного обеспечения. Учебное пособие /Под ред. Л.Г. Гагариной. – М.: ИД «Форум»: ИНФРА-М, 2008. – 400 с.: ил. – (Высшее образование).

 

[2] Информационные системы и технологии в экономике и  управлении: Учебник / Под ред. проф. В.В. Трофимова. — М.: Высшее  образование, 2006.-480 с.

[3] Карминский A.M., Черников Б.В. Информационные системы в экономике: В 2-х ч. Ч. 2. Практика использования: Учеб. пособие. - М.: Финансы и статистика, 2006. - 240 с : ил.

 

[4] Кудрявцев Д.В., Арзуманян М.Ю.,  Григорьев Л.Ю. Технологии бизнес-инжиниринга.  Учебное  пособие / под редакцией Д.В. Кудрявцева. — СПб.:  Изд-во Политехн. ун-та, 2014.

 

[5] Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: РИА «Стандарты и качество», 2004 – 408 с. (Серия «Практический менеджмент»).