Разработка регламента выполнения процесса «Предоставление рекламных услуг

Содержание:

Введение

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

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

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

• • Общие положения. Здесь указывается назначение регламента (для каких целей он создан), его область применения (объекты или работники организации, которых касается регламент) и нормативные документы (документы, на основании которых был создан данный регламент). Также данный раздел содержит порядок утверждения, внесения изменений и отмены регламента.
  • Термины, определения и сокращения. Раздел содержит в себе определение терминов и разъяснения к ним. Термины приводятся в алфавитном порядке. Каждый термин пишется с новой строки в единственном числе. Определение термина указывается через тире, которое заменяет собой слово «ЭТО». В качестве источников определений рекомендуется использовать государственные стандарты и нормативные документы организации.
  • Описание процесса. Приводится подробное пошаговое описание процесса. Каждый новый этап процесса описывается в отдельном подпункте. Также указываются работники, причастные к исполнению действия. Приводится описание действия и ожидаемый результат.
  • Ответственность. В этом разделе приводится описание ответственности за неисполнение регламента. Может содержать дисциплинарную, административную и уголовную ответственность. Все зависит от сложности производственных процессов и сферы деятельности организации.
  • Контроль. Указание ФИО должностного лица, ответственного за контроль исполнения регламента. Также указываются средства контроля, если они были использованы.

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

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

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

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

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

1. Моделирование бизнес-процессов

1.1 Описание предметной области. Постановка задачи

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

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

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

Информация для решения данной задачи будет взята с открытых источников в интернете и личного опыта общения с рекламной компанией ООО «ВАТМАН» (название компании изменено).

Представим для рассмотрения организацию ООО «ВАТМАН». Компания представлена из нескольких человек:

1. Директор.
2. Бухгалтер.
3. Агент.
4. Менеджер.
5. Дизайнер.
6. Технический специалист.

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

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

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

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

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

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

• • BPWin и ERWin.
  • Oracle Designer.
  • ARIS.

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

• Наличие учебных материалов в открытом доступе
• Возможность работы с несколькими нотациями для проектирования моделей.
• Возможность работы с СУБД.
• Распространенность среди разработчиков.
• Доступность ознакомительных версий продукта.

Приступим к рассмотрению систем.

BPWin и ERWin. Являются продуктами компании Computer Associates International, Inc. (CA), которая входит в пятёрку ведущих производителей программного обеспечения для моделирования. На текущий момент программное обеспечение принадлежит компании Erwin, inc., Эта компания была создана после того, как Paralax Capital Partners в 2016 году выкупила программный пакет у Computer Associates International. Тем не менее мы рассмотрим пакет от CA, Inc.

Пакет BPWin представляет собой инструмент для визуального моделирования бизнес-процессов и основан на методологии IDEF^[1]. Предназначен для функционального моделирования и анализа деятельности предприятия.

Возможности BPWin:

• • Поддерживает работу с нотациями IDEF0, DFD и IDEF3.
  • Позволяет оптимизировать процедуры в организации.
  • Интегрирован с ERWin, что позволяет моделировать базы данных на основе модели.
  • Содержит собственный генератор отчетных документов.
  • Позволяет выполнять слияние и расщепление моделей.
  • Отвечает стандартам качества ISO9000.

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

Возможности ERWin:

• • поддержка методологии структурного моделирования SADT;
  • поддержка прямого создания БД на основе модели и обратной генерации модели на основе существующей БД для 20 типов существующих СУБД;
  • имеет интеграцию со продуктами Сomputer Associates;
  • позволяет использовать шаблоны и компоненты созданных ранее моделей;
  • имеет встроенные средства документирования БД.

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

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

Главными особенностями Oracle Designer является хорошо организованный сбор данных о потребностях пользователей и глубоко продуманная автоматизация построения приложений с гибким графическим интерфейсом. Программный пакет содержит менеджер версий и позволяет вести учет изменений, происходящих с моделью в период работы с ней, что очень удобно для разработчиков. Также системой поддерживаются Большинство современных методов разработки, включая RAD и JAD.

Средства концептуального моделирования Oracle Designer включают в себя:

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

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

На основе построенных моделей система способна самостоятельно сгенерировать серверные компоненты не только на Oracle DB, но и на основе целого ряда СУБД, включая Microsoft SQL Server, Sybase и других. Такой большой выбор даёт продукту от Oracle несомненные преимущества.

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

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

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

ARIS. Интегрированное средство моделирования бизнес-процессов от компании IDS Scheer AG. Программный пакет объединяет в себе разнообразные методы моделирования и анализа систем. В первую очередь это средство описания, анализа, оптимизации и документирования бизнес-процессов. Достоинством данной системы является возможность построения одной и той же модели с использованием различных сочетаний методик. Такой подход позволяет работать с системой специалистам, имеющим различную теоретическую базу. Методика моделирования ARIS построена на разработанной Августом Шером теории построения интеграционных информационных систем, которая определяет принципы построения моделей и отражающих различные аспекты исследуемой системы факторах. Выделяют следующие модели:

• Организационные.
• Функциональные.
• Информационные.
• Модели управления.

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

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

Стоит также отметить несколько особенностей системы ARIS:

• Основная бизнес-модель системы - eEPC^[2]. По существу, модель eEPC расширяет возможности IDEF0, IDEF3 и DFD.
• в системе есть внутренняя база данных, которая позволяет проверять модель на ошибки, выполнять поиск противоречий и проверить целостность общей картины
• ARIS – единственная система, которая ориентирована на описание бизнеса с применением одновременно различных техник. Данный факт помогает оценить проектируемую модель со всех сторон.

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

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

2.1 Выбор методологии

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

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

• IDEF0;
• IDEF3:
• DFD

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

IDEF0 – методология функционального моделирования и графическая нотация, предназначенная для графического представления и описания бизнес-процессов. Стандарт был разработан в 1981 году в США. Его разработали специально для автоматизации промышленных предприятий. Разработчикам программного обеспечения не хватало новых методов анализа бизнес-процессов и поэтому они разработали новую методологию IDEF0, для которой применялись новые нотации^[3].

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

• Входящие (Input) – вводные, необходимые для начала процесса
• Управление (Control) – механизмы управления (Инструкции, приложения, документация и пр.)
• Механизм (Mechanism) – ресурсы, которые используются для протекания процесса (Люди, оборудование и пр.)
• Исходящие (Output) – вывод результата процесса, выходной продукт

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

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

Рисунок 1

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

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

Основным структурным элементом является действие, или как принято его назвать в терминологии «Unit of Work» (единица работы). Действие в нём описывается глаголом или отглагольным существительным.

Пример такого блока можно увидеть на рисунке 2.

Рисунок 2

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

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

Существует 3 вида связей:

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

Графическое изображение этих связей можно увидеть на рисунке 3

Рисунок 3

Если для связи типа «временное предшествование» всё довольно просто, то с двумя другими стоит внести пояснения.

Объектный поток – тип связи, используемый для связи двух блоков действий, в случае если «принимающий» блок может быть выполнен только при наличии объекта от «отдающего» блока. Например, действие «Оплатить счёт» не может начаться без предоставления счета от действия «Получить счёт».

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

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

• И (AND, &) – каждое конечное действие обязательно инициируется или каждое исходное действие должно завершится перед выполнением инициируемого.
• ИЛИ (OR, O) – хотя бы одно конечное действие инициируется или хотя бы одно из исходных действий должно завершится.
• Исключительное ИЛИ (XOR, X) - одно и только одно конечное действие инициируется или одно и только одно исходное действие должно завершится.

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

• Разворачивающее
• Сворачивающее

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

• И (AND, &) – все действия начнутся или завершатся одновременно.
• ИЛИ (OR, O) – одно и более действий начнутся или закончатся одновременно.
• Исключительное ИЛИ (XOR, X) – Одновременное начало или окончание действий невозможно

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

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

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

• И (J7)
• ИЛИ (J8)

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

Рисунок 4

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

DFD. Диаграммы потоков DFD^[4] во многом схожи с IDEF0 и моделируют систему как набор действий, которые соединяются между собой стрелками. Но в отличие от IDEF0, диаграммы потоков данных содержат в себе еще два новых типа объектов:

• Хранилища данных.
• Внешние сущности.

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

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

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

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

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

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

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

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

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

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

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

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

В предыдущих параграфах мы рассмотрели средства моделирования бизнес-процессов и основные методологии. Для дальнейшей работы по описанию бизнес-процесса мы будем использовать программный пакет AllFusion Process Modeler r7, больше известный как BPwin. Для наших целей возможностей данного пакета будет достаточно. Описывать процессы мы будем при помощи диаграммы с нотацией IDEF0.

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

• Входящие материалы (Input) - материалы и документы, которые мы получаем от заказчика в процессе получения материалов для размещения в качестве рекламы.
• Управляющие элементы (Control) - механизмы управления (Инструкции, приложения, документация и пр.), которые участвуют в обработке заказа.
• Механизмы обработки (Mechanism) – ресурсы, люди и прочие материалы для обеспечения протекания процесса реализации обработки заказа.
• Выходной продукт (Output) – что мы предоставляем заказчику в качестве конечного продукта.

Начнем с описания входящих материалов. Заказчик чаще всего приходит со своими материалами и представлением о том, что он хочет видеть на выходе. Таким образом исходными материалами для начала обработки заказа являются:

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

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

• Прайс лист.
• Должностная инструкция.
• Техническая документация на экран.

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

• Дизайнер.
• Заказчик.
• Менеджер.
• Бухгалтер.
• Технический специалист.
• Графическая станция.
• Светодиодный рекламный экран.

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

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

Владельцем процесса здесь является директор. Мы будем рассматривать процесс с его перспективы. Рассмотрим процесс предоставления рекламной услуги в ООО «Ватман»:

Рисунок 5- Контекстная диаграмма функциональной модели

На рисунке 5 представлена диаграмма предоставления услуги. Мы наглядно показали все входы и выходы процесса. Для более подробного разбора выполним её декомпозицию:

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

На рисунке 6 мы видим более подробное описание процесса. Теперь он разбит на 4 действия:

• Принять заказ.
• Заключить договор.
• Обработать исходный рекламный материал.
• Разместить рекламу.

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

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

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

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

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

2.3 Предлагаемые мероприятия по улучшению бизнес-процессов.

Рассмотренная нами модель предоставление рекламной услуги на примере ООО «Ватман» дает общее представление о протекании данного действия. Давайте постараемся выделить основные недостатки в предоставленном нам процессе:

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

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

Для решения первой проблемы мы выполним перенос ознакомления с прайс-листом в подпроцесс «принятие заказа». Это позволит потенциальному заказчику сразу ознакомится с условиями сделки и принять более взвешенное решение. Сделка будет более клиент ориентированной чем сейчас.

Вторым улучшением процесса будет исключение менеджера из процесса подписания договора. Это обусловлено двумя вещами:

• Ознакомление с прайс-листом уже выполнено на этапе принятия заказа.
• Проект договора уже подготовлен и нуждается лишь в подписании.

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

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

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

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

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

• Автоматизация приема заказов.
• Сохранение информации о клиентах.
• Формирование проекта договора на основе актуального шаблона.
• Хранение договора в единой базе документов.
• Хранение рекламного контента в базе контента.
• Централизованное управление контентом на рекламных экранах.

Как можно видеть, плюсы от внедрения информационной системы

весьма существенны.

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

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

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

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

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

Рисунок 7

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

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

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

Рисунок 8 Декомпозиция процесса «Предоставить рекламную услугу» с исправлениями.

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

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

Таким образом мы внесли ряд улучшений в бизнес-процесс. Эти улучшения окажут положительное влияние на работу бизнеса в целом и на работу сотрудников в частности.

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

Заключение

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

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

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

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

1. Проектирование экономических информационных систем: Учебник/ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с., с.35-41
2. Моделирование и анализ IDEF-технологии: практикум /С.В. Черемных, И.О. Семенов, В.С. Ручкин. – М.:Финансы и статистика, 2006. – 192с.
3. Борисов А.Б. Что такое хорошо и что такое плохо при регламентации бизнес-процессов, или как создать «правильный» регламент. / http://www.e-xecutive.ru/knowledge/announcement/1052702/. - 2009.
4. Елиферов В.Г., Репин В.В. Бизнес-процессы. Регламентация и управление. – М.: Инфра-М. – 2009. – 320 с.
5. Кондратьев В.В., Кузнецов М.Н. Показываем бизнес-процессы от модели процессов компании до регламентов процедур. – М.: Эксмо. – 2008. – 256 с.
6. https://www.profiz.ru/sr/9_2014/reglament/
7. http://www.reengine.ru/
8. https://studbooks.net/1471327/menedzhment/instrumentalnye_sredstva_modelirovaniya
9. https://habr.com/
10. http://khpi-iip.mipk.kharkiv.edu/library/technpgm/labs/lab05.html
11. https://www.cfin.ru/management/people/instructions/rules.shtml
12. https://ru.wikipedia.org/

1. IDEF - (I-CAM DEFinition или Integrated DEFinition) — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяют отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах ↑

2. eEPC (extended Event-driven Process Chain) - расширенная модель цепочки процессов, управляемых событиями. ↑

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

4. DFD – (DataFlow Diagram) диаграммы потоков данных ↑