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

Простая блок-схема

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

Задание 1

Рис. 3.3. Простая блок-схема (этап 3)

8. Введите текст в фигуры блок-схемы (см. Рис. 3.4). Для ввода текста в фигуру выполните действия:

9. На вкладке Главная в группе Сервис выберите инструмент Указатель .

• Щелкните фигуру, в которую должен быть введен текст.
• Напечатайте нужный текст.

Примечание:

1. Чтобы увеличить масштаб фигуры, нажмите на клавиатуре комбинацию клавиш + и щелкайте левой клавишей мыши по фигуре, пока не добьетесь нужного масштаба.
2. Чтобы уменьшить масштаб фигуры, нажмите на клавиатуре комбинацию клавиш + и щелкайте правой клавишей мыши по фигуре, пока не добьетесь нужного масштаба.

Рис. 3.4. Простая блок-схема (этап 4)

Нумерация фигур в блок-схеме

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

Задание 2

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

   Для этого:

   • На вкладке Вид в группе Макросы щелкните кнопку со списком Надстройки , выберите группу Дополнительные решения Visio , а в ней команду Нумерация фигур .
   • В открывшемся окне Нумерация фигур укажите параметры
     • на вкладке Общие :
       • Операция — Автонумерация;
       • Применить к — Все фигуры;
       • Начать с — 1;
       • Интервал — 1;
       • Поставьте флажок Продолжить нумерацию фигур при перетаскивании на страницу.
     • На вкладке Дополнительно :
       • Поместить номер — Перед текстом фигуры;
       • Порядок нумерации — Слева направо, сверху вниз;
       • Поставьте флажок Исключать соединительные линии .
     • Щелкните кнопку ОК .
2. Сохраните блок-схему.

Рис. 3.6. Простая блок-схема (этап 6)

Изменение блок-схемы

Добавление фигуры между двумя другими фигурами

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

Удаление фигуры

Для удаления фигуры с блок-схемы выделите данную фигуру и щелкните на клавиатуре.

Перенумерация фигур

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

1. На вкладке Вид в группе Макросы щелкните кнопку Надстройки и выберите в группе Дополнительные решения Visio команду Нумерация фигур .
2. В открывшемся окне Нумерация фигур на вкладке Общие выберите переключатель Перенумеровать в том же порядке , укажите начальный номер для нумерации и щелкните ОК .

Задание 3

1. Измените блок-схему, подготовленную при выполнении задания 2:
   • Удалите фигуру Документ (Отправить заявление).
   • Между фигурами Решение (Заявление оформлено правильно) и Документ (Отправить отказ) поместите фигуруПроцесс (Переслать помощнику по торговой выставке).
   • Добавьте фигуру Процесс (Позвонить участнику выставки по поводу оплаты) ниже фигуры Документ (отправить счет).
   • Перенумеруйте фигуры блок-схемы в том же порядке, начиная с начального номера — 1.
2. Сохраните блок-схему.

Рис. 3.7. Простая блок-схема (этап 7)

Изменение расположения соединенных фигур

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

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

Задание 4

Функциональная блок-схема

Назначение макета Функциональная блок-схема

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

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

Задание 5

Добавление, перемещение, удаление дорожки

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

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

Для перемещения дорожки:

1. Щелкните заголовок дорожки, которую необходимо переместить, чтобы выделить ее. Указатель мыши примет форму значка перемещения.
2. Перетащите дорожку в нужное место.

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

Для удаления дорожки:

1. Щелкните подпись дорожки, которую требуется удалить.
2. Нажмите клавишу на клавиатуре.

Примечание. При удалении дорожки также удаляются все фигуры, содержащиеся на ней.

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

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

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

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

1 – Задайте границы процесса

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

2 – Нарисуйте основные блоки процесса

Расположите основные блоки (подпроцессы, операции) , в том порядке, в котором они выполняются.

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

3 – Добавьте развилки и другие события

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

4 – Обозначьте роли участников процесса

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

По необходимости добавляйте недостающие операции.

5 – Разместите на схеме документы

Документ, это не обязательно официальная бумага с семью подписями. С точки зрения управления бизнес процессами, документ это информация на любом информационном носителе. Электронное письмо, доклад, презентация, СМС – все это документы.

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

6 – Добавьте используемые программы и базы данных

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

7 – Расположите инструменты и материалы

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

8 – Определите показатели эффективности в бизнес-процессе

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

9 – Свяжите полученную схему с другими процессами

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

10 – Проверьте полученную модель бизнес-процесса

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

• С чего начинается и чем заканчивается бизнес-процесс?
• С какими процассми он связан? Чем обменивается?
• Какие операции выполняются? В каком порядке?
• Кто выполняет операции в процессе?
• Какие документы используются и появляются в процессе? В каких операция эти жокументы используются/появляются?
• Какие интсрументы, материалы, ПО и базы данных используются в процессе и в каких операциях?
• Какие показатели эффективности и где именно фиксируются в бизнес-процессе?

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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

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

Введение

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

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

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

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

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

Проблема данной курсовой работы звучит так: насколько практичны в использовании (простоты, наглядны и информативны) схемы, проектируемые в MS Visio.

В качестве объекта выступает бизнес-моделирование.

Предметом обозначим: моделирование бизнес-процессов предприятия, занимающегося оказанием услуг по автоперевозкам, в MS Visio.

Исходя от проблемы, обозначим целью: определить насколько практичны в использовании схемы, проектируемые в MS Visio, на примере транспортной компании (ТК) ООО «ЭкоТранс».

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

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

Ознакомиться с деловой графикой в MS Visio;

Проанализировать бизнес-процессы ТК ООО «ЭкоТранс»

Описать бизнес-процессы ТК ООО «ЭкоТранс» с использованием бизнес-моделирования в Microsoft Visio

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

1. Методологии описания предметной области

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

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

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

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

1.1 Понятие о семействе стандартов IDEF

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

IDEF-методология создавалась в рамках проводимой в США программы компьютеризации промышленности ICAM (Integrated Computer Aided Manufacturing), в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных системах. Отсюда и происходит название данного семейства стандартов - Icam DEFinition - IDEF.

В настоящий момент к семейству IDEF можно отнести следующие стандарты:

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

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

IDEF1X (IDEF1 Extended) - методология построения реляционных структур. IDEF1X относится к типу методологий “сущность-взаимосвязь” (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF2 - методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе.

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

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

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

Наиболее подробно рассмотрим стандарты, которые потребуются при описании бизнес-процессов в данной курсовой работе, это: IDEF0, IDEF3.

Функциональная методика IDEF0.

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

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

a) Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (Рисунок 1.1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:

Верхняя сторона имеет значение "Управление" (Control);

Левая сторона имеет значение "Вход" (Input);

Правая сторона имеет значение "Выход" (Output);

Нижняя сторона имеет значение "Механизм" (Mechanism).

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

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Рисунок 1.1 - Функциональный блок

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

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

Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0» (Рисунок 1.2).

Рисунок 1.2 - Пример контекстной диаграммы

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

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком - Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 - модели. Наглядно принцип декомпозиции представлен на рисунке 1.3. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую “деталь” на входе в функциональный блок “Обработать на токарном станке” не имеет смысла отражать на диаграммах более высоких уровней - это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных “концептуальных” интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение “туннеля” (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из “туннеля”) только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока - приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии - в таком случае, они сначала “погружаются в туннель”, а затем, при необходимости «возвращаются из туннеля».

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

Стандарт документирования технологических процессов IDEF3.

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

Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

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

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

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

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

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы, относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта и его Трансформаций в Процессе (Object State Transition Network, OSTN).

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

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

На рисунке 1.4 изображена диаграмма PFDD, являющаяся графическим отображением сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса.

Рисунок 1.4 - Диаграмма PFDD сценария обработки детали

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация возможных типов перекрестков приведена в таблице 1.

Таблица 1 - Классификация типов перекрестков

Сценарий, отображаемый на диаграмме, можно описать в следующем виде:

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

Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB «Окрасить Деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рисунке 1.4, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1», «1.2» и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.

Если диаграммы PFDD технологический процесс «С точки зрения наблюдателя», то другой класс диаграмм IDEF3 - OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». На рисунке 1.5 представлено отображение процесса окраски с точки зрения OSTN диаграммы. «Состояния объекта» (в нашем случае детали) и «Изменение состояния» являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

Рисунок 1.5 - Процесс окраски с точки зрения OSTN диаграммы

2. Инструменты моделирования бизнес-процессов

Для описания бизнес-процессов существует множество инструментальных средств BPWin, ERWin, PowerDesigner, Business Studio, ELMA BPM, Visual Paradigm и другие.

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

2.1 Технические особенности. Хранение данных

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

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

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

Рисунок 2.1 - Набор готовых шаблонов MS Visio

2.2 Поддерживаемые методологии и нотации

Поскольку набор символов и шаблонов Visio может быть произвольно расширен и сам продукт не предполагает глобальных ограничений на возможности применения символов и связей между ними, описание бизнес-процессов с помощью Visio формально может быть осуществлено в рамках практически любой методологии. При этом в комплекте поставки продукта в любой редакции (Standard, Professional) есть набор шаблонов моделей для наиболее распространенных нотаций, таких как диаграммы потоков данных, диаграммы цепочки добавленного качества, диаграммы типа Event-driven Process Chain, IDEF0, SwimLane, а также шаблоны для моделирования оргструктур компаний.

3. Анализ предметной области ООО «ЭкоТранс»

Транспортная компания ООО «ЭкоТранс» основана 2008 году. Первые услуги по автоперевозке грузов были оказаны потребителям, ведущим бизнес в Орловской области. Многие крупнейшие предприятия региона заключили с компанией долгосрочные контракты на грузопассажирские перевозки. Для ООО «ЭкоТранс» услуги грузоперевозки (Орловская область) внутри региона стали успешным стартом для дальнейшего развития. Сегодня география транспортных услуг шагнула далеко за пределы родной области. Расширение географии своей деятельности потребовало увеличения количества современного грузового автотранспорта, поэтому для доставки грузов теперь используется не только свой собственный обширный автопарк, но и автомобили партнёров.

ООО «ЭкоТранс» не только обеспечивает грузоперевозки по России, но и предоставляет клиентам сопутствующие услуги, такие как: экспедирование и страховка груза.

a) Транспортное экспедирование. Данная услуга позволяет клиенту не только облегчить процесс грузоперевозки, но и удешевить его. Транспортное экспедирование грузов состоит из нескольких видов услуг:

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

Подбор транспортного средства. Учитывается вес груза, его габариты и маршрут;

Планирование маршрута. Выбирается самая скоростная и безопасная схема движения;

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

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

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

3.1 Организационная структура ООО «ЭкоТранс»

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

3.2 Бизнес-процесс «Перевозка груза»

Бизнес-процесс «Перевозка груза» включает в себя:

1 Получение заявки. Заказчик отправляет заявку диспетчеру, а диспетчер её принимает.

2 Заключение договора. Между заказчиком и директором заключается договор на основании, которого осуществляется перевозка.

3 Проверка на наличие договора. Диспетчер проверят наличие договора.

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

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

6 Прохождение медицинского осмотра. Водитель проходит медицинский осмотр.

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

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

9 Отметка об исправности ТС в путевом листе. Водитель ставит отметку об осмотре ТС в путевом листе.

10 Осмотр ТС. Водитель предоставляет транспортное средство для осмотра механику. Механик осматривает транспортное средство. Проверяет: герметичность и действие тормозных систем, систем питания, охлаждения, системы выпуска отработанных газов; исправность рулевого управления, внешних световых приборов, стеклоочистителей; крепление колес; наличие медицинской аптечки, огнетушителя, знака аварийной остановки.

11 Отметка об исправности ТС в путевом листе. Механик ставит отметку об исправности ТС в путевом листе.

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

13 Получение документов. Водитель забирает транспортные накладные у заказчика.

14 Возвращение с линии. Водитель с линии возвращается в гараж.

15 Осмотр ТС. При возвращении с линии водитель предоставляет транспортное средство для осмотра механику.

16 Отметка о состоянии ТС в путевом листе. Механик ставит отметку о состоянии ТС в путевом листе.

17 Передача документов в бухгалтерию. Водитель передает транспортные накладные в бухгалтерию.

18 Выписка документов бухгалтерией. Бухгалтерия выписывает документы: акт выполненных работ, счет фактура, счет на оплату.

19 Оплата услуги заказчиком. Бухгалтерия передает выписанные документы для оплаты заказчику. Заказчик оплачивает оказанную услугу.

3.3 ИТ-инфраструктура

информационный сетевой моделирование

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

ЛВС - локальная вычислительная сеть (LAN, local area network).

В организации ООО «ЭкоТранс» ЛВС выполнена по топологии «звезда».

В ИС объекта обследования используется служба каталогов корпорации Microsoft - Active Directory. Данная служба используется для регулирования групповых политик домена. Домены имеют иерархическую структуру.

В аппаратной части ИС объекта: 2 серверов; 16 рабочих станций.

Программное обеспечение ООО "ЭкоТранс": операционная система Windows XP Servise Pack 2/3, MS Office 2007, антивирусное программное обеспечение - Panda Antivirus Platinum, Налогоплательщик ЮЛ, 1С: Бухгалтерия, 1 С: Зарплата и кадры, ПП "Справочник сертификатов",СКЗИ Крипто Про CSP, ПП "СТЭК-Траст". АРМ "ТРАСТ-Клиент", Система "СТЭК-Траст". АРМ Страхователя, Утилита для ФСС, Документы ПУ 5, CheckXML, Canon Solution Menu, ABBYY FineReader Professional Edition, Total Commander, WinDjView, Adobe Acrobat Professional, WinRAR и другие.

4. Описание бизнес-процессов ТК ООО «ЭкоТранс» с использованием бизнес-моделирования в Microsoft Visio

4.1 Построение модели в нотации IDEF0 и ее декомпозиция

Создадим модель ТК ООО «ЭкоТранс» по методологии IDEF0. Сначала построим контекстную диаграмму бизнес-процесса «Перевозка груза» (Рисунок 4.1). Согласно нотации IDEF0 назовём этот функциональный блок «Перевезти груз».

Рисунок 4.1 - Контекстная диаграмма процесса «Перевозка груза»

Затем разобьём бизнес-процесс «Перевозка груза» на составляющие: «Обработка заявки», «Заключение договора», «Подготовка к перевозке груза», «Оформление документов, необходимых для перевозки груза», «Осуществление перевозки груза». И соответствующим образом декомпозируем функциональный блок «Перевезти груз» (Рисунок 4.2).

Рисунок 4.2 - Диаграмма декомпозиции процесса «Перевозка груза»

Подробнее рассмотрим бизнес-процессы: «Обработка заявки» (Рисунок 4.3); «Подготовка к перевозке груза» (Рисунок 4.4); «Оформление документов, необходимых для перевозки груза» (Рисунок 4.5); «Осуществление перевозки груза» (Рисунок 4.6).

Рисунок 4.3 - Диаграмма декомпозиции процесса «Обработка заявки»

Рисунок 4.4 - Диаграмма декомпозиции процесса «Подготовка к перевозке груза»

Рисунок 4.5 - Диаграмма декомпозиции процесса «Оформление документов, необходимых для перевозки груза»

Рисунок 4.6 - Диаграмма декомпозиции процесса «Осуществление перевозки груза»

4.2 тПостроение модели в нотации IDEF3

Теперь построим модель ТК ООО «ЭкоТранс» используя методологию IDEF3. Декомпозиция процесса «Перевозка груза» представлена на рисунке 4.7

Рисунок 4.7 - Диаграмма PFDD декомпозиции процесса «Перевозка груза»

Символ «», означает «Исключающее ИЛИ», он же «XOR» (Exclusive OR).

Заключение

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

Описание бизнес-процессов возможно различными способами: текстовый, табличный, графический. Для их описания существует множество методологий (IDEF0, IDEF3, DFD, WORKFLOW, UML, ARIS и другие) и инструментальных средств (BPWin, ERWin, PowerDesigner и другие).

Для описания бизнес-процессов ТК ООО «ЭкоТранс» в графической форме, были выбраны методологии моделирования бизнес-процессов IDEF0, IDEF3. Моделирование осуществлялось посредством продукта корпорации Майкрософт - Visio. Данная программа имеет готовый шаблон для моделирования в нотации IDEF0, а для IDEF3 пришлось создать свой набор элементов. Что подтверждает малую функциональность, но, в тоже время, отсутствие глобальных ограничений в процессе проектирования.

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

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

Литература

1 Голичев В.Д., Голичева Н.Д., Гусарова О.М. и др. Актуальные вопросы экономики и управления в условиях модернизации. Коллективная монография. - Смоленск: Смолгортипография, 2014. - 212с.

2 Гусарова О.М. Моделирование результатов бизнеса в менеджменте организации // Перспективы развития науки и образования. - Тамбов: Бизнес-Наука-Общество, 2014. - с. 42-43.

Размещено на Allbest.ru

Подобные документы

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

практическая работа , добавлен 14.02.2012


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

реферат , добавлен 14.12.2011


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

курсовая работа , добавлен 19.06.2015


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

контрольная работа , добавлен 19.12.2010


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

реферат , добавлен 29.04.2009


Основні визначення та опис UML. Опис основних компонентів, використаних у Microsoft Visio. Створення діаграми класів в Microsoft Visio 2010. Використання побудованої моделі при модифікаціях системи. Структура системи, її класи, їх атрибути та оператори.

практическая работа , добавлен 07.05.2014


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

дипломная работа , добавлен 21.05.2015


Управление дистанционной настройкой и установкой ПО. История развития VMware ThinApp. Создание пакета автоматической установки Microsoft Office Visio Professional 2007. Анализ программного обеспечения для него. Тестирование полученного msi-пакета.

курсовая работа , добавлен 14.03.2013


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

дипломная работа , добавлен 20.07.2014


Среда Microsoft Visio: понятие, основные функции. Функция автосоединения в Office Visio 2007. Логарифмическая функция правдоподобия. График вероятностей отказа версий программного обеспечения. Визуальное моделирование в UML. Общий вид диаграммы классов.

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

Зачем автоматизировать описание бизнес-процессов

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

Можно выделить пять основных групп задач:

-разработка внутрифирменных положений и должностных инструкций. Формализованные описания бизнес-процессов дают ответ на вопрос, как «движется» тот или иной документ в компании, какие функции выполняют конкретные сотрудники и подразделения. На основе этих данных могут быть сформированы положения по структурным подразделениям, должностные инструкции, положения по управлению и документообороту или регламенты бизнес-процессов. При этом некоторые системы (например, ARIS, ЕМ Tool Kit) позволяют формировать подобные документы автоматически, после того как построены модели бизнес-процессов;

- попроцессное калькулирование и планирование. Для точного расчета стоимости тех или иных видов деятельности в компании, а также правильного определения себестоимости выпускаемой продукции используется методология попроцессного калькулирования (Activity based costing) 1 , в основе которой должно лежать формализованное описание бизнес-процессов. По мнению авторов статьи, технологию Activity based costing можно реализовать и в Excel, однако если в бизнес-процессах компании произойдут какие-либо изменения (например, в последовательности действий сотрудников, штатном расписании или заработной плате), построенную модель придется полностью переделывать. В то время как специализированная система позволит с минимальными затратами труда учесть подобные перемены при расчете стоимости бизнес-процессов и себестоимости продуктов или услуг методом Activity based costing. Аналогичная ситуация складывается с использованием бюджетирования на основе действий (Activity based budgeting) 2 . Серьезным аргументом в пользу необходимости описания бизнес-процессов является то, что оно позволяет проследить, где и как создается поток ценности для клиентов компании, и устранить источники неоправданных затрат;

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

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

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

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

Личный опыт

Алексей Прошин, директор по инструментальным средствам описания бизнес-процессов компании «ФОРС - Центр разработки» (Москва) Одна из задач, которую удается решить, описав бизнес-процессы, -успешное внедрение информационной системы. Главная причина неудачной реализации IT-проектов заключается в несовпадении представлений об IT-технологиях у людей, занимающихся бизнесом, и тех, кто реализует их на практике. Чтобы этого избежать, все должны говорить на одном языке, понятном и менеджерам высшего звена, включая финансовых директоров. Такой язык можно создать при помощи инструментальных средств моделирования и анализа бизнес-процессов. На их основе строятся диаграммы, графические модели, шаг за шагом демонстрирующие, как построены в компании бизнес-процессы, как организовано взаимодействие между людьми и что необходимо изменить. Особо хочется подчеркнуть, что главная цель описания бизнес-процессов - понимание и оптимизация взаимодействия между всеми составляющими компании, вовлеченными в решение задач бизнеса. Необходимость же автоматизации тех или иных операций - это вопрос, ответ на который может быть получен, только когда есть четкое представление об их месте и назначении в общей картине бизнеса.

Критерии выбора

Выбор системы будет зависеть от задач, стоящих перед компанией, а также ее финансовых возможностей. Стоимость программных средств на пять рабочих мест может составлять от 3 тыс. до 30 тыс. долл. США в зависимости от функциональных возможностей. Однако, по мнению авторов, при выборе программного обеспечения помимо стоимости основными критериями являются: методология описания бизнес-процессов, возможность использования атрибутов и автоматического обновления моделей, интеграция с учетными или ERP-системами.

Методологии описания бизнес-процессов

Сегодня существует два основных подхода к графическому представлению бизнес-процессов: методология SADT/IDEF0 (Structured Analysis and Design Technique/ ICAM DEFinition) и ARIS (Architecture of Integrated Information Systems). С точки зрения пользователя, бизнес-процессы в стандарте IDEF0 проще и понятнее (см. рис. 1). Схемы бизнес-процессов, составленные по методологии ARIS, будут содержать больше данных, однако они достаточно сложны для восприятия пользователями, которые не имеют специальных навыков работы с ними. Поэтому, если предприятие приобретает программное средство описания бизнес-процессов для разработки регламентов, положений, должностных инструкций и анализа бизнес-процессов, можно рекомендовать использовать системы, поддерживающие стандарты IDEFO. Для оценки стоимости бизнес-процессов, разработки технического задания на внедрение ERP-систем, создания системы внутреннего контроля и управления рисками, а также разработки сбалансированной системы показателей больше подойдет методология ARIS. На рис. 2 приведен фрагмент ARIS-модели бизнес-процесса «Предоставление кредита» в графическом представлении (нотации) еЕРС (extended Event-driven Process Chain).

Использование атрибутов

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

Автоматическое обновление моделей бизнес-процессов

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

Интеграция с другими системами

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

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

Программные системы, представленные на рынке

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

MS Visio (Microsoft);

ЕМ Tool Kit (ИК «Ориентсофт»);

ARIS (IDS Scheer AG);

Интегрированные системы (BAAN/Dem, Oracle Designer).

MS Visio

Визуальное средство MS Visio - это приложение из семейства Microsoft Office 2000. Оно не является специализированным программным обеспечением для описания бизнес-процессов, поэтому его функциональные возможности весьма ограниченны и не позволяют проводить глубокий анализ и оценку моделей, разрабатывать какие-либо регламентирующие документы, а также автоматически вносить изменения в модели. MS Visio представляет собой нетрадиционный и очень гибкий графический редактор, который обеспечивает быстрое наглядное представление небольших по объему и обобщенных по содержанию моделей. Стоимость одной лицензии варьируется от 225 долл. США за стандартную конфигурацию до 550 долл. США за профессиональную.

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

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

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

ЕМ Tool Kit

ЕМ Tool Kit (Enterprise Modeling Tool Kit) 4 позволяет описывать бизнес-процессы в формате IDEF0, формировать нормативные документы, регламентирующие деятельность компании (регламенты документооборота, должностные инструкции и др.), а также проводить аудит организационных систем, например системы менеджмента качества, внутреннего контроля и т.д. Средняя стоимость системы на пять рабочих мест составляет около 3 тыс. долл. США.

Преимущества. Система позволяет создавать вложенные модели бизнес-процессов (см. рис. 3 на с. 92), автоматически формировать отчеты и определять атрибуты для действий, выполняемых в ходе бизнес-процесса. Нужно отметить, что на российском рынке программных систем представлены модули, позволяющие автоматически загружать необходимые атрибуты из программных продуктов, разработанных фирмой «1С». Благодаря использованию атрибутов ЕМ Tool Kit дает возможность оценить стоимость и продолжительность того или иного бизнес-процесса. Возможна организация одновременной работы нескольких пользователей.

Недостатки. Среди наиболее существенных недостатков системы можно отметить отсутствие операторов «и», «или», что затрудняет описание логики бизнес-процессов. Стандартные инструменты ЕМ Tool Kit не позволяют реализовать расширенную методологию попроцессного калькулирования и расчет полной себестоимости выпускаемой продукции, предоставляемых услуг или других объектов затрат.

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

Аналогом ЕМ Tool Kit является система BPwin, которая обладает большими возможностями в части поддерживаемых методологий (IDEFO, IDEF1X, IDEF3) и формирования отчетов. Однако, по мнению авторов, BPwin больше подойдет специалистам 1Т-службы, так как в первую очередь ориентирована на решение задач, связанных с внедрением корпоративных информационных систем. /

Личный опыт

Олег Костиков, директор по экономике ОАО «Балтийский завод» (Санкт-Петербург) Состояние дел на ОАО «Балтийский завод» на момент начала внедрения корпоративной информационной системы (КИС) требовало глубокого анализа структуры предприятия, функций различных подразделений, документооборота для понимания ситуации «как есть» и выявления проблем и путей их решения

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

ARIS

Платформа ARIS компании IDS Scheer AG является специализированным набором инструментов для структурированного описания и анализа бизнес-процессов. В состав системы входят функциональные модули для:

Проектирования и оптимизации бизнес-процессов (ARIS Easy Design, ARIS Toolset, ARIS Business Design, ARIS Business Architect, ARIS Business Server);

Динамического анализа и оптимизации бизнес-процессов (ARIS Simulation);

Разработки и внедрения системы менеджмента качества (ARIS Quality Management Scout);

Мониторинга и контроля эффективности бизнес-процессов (ARIS Process Perfomance Manager);

Управления процедурами, обеспечивающими работу системы внутреннего контроля за формированием финансовой отчетности (ARIS Audit manager);

Разработки, внедрения и поддержания системы управления операционными рисками (ARIS Process Risk Scout);

Создания системы попроцессного калькулирования - Activity based costing (ARIS Process Cost Analyzer);

Проектирования системы сбалансированных показателей (ARIS BSC) и др.

В зависимости от приобретаемых модулей и количества рабочих мест стоимость системы может составлять от 9 тыс. до 13 тыс. евро. В ARIS существует более 130 различных способов графического представления моделей деятельности организации. Из них для финансового директора будут полезны модели:

Организационной структуры (Organizational Chart);

Цепочки добавленной стоимости (Value Added Chain Diagram);

Расширенной событийно-ориентированной цепочки процесса (extended Event Driven Process Chain).

Преимущества. ARIS-платформа обладает большим набором функций. В ней предусмотрена возможность анализа построенных моделей бизнес-процессов, определения «узких» мест и оптимизации бизнес-процессов на основе анализа «что-если». Иными словами, пользователь может изменять те или иные бизнес-процессы, к примеру перераспределить полномочия сотрудников и оценить, насколько увеличится время на выполнение тех или иных операций или стоимость работ. Модуль ARIS Process Cost Analyzer позволяет реализовать традиционную методологию Activity based costing для определения стоимости бизнес-процессов, а результаты использовать в модуле стратегического управления предприятием (ARIS BSC). Применяя дополнительные модули и внутренний язык программирования, пользователь может сформировать любые регламенты и положения, а также управлять рисками компании, создать систему менеджмента качества и внутреннего контроля.

Недостатки. К недостаткам можно отнести достаточно высокую стоимость программного обеспечения. Графическое представление моделей бизнес-процессов достаточно сложное для восприятия неподготовленных пользователей. Надо также отметить, что для использования, к примеру, ЕМ Tool Kit требуется пройти учебный курс длительностью два-три дня, а для освоения основных функциональных возможностей ARIS придется посетить несколько специализированных учебных курсов продолжительностью от пяти до пятнадцати дней. Кроме того, система содержит большое количество функций, которые, возможно, никогда не будут востребованы. На практике используется не более 15% всех типов моделей, которые могут быть сформированы.

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

Рекомендации. Система подойдет крупным компаниям и холдингам, планирующим внедрять дорогостоящие ERP-системы, проводить сертификацию в соответствии со стандартами ISO 9001:2000, внедрять сбалансированную систему показателей и методику попроцессного калькулирования для бизнес-процессов.

Интегрированные системы

Сегодня многие ERP-системы включают модули, позволяющие составить описание бизнес-процессов. В качестве примера можно привести Oracle Designer и BAAN DEM.

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

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

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

От простого к сложному

Выбор программных инструментальных средств для моделирования бизнес-процессов зависит в первую очередь от стратегии компании, масштабов деятельности, уровня зрелости процессов и технологий управления, а также от существующего уровня автоматизации. По мере развития бизнеса будут усложняться бизнес-процессы и соответственно возрастут требования к инструментам, позволяющим их документировать. По мнению авторов, компаниям можно рекомендовать начинать работу по описанию бизнес-процессов при помощи MS Visio или ЕМ Tool Kit, а с развитием бизнеса и повышением уровня автоматизации постепенно переходить на интегрированные платформы. /

Личный опыт

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

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

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

Создание схемы в Visio

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

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

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

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

Привязка процесса к данным в SharePoint Designer

После доработки рабочего процесса, переходим в настройки. Там указываем необходимое условие запуска (запускать автоматически при создании элемента), а так же ставим галочку у опции «Show workflow visualization on status page» (требуется активировать возможности SharePoint Server Enterprise на коллекции сайтов). Это именно то, ради чего стоит создавать рабочие процессы именно в Visio. Теперь перейдем на сайт, создадим любой элемент в списке «Входящих», перейдем в список задач и завершим задачу, а затем откроем окно статуса рабочего процесса:

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

Заключение

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

• Требуется SharePoint Enterprise Server и Visio Premium