Построение модели бизнес-процессов отдела "Копи-центр" ООО "Полиграфия"

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОСИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

Кафедра Менеджмента

КонтрольнаяРАБОТА

По дисциплине «Реинжиниринг и управление бизнес-процессами»

Новосибирск 2016

1. Описание методологии IDEF0

Для анализа бизнес-процессов, рассматриваемых в работе, была выбрана методология IDEF0. IDEF0 - нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающих эти функции. Стандарт IDEF0 (Integration Definition for Function Modeling) утвержден в США в 1993 как Федеральный стандарт обработки информации. В России находится в статусе руководящего документа с 2000 года и в настоящее время в качестве стандарта не утвержден. Тем не менее методология IDEF0 является одним из популярных подходов для описания бизнес-процессов. К ее особенностям можно отнести:

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

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

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

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

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

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

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

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

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

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

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

2. Описание программных средств

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

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

«BPwin» позволяет:

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

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

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

Достоинствами «BPwin» являются:

1. Управление сложными бизнес-процессами.

2. Анализ бизнеса с различных сторон: поддержка в BPwin сразу трех нотаций: IDEF0, IDEF3 и DFD.

3. Интуитивно-понятный графический интерфейс.

4. Настраиваемый интерфейс электронных таблиц.

5. Интерфейс к средствам имитационного моделирования.

6. Собственный генератор отчетов.

7. Функционально-стоимостной анализ (ABC).

3. Описание предметной области

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

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

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

· сдача статистики по каждому оператору отдела;

· учет рабочего времени персонала;

· обеспечение отдела расходными материалами;

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

· сбор информации о постоянных клиентах и внесение их в клиентскую базу;

· интервьюирование клиентов об новых направлениях деятельности копи-центра для удовлетворения спроса;

· контроль внешнего вида сотрудников;

· обеспечение быстрого и качественного обслуживания клиентов;

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

· контроль оплаты клиентами услуг копи-центра.

Отдел оказывает следующий спектр услуг:

· ксерокопирование цветное и черно-белое;

· сканирование;

· отправка файлов по электронной почте;

· набор и распечатка текстов, чертежей, схем;

· цветная широкоформатная распечатка фотографий, афиш, плакатов;

· брошюровка документов, рефератов, дипломных проектов и т.д. (традиционным методом и оборудованием MetalBind);

· ламинирование;

· фольгирование;

· прием и отправка факсов для клиентов;

· разработка схем для вышивания на форматах А3, А4;

· поиск информации в сети;

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

· запись информации на информационные носители;

· резка;

· вставка изображения в рамку;

· вставка люверса.

4. Моделирование бизнес-процессов «Как есть»

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

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

На рисунке 3 представлена модель «As-Is» бизнес-процесса расчета стоимости заказа. Именно этот бизнес-процесс является «узким местом» деятельности отдела.

Рисунок 1 - Контекстная диаграмма модель «As-Is» процесса выполнения заказов

Рисунок 2 - Декомпозиция модели «As-Is» процесса выполнения заказов

Рисунок 3 - Модель «As-Is» расчета стоимости заказа

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

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

5. Оценка эффективности процесса

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

1. Отсутствие контроля стоимости заказа.

2. Отсутствие контроля расходных материалов.

3. Возможность возникновения ошибок при расчете стоимости заказа.

4. Недостоверные данные в отчете по выручке.

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

6. Рекомендации по реорганизации процесса

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

7. Построение модели «Как будет»

На рисунке 4 представлена контекстная диаграмма деятельности отдела «Как будет».

Рисунок 4 - Модель «To-Be» процесса выполнения заказов

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

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

Рисунок 5 - Модель бизнес-процесса выполнения заказа

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

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

Рисунок 6 - Модель процесса формирования заказа

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

На рисунке 8 представлена декомпозиция процесса выдачи заказа. Согласно сформированному заказу оператор осуществляет печать заказа и передает заказ клиенту. Клиент проверяет качество заказа. Если заказ выполнен неверно или клиента не устраивает качество заказа, клиент возвращает заказ оператору и оператор устраняет выявленные недостатки.

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

Рисунок 7 - Модель бизнес-процесса оплаты заказа

Рисунок 8 - Модель бизнес-процесса выдачи заказа

Рисунок 9 - Модель бизнес-процесса формирования сменного отчета по выручке

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

Список литературы

1. Бугорский В.Н., Соколов Р.Е. Экономика и проектирование информационных систем. - СПб.: Питер, 2011.-340 с.

2. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. - М.: Вильямс, 2014. - 176с.

3. Грабауров В.А. Информационные технологии для менеджеров. - М.: Финансы и статистика, 2012. - 368 с.

4. Зиндер Е.З. Бизнес-реинжиниринг и новое системное проектирование. М.: Синтег, 2010. - 235с.

5. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие. М., Центр Информационных Технологий, 2006. - 310 с.

6. Карминский А.М., Нестеров П.В. Информатизация бизнеса. - М.: Финансы и статистика, 2013. - 415 с.

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