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

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

Создание бизнес-процессов

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

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

Коллективная работа

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

Модуль обладает принципиально новой архитектурой и содержит обширный и значимый функционал. Дизайнер бизнес-процессов включен только в «старшие» редакции «1С-Битрикс: Управление сайтом»: Бизнес и Веб-кластер .

• Tutorial

Эту статью я написал в продолжение статьи о BPM-системах . И здесь я хочу рассказать о принципах работы BPMS на примере конкретной системы - Bizagi. Я постараюсь пояснить, как происходит процесс моделирования, разработки и исполнения бизнес-процесса в этой системе на практическом примере.

Bizagi: Model. Build. Run

Bizagi - это BPM-система, разработанная одноименной компанией, и направленная на моделирование, исполнение, автоматизацию и анализ бизнес-процессов. Система Bizagi включает 3 модуля для полноценной настройки процессов:

• Modeler - полнофункциональная среда моделирования процессов в нотации BPMN;
• Studio - среда разработки бизнес-процессов;
• Engine - среда исполнения процессов, которая доступна пользователям в любом браузере с любого устройства.

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

Modeler

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

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

Вы можете использовать один из трех способов моделирования бизнес-процесса:

• New Process - создать свой новый бизнес-процесс;
• Import Process - импортировать бизнес-процесс;
• Process Xchange - выбрать готовую модель из базы бизнес-процессов, предложенной компанией Bizagi. Выбрав шаблон, вы можете доработать его под реалии своего бизнеса. Все представленные модели написаны на английском языке.

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

Моделирование бизнес-процесса производится в формате BPMN 2.0. Этот формат несколько отличается от известного многим BPMN 2.0, я с этим столкнулся на практике. Некоторых возможностей, которые подразумеваются в BPMN 2.0 и в некоторых других программах, созданных для работы исключительно с моделированием, в формате Bizagi вы не найдете. Например, здесь нет так называемой “внешней сущности”. Зато в Bizagi имеются собственные разработки, которых нет в других системах, например, Mailstone - промежуточный этап.

Созданные в Modeler карты бизнес-процессов можно как “расшаривать” на портале Bizagi, так и использовать коллаборатив, то есть несколько сотрудников могут выполнять совместную работу, что очень удобно.

Мodeler имеет русскоязычный вариант интерфейса, в отличие от двух других модулей.

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

Studio

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

Хочу отметить, что Modeler и Studio бесплатны. В базовый пакет Studio включены до 20 тестовых пользователей.

Engine

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

Лицензии Engine платные. Бесплатен только тестовый режим.

В Engine предусмотрено два вида лицензии:

• постоянная лицензия;
• лицензия на год.

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

Engine предполагает пошаговое исполнение разработанного бизнес-процесса с учетом всех прописанных в Studio условий.

Без модуля Engine вы не сможете полноценно работать в системе и исполнять прописанные бизнес-процессы.

Как работает Bizagi

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

1. Моделирование

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

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

Мы моделируем схему бизнес-процесса Payment Request: определяем начало процесса, события, оповещения, бизнес-правила и конец бизнес-процесса.

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

• Отказать;
• Одобрить.

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

Графическая карта бизнес-процесса выглядит так:

2. Разработка структуры данных

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

В нашем примере мы должны разработать три сущности (Entity):

• Запрос на оплату счета;
• Контрагент (поставщик, которому необходимо оплатить счет);
• Причина отказа.

Для каждой из этих сущностей необходимо прописать атрибуты (поля), которые будут доступны для заполнения. Атрибуты делятся на:

• Предустановленные (их очень много) - атрибуты, которые предлагает сама система;
• Пользовательские - те, которые пользователь создает вручную.

На скриншоте видно, какие атрибуты прописаны для каждой сущности.

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

3. Создание форм (пользовательского интерфейса)

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

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

Форма - это то, с чем впоследствии будет работать пользователь.

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

В нашем примере необходимо разработать 3 формы:

• Создания запроса на оплату;
• Проверка запроса на оплату;
• Формирования печатной формы.

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

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

Теперь рассмотрим сам процесс создания формы (например, Создания запроса на оплату).

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

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

Здесь мы видим поля:

• Срок оплаты;
• Сумма счета;
• Номер счета;
• Контрагент;
• Присоединенный файл (возможно прикрепить счет на оплату).

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

Макет формы можно разделить:

• на три равные части (33%-34%-33%);
• на две равные (50%-50%) части;
• на две неравные (70%-30%, 30%-70%) части;
• оставить макет неделимым (Full layout).

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

Поле Причина отказа становится видным для руководителя, только если в поле Одобрено он выбрал вариант No. То есть видимость полей можно настроить не только в формате Видно-Не видно, но и в зависимости от каких либо условий. Это условие выглядит так
PaymentRequestApproved is equal to false

Если Руководитель установил вариант Yes, становится доступной функция распечатать запрос на оплату. Для него уже никакие функции недоступны, кроме Generate template.

4. Определение бизнес-правил

В Bizagi предусмотрено три этапа установки бизнес-правил:

• Define Expressions - предполагает обработку условий
• Activity Actions (Events) - предполагает обработку событий
• Perfomance - предполагает обработку пользователей, работающих на том или ином этапе бизнес-процесса.

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

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

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

Activity Actions
На этапе Activity Actions мы можем прописать предопределенные поля. Предопределенные поля могут заполняться в трех случаях (на выбор):

• при открытии формы;
• при сохранении;
• при выходе из формы.

Например, на этапе Создания запроса на оплату, мы можем указать, что при открытии формы у нас есть два предопределенных поля:

• Дата - здесь мы указываем, что дата запроса автоматически заполняется текущей датой DateTime.Today
• Автор (сотрудник) - здесь прописываем, что тот, кто инициировал документ, автоматически становится его автором Me.Case.Creator.Id

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

• На этапе Создания сделки работает сотрудник, создавший эту сделку. User Id Equal Case Creator
• На этапе Проверки запроса работает Руководитель того, кто создал документ. User Id Equals CurrentAssigneeBoss

5. Описание правил оповещения
После того, как мы прописали, как работают бизнес-правила, мы описываем правила оповещения.

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

Оповещения бывают двух видов:

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

Использовать можно оба вида оповещений одновременно.

В нашем бизнес-процессе при смене этапа (Одобрен или Не одобрен запрос на оплату), Сотруднику отправляется сообщение о том, что счет одобрен или требует уточнения.

6. Создание печатной формы

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

В системе можно создавать, так называемый, document templates. Для печатной формы запроса можно использовать word, excel или простой текст. Мы создали форму, которую должен распечатать тот, на ком заканчивается процесс, и поставить свою подпись. В этой печатной форме видна вся основная информация по запросу:

• Дата создания;
• Пользователь;
• Номер счета;
• Дата счета;
• Сумма счета;
• Основание;
• Подпись ответственного лица.

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

Исполнение бизнес-процесса

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

Рассмотрим, как происходит исполнение созданного нами бизнес-процесса:

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

1. Пользователь заполняет необходимые поля (поле Дата и Автор заполнены автоматически). Пользователь прикрепляет счет на оплату.

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

Если руководитель выбрал Yes:
4. Появляется кнопка Generate document для распечатки запроса. Руководитель выводит печатную форму и подписывает ее.
5. Сотрудник, инициировавший запрос, получает уведомление об одобрении счета

Если руководитель выбрал No:
4. Сотрудник, инициировавший запрос, получает уведомление об отказе в оплате счета.
Бизнес-процесс исполнен.

Еще несколько слов о Bizagi

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

В системе предусмотрена интеграция: возможно “снаружи” подключаться к Bizagi, либо из самой Bizagi подключаться к другим программам посредством API. Она использует web-сервисы и SOAP.

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

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

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

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

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

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

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

Возможно ваши старые бизнес-процессы в визуальном редакторе Дизайнера Бизнес-Процессов выглядят как-то так:

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

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

Новый модуль Бизнес-Процессов позволяет связать последний РЕЗУЛЬТАТ с первыми ВХОДНЫМИ ДАННЫМИ. Таким образом вы можете создать бесконечно повторяющийся Бизнес-Процесс!

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

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

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

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

Министерство образования Российской Федерации

Новосибирский Государственный Педагогический Университет

Факультет Технологии и Предпринимательства

Специальность «Информационный сервис»

КУРСОВАЯ РАБОТА

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

Выполнил: Студент группы ИС-1

Кудрявцев А. В.

Проверил:

Тиковенко Д. Н.

г. Новосибирск

Введение

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

1.2.3 Методология IDEF0

1.2.4 Методология IDEF3

1.2.5 Методология BAAN

3. Моделирование Бизнес-процессов дизайн-студии

3.1 Базовый блок

3.4 Производство

3.6 Отгрузка и получение

3.7 Складирование

Заключение

Библиографический список

Введение

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

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

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

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

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

Для проведения анализа и совершенствования деятельности компании необходимо построить и начинать использовать ее бизнес-модель.

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

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

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

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

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

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

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

1.1 Подходы к описанию бизнес-процессов

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

Вертикальное описание

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

Рисунок 1.1 - Описание организации

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

Горизонтальное описание

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

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

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

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

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

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

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

Способы описания бизнес-процессов, представлены рисунком 1.2 .

Рисунок 1.2- Способы описания бизнес-процессов

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

Описание окружения бизнес-процесса

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

Рисунок 1.3 - Схема окружения бизнес-процесса

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

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

Таблица 1.1 - Характеристики первичных и вторичных входов и выходов бизнес-процессов

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

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

1.2 Внутренняя структура бизнес-процесса

моделирование дизайнерский программный информационный

1.2.1 Методология DFD - верхний уровень

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

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

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

Рисунок 1.3 - Диаграмма потоков данных - DFD

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

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

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

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

Рисунок 1.4 - Разработка сети бизнес-процессов

1.2.2 Методология WFD - нижний уровень

В свою очередь стандарт WFD расшифровывается как Work Flow Diagram и представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня. У диаграммы потоков работ имеются и другое название - диаграмма алгоритмов.

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

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

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

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

1.2.3 Методология IDEF0

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

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

В стандарте IDEF0 c помощью входа показывают объекты - информационные и материальные потоки, которые преобразуются в бизнес-процессе. С помощью управления показывают объекты - материальные и информационные потоки, которые не преобразуются в процессе, но нужны для его выполнения. С помощью механизмов стали показывать механизмы, при помощи которых бизнес-процесс реализуется: технические средства, люди, информационные системы и т.д. Стандарт описания процессов IDEF изображен на рисунке 1.6 . Выход бизнес-процесса, описанного в стандарте IDEF0 полностью соответствует по смыслу выходу процесса, описанному при помощи DFD-схемы .

Четыре типа объектов, применяемых для описания входов и выходов в стандарте IDEF0, в английском варианте образуют сокращение ICOM и на схеме IDEF0 размещаются в строго отведенных местах относительно работ, которые называются функциональными блоками в соответствии с таблицей 2

Таблица 2. Название и размещение входов и выходов в стандарте IDEF0

Рисунок 1.6 - Стандарт описания бизнес-процесса IDEF0

Стандарт IDEF0 целесообразно использовать в проектах по описанию и оптимизации локальных бизнес-процессов, в небольших проектах в которых больше участвуют и принимают решения специалисты предметных областей, а руководители высшего уровня привлекаются для принятия решений по минимуму. На рисунке 1.8 приведена диаграмма IDEF0 верхнего уровня бизнес-процесса "Увольнение сотрудника"

Рисунок 1.8 - Диаграмма IDEF0 верхнего уровня бизнес-процесса "Увольнение сотрудника"

1.2.4 Методология IDEF3

Стандарт IDEF0, который был рассмотрен ранее является развитием классического DFD - подхода и предназначен для описания бизнес-процессов верхнего уровня. Для описания временной последовательности и алгоритмов выполнения работ стандарт IDEF0 не подходит. Для решения этой задачи стандарт IDEF0 получил дальнейшее развитие, в результате чего был разработан стандарт IDEF3 (рис. 1.9) , который входит в семейство стандартов IDEF .

Рисунок 1.9 - Схема бизнес-процесса в стандарте IDEF3.

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

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

Перекресток "Исключающий ИЛИ" обозначает, что после завершения работы "A", начинает выполняться только одна из трех расположенных параллельно работ B, С или D в зависимости от условий 1, 2 и 3. Перекресток "И" обозначает, что после завершения работы "A", начинают выполняться одновременно три параллельно расположенные работы B, С и D. Перекресток "ИЛИ" обозначает, что после завершения работы "A", может запуститься любая комбинация трех параллельно расположенных работ B, С и D. Например может запуститься только одна из них, могут запуститься три работы, а также могут запуститься двойные комбинации В и С, либо C и D, либо B и D. Перекресток "Исключающий ИЛИ" является самым неопределенным, так как предполагает несколько возможных сценариев реализации бизнес-процесса и применяется для описания слабо формализованных ситуаций.

Таблица 3 - Типы связей между работами в стандарте IDEF3

Перекрестки "И" и "ИЛИ" подразделяются еще на два подтипа - синхронные и асинхронные. Перекрестки синхронного типа обозначают, что работы В, С и D запускаются одновременно после завершения работы A. Перекрестки асинхронного типа требований к одновременности не предъявляют .

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

1.2.5 Методология BAAN

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

Таблица 4 - Модели методологии BAAN

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

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

Рисунок 1.10 - Модель метаструктуры предприятия - ESM / BAAN.

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

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

2. Бизнес-процессы в дизайнерской деятельности

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

В этой работе будет рассмотрен стандарт из семейства IDEF ((ICAM Definition) - IDEF0. Для работы по данной методологии, нам потребуется инструментальная база - Computer Associates BPwin 4.0. IDEF0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции. Мы, рассмотрим лишь общую функциональную модель производства продукции, но не будем затрагивать такие вещи, как: отдел кадров, бухгалтерию и иных возможных структур не принимающих участия в прямом производстве, также как и управленческие начала, мы не берем в расчет. (с вытекающими отсюда функциональными системами и информационными потоками связывающих эти объекты).

3. Моделирование бизнес-процессов дизайн-студии

3.1 Базовый блок

Рисунок 3.1 - Базовый блок, с входами и выходами

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

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

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

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

Изделие укомплектовывается оборудованием (электронная начинка) и тестируется. Если все декларированные работы произведены, товар упаковывается и пересылается на склад;

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

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

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

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

Рисунок 3.3 - Дерево узлов

3.3 Отдел по работе с клиентами

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

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

Рисунок 3.4 - Отдел по работе с клиентами

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

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

Примечание:

*На производстве, после гибки будущих деталей, информация направляется в отдел по «Работе с клиентами», дизайнеру, перед окраской изделия. Для уточнения цвета, фактуры и качества покрытия у клиента. Аналогичным образом происходит после окраски и завершающих работ, все ли устраивает клиента и можем ли мы двигаться дальше. На рисунке 3.2 видно, что выходящая стрелка из “Производство», уходит на «Отдел по работе с клиентами» заходящую сверху и выступающую в роли управления отдельного участка бизнес-процесса;

*Еще одна входящая стрелка «Результаты» играет туже роль, что и «Корректировка заказа», на рисунке 3.2 видно, что выходящая стрелка из «Сборка изделия, тестирование», уходит на «Отдел по работе с клиентами» заходящую сверху и выступающую в роли управления отдельного участка бизнес-процесса;

*Стрелка «Отчет» выходящая из функционального блока «Отгрузка и получение, оповещает о завершении работ.

3.4 Производство

Рисунок 3.5 - Производство

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

«Корректировка заказа» см. раздел 3.3, примечание.

3.5 Сборка изделия. Тестирование

Рисунок 3.6 - Сборка. Тестирование

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

«Результаты» см. раздел 3.3, примечание.

3.6 Отгрузка и получение

Рисунок 3.7 - Отгрузка и получение

3.7 Складирование

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

Заключение

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

Серьезным подспорьем в данной вопросе служит программный инструмент визуального моделирования бизнес-процессов BPwin 4.0 на основе стандартов DFD, WFD, IDEF0, IDEF3 и т.д.

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

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

Курсовой проект выполнен с использованием инструментов визуального моделирования бизнес-процессов BPwin 4.0 автоматизированным способом и посвящен системе анализа управления дизайн студии.

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

Библиографический список

1.Бизнес-инжиниринговые технологии [Электронный ресурс]: содержит статьи направленные на управленческое консультирование и управление организаций. - Современные методологии описания бизнес-процессов. - М., - Режим доступа: http://www.betec.ru/index.php?id=06&sid=27. - Загл. с экрана

2.Бойко, В.В Проектирование баз данных информационных систем [Текст] / В.В. Бойко, В.М Савинков. - М.: Финансы и статистика, 1989. - 351 с.

3.Грекул, В.И. Проектирование информационных систем [Текст]: учебное пособие / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. - 2-е изд. испр. - М.: Интернет-Университет Информационных Технологий: БИНОМ Лаборатория знаний, 2008. - 300 с.

4.Дворников А. IDEF как инструмент моделирования процессов [Текст] / Дворников А. // Авант партнер. - 2005. - №22 (79). - с. 24-35

5.Калянов Г.Н. Теория и практика реорганизации бизнес-процессов [Текст] / Г.Н. Калянов. - М.: Синтег, 2000. - 192 с.

6.Ковалев В.Н. Описание бизнес-процессов - к вершинам мастерства [Текст] / С.В. Ковалев, В.Н. Ковалев. // Консультант директора. - 2004. - №10. - с. 13-22.

7.Ковалев В.Н. Современные методологии и стандарты описания бизнес-процессов: преимущества, недостатки и области применения [Текст] / С.В. Ковалев, В.Н. Ковалев. // Справочник экономиста. - 2006. - №11. - с. 32-46

8.Ковалев С.В. Технология структуризации и описания организации - шаг за шагом [Текст] / С.В. Ковалев, В.Н. Ковалев. // Консультант директора. - 2004. - №8. - с. 5-10.

9.Мазур, И.И Управление проектами. Справочник для профессионалов [Текст] / И.И. Мазуро, В.Д. Шапиров. - М.: Высшая школа, 2001. - 56 с.

10.Маклаков С.В. Моделирование бизнес процессов с AllFusion Process Modeler (BPWin 4.1) [Текст] / С.В. Маклаков. - М.: ДИАЛОГ МИФИ, 2004. - 240 с.

11.Марка, Д.А. Методология структурного анализа и проектирования [Текст] / Д.А. Марка, К. МакГоуэн - М.: Наука, 1993. - 124 с.

12.Робсон, М Практическое руководство по реинжинирингу бизнес-процессов [Текст] / М. Робсон, Ф. Уллах. - М.: Аудит, 1997. - 97 с.

13.Черемных, С.В. Моделирование и анализ IDEF-технологии [Текст]: практикум / С.В.Черемных, И.О.Семенов, В.С.Ручкин. - М.: Финансы и статистика, 2002. - 192 с.

14.Шеер А.В. Бизнес-процессы. Основные понятия. Теория. Методы [Текст] / А.В Шеер. - М.: Весть-метаТехнология, 1999. - 94 с.

15.Шеер А.В. Моделирование бизнес-процессов [Текст] / А.В. Шеер. - М.: Весть-метаТехнология, 2000. - 86 с.

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

...

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

Классификация бизнес-процессов, различные подходы к их моделированию и параметры качества. Методология и функциональные возможности систем моделирования бизнес-процессов. Сравнительная оценка систем ARIS и AllFusion Process Modeler 7, их преимущества.

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


Моделирование информационной системы (ИС) бизнес-процессов продуктового супермаркета "Большая Ложка" на ранней стадии (фазе формирования концепции предприятия) стандартами UML. Сценарий для моделирования ИС, начальные данные и структура управления.

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


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

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


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

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


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

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


Понятие и сущность ИТ-консалтинга. Направления деятельности фирм специализирующихся в сфере информационного консалтинга. Базовые понятия бизнес-моделирования. Классификация бизнес-процессов. Особенности отчета о причинно-следственном анализе проблемы.

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


Создание бизнес-модели процесса выдачи потребительских кредитов. Организационное обеспечение кредитного процесса. Моделирование и документирование бизнес-процессов в программе BPwin. Построение модели AS IS. Предложение по автоматизации бизнес-процесса.

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


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

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


Построение имитационной модели бизнес-процесса "Управление инцидентами" компании "МегаФон" с целью прогнозирования совокупной стоимость ИТ-сервиса по обслуживанию инцидентов. Разработка моделирующих алгоритмов для реализации компьютерных программ модели.

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


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

Документируем новый дизайн бизнес-процесса

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

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

начинается.

Корректируем обновленный дизайн процесса

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

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

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

Редизайн бизнес-процессов: полезные советы

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

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

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