Как разработать модуль по учету заказов в рекламных агентствах

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

ИНФОРМАЦИОННАЯ МОДЕЛЬ И ЕЕ ОПИСАНИЕ

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

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

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

В нашем случае в основу модели положен этап оформления заказа клиента на оказание услуг рекламной компанией «НьюТон», поэтому на контекстной диаграмме отображена единственная работа «Заказы клиентов» (рис. 1, 2).

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

На вход системы поступает информация от клиентов в виде звонков.

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

К управленческим аспектам, которыми руководствуется работа, относятся правила, стратегии, процедуры или стандарты:

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

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

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

Взаимодействие системы с окружающим миром изображается в виде стрелок. Они входят в грани работы следующим образом:

• стрелка «управление» — верхняя грань работы;
• стрелка «механизм» — нижняя грань работы (табл. 1);
• стрелка «вход» — левая грань работы;
• стрелка «выход» — правая грань работы.

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

ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

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

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

Для проектирования базы данных воспользуемся методом «сущность-связь». Данный метод называют также методом ER-диаграмм. У ER-модели есть два уровня — логический и физический. Разделение модели данных на такие уровни позволяет решить важные задачи.

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

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

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

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

На рис. 3 представлена логическая ER-модель.

Необходимо выделить следующие сущности:

• Клиент (ключ — номер клиента);
• Сотрудник (ключ — номер сотрудника);
• Заказ (ключ — номер заказа).

Обозначим связи между выделенными сущностями:

• Сотрудник выполняет Заказ;
• Клиент делает заявку на Заказ.

Представим атрибуты, формирующие сущности:

• Заказ: название, номер, количество, стоимость заказа;
• Клиент: код, наименование, ИНН, юридический адрес, телефон;
• Сотрудник: код, наименование, ИНН, юридический адрес, телефон.

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

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

1. «Клиенты»;
2. «Сотрудники»;
3. «Заказы»;
4. «Услуги».

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

Рассмотрим более подробно каждую таблицу. Таблица «Клиенты» содержит все данные о клиентах, с которыми работает организация (табл. 4).

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

В таблицу «Заказы» входят все данные о заказах, оформленных с клиентом на определенный срок (табл. 5).

Таблица «Услуги» содержит все данные о наборе услуг, предоставляемых организацией клиенту (заказчику) (табл. 6).

Далее построим схему данных, на которой отражены имеющиеся связи (рис. 4).

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

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

ЭКРАННЫЕ ФОРМЫ

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

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

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

• появлением на экране меню нижнего уровня;
• выполнением команды (например, возвратом в системное меню);
• выполнением процедуры (например, процедуры ввода или вывода информации).

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

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

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

Рассмотрим подробно разработанные экранные формы и соответствующее программное обеспечение.

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

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

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

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

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

5. Форма поиска заказа, клиента и исполнителя — по типу запроса вызывает форму, соответствующую вашему выбору, для дальнейшей корректировки и просмотра (рис. 10).

Вывод

При помощи разработанного модуля по учету заказов руководители данной рекламной компании могут:

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

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

М. В. Алтухова, независимый консультант