Проектирование реализации операций бизнес-процесса «Предоставление рекламных услуг» (Реинжиниринг бизнес-процессов)

Содержание:

Введение

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

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

Целью курсовой работы является рассмотрение основ проектирования реализации операций бизнес-процесса «Предоставление рекламных услуг»

Для достижения данной цели были поставлены следующие задачи:

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

- рассмотреть показатели бизнес-процессов;

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

Данная курсовая работа состоит из введения, трех глав, заключения и библиографического списка.

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

Глава 1. Аналитическая часть. Методология ARIS. Моделирование бизнес-процесса

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

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

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

1.1 Реинжиниринг бизнес-процессов

ARIS опирается главным образом на собственную архитектуру с пятью видами - "АРИС дом". Эти пять представлений являются:

•организационной моделью;

•управленческой моделью;

•моделью данных;

•функциональной моделью;

•выходной(сервисной) моделью.

Классификация выполнена таким образом, чтобы разбить сложность модели на пять аспектов и тем самым упростить моделирование. Каждое представление концепции ARIS (architecture of integrated information) systems демонстрирует модель бизнес-процесса в определенном аспекте:

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

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

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

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

5.Управленческом - вид процесса, который соединяет все другие представления во временно-логический график, например, в управляемых событиях технологической цепочки или BPMN.

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

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

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

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

1.2 Концепция жизненного цикла

Структуры методологии моделирования бизнес-процессов и концепции жизненного цикла появились в различных прикладных областях, таких как Computer Integrated Manufacturing (CIM), автоматизация делопроизводства и проектирование информационных систем.

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

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

Динамическое поведение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модели используются для настройки приложения. Их можно понимать как графическую программу. Благодаря такому повторному использованию ручное программирование программного кода уменьшается.

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

1.Модель строительства и хранения.

2.Выбор/поиск и анализ моделей.

3.Конфигурация модели.

4.Интеграция моделей.

5.Адаптация и модификация модели.

6.Эволюция и изменение модели.

7.Модель исполнения и интерпретации.

1.3 Основные правила методологии ARIS

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

Рекомендации по использованию событий:

1.В начале процесса или после интерфейса запуска.

2.В конце процесса или до конца интерфейса.

3.События принятия решений по соединителям XOR или OR.

4.Для важных событий, например, вехи в проекте.

5.Действия или события не должны иметь более одного исходящего или входящего соединения.

6.Поток управления процессом моделируется с использованием Правил (шлюзов).

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

1.Из одного входящего соединения следует несколько исходящих соединений (SPLIT).

2.Из нескольких входящих подключений следует точно одно исходящее подключение (JOIN).

3.Возможна последовательность Правил.

4.Er модель обычно закрывается с тем же оператором, как была открыта, и заканчивается "EPC Событием".

5.Логические операторы.

В EPC можно использовать следующие правила:

1.Разделение - шаги обработки, которые следуют правилу, происходят параллельно и должны быть выполнены.

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

3.SPLIT - точно один из следующих шагов обработки правил должен быть выполнен.

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

5.Для логических операций между событиями и действиями существуют специальные правила, которые показаны в модели ARIS Express [6].

1.4 АРИС: набор инструментов

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

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

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

3.ARIS-Project Manager используется для управления проектами. Он предназначен для планирования, контроля и мониторинга всего проекта на всех его этапах. ARIS-Project Manager определяет все задачи, которые будут решаться в процессе моделирования бизнес-процессов.

4.Цель ARIS-Navigator - предоставить компьютеризированную документацию для корпоративной модели, разработанной на этапах моделирования.

"АРИС Экспресс 2", er модель - программа, выпущенная для операционных систем на базе Microsoft Windows. Также она работает в других ОС, таких как Mac OS X или Linux.

Для загрузки программы:

1.Переходят на профильный сайт.

2.Выбирают метод загрузки для ОС.

3.Входят в сообщество ARIS, принимают Лицензионное соглашение и Правила экспорта Software AG, чтобы иметь возможность загрузить ПО.

4.Знакомятся с инструкцией по установке независимо от того, какая загрузка выбрана.

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

Программа имеет очень продвинутую бесплатную функцию ARIS Cloud. Это полномасштабный продукт для анализа бизнес-процессов, который как услуга предоставляется совершенно бесплатно для исследовательских и образовательных целей. Он поддерживает совместные проекты по улучшению процессов и доступен для 1000 пользователей одновременно по всему миру. С бесплатной пробной версией software ag ARIS Cloud бесплатная подписка длится 30 дней. С AERIS Cloud для студентов бесплатная подписка длится 3 месяца.

EPC предлагает множество способов для моделирования процессов, их анализа и определения потенциалов улучшения. Модель EPC непосредственно встроена в интерактивный просмотрщик моделей. Можно скачать его и редактировать бесплатно модели в ARIS Express 2 er. Также можно использовать предоставленные видеоуроки, чтобы найти легкий путь в мир АРИС.

Процесс моделирования:

1.Загружают ARIS Express.

2.Просматривают примеры моделей или видеоуроки.

3.Начинают моделирование.

4.Присоединяются к сообществу ARIS.

5.Получают бесплатную копию "шпаргалки". Для этого нажимают на картинку на профильном сайте, чтобы увеличить ее и скачать документ в формате PDF.

Процессы преобразования в XPDL

Процессы преобразования в XPDLФото: social-biz.org

Для моделирования процессов, которые должны быть преобразованы в XPDL, используют ARIS версии 6.2.

При установке и настройке ARIS запускают программу ARIS Toolset:

1.В строке меню выбирают Файл-> Создать, а затем модель в следующем диалоговом окне.

2.Появится другое диалоговое окно, в котором выбирают место, где будет храниться модель ARIS. Можно выбрать, например, LOCAL-> Demo62-> Основная группа.

3.После нажатия кнопки «Далее» появляется другое диалоговое окно. Необходимо установить флажок «Процессы» и выбрать тип модели eEPC.

4.Появится диалоговое окно, в котором необходимо назначить имя для новой модели ARIS.

5.Вводят имя и нажимают кнопку "Готово". Окно покажет область редактирования для новой модели [2].

6.При моделировании ARIS используют только элементы панели инструментов, отмеченные красным кружком.

7.Элемент, помещенный в правом верхнем углу в наборе инструментов, называется функцией в АРИС, он будет отображен в Activity/Task в XPDL, поэтому используют его для определения задач в процессе.

8.Элемент называется правилом AND в ARIS и сопоставляется с фиктивным действием (маршрут) в XPDL с помощью AND Split или Join в зависимости от того, как пользователь подключает его к задачам.

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

10.Убеждаются, что данные содержат только буквенно-цифровые символы или символы «_», «-», «.».

11.После создания модели в ARIS можно экспортировать ее в XML.

12.Для этого нужно найти определение процесса в древовидном представлении ARIS, щелкнуть его правой кнопкой мыши и выбрать «Экспорт / Импорт-> Экспорт XML...».

13.После нажатия на «Экспорт XML» пользователя попросят ввести используемый язык, а затем выбрать местоположение и имя файла XML, который будет сгенерирован.

14.Нажимают на соответствующий значок, чтобы преобразовать этот * .aml файл в XPDL.

15.Отправляют XPDL-файл в хранилище, позже можно загрузить его в движок через "Package Mng"- раздел приложения.

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

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

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

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

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

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

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

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

2.1 План стандартизации процессов

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

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

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

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

Роли не пересекаются. То, что выполняет специалист по контекстной рекламе, не выполняет копирайтер и т. п.

Роли охватывают все процессы. Нет задач, исполнитель которых не определен.

Последние два пункта соответствуют принципу MECE (mutually exclusive, collectively exhaustive), разработанному консалтинговой компанией McKinsey & Company. Согласно ему, любая структура должна описываться непересекающимися блоками, вместе составляющими полную группу событий.

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

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

Удобно изображать такие последовательности в виде блок-схем. Возьмем для примера процесс «Настройка таргетированной рекламы» и представим его схематически:

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

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

- относятся к основной деятельности и напрямую влияют на доход

- основаны на взаимодействии с клиентом

- включают больше рутинных операций, чем творческих

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

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

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

2.2 Выбор системы автоматизации рекламного агентства

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

Рисунок 1 – Бизнес-процесс рекламного агентства

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

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

Рисунок 2 Модель деятельности рекламного агентства, предоставляющие услуги по рекламе

Как показано на рисунке 1, входящими информационными потоками деятельности рекламного агентства являются:

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

- средства заказчиков;

- материалы для изготовления баннеров и др. рекламы.

Результатной данной деятельности является:

- реализованные проекты

- выполненные заказы

- деловое кредо рекламного агентства

- отчеты для внешних пользователей.

Для реализации данного проекта не менее важными являются:

- учетная политика организации;

- работа менеджера;

- работа администратора.

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

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

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

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

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

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

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

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

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

В целом выделяют два подхода к моделированию.

Структурно-алгоритмический – основными строительными блоками модели при использовании данного подхода являются функции (процедуры). Модель представляет собой выстроенную последовательность функций, при этом имеется возможность их декомпозиции на составные части; на вход каждой функции поступают некоторые данные, на выходе имеются определенные результаты ее выполнения, показывается ресурсное окружение функции – люди, информационные системы, регламенты [3].

К этому блоку относится методология IDEF; инструментом, реализующим данную методологию, является BPWin.

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

Методологии, поддерживающие объектно-ориентированный принцип: методология Aris (группа продуктов IDS Sheer «Aris») и методология UML (продукт Rational Rose). Методология UML в основном ориентирована на разработку программного обеспечения, Aris используется для описания бизнес-процессов предприятия [7].

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

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

В России для моделирования и анализа бизнес-процессов достаточно широко используются следующие средства моделирования: Rational Rose, Oracle Designer, AllFusion Process Modeler (BPWin) и AllFusion ERwin Data Modeler (ERWin), ARIS, Power Designer [2]. За рубежом, помимо упомянутых, активно используются такие средства, как System Architect, Ithink Analyst, ReThink и др.Для качественного обоснования производственной необходимости выбираемой конфигурации средств моделирования необходимо:

1) четко сформулировать все «производственные» постановки задач по моделированию;

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

3) сопоставить функционал по моделированию возможных к использованию инструментальных средств (модулей инструментальных средств) [2].

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

Методология DFD предполагает анализ и проектирование хранилищ данных, IDEF3 служит для анализа участков работы основного бизнес-процесса, поведения системы в различных ситуациях. Методология UML применяется при непосредственном проектировании информационных систем. Для реализации поставленных в данной работе задач подходят методологии ARIS и IDEF0 [4].

В качестве инструмента моделирования выберем нотацию IDEF0 и программное средство моделирования - CA ERWin Process Modeller.

Описание IDEF0 модели построено в виде иерархической пирамиды, в вершине которой представляется самое общее описание системы, а основание представляет собой множество более детальных описаний.

Нотация IDEF0 построена на следующих принципах [5]:

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

2) Лаконичность. Графический язык позволяет большой объем информации о бизнес-процессах изобразить на одной диаграмме.

3) Нотация IDEF0 имеет единые подходы к стандартам, что позволяет избегать двойных толкований графического изображения. Основными стандартами являются [5]:

– наличие от 3 до 6 функциональных блоков;

– информация не должна выходить за рамки контекста;

– диаграммы должны обладать связанностью интерфейса, когда номера блоков, дуги и ICOM коды имеют единую структуру;

–имена функций блоков и наименования дуг должны быть уникальными;

– четкость определения ролей данных и разделения входов и управляющих воздействий;

– лаконичность замечаний для Дуг и имен функций;

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

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

В процессе моделирования очень важным является требование четкости определения направления разработки модели – ее контекста, точки зрения и цели.

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

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

Цель отражает причину создания модели и определяет ее назначение. При этом, все взаимодействия в модели рассматриваются именно с точки зрения достижения поставленной цели.

В рамках методологии IDEF0 модель системы включает в себя серию взаимосвязанных диаграмм, разделяющих сложную систему на составные части. Диаграммы более высокого уровня (А-0, А0) – являются наиболее общим описанием системы, представленным в виде отдельных блоков. Декомпозиция этих блоков позволяет достигать требуемого уровня детализации описания системы [6].

Разработка IDEF0-диаграмм начинается с построения самого верхнего уровня иерархии (А-0) – одного блока и интерфейсных дуг, описывающих внешние связи рассматриваемой системы. Имя функции, записываемое в Блоке 0, является целевой функцией системы с принятой точки зрения и цели построения модели.

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

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

Заключение

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

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

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

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

4. Обеспечить надежный учет и контроль поступлений и расходования денежных средств на всех уровнях управления.

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

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

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

Библиография

Нормативно-правовые документы

1. Конституция Российской Федерации от 12 декабря 1993 г. (с изм. и доп., вступ. в силу с 21.07.2014)

Произведения из многотомного издания

1. Бобошко Д.Д. 1С: Предприятие версии 7.7: Программирование в примерах. М.: КУДИЦ-Образ, 2016. 235 с.

2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: учебник. М.: Финансы и статистика, 2014. 353 с.

1. Грекул В.В. Проектное управление в сфере информационных технологий. М.: БИНОМ, ИНФРА-М, 2013.

2. Каляное Г.Н. CASE-технологии: Консалтинг в автоматизации бизнес-процессов. Изд. 3-е. М.: Горячая линия -Телеком, 2013.

3. Маклаков С.В. BPwin и ERwin. Case - средства разработки информационных систем. М.: Диалог-Мифи, 2016. 256 c.

4. Михайлов А.В. 1С:Предприятие 7.7/8.0: системное программирование. СПб.: БХВ-Петербург, 2015. 336 с.

5. Муромцев В.В. Проектирование информационных систем: Учебное пособие для студентов вузов заочной формы обучения по спец. 010502 "Прикладная информатика в экономике". Белгород: БелГУ, 2019. 160.

6. Постовалов С.Н., Постопавалова А.Ю. 1С: Предприятие 7.7. Уроки программирования. СПб.: БХВ-Петербург, 2018. 308 с.

7. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник:/ Под ред. Ю.Ф. Тельнова. М.: Финансы и статистика, 2016. 512 с.

8. СУБД Microsoft Access: Учебное пособие для вузов/Н.Н. Гринченко, Е.В. Гусев, Н.П. Макаров, А.Н. Пылькин, Н.И. Цуканова- М.: Горячая линия-Телеком, 2019.