Моделирование бизнес процессов as is начинается с определения диаграммы

На основе анализа текущих процессов
принятия, проведения опросов среди
сотрудников и их информирование была
создана следующая AS-ISмодель, которая позволяет выделить и
систематизировать процессы, протекающие
в данной системе при её функционировании.
Главная контекстная диаграмма данной
модели приводится на рисунке 1.1.

Рисунок 1.1 – Главная контекстная
диаграмма (модель AS-IS)

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

1. прием сотрудника на работу;

2. проведения опросов;

3. формирование документов.

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

Рисунок 1.2 – Декомпозиция контекстной
диаграммы

Для детального понимания процесса
«Формирование документов» он разбивается
на следующие два процесса:

1. формирование и подготовка документов;

2. формирование сопутствующих документов.

Декомпозиция
процесса «Формирование документов»
приводится на рисунке 1.3.

Рисунок 1.3 – Декомпозиция процесса
«Формирование документов»

1.3 МодельTO-BE

Модель TO-BE
(«как должно быть»)создается на основе AS-IS, с устранением
недостатков в существующей организации
бизнес-процессов, а так же с их
совершенствованием и оптимизацией
путём устранения выявленных на базе
анализа AS-IS узких мест.

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

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

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

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

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

• удобный просмотр запрошенной информации.

На основе анализа созданной выше AS-ISмодели процессов проблемной области
была созданаTO-BEмодель, контекстная диаграмма которой
приводится на рисунке 1.4.

Рисунок 1.4 – Главная контекстная
диаграмма (модель TO-BE)

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

1. регистрация и поддержка пользователей;

2. работа с данными документов;

3. работа с вспомогательными данными;

4. формирование, проведение и просмотр
   результатов опросов

Декомпозиция контекстной диаграммы
представлена на рисунке 1.5.

Рисунок
1.5 – Декомпозиция контекстной диаграммы

Процесс «Регистрация и поддержка
пользователей» для детального рассмотрения
разбивается на четыре процесса:

1. регистрация сотрудника;

2. изменение личных и секретных данных
   регистрации;

3. восстановление пароля;

4. удаление пользователя.

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

Рисунок 1.6 – Декомпозиция процесса
«Регистрация и поддержка пользователей»

Процесс «Работа с вспомогательными
данными» был декомпозирован на следующие
три процесса:

1. добавление соответствующих данных;

2. изменение соответствующих данных;

3. удаление соответствующих данных.

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

Декомпозиция процесса «Работа с данными»
приводится на рисунке 1.7.

Рисунок 1.7 – Декомпозиция процесса
«Работа с соответствующими данными»

Процесс «Формирование, проведение и
просмотр результатов опросов» был
разделён на следующие три процесса:

1. работа с категориями опросов;

2. проведение, обработка результатов
   опросов;

3. просмотр результатов опросов.

Получателем и отправителем данных
является «Сотрудник» и «Менеджер».
Декомпозиция данного процесса приводится
на рисунке 1.8.

Рисунок 1.8 – Декомпозиция процесса
«Формирование, проведение и просмотр
результатов опросов»

2 ЦЕЛЬ И ЗАДАЧИ ПРОЕКТА

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

Основное назначение портала:

• Автоматизирование документооборота;

• Облегчение обмена информацией между
  сотрудниками компании;

• Объединение хранилищ отчётных и учётных
  документов и так же различных
  информационных ресурсов;

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

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

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

1. Посетители портала;

2. Владельцы портала;

3. Администраторы портала.

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

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

• аутентификацию пользователей;

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

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

• добавление, удаление групп пользователей
  и пользователей в них;

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

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

• изменение содержимого главного меню
  в режиме WYSIWYG;

• изменение содержимого страниц новостей
  и информационных страниц в режиме
  WYSIWYG.

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

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

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

• объединение станиц посредством тегов;

• автономное редактирование правого
  блока страниц, с содержащимся на нём
  блоками с социальной информацией;

• поддержка версионности документов и
  страниц;

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

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

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

• использование своего, единого набора
  стилей и шаблонов для редактирования
  страниц портала;

• изменяемое и скрываемое Ribbon-меню;

• поддержка создания, проверки и
  утверждения страниц портала и документов.

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

Из пользовательских блоков реализованы
следующие:

• Отличный
  от стандартного SharePoint
  2010 дизайн;

• Область
  новостей;

• Область
  часто посещаемый страниц с сортировкой
  по рейтингу;

• Выпадающее
  главное меню;

• Облачко
  тегов;

• Опрос;

• Поиск
  по полезным ссылкам;

• Телефонный
  справочник;

• Библиотека
  документов;

• Поддержка
  версионности документов;

• Страница
  со ссылками на продукты компании и
  используемыми подразделениями компании
  программами;

• Возможность
  создания страницы с полезной информацией
  для предприятия.

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

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

В качестве технологии хранения и доступа
к данным необходимо использовать СУБД
MicrosoftSQLServer20008R2,
которая обеспечивает централизованное
структурированное хранение всех данных
системы, гарантируя их целостность и
непротиворечивость, а также предоставляя
множество сервисов низкого уровня для:
чтения данных из хранилища, сохранения
данных, изменения их структуры и прочее.

Система должна быть разработана под
семейство операционных систем Windowsв интегрированной среде разработкиMicrosoftVisualStudio10.0, в качестве системы
управления данными и содержимым выбрана
системаMicrosoftSharePointServer2010, в качествеWeb-сервера –IIS7.0. В качестве технологии разработки –
технология разработки современныхWeb-приложений и сервисовASP.NETна базеFramework3.5 и выше и язык
программированияC#, а
также технология доступа к даннымLinQtoSQLиLinQtoSharePoint.

3 ЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕ

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

Моделирование БП позволяет улучшить работу организации. Это становится возможным вследствие того, что:

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

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

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

— оптимизацию расходов,

— снижение рисков,

— повышение эффективности бизнес-процессов.

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

В рамках проекта было выполнено:

— построение текущей модели бизнес-процессов проведения аудита;

— анализ модели на предмет потенциально узких мест и ресурсоемких задач;

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

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

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

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

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

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

— Описание и анализ целей и задач подразделения компании, в части бизнес-процессов внутреннего аудита;

— Описание текущих моделей бизнес-процессов внутреннего аудита;

— Оценка соответствия текущих бизнес-процессов внутреннего аудита нормативным документам;

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

Существует множество разных методологий и концепций моделирования бизнес‑процессов. Наиболее популярные нотации, применяемые нами для моделирования бизнес‑процессов – это серия стандартов IDEF, ARIS eEPC и BPMN 2.0.

В данном проекте была использована нотация BPMN (Business Process Model and Notation).

Специалистами компании «Бизнес-Азимут» было описано 107 операций и функций, разработано 13 графических моделей бизнес‑процессов, в виде диаграмм BPMN 2.0.

После моделирования была осуществлена оценка соответствия процессов внешнего и внутреннего аудита модели AS-IS, представленной в виде диаграммы Process landscape ARIS.

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

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

Когда я сам изучал моделирование бизнес-процессов при реинжиниринге, то во всех учебниках встречал два понятия — AS IS и TO BE. И все авторы писали, что сначала необходимо составить нотацию AS IS (буквальный перевод — «как есть»), т.е. как система работает в настоящее время, и только потом приступать к процессу модернизации, т.е. создавать нотацию TO BE (Как должно быть).

Проще говоря, сначала следует изучить, как работает предприятие или отдел сейчас, сделать описание бизнес процесса, и только потом, на основе нотации AS IS, начинать оптимизацию. Но все эти теории хороши, когда есть что описывать по схеме «Как есть». В реальности ситуация чаще всего иная.

Описывать нечего

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

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

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

Еще ярче, в тех же продажах, заметна разница между действиями при работе с лидами:

• Один менеджер отправит прайс-лист или коммерческое предложение и успокоится на этом.
• Другой сначала позвонит, все уточнит.
• Третий будет добиваться личной встречи даже там, где без нее можно прекрасно обойтись.

Перед ними стоит задача — обработать лиды и сделать план продаж. Возможно, есть даже перечень рекомендаций, как это лучше делать. Но единой системы нет. И люди начинают нарушать последовательность действий, поступать на свое усмотрение и т. д.

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

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

Описывать незачем

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

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

Зачем создают нотации AS IS?

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

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

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

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

Потому не имеет смысла тратить силы и время на составление полноценной нотации AS IS с сопроводительной документацией, включать этот этап в план работ и т. д. Если ваш клиент не ждет от вас этого этапа в обязательном порядке, что иногда случается в крупном бизнесе или в случаях, когда заказчики тоже читали те самые учебники, предоставляйте сразу решение — TO BE. Вы должны быть на стороне клиента, и давать ему то, что реально нужно. Это подход продуктивности.

‍Пример использования нотации AS IS и TO BE

Я сотрудничал с хлебокомбинатом, который имеет цех выпечки, склад и подразделение охраны. При составлении нотации AS IS стало очевидно, что участие охраны в процессе выпечки хлеба абсолютно не нужно.

Как выглядит процесс:

1. Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
2. Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
3. Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
4. Выполняют выпуск хлеба.
5. Далее они должны сдавать полученную партию и документы охране. 
6. Охрана проверяет партию и дает разрешение. Причем, разрешение дается всегда, так как что может охрана? Убедиться, что в партии есть хлеб. Максимум – подсчитать его количество
7. Охрана выдает разрешение. 
8. Цех выпечки передает партию товара на склад. 
9. Склад принимает товар.

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

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

Процесс TO BE будет таким:

1. Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
2. Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
3. Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
4. Выполняют выпуск хлеба.
5. Цех выпечки передает партию товара на склад.
6. Склад принимает товар.

Источник: Блог компании Системный интегратор Тринион

Создание модели AS-IS бизнес-процессов деятельности компании

⇐ Предыдущая567891011121314Следующая ⇒

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

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

Контекстная модель:

Название: Реализация готовой продукции со склада.

Цель: Увеличение продаж.

Точка зрения: Начальник отдела продаж.

Входные данные: копия накладной, копия договора, заказ.

Выходные данные: требование, счет, выписка из журнала, отчет, отказ от выполнения заказа.

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

Механизмы: сотрудник отдела продаж.

Контекстная модель представлена на рисунке 18.

Рис.18. Контекстная диаграмма

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

Рис.19. Диаграмма декомпозиции

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

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

Рис.20. Диаграмма декомпозиции A1

Рис.21. Диаграмма декомпозиции A2

Рис.22. Диаграмма декомпозиции A3

Рис.23. Диаграмма декомпозиции A4

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

---

⇐ Предыдущая567891011121314Следующая ⇒

---

Дата добавления: 2016-11-12; просмотров: 898 | Нарушение авторских прав

---

Похожая информация:

Поиск на сайте:

Нотация ARIS Value-added Chain Diagram (ARIS VAD)

На рис. 2.30 представлена одна из важнейших нотаций ARIS — нотация ARIS VAD. Диаграмма цепочки процесса, добавляющего ценность, использует­ся при описании бизнес-процессов организации на верхнем уровне. Как прави­ло, консультанты, использующие ARIS, рекомендуют выделять шесть-восемь бизнес-процессов верхнего уровня и описывать их в нотации ARIS VAD. За­тем выполняется декомпозиция полученных процессов верхнего уровня в но­тации ARIS VAD или ARIS еЕРС.

Модели AS-IS и ТО-ВЕ

Рассмотрим объекты нотации ARIS VAD, представленные на рис. 2.30.

Основным объектом нотации ARIS VAD является Value-added chain — процесс или некоторая группа функций организации, которая служит для получения добав­ленной ценности. Объекты соединяются между собой пунктирной стрелкой, кото­рая имеет тип is predecessor of («является предшественником»). Этот тип связи по­казывает, что один процесс — предшественник другого. Очевидно, однако, что на практике все основные процессы цикличны. Кроме того, они имеют обратные свя­зи. Поэтому термин is predecessor of, на наш взгляд, является неудачным.

Между процессами, приведенными на рис. 2.30, могут быть отображены пото­ки материальных ресурсов и информации, для описания которых можно вос­пользоваться объектами типа Cluster и Technical term, соответственно. Для опи­сания инфраструктуры, необходимой для выполнения процесса, в данном приме­ре выбраны типы объектов Product/Service и Information service. Выбор типов объек­тов для отображения реальных потоков является в достаточной степени услов­ным. Очень важно в начале работ по моделированию процессов определиться, какие именно типы объектов будут использованы и какие объекты реального мира они будут отображать. Так, в случае примера, приведенного на рис. 2.30, можно было бы показать все потоки (информационные и материальные) при помощи объектов типа Technical term.

На рис. 2.30 показаны также объекты Organizational unit, отображающие под­разделения, выполняющие соответствующие процессы.

Объекты соединяются между собой при помощи связей определенного типа (см. рис. 2.30). Например, информационный поток, отображаемый объектом Cluster, является входящим для первого процесса и связан с ним при помощи стрелки типа is input for («является входом для»). Другой пример — тип связи executes («исполняет») между объектами Value-added chain и Organizational unit. Тип связи is used by показывает, что Product/Service используется процессом и т.д. Таким образом, в методологии ARIS важнейшим требованием является корректный выбор и дальнейшее использование связей и объектов определенного типа.

На рис. 2.31 представлен пример модели верхнего уровня, выполненный в нотации ARIS VAD. Вы уже знакомы с этим процессов. Выше, на рис. 2.16, этот же процесс представлен в нотации IDEF0.

88____________________________ ВВ. Репин, В.Г. Елиферов Процессный подход к управлению

Глава 2 Выбор методологии описания бизнес-процессов________________________________ 89

Принципы построения диаграммы процесса верхнего уровня в нотации ARIS VAD существенно отличаются от нотации IDEF0. Так. в нотации ARIS VAD стрелки могут входить в любую сторону объекта Value-added chain. (Напомним, что в нотации IDEF0 каждая сторона объекта Activity (функция) имеет глубоки и смысл). На рис. 2.32 представлена ситуация, возможная в нотации ARIS VAD. когда на диаграмме процесса приводится множество обратных связей, которые понятны только аналитику, создавшему модель.

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

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

90 В.В. Репин, В.Г. Елиферов. Процессный подход к управлению

2.7.2. Нотация ARIS еЕРС — расширение нотации IDEF3

Нотация ARIS еЕРС (extended Event Driven Process Chain) — расширенная цепочка процесса, управляемого событиями.

Нотация разработана специалис­тами компании IDS Scheer AG, Германия, в частности, профессором Шеером. В табл. 2.2 приводятся основные объекты, используемые в рамках нотации.

Таблица 2,2 Основные объекты, используемые при построении диаграмм еЕРС

Помимо основных объектов, указанных в табл. 2.2, при построении диаграм­мы еЕРС могут быть использованы многие другие объекты. На практике приме­нение большого числа объектов различных типов нецелесообразно, так как это значительно увеличивает размер модели и затрудняет ее прочтение.

Глава 2 Выбор методологии описания бизнес-процессов 91

Для понимания смысла нотации ARJS сЕРС рассмотрим основные используе­мые типы объектов и связей (рис. 2.34—2.38). На рис. 2.34 представлена простей­шая модель ARIS еЕРС, описывающая фрагмент бизнес-процесса предприятия.

Из рис. 2.34 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрел­ка, соединяющая Событие 1 и Функцию 1, «активирует» (activates) или иници­ирует выполнение Функции 1. Функция 1 «создает» (creates) Событие 2, за которым следует символ логического оператора «И», «запускающий» выпол­нение Функций 2 и 3.

Внимательный анализ нотации ARIS еЕРС показывает, что она практически не отличается от нотации IDEF3. Важнейшим отличием ARIS еЕРС является наличие объекта «событие» (event). Этот объект служит для отображения в модели возможных результатов выполнения функций, в зависимости от которых выпол­няется та или иная последующая ветвь процесса. Нотация ARIS еЕРС называет­ся, очевидно, расширенной именно вследствие наличия в ней объекта «событие» (в IDEF3 такого объекта нет). На рис. 2.35 приводятся примеры применения символов логики и событий при построении моделей в нотации ARIS еЕРС.

При построении моделей в ARIS еЕРС необходимо соблюдать следующие правила:

1. Каждая функция должна быть инициирована событием и завершаться
событием;

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

Кроме этих правил, существуют и другие важные требования к формирова­нию моделей в ARIS. Их можно изучить с помощью методического материала «Методы ARIS». который устанавливается на компьютер одновременно с демо-версией продукта, а также в [6].

На рис. 2.36 показано применение различных объектов нотации ARIS еЕРС при создании модели бизнес-процесса.

92____________________________ ВВ. Репин, В.Г. Елиферов. Процессный подход к управлению

Из рис. 2.35 и 2.36 видно, что бизнес-процесс в нотации ARIS еЕРС представ­ляет собой последовательность процедур, расположенных в порядке их выполне­ния. Следует отметить, что реальная длительность выполнения процедур в ARIS еЕРС визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено вы-

Глава 2 Выбор методологии описания бизнес-процессов___________________________________ 93

полнение двух задач одновременно. Используемые при построении модели СИМ-ЮЛЫ логики позволяют отразить ветачение и слияние бизнес-процесса. Для по­лучения информации о реальной длительности процессов и визуального отобра­жения загруженности персонала в процессе можно использовать другие инстру­менты описания, например диаграммы Гантта в системе MS Project.

Рассмотрим примеры применения нотации ARIS еЕРС для описания биз­нес-процессов. На рис. 2.37. представлен бизнес-процесс обработки заказа кли­ента. Этот же процесс изображен в нотации IDEF3 на рис. 2.23.

Процесс начинается с события «Поступил заказ клиента». Это событие ини­циирует функцию «Выполнить учет заказа в системе», которую выполняет менед­жер Отдела сбыта. Для выполнения работы он использует «Систему учета зака­зов». Результат выполнения функции отображается событием «Учет заказа вы­полнен». После этого менеджер Отдела сбыта выполняет функцию «Выполнить анализ на соответствие номенклатуре». Результатом выполнения функции явля­ются два альтернативных события «Заказ соответствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса используется символ логического оператора — исключающее «ИЛИ».

Функция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: 1) заказ не соответствует номенклатуре и 2) произ­водство невозможно. Для отображения на схеме процесса этих вариантов ис­пользуется символ логического оператора «ИЛИ» и т.д.

Как видно из рис. 2.37, схема процесса в ARIS еЕРС отличается от схемы в IDEF3 наличием объектов: событий, документов, прикладных систем и долж­ностей. Схема в ARIS eEPS визуально предстаатяется более информативной и воспринимается лучше, однако размер этой схемы существенно превышает раз­мер схемы в IDEF3.

Рассмотренный выше процесс может быть представлен также в нотации ARIS PCD (Process Chain Diagram) — разновидности ARIS еЕРС. На рис. 2.38 показан бизнес-процесс обработки заявки клиента в нотации ARIS PCD. При описании этого процесса использованы все объекты, которые составляют процесс, по­казанный на рис. 2.37, но расположены они в виде столбцов таблицы. В пер­вом столбце представлены события и некоторые символы логики, во втором — функции, в третьем — входящие и исходящие документы, в четвертом — виды прикладного программного обеспечения, в пятом — должности сотрудников, задействованных в процессе. Такое представление процесса является более «стан­дартным». Оно лучше подходит для целей документирования процессов. Одна­ко представление в нотации ARIS PCD обладает существенным недостатком — его можно эффективно применять для простых (не более пяти-восьми функ­ций), желательно линейных, процессов. Сложные процессы с разветвленной логикой отображать при помощи нотаций ARIS PCD неудобно, что наглядно видно на рис. 2.38.

94_________________________________ ВВ. Репин. В.Г. Елиферов. Процессный подход к управлению

Рис. 2.37. Пример модели процесса

Глава 2 Выбор методологии описания бизнес-процессов_______________________________ 95

в нотации AR1S eEPC.

96____________________________ В.В, Репин, В.Г. Елиферов. Процессный подход к управлению

Рис. 2.38. Пример обработки

Глава 2 Выбор методологии описания бизнес-процессов 97

заявки и нотации AR1S PCD.

X4

98 В.В. Репин,В Г. Елиферов Процессный подход к управлению

2.7.3.

Нотация AR1S Organizational Chart

Нотация ARIS Organizational Chan яа!яется одной ИЗ основных нотаций ARIS и предназначена для построения схем организационной структуры предприя­тия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения пред­приятия в виде иерархической структуры, как показано на рис.

2.39.

Модель строится из объектов Organizational unit, Position, Internal person и др.

Заложенные в нотацию типы связей позволяют отразить различные виды от­ношений между объектами организационной структуры. В представленном на рис. 2.39 примере Предприятие управляется Директором, при этом используется тип связи is Organization Manager for. Иерархия подразделений строится при по­мощи связей типа is composed of. Кроме того, могут быть указаны должности — Position и фамилии реальных сотрудников, их занимающие — Internal person, тип связи occupies.

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

Глава 2 Выбор методологии описания бизнес-процессов_________________________________ 99

Предыдущая78910111213141516171819202122Следующая

Диаграмма VAD и пример ее построения

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

Общая характеристика построения моделей бизнес-процессов в архитектуре ARIS

• Использование подхода «сверху-вниз», т.е.

Бизнес-процесс

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

• Модели создавать с учетом последующих шагов их использования в проекте:

o Организационные изменения

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

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

o Сертификация по ISO 9000:2000

o Внедрение корпоративных информационных систем

• Обучение и поддержка конечных пользователей

• Тиражирование решения на родственных предприятиях

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

Основные определения и объекты диаграммы VAD

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

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

• Эти процессы формируют стоимость продукции и работ, количество и качество выпускаемой продукции и т.д.

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

Объекты диаграммы VAD: Соединение, Звено цепочки добавленного качества, Звено цепочки добавленного качества, Организационная единица, Организационная единица, Тип организационной единицы, Тип организационной единицы, Технический термин, Кластер, Пакет, Продукт/услуга, Услуга, Информационная услуга, Цель, Экземпляр ключевого показателя результативности, Тип прикладной информационной системы, Риск.

Диаграмма VAD и пример ее построения

Сценарий №3.

• Бизнес-процессы компании включают в себя: Основные бизнес-процессы, Обеспечивающие бизнес-процессы, Бизнес-процессы управления.

Рисунок 16. Итоговая модель

• Основные бизнес-процессы включают в себя: Стратегическое планирование, Маркетинг, Разработка технологии, Производство, Продажа.

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

• Основные бизнес-процессы Маркетинга: Изучение рынков и потребителей, Реклама и продвижение товаров, Анализ и оценка маркетинга.

• Основные бизнес-процессы Разработки технологии: Разработка технологии новых продуктов.

• Основные бизнес-процессы Производства: Производство новых продуктов, Производство продуктов на заказ.

• Основные бизнес-процессы Продажи: Расчеты с клиентами.

Рисунок 17. Итоговая модель

---

Date: 2015-09-05; view: 1356; Нарушение авторских прав

Понравилась страница? Лайкни для друзей: