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

УДК 004.94

Столяров Александр Исмаилович
Магнитогорский государственный технический университет им. Г. И. Носова
Бакалавр прикладной информатики

Аннотация
В статье рассматривается применение методологий моделирования IDEF0, IDEF3, DFD, ARIS и UML для описания бизнес-процесса «Создание рекламного продукта». Дается определение миссии организации, его целей и основных статей дохода. Так же статья содержит управленческое решение, выдвинутое на основе анализа «узких мест».

Ключевые слова: моделирование, предметная область

---

THE DEVELOPMENT OF MODELS DESCRIBING THE BUSINESS-PROCESS OF «PROMOTIONAL PRODUCT CREATION»

Stolyarov Alexander Ismailovich
Magnitogorsk State Technical University
Bachelor of Applied Informatics

Abstract
The article deals with the application of methodologies for modeling IDEF0, IDEF3, DFD, ARIS and UML to describe business — the process of «Creating a promotional product.» The definition of the mission of the enterprise, its objectives and the main items of income. The same article provides administrative decision, put forward on the basis of the analysis of «bottlenecks».

Keywords: modeling, subject area

---

Библиографическая ссылка на статью:
Столяров А.И. Разработка моделей описания бизнес-процесса «Cоздание рекламного продукта» // Современная техника и технологии. 2016. № 12. Ч. 2 [Электронный ресурс]. URL: https://technology.snauka.ru/2016/12/11467 (дата обращения: 24.02.2023).

Содержание:

Введение

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

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

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

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

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

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

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

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

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

Глава 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.

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

Единственный в мире Музей Смайликов Самая яркая достопримечательность Крыма

Скачать 27.78 Kb. Название Моделирование бизнеспроцессов рекламного агентства Анкор Моделирование бизнес-процессов рекламного агентства Дата 29.11.2021 Размер 27.78 Kb. Формат файла Имя файла Моделирование бизнес-процессов рекламного агентства.docx Тип Закон #285274

---

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

Лайт-версия процессного подхода к управлению

Любое digital-агентство, которое стремится привлечь новых клиентов, должно иметь достаточно ресурсов, чтобы взять их в работу. Обеспечить соответствие объема ресурсов объему задач помогает масштабируемая бизнес-модель, которой посвящена наша статья «Масштабирование бизнеса: 7 первых шагов к росту рекламного агентства».

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

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

От теории к реальности

Для начала немного теории.

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

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

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

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

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

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

1 Определить роли

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

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

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

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

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

2 Определить процессы

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

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

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

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

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

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

3 Задокументировать процессы

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

Закрепить процессы можно в виде:

• диаграмм
• рабочих регламентов
• шаблонов для программного обеспечения (ПО)

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

Диаграммы

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

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

Они составляются из следующих элементов:

• работы
• стрелки/связи
• перекрестки (слияния/разветвления работ)
• объекты ссылок
• элементы поведения (события, принятая решений и т. п.)

С полной инструкцией по применению IDEF3 можно познакомиться здесь. В качестве альтернативы удобно применять стандарт нотации BPMN 2.0. Его спецификация переведена на русский язык.

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

Рабочие регламенты

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

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

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

Шаблоны для ПО

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

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

Такие заготовки — еще один способ формализовать выделенные бизнес-процессы. Цель применения шаблонов исключительно практическая: они экономят время на подготовку к работе с новым клиентом.

Что дальше

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

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

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

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

Проектирование информационной системы ‘Деятельность рекламного агентства’

Содержание

Введение

1.   Проектирование ИС: общие понятия

2.      Описание бизнес-процессов в BP-Win

2.1 IDEF0

2.2 IDEF3

2.3 DFD

3.   ER-Win

4.      Rational Rose

4.1 Диаграмма вариантов использования

4.2 Диаграмма состояний

.3 Диаграмма деятельности

.4 Диаграммы взаимодействий

.5 Диаграммы классов

.6 Проектирование структуры web-сайта

.7 Визуальное представление web-сайта

Заключение

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

Введение

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

применение на практике знаний, полученных в процессе изучения курса
«Проектирование информационных систем»;

получение практических навыков создания ИС, основанных на БД.

получение представлений о методах и средствах проектирования современных
информационных систем;

приобретение навыков использования CASE-средств проектирования ИС.

1. Проектирование ИС: общие понятия

Проектирование — процесс преобразования входной информации об объекте
проектирования в проект ИС, т.е. процесс проектирование сводится к
последовательной формализации проектных решений на различных стадиях ЖЦ ИС.

Проект — проектно-конструкторская и технологическая документация, в
которой представлено описание проектных решений по созданию и эксплуатации ИС в
конкретной программно-технической среде.

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

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

Этапы проектирования ИС:

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

2.      Включает

ü Исследование и анализ существующей ИС

ü  Определение требований к создаваемой ИС

ü  Оформление технико-экономического обоснования

ü  Оформление технического задания на разработку ИС

3.     Проектирование (техническое проектирование или
логическое проектирование)

4.      Включает

ü Разработку в соответствии со сформулированными требованиями
функциональной и системной архитектуры

ü  Оформление технического проекта

Последовательность и содержание этих этапов предписываются [ГОСТ
34.601-90. Автоматизированные системы. Стадии создания.], следующим
образом:

. Формирование требований к ИС.

1.1.  Обследование объекта автоматизации и обоснование необходимости
(целесообразности) создания ИС.

1.2.   Формирование требований заказчика к ИС (определение целей).

.3.     Оформление отчета о выполненной работе и заявки на разработку ИС
(тактико-технического задания)

2.     Разработка концепции ИС.

2.1.  Изучение объекта

2.2.   Проведение необходимых научно-исследовательских работ

.3.     Разработка вариантов концепции ИС и выбор концепции, наиболее
полно удовлетворяющего требованиям заказчика

.4.     Оформление отчета о выполненной работе

3.     Техническое задание

Разработка, согласование и утверждение ТЗ на создание ИС

4.     Эскизный проект

4.1.  Разработка предварительных проектных решений по ИС и ее частям

4.2.   Разработка документации на ИС и ее части

5.     Технический проект

5.1.  Разработка проектных решений по системе и ее частям

5.2.   Разработка документации на ИС и ее части

.3.     Разработка и оформление документации на поставку изделий для
комплектования ИС и/или технических требований на их разработку

.4.     Разработка заданий на проектирование в смежных частях проекта объекта
автоматизации.

.5.     После завершения работы над проектом ИС наступает стадия
разработки ИС или, как говорят чаще, реализации.

.6.     Реализация (рабочее проектирование, программирование) включает

ü Создание программного обеспечения ИС и его отладку

ü  Наполнение БД

ü  Создание рабочих инструкций для персонала

ü  Оформление рабочих проектов

Реализованная система передается заказчику для внедрения и опытной
эксплуатации.

6.     Внедрение (тестирование, опытная эксплуатация)

7.      Включает

ü Запуск системы у заказчика

ü  Обучение персонала

ü  Поэтапное внедрение в эксплуатацию

ü  Оформление акта о приемо-сдаточных испытаниях ИС

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

8.     Эксплуатация (сопровождение, модернизация)

9.      Включает

ü Сбор информации о функционировании ИС

ü  Исправление ошибок и недоработок

ü  Оформление требований к модернизации

Подходы к проектированию ИС:

ü Функционально модульный или структурный — в основу положен принцип
функциональной декомпозиции, в котором система описывается в терминах иерархии
ее функций и передачи информации между отдельными функциональными элементами.

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

2. Описание бизнес процессов в BP—Win

.1 IDEF0

IDEF0
— Function Modeling — методология функционального
моделирования и графическая нотация, предназначенная для формализации и
описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические
отношения между работами, а не их временная последовательность (WorkFlow).

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

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

Общая структура декомпоций IDEF0 для рекламного агентства

IDEF0

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

Фрагмент такой диаграммы рекламного агентства

Презентационные диаграммы (For Exposition Only diagrams — FEO diagrams) часто включают в модели, чтобы
проиллюстрировать другие точки зрения или детали, выходящие за рамки
традиционного синтаксиса IDEF0.
Диаграммы FEO допускают нарушение любых правил
построения диаграмм IDEF0 в целях
выделения важных с точки зрения аналитика частей модели. Естественно, если
диаграмма FEO включена в модель исключительно для
отображения другой точки зрения на систему, она, скорее всего, внешне будет
выглядеть как обыкновенная IDEF0-диаграмма,
удовлетворяя всем ограничениям IDEF0.

Пример диаграммы декомпозиции А1, А2, А3, А4 для рекламного
агентства

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

Стрелками входа для «заключения договоров» являются звонки клиентов и
документация. Стрелками управления служат законодательство и антиплагиат.
Стрелками механизма выступают директор и сотрудники рекламного агентства.
Стрелка выхода — заказ клиента.

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

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

Стрелкой входа для «выпуска рекламной продукции» является контроль за
процессом. Стрелками управления служат законодательство и антиплагиат.
Стрелками механизма выступают директор и сотрудники рекламного агентства.
Стрелки выхода — прибыль и готовая рекламная продукция.

Диаграммы декомпозиции А11, А12, А13, А14

Диаграммы декомпозиции А21, А22, А23, А24

Диаграммы декомпозиции А31, А32

Диаграммы декомпозиции А41, А42, А43, А44

.2 IDEF3

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

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

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

Основой модели является сценарий бизнес процесса. Единицы работы Unit of Work (UOW), также называемые работами (activity), являются центральными компонентами
модели.

Связи. Обычно организовываются слева направо, так чтобы стрелка начиналась на
правой стороне и заканчивалась на левой.

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

Соединения (перекрестки Junction (J)). Завершение одного действия может инициализировать
выполнение сразу нескольких действий или наоборот, определенное действие может
требовать завершения нескольких других действий для начала своего выполнения.
Соединения разбивают или соединяют внутренние потоки и используются для
описания ветвления процессов. Все перекрестки на диаграмме нумеруются, каждый
номер имеет префекс J и порядковый
номер (J1, J2)

 Разворачивающие соединения используются для разбиения потока

 Сворачивающие соединения объединяют потоки

Типы соединений

Графическое обозначение	Название	Вид	Правила инициализации
Соединение И	Разворачивающее	Каждое конечное действие обязательно инициализируется.
		Сворачивающее	Каждое исходное действие обязательно должно завершиться.
Соединение Эксклюзивное ИЛИРазворачивающееОдно и только одно конечное действие инициируется.
		Сворачивающее	Одно и только одно исходное действие должно завершиться.
Соединение ИЛИРазворачивающееОдно (или более) конечное действие инициируется.	Одно (или более) исходное действие должно завершиться.

Соединение ИЛИ. Предназначено для тех случаев, которые не
могут быть описаны
первыми 2 способами.

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

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

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

 

.3 DFD

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

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

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

ü внешние сущности (внешние ссылки) external references;

ü  системы/подсистемы (функции обработки информации, работы);

ü  процессы;

ü  накопители данных, хранилища data store (таблицы для хранения информации);

ü  потоки данных (стрелки) arrows — документы, объекты, сотрудники или
отделы, которые участвуют в обработке информации

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

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

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

Создание диаграммы потоков данных

DFD-Диаграммы для рекламного агентства

3. ER—Win

ER—win для проектирования реляционных баз данных

Модель сущность-связь (ER-модель) (англ. entity-relationship model,
ERM) — модель данных, позволяющая описывать концептуальные схемы предметной
области.

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

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

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

При создании реальных моделей данных количество сущностей и атрибутов
может исчисляться сотнями. Для более удобной работы с большими моделями в ERwin предусмотрены подмножества модели
(Subject Area), в котором можно включать тематические
общие сущности. Одна и также сущность может входить в несколько Subject Area. Все изменения, созданные в одной Subject Area автоматически отображаются в общей
модели. Каждая из Subject Area может соответствовать определенной задачи: финансовой, производственной
и т.д.

Физическая модель

Логическая модель

Логическая модель с хранимым отображением в акценте на
атрибуты

Логическая модель с хранимым отображением в акценте на
сущности

Физическая модель с хранимым отображением в акценте на
сущности

Схема БД на основе диаграммы в MS Access

4. Rational Rose

CASE средство Rational Rose фирмы (Rational Software Corporation) является одним из наиболее мощных инструментариев анализа и
проектирования объектно-ориентированных систем. Реализует генерацию кодов
программ для С++, Visual C++, VB, Java, Power Builder. Базируется на UML.

4.1 Диаграмма вариантов использования

Суть данной диаграммы состоит в следующем: проектируемая система
представляется в виде множества сущностей или актеров, взаимодействующих с
системой с помощью так называемых вариантов использования. При этом актером или
действующим лицом называется любая сущность, взаимодействующая с системой
извне. Это может быть человек, техническое устройство, программа или любая
другая система, которая может служить источником воздействия на моделируемую
систему так, как определит сам разработчик. В свою очередь вариант
использования служит для описания сервисов, которые система предоставляет
актеру. При этом ничего не говорится о том, каким образом будет реализовано
взаимодействие актеров с системой. Каждый вариант использования — это
потенциальное требование к системе, и пока оно не выявлено, невозможно
запланировать его реализацию. Use case редактор
используется для построения.

Условное обозначение	Описание условного обозначения
Actor-актер системы, т.е. любое действующее лицо, которое представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей. В системе актерами являются «Менеджер по поставкам», «Менеджер по продажам», «Начальник транспортного отдела» и «Управляющий».
Use case -стандартное обозначение варианта (прецедента) использования, описывающий типичное взаимодействие между пользователем и системой.
связь, называемая коммуникацией (communication). Устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования.
связь включения (include) между двумя вариантами использования, которая указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательности поведения другого варианта использования.
связь расширение (extend)отмечает тот факт, что один из вариантов использования может присоединять к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования.

Диаграмма прецедентов для директора рекламного агентства

Диаграмма прецедентов для администратора рекламного агентства

Диаграмма прецедентов для менеджера-копирайтора рекламного
агентства

Диаграмма прецедентов для клиента рекламного агентства

4.2 Диаграмма состояний

Диаграммы состояний (state diagrams) являются хорошо известным средством
описания поведения систем. Они определяют все возможные состояния, в которых
может находиться конкретный объект, а также процесс смены состояний объекта в
результате влияния некоторых событий. Условные обозначения диаграммы состояний:

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

Диаграмма состояний для оформления заказа на рекламу

С состоянием можно связывать следующие данные: деятельность, входное
действие, выходное действие и событие.

Деятельность (activity) — это поведение, реализуемое объектом, пока он
находится в данном состоянии. Деятельность изображают внутри самого состояния;
ее обозначению должно предшествовать слово do (делать) и двоеточие.

Входное действие (entry action) — это поведение, которое выполняется,
когда объект переходит в данное состояние. Входное действие также показывают
внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

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

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

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

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

Составное состояние (composite state) — это такое сложное состояние,
которое состоит из вложенных в него состояний.

Историческое состояние (history state) применяется в контексте составного
состояния. Оно используется для запоминания того из последовательных
подсостояний, которое было текущим в момент выхода из составного состояния.
Обозначается символом h в кружочке.

.3 Диаграмма деятельности (Activity diagram)

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

Условные обозначения диаграммы деятельности:

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

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

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

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

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

Диаграмма активности для рекламного агентства

.4 Диаграммы взаимодействия

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

Диаграммы последовательности действий отображают взаимодействие объектов,
упорядоченное по времени. Диаграммы последовательности обычно соответствуют
реализации прецедентов в логическом представлении системы. На диаграмме
последовательности объект изображается в виде прямоугольника на вершине
пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline)
объекта или временной линией (timeline). Она представляет собой фрагмент
жизненного цикла объекта в процессе взаимодействия. Линия жизни служит для
обозначения периода времени, в течении которого объект существует в системе и
следовательно может потенциально участвовать во всех ее взаимодействиях. В
процессе функционирования объектно-ориентированных систем одни объекты могут
находиться в активном состоянии, непосредственно выполняя определенные действия
или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно
выделить подобную активность объектов применяется специальное понятие,
получившее название фокус управления. Фокус управления изображается в виде
вытянутого узкого прямоугольника.

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

Диаграмма последовательности

Основной поток событий

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

Предусловия.

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

прецедент начинается, когда клиент получил заказ и готов его оплатить

клиент проверяет правильность выполнения заказа.

если всё правильно, то он нажимает подтверждение и расплачивается
карточкой. Если есть ошибка, то выполняется поток ошибок Е1.

клиент вводит свой PIN-код.

устройство дает подтверждение, в случае отсутствия подверждения,
выполняется альтернативный поток событий А1.

устройство списывает необходимую сумму за оплаченный заказ.

менеджер выдает клиенту квитанцию и чек за оказанные услуги.

клиент получает квитанцию и чек.

прецедент завершается.

Альтернативный поток событий А1.

1. устройство не дает подтверждения по вводу PIN-кода.

. менеджер сообщает клиенту об ошибке.

. прецедент завершается.

Поток ошибок Е1 — ошибка в заказе.

1. пациент, обнаружив ошибку в сумме или в выполненном заказе, сообщает о
ней менеджеру.

. менеджер проверяет информацию полученную от клиента.

. менеджер производит корректировку.

. исправленный чек(квитанция) или заказ предоставляются клиенту на
рассмотрение.

. прецедент завершается.

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

4.5 Диаграммы классов

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

Атрибут — это элемент информации, связанный с классом.

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

Связь — семантическая взаимосвязь между классами. Чтобы один класс мог послать
сообщение другому на диаграмме взаимодействия должна существовать связь.

Ассоциации (association) — отношения между экземплярами классов.

Стрелки — навигации. Могут быть однонаправленные и двунаправленные.

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

Агрегации (aggregations) представляют собой более тесную форму ассоциации.
Агрегация — это связь между целым и его частью.

Стереотипы — это механизм, позволяющий разделять классы на категории. В
языке UML основными стереотипами являются: Boundary (граница), Entity
(сущность) и Control (управление).

Граничные классы (boundary classes) — это классы, которые расположены на
границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы
с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими
системами.

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

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

Диаграммы компонентов (component diagram) показывают различные компоненты
системы и зависимости между ними. Компонент представляет собой физический
компонент программного кода. Зависимости между компонентами показывают как
изменения одного компонента могут повлиять на другой.

Диаграммы размещения (deployment diagram) отражают физические зависимости
между программными и аппаратными компонентами разрабатываемой системы
Показывает размещение объектов и компонентов в распределенной системе. Каждый
узел представляет собой некоторый тип вычислительного устройства.

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

 

Генерация
кода диаграммы классов на языке Visual Basic

CREATE
TABLE T_14 (

сотрН INTEGER NOT NULL,

заказН INTEGER NOT
NULL,PK_T_1446 PRIMARY KEY (сотрН, заказН)

);INDEX
TC_T_14114 ON T_14 (сотрН );INDEX TC_T_14115 ON
T_14 (заказН );TABLE T_сотрудники (

сотрН INTEGER NOT NULL,

фамилияСотр VARCHAR ( 255 ) NOT NULL,

имяСотр VARCHAR ( 255 ) NOT NULL,

отчествоСотр VARCHAR ( 255 ) NOT NULL,

телефонСотр INTEGER NOT NULL,

паспортСотр INTEGER NOT NULL,

кодДолжности INTEGER NOT NULL,PK_T_сотрудники40 PRIMARY KEY (сотрН)

);INDEX
TC_T_сотрудники127 ON T_сотрудники (кодДолжности );

CREATE
TABLE T_должности (

кодДолжности INTEGER NOT NULL,

должностьСотр VARCHAR ( 255 ) NOT NULL,

сотрН INTEGER,PK_T_должности42 PRIMARY KEY (кодДолжности)

);INDEX
TC_T_должности129 ON T_должности (сотрН );

CREATE
TABLE T_прайслист (

кодУслуги INTEGER NOT NULL,

названиеУслуги VARCHAR ( 255 ) NOT NULL,

ценаУслуги DOUBLE PRECISION NOT
NULL,

кодПродукции INTEGER NOT NULL,PK_T_прайслист43 PRIMARY KEY (кодУслуги)

);INDEX
TC_T_прайслист130 ON T_прайслист (кодПродукции );TABLE T_заказы
(

заказН INTEGER NOT NULL,

датаЗ DATE NOT NULL,

датаВыполнЗаказа DATE NOT NULL,

датаВыдачиЗаказа DATE NOT NULL,

получен SMALLINT NOT NULL,

стоимость DOUBLE PRECISION NOT
NULL,_клиент_ID INTEGER NOT NULL,PK_T_заказы41 PRIMARY KEY (заказН)

);INDEX
TC_T_заказы128 ON T_заказы (T_клиент_ID );TABLE T_виды_услуг (

кодПродукции INTEGER NOT NULL,

назвВидаУслуг VARCHAR ( 255 ) NOT NULL,

кодУслуги INTEGER,_прайслист_кодУслуги INTEGER NOT NULL,PK_T_виды_услуг44 PRIMARY KEY (кодПродукции)

);INDEX
TC_T_виды_услуг131 ON T_виды_услуг (кодУслуги );INDEX TC_T_виды_услуг132 ON T_виды_услуг (T_прайслист_кодУслуги );TABLE T_16 (

заказН INTEGER NOT NULL,

кодУслуги INTEGER NOT
NULL,PK_T_1648 PRIMARY KEY (заказН,
кодУслуги)

);INDEX
TC_T_16119 ON T_16 (заказН );INDEX TC_T_16120 ON
T_16 (кодУслуги );TABLE T_клиент (

клиентН INTEGER NOT NULL,

фамилияКл VARCHAR ( 255 ) NOT NULL,

ИмяКл VARCHAR ( 255 ) NOT NULL,

ОтчествоКл VARCHAR ( 255 ) NOT NULL,

телефонКЛ INTEGER NOT NULL,

паспортКл INTEGER NOT NULL,

адресКл VARCHAR ( 255 ) NOT
NULL,_клиент_ID INTEGER NOT NULL,PK_T_клиент45 PRIMARY KEY (T_клиент_ID)

);TABLE
T_виды_услуг ADD CONSTRAINT FK_T_виды_услуг69 FOREIGN KEY (кодУслуги) REFERENCES T_прайслист (кодУслуги) ON DELETE NO ACTION ON
UPDATE NO ACTION;TABLE T_виды_услуг ADD CONSTRAINT FK_T_виды_услуг70 FOREIGN KEY (T_прайслист_кодУслуги) REFERENCES T_прайслист (кодУслуги) ON DELETE NO ACTION ON UPDATE NO ACTION;TABLE T_заказы ADD CONSTRAINT FK_T_заказы63 FOREIGN KEY (T_клиент_ID) REFERENCES T_клиент (T_клиент_ID) ON DELETE NO ACTION ON UPDATE NO ACTION;TABLE T_16 ADD
CONSTRAINT FK_T_1666 FOREIGN KEY (заказН) REFERENCES T_заказы (заказН) ON DELETE NO ACTION ON
UPDATE NO ACTION;TABLE T_16 ADD CONSTRAINT FK_T_1667 FOREIGN KEY (кодУслуги) REFERENCES T_прайслист (кодУслуги) ON DELETE NO ACTION ON UPDATE NO ACTION;TABLE T_14 ADD
CONSTRAINT FK_T_1461 FOREIGN KEY (сотрН) REFERENCES T_сотрудники (сотрН) ON DELETE NO ACTION ON
UPDATE NO ACTION;TABLE T_14 ADD CONSTRAINT FK_T_1462 FOREIGN KEY (заказН) REFERENCES T_заказы (заказН) ON DELETE NO ACTION ON UPDATE NO ACTION;TABLE T_сотрудники ADD CONSTRAINT FK_T_сотрудники68 FOREIGN KEY (кодДолжности) REFERENCES T_должности (кодДолжности) ON DELETE NO ACTION ON UPDATE NO ACTION;TABLE T_прайслист ADD CONSTRAINT FK_T_прайслист73 FOREIGN KEY (кодПродукции) REFERENCES T_виды_услуг (кодПродукции) ON DELETE NO ACTION ON
UPDATE NO ACTION;TABLE T_должности ADD CONSTRAINT FK_T_должности60 FOREIGN KEY (сотрН) REFERENCES T_сотрудники (сотрН) ON DELETE NO ACTION ON UPDATE NO ACTION;

 

4.6
Проектирование структуры web-сайта

.7 Визуальное представление спроектированного web-сайта

Заключение

В ходе выполнения курсовой работы были достигнутые поставленные цели,
такие как: применение на практике знаний, полученных в процессе изучения курса
«Проектирование информационных систем» и получение практических навыков
создания информационных систем, основанных на БД. Так же, я считаю, с успехом
были освоены программы «Process Modeler», «ERwin Data Modeler» и «IBM Rational rose».

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

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

информационная система база данный

1. Н.В. Барклаевская, Методические указания к выполнению
лабораторных работ, СПб, 2006.

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

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

Когда возникают проблемы с управлением?

Роль процессного управления возрастает по мере роста организации. Это происходит по нескольким причинам:

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

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

Основные проблемы рекламного агентства

Рекламные агентства сталкиваются с проблемами, которые характерны для сегмента B2B в целом:

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

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

Отраслевые исследования:

В исследование АКАР (Ассоциации коммуникационных агентств России) показало, что для 22 опрошенных компаний в приоритете стоит более тесное сотрудничество и консультации с клиентами. Средняя численность сотрудников в компаниях, участвующих в исследовании — 97 человек. «Бизнес-Монитор. З-я волна исследования»

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

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

Бизнес-процесс продаж в рекламном агентстве

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

Упущен лид

Для заказа услуг в рекламном агентства клиент составляет бриф с кратким описанием своего продукта и просит рассчитать стоимость услуг. В ответ на запрос менеджер агентства высылает медиаплан — аналог коммерческого предложения.

Проблемы:

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

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

Процессный подход решает описанную проблему за счет механизма передачи ответственности и стандартизации процедур в рамках корпоративных регламентов. За исполнение таких регламентов отвечают системы автоматизации бизнес-процессов, которые регистрируют события (приход письма, получение заявки, отправка документа) и автоматически открывают задачу, сообщая о ее статусе одновременно исполнителю и руководству. Внедрение средств мониторинга задач помогло клиентам Comindware увеличить конверсию лидов на 17-20%.

Не согласован медиаплан

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

Проблемы:

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

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

Сорвано начало кампании

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

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

Контроль дебиторской задолженности

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

Отраслевые исследования:

80 % из 98 агентств, участвующих в исследовании АКАР, управляли дебиторской задолженностью. 41 % участников опроса делали это силами клиентского менеджера, еще 24 % затруднились назвать ответственных. Исследования постоплат на рынке коммуникаций в России

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

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

Идеальная система управления рекламным агентством

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

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

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

Comindware Business Application Platform

На Comindware Business Application Platform создана система комплексной автоматизации рекламного агентства. Решение разработано DBS-Soft совместно с представителями рекламной отрасли, поэтому учитывает максимальное количество типовых бизнес-процессов рекламного агентства на стратегическом и операционном уровне. Решение покрывает задачи в области аккаунт менеджмента, медиапланирования и приобретения рекламного инвентаря, производства рекламной продукции, а служб обеспечения от АХО до отдела кадров.

Основные модули продукта DBS-Soft:

• Блок «Бизнес» — взаимодействие с клиентами и управление рекламными проектами;
• БЛОК CRM — формирование цифровых профилей клиентов;
• Блок «Документооборот» — поддержка внешнего и внутреннего документооборота;
• Блок «Корпоративный портал» — поддержка работы АХО, HR и ИТ-отдела компании.

Антон Ермаков, директор по маркетингу Comindware. Имеет большой опыт в сфере цифровой трансформацией, более 10 лет, по направлению BPM и автоматизация бизнес-процессов в рекламном бизнесе. Автор статей и исследований на CNews, Tadviser, Ведомости и др.