close

Вход

Забыли?

вход по аккаунту

Легостаев Алексей Сергеевич. Разработка АРМ менеджера по продажам корпусной мебели (на материалах ООО «Талисман»)

код для вставки
1
2
3
АННОТАЦИЯ
ВКР 61 с., 28 рис., 3 табл., 17 источников.
АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО, ПРОДАЖА, МЕНЕДЖЕР
ПО ПРОДАЖАМ, АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ,
УЧЕТ ДОКУМЕНТООБОРОТА.
Выпускная
квалификационная
работа
посвящена
разработке
автоматизированного рабочего места менеджера по продажам корпусной мебели.
В первой главе производится постановка целей и задач работы, выполняется
анализ предметной области и раскрытие рассматриваемого бизнес-процесса,
выполняется обзор аналогов и прототипов.
Во второй главе производится проектирование автоматизированного
рабочего
места,
проектирование
структуры
программы,
концептуальное
проектирование базы данных, обеспечение целостности и безопасности данных,
проектируются состояния системы и транзитивная сеть логики диалога с
пользователем.
В третьей главе производится реализация спроектированной программы.
Выполняется анализ программных средств и технология для реализации,
реализация логики диалога с пользователем. Также в главе представлены
наглядные примеры экранных форм работающей программы.
4
Содержание
Введение
5
1 Аналитическая часть
8
1.1 Общие сведения о компании ООО «Талисман»
8
1.2 Анализ предметной области
9
1.3 Обоснование необходимости автоматизации работы
11
1.4 Требования к системе
12
1.4.1 Функциональные требования
12
1.4.2 Нефункциональные требования
13
1.5 Обзор аналогов и прототипов
13
1.6 Описание и систематизация бизнес-процессов предметной области
15
2 Проектирование автоматизированного рабочего места менеджера по продажам
корпусной мебели
31
2.1 Проектирование структуры системы
31
2.2 Концептуальное проектирование схемы базы данных
32
2.3 Обеспечение целостности данных
37
2.4 Обеспечение безопасности данных
39
2.5 Разработка транзитивной сети диалога с пользователем
42
3 Реализация автоматизированного рабочего места менеджера по продажам
корпусной мебели
46
3.1 Анализ программных средств и технологий
46
3.2 Примеры экранных форм
48
Заключение
56
Список литературы
57
Удостоверяющий лист на демонстрационный материал
60
Информационно-поисковая характеристика документа на электронном
носителе
61
5
Введение
С начала активного внедрения автоматизации производства его развитие в
России в различных сферах и размерах предприятий существенно различалось. С
самых ранних периодов 1990-х годов крупные предприятия имели возможность и
доступ к интегрированным системам и программам автоматизации. Малый
бизнес, в свою очередь, автоматизация производства была недоступна или
внедрялась очень редко и лишь частично. Только во второй половине 90-х малые
предприятия
получили
широкий
доступ
к
программным
продуктам
автоматизации, но даже при этом это были лишь прикладные решения,
произведенные российскими разработчиками.
Автоматизация обработки информации – это применение программных
средств и технологий с целью облегчения человеческого труда, вытеснения его
ручных форм и повышения производительности.
Суть автоматизации процесса заключается в уменьшении количества
операций и действий с данными, вручную выполняющимися человеком.
Результатом
автоматизации,
производительности
труда
в
свою
очередь,
человека-сотрудника,
будет
уменьшение
увеличение
времени
на
проведение процесса в целом, уменьшения количества возможных недочетов и
ошибок, которые могут возникнуть из-за "человеческого фактора". Таким
образом, автоматизация не только полезна, но и очевидна для увеличения
производительности бизнеса в целом.
Основной проблемой автоматизации, в свою очередь, можно считать
необходимость учета и контроля всех информационных потоков, особенностей
процессов и функций для каждой конкретной компании, осуществления
автоматизации, например, учета счетов и документации, и некоторых других
областей.
В процессе автоматизации малому бизнесу приходится сталкиваться с
необходимостью
сегодняшний
решения
день
организации, учета и
самых
наибольшей
разнообразных
актуальностью
задач.
обладает
Например,
на
необходимость
контроля документооборота с партнерами и клиентами
6
компании. Несмотря на кажущуюся простоту, данные задачи связаны с
необходимостью
решения
важных
проблем:
проверка
совместимости
и
правильности всей совокупности документов, их учет и контроль, а также защита
их содержимого и данных.
Средства автоматизации - в данном контексте пойдет речь о программных
продуктах, призванных решить задачу автоматизации.
Выбор необходимого программного обеспечения достаточно сложная
задача, требующая серьезных знаний, как в предметной области и секторе,
который занимает компания на рынке, так и понимания и учета уникальных
особенностей компании, процессов и функций, которые в ней происходят. На
сегодняшний день рынок продуктов программного обеспечения обширен и
разнообразен,
однако
даже
в
этом
случае
прослеживается
отсутствие
систематизированных объективных критериев и стандартов, с помощью которых
возможно оценить предлагаемое программное решение - возникает вопрос о
возможности существования специалистов способных произвести правильный
выбор. Впрочем, возникает вопрос и о существовании программного обеспечения,
способного решить поставленные задачи. На оба вопроса можно дать
положительный
ответ:
на
текущий
момент
большинство
разработчиков
программного обеспечения для автоматизации бизнеса закладывают в свои
решения механизмы, обеспечивающие хорошую адаптивность. Это может
проявляться в возможностях параметрической и/или программной настройки. Что
касается правильного выбора, то в такой ситуации должен быть найден
компромисс между наиболее полным удовлетворением требований и стоимостью
настройки. В силу ограниченности предложения программных решений для
каждой
конкретной
оптимальной
системы
задачи
по
существует
заранее
возможность
определенным
выбора
наиболее
критериям.
Конечно,
осуществление такого выбора лучше поручать соответствующим специалистам:
внешним консультантам или собственному отделу АСУ.
Средства
требованиям:
автоматизации
должны
удовлетворять
следующим
7

Использовать наиболее современные технологии и методы учета,
контроля, планирования и прогнозирования, характерные для прикладной
области.

Применять наиболее передовые инструментальные средства и
технологии при разработке и настройке программного обеспечения.

При создании любого решения в него закладываются технологии,
современные на момент создания, в дальнейшем системы
развиваются,
ориентируясь, в том числе, и на изменения в инструментах и средствах.
Основной задачей разрабатываемого проекта является автоматизация
деятельности менеджера по продажам, то есть создать систему автоматизации
рабочего места менеджера по продажам.
Основные цели разрабатываемого проекта представляют собой:
 Ознакомиться с работой компании и деятельностью менеджера по
продажам
 Выполнить анализ предметной области и раскрыть бизнес процесс
продажи корпусной мебели
 Ознакомиться с особенностями среды разработки Lazarus
Использование проекта приводит к уменьшению затрат, связанных с
формированием документов и обработкой данных, к сокращению сроков
выполнения работ и повышения ее качества; росту производительности труда
менеджера по продажам.
8
1 АНАЛИТИЧЕСКАЯ ЧАСТЬ
1.1 Общие сведения о компании ООО «Талисман»
Компания ООО «Талисман» начала свою деятельность с 2014 года, как
содружество профессионалов, имеющих большой опыт работы в различных
областях деятельности.
ООО
«Талисман»
- это молодая
и динамично
развивающаяся компания.
Сотрудничество с клиентами осуществляется на основании заключаемых
договоров.
Компания ООО «Талисман» занимается производством и продажей
корпусной мебели.
Структура компании ООО «Талисман» представлена виде следующей
схемы на рисунке 1.1. Прямоугольниками обозначены отделы и подразделения,
скругленными прямоугольниками – отдельные сотрудники.
Рисунок 1.1 – Структура компании ООО "Талисман"
9
Генеральный директор компании имеет в своем подчинении несколько
различных отделов, общая задача которых – получить прибыль путем продажи
корпусной
мебели.
Компания
подразделяется
на
отдел
по
продажам,
транспортный отдел, юридический отдел, экономический отел. Отделом по
продажам руководит начальник отдела продаж, в подчинении у которого
находится менеджер по продажам.
1.2 Анализ предметной области
В целом на менеджера по продажам возлагается:

поиск новых клиентов;

переговоры с целью заключения договора (это одна из основных
функций менеджера по продажам);

обеспечение акта продажи (курирование процесса передачи
ресурса, прихода денег; ведение платежных документов);

обеспечение обратной связи с клиентом (ведение базы данных).
Основной задачей менеджера по продажам на сегодняшний день является
проведение встреч и переговоров с клиентами, как частными лицами, так и
представителями других компаний, организация их встреч для заключения
сделки.
Поскольку процесс
сделки четко
регулируется
и контролируется
законодательством, при проведении сделки менеджеру по продажам остается
только курировать приход денежных средств от клиента, подписание договоров и
актов выполненных работ и вовремя напоминать ему о необходимости провести
платеж или вернуть акт.
В компании ООО «Талисман» в отделе продаж и маркетинга наблюдается
совмещение функций менеджера по продажам и маркетолога, то есть менеджер
по продажам сам занимается продвижением продукции и описанием ё
преимуществ клиенту, а так же иногда решает вопросы в конфликтных ситуациях
и участвует в разработке программы продвижения продукции в целом.
10
Менеджер по продажам проверяет информационные и рекламные ресурсы
компании на наличие заявок от потенциальных клиентов. Так же менеджер
принимает у себя клиентов, пришедших в офис компании лично и проводит
обзванивает возможных клиентов из производственных журналов и справочников
компаний – так называемой «холодной базы». При наличии заявки от
потенциального клиента менеджер осуществляет с ним обратную связь через
оставленные контактные данные и удостоверяется в желании клиента к
сотрудничеству. Если после звонка клиент заинтересовался в покупке, менеджер
также сохраняет его контактные данные и договаривается о встрече или дате
дальнейших переговоров и заносит эти данные в список встреч. Далее менеджер
сохраняет все собранные контактные данные в справочник клиентов. Далее, после
проведения встречи с клиентом менеджер сохраняет данные о результатах
переговоров в списке встреч.
При необходимости или по желанию клиента менеджер просит
специалиста-замерщика провести замеры непосредственно на адресе, указанном
клиентом.
Менеджер проводит встречу с клиентом или фиксирует встречу
представителя от своей компании или представителя от клиента, во время которой
проводятся переговоры по следующим пунктам: стоимость работ, сроки
выполнения и срок гарантии на товар. Создается заказ, куда вносится вся
необходимая информация о товаре, его видах и размерах, выбранном
оборудовании, сроках оплаты и т.д.
После согласования менеджером всех разногласий с клиентом создается
запись в списке договоров, по данным из которой заключается договор,
выписывается счет на оплату (организуется сбор подписей руководителей
исполнителя и клиента). Затем, по мере подписания и получения оплаты статус и
информация в записи договора изменяется в списке договоров.
После заключения договора и получения предоплаты менеджером
создается запись в списке актов выполненных работ, по данным из этой записи
выписывается акт выполненных работ. Затем менеджер регистрирует отправку
11
акта выполненных работ в списке актов. Статус актов в списке актов изменяется
по мере поступления актов выполненных работ с подписью клиента.
По окончании месяца менеджером по продажам формируется отчет о
проделанной работе по данным списка договоров, списка актов, справочника
клиентов и собственным записям. В отчете отмечаются договора, заключенные
менеджером по продажам, конечная стоимость проведенной сделки по ним, и
отчисления менеджеру, курировавшему сделку.
Далее приведено описание процессов, которые менеджер по продажам на
данный момент. Разрабатываемое автоматизированное рабочее место менеджера
по продажам должно быть простым в использовании и легким в освоении. Новые
сотрудники не должны испытывать неудобства в использовании, а процесс
адаптации занимать минимальное время, так как экономия временных ресурсов
является
немаловажным
показателем
производительности
и
конкурентоспособности. Функционал системы автоматизированного рабочего
места менеджера по продажам представлен на рисунке 1.2
12
Рисунок 1.2 – Диаграмма вариантов использования –
«Продажа корпусной мебели»
1.3 Обоснование необходимости автоматизации работы менеджера по
продажам
В результате анализа обязанностей, схемы работы, очередности обработки
информации выделены следующие недостатки:

большие затраты внимания менеджера по продажам на выполнение
рутинных операций и составление реестров и отчетов;

неполное и неэффективное использование технических средств,
имеющихся в наличии;

низкая оперативность, снижающая качество работы.
Очевидно,
представлении,
что
что
работа
сильно
менеджера
влияет
на
довольно
результаты
рутинна,
в
данном
деятельности: работа
замедляется, возникает большое количество ошибок, документы могут быть
оформлены некорректно. Из-за этого начальнику отдела продаж и маркетинга
приходится проверять и перепроверять созданные документы и правильность
суммы оплаты. Вся эта работа становится очень трудоемкой и требующей
больших затрат времени и внимания, она сужает возможности оперативного
получения информации.
Таким образом, на основании приведенных выше недостатков возникла
необходимость автоматизации работы менеджера по продажам, что позволит
надежно хранить, обрабатывать информацию и при этом резко снизить
трудоемкость и повысить достоверность, оперативность получения результатной
информации и итоговых документов.
1.4 Требования к системе
1.4.1 Функциональные требования
13
В процессе ознакомления с деятельностью компании ООО «Талисман» и
изучения предметной области работы менеджера по продажам были выявлены
следующие функциональные требования к системе:

возможность аутентификации пользователя в системе;

возможность ведения справочника клиентов (добавлять и удалять
клиентов, изменять их контактные данные);

возможность ведения документации (списка договоров, списка актов
о выполнении работы, месячного отчета о работе).

возможность заполнения шаблонов договора и акта о выполнении
работы;

возможность печати договора, акта о выполнении работы и отчета по
продажам за месяц.
1.4.2 Нефункциональные требования
Основными
нефункциональными
требованиями
для
разрабатываемой
информационной системы являются:

понятный для пользователя интерфейс;

использование базы данных для хранения информации;

обеспечение непротиворечивости и целостности данных.
1.5 Обзор аналогов и прототипов
На момент написания данной работы поиск аналогов разрабатываемой
информационной системы выявил несколько программных решений.
Рассмотрим наиболее популярные из них.
1.
АПЕК CRM Lite
14
«АПЕК
CRM
Lite» —
мощная
CRM-система,
которая
позволяет
централизовано управлять: информацией о клиентах, продажами, закупками,
финансами, задачами и кадрами.
Программа АПЕК CRM Lite позволяет вести учет всех взаимоотношений с
клиентами: полную информацию о контрагенте (реквизиты, контактные лица,
телефоны); сохранять всю историю сотрудничества; учет проектов, счетов,
договоров, документов; финансовый анализ.
2.
Клиентская база
Инструмент управления бизнесом. С помощью программы можно вести
единую базу данных; создавать любые таблицы, используя более восьми типов
полей; разграничивать для пользователей права на доступ к данным; проводить
персонализированные электронные рассылки с возможностью планирования
времени и прикрепления файлов; генерировать документы с помощью шаблонов
на базе данных из любых таблиц и многое другое. Поставляется в трех версиях:
Local, Web и SaaS. Из недостатков системы можно выявить:

Ограниченный срок поддержки

Платное сопровождение и дополнительная настройка
3.
Galloper CRM
Galloper CRM - это простая CRM система для автоматизации отделов
продаж, необходимая:

для внедрения концепции CRM;

при неэффективной работе менеджеров (например, все еще в Excel);

при потере контактных данных и сложностях в восстановлении
истории взаимодействия с клиентом;

при отсутствии механизма учета, контроля и анализа продаж и
отношений с клиентами.
4.
«1С: Предприятие» 8.0
15
Система программ «1С: Предприятие 8» включает в себя платформу и
прикладные
решения,
разработанные
на
ее
основе,
для
автоматизации
деятельности организаций и частных лиц. Сама платформа не является
программным продуктом для использования конечными пользователями, которые
обычно работают с одним из многих прикладных решений (конфигураций),
разработанных на данной платформе. Такой подход позволяет автоматизировать
различные виды деятельности, используя единую технологическую платформу.
Платформа 1С: Предприятие 8 была создана с учетом 6-летнего опыта
применения системы программ 1С: Предприятие 7.7, которую используют
десятки тысяч разработчиков. Несмотря на значительные изменения, новая
версия 8 сохранила идеологическую преемственность с предыдущими версиями.
Таблица 1 – Сравнительный анализ аналогов
Название
Ведение
Ведение
Печать
Не
аналога
справочника
документации
документации
покупка
клиентов
требуется
лицензии
программы
Не
требуется
дополнительная
для
покупка
компонентов
и
обновлений
АПЕК
CRM
+
+
+
-
-
+
+
+
-
-
Galloper CRM
+
+
-
+
-
1С:
+
+
+
-
-
+
+
+
+
+
Lite
Клиентская
база
Предприятие 8
Собственная
разработка
Таким образом, наиболее выгодным и обоснованным решением для
компании будет разработка собственной системы автоматизации рабочего места
менеджера по продажам.
1.6 Описание и систематизация бизнес-процессов предметной области
16
Важнейшим этапом процесса разработки информационной системы
является этап системного анализа и моделирования деятельности предприятия. От
проведения этого этапа зависит успех проекта в целом.
Успех моделирования достигается путем составления разных моделей,
которые отображают бизнес-процессы и которые понятны всем участникам
проекта. Одновременно модель служит для документирования существующего
состояния дел и изучения возможностей улучшения работы.
Процесс моделирования начинается с анализа предметной области и
включает:

сбор информации о предметной области;

документирование полученной информации;

представление ее в виде модели.
Анализ предметной области связан с понятиями, определяющими субъект
моделирования, цель и точку зрения на модель, позволяющими наиболее точно
рассмотреть исследуемую область. Под субъектом моделирования понимается
сама система, при этом необходимо точно установить, что входит в систему, а что
лежит за ее пределами, определить, что будет в дальнейшем рассматриваться как
компоненты системы, а что как внешние воздействия. Другими словами, в начале
моделирования необходимо определить предметную область и внешнюю область,
находящуюся за пределами рассмотрения.
Описание предметной области как системы в целом, так и ее компонентов
является основой построения модели.
При определении предметной области необходимо учитывать две ее
характеристики – широту и глубину. Широта определяет границы модели – что
будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на
каком уровне детализации модель является завершенной. После определения
границ модели предполагается, что новые объекты не должны вноситься в
систему.
Данная предметная область описана с помощью методологии IDEF0,
которая предназначена для описания существующих бизнес- процессов или
17
информационных потоков с использованием, как естественного языка, так и
графических изображений.
Методология IDEF0 предписывает построение иерархической системы
диаграмм. На верхнем уровне произведем описание системы в целом и её
взаимодействие с окружающим миром.
Модель в IDEF0 может строиться на основе организационной структуры.
В этом случае иерархия объектов в модели должна соответствовать иерархии
структурных подразделений предприятия. Так на контекстной диаграмме
показывается деятельность предприятия в целом, на диаграмме А0 показывается
деятельность
крупных
показывается
структурных
деятельность
отделов
подразделений,
первого
на
диаграмме
крупного
А1
структурного
подразделения и т.д. На нем представлена деятельность крупных структурных
подразделений.
Частично
показаны
потоки
документов
и
материалов.
Рассматриваемая диаграмма является моделью взаимодействия подразделений. О
бизнес-процессах, выполняемых в этих подразделениях можно судить лишь по
косвенным признакам — по названию и по специфике входов-выходов каждого
блока.
В IDEF0 различают четыре типа стрелок:
1.
Вход – это материал или информация, которые используются в ходе
выполнения процесса или преобразуются в выходную информацию.
2.
Управление – правила, стратегии, процедуры или стандарты,
которыми руководствуется процесс.
3.
Выход – это материал или информация, которая получается в ходе
выполнения процесса.
4.
Механизм – это ресурсы, которые выполняют работу (персонал
предприятия, устройства и т.д.).
На рисунке 1.2 рассмотрим действия бизнес-процессов, как они есть
сейчас (модель «AS-IS»).
18
Рисунок 1.2 – Диаграмма бизнес-процесса «Процесс проведения акта продажи
корпусной мебели»
Заявка с сайта компании – заполненная на сайте компании клиентом
заявка, выражающая его желание купить корпусную мебель.
Сообщения из социальных сетей и групп – сообщения, оставленные в
рекламных или социальных ресурсах компании, выражающие желание клиента
купить корпусную мебель.
Заявка от клиента, пришедшего в офис лично – пришедший лично клиент,
узнавший о компании из рекламных ресурсов, и оставивший заявку.
Удачный телефонный звонок заинтересованному клиенту – звонок, после
которого собеседник заинтересовался в покупке корпусной мебели.
Денежные средства клиента – денежные средства, которые заплатит
клиент в процессе заключения договора в качестве предоплаты и оплаты за
полученную корпусную мебель.
Каталог мебели – каталог с ассортиментом мебели, присутствующей в
наличии или доступной для изготовления, который просматривает клиент для
составления заявки.
19
Действующее законодательство – документ, содержащий правила, общие
принципы, характеристики, касающиеся определенных видов деятельности или
их результатов, и доступный широкому кругу потребителей (пользователей).
Устав компании – документ, который определяет порядок и условия
работы и функционирования гостиницы.
Менеджер по продажам – сотрудник, ведущий процесс продажи.
Команда по сборке и установке – специалисты, доставляющие мебель по
указанному адресу и проводящие её сборку и установку.
Запись в списке договоров – запись с хранящейся информацией о
заключенных договорах для составления и ведения отчетности.
Запись в списке актов – запись с хранящейся информацией о выполненном
акте продажи для составления и ведения отчетности.
Запись в месячный отчет по продажам – запись, из которой в дальнейшем
будет составлен документ, хранящий информацию о размерах продаж за месяц.
Произведем дальнейшее разбиение для получения диаграммы детализация
процесса «Проведение процесса продажи корпусной мебели».
На рисунке 1.3 представлена детализация процесса «Процесс продажи
корпусной мебели».
20
Рисунок 1.3 – Детализация процесса «Процесс проведения акта корпусной
мебели»
Как видно из диаграммы, весь процесс разбивается на шесть блоков:
Поиск клиента – различными способами и с помощью информационных,
социальных и рекламных ресурсов менеджер по продажам находит людей,
заинтересованных в покупке корпусной мебели.
Переговоры с клиентом и подтверждение заказа – проведение переговоров
с клиентами в различных форматах для выяснения всех просьб и пожеланий, а так
же размеров и особенностей покупаемой корпусной мебели.
Создание документации – после получения сформированного заказа
менеджер по продажам создает документацию, удостоверяющую процесс
продажи.
Оплата и проведение работ по доставке и установке – клиент оплачивает
заказ по договору и получает купленную корпусную мебель в надлежащем
состоянии.
Процесс подписи акта о выполнении – клиент подписывает документ,
удостоверяющий, что корпусная мебель была доставлена в полном объеме и в
срок, не имела никаких изъянов, а также была правильно и надежно собрана.
Занесение информации из договора в отчет по продажам – менеджер
заносит информацию о закрытой сделке в отчет по продажам для составления и
ведения отчетности.
Диаграмма декомпозиции блока «Поиск клиента» представлена на
рисунке 1.4
21
Рисунок 1.4 – Декомпозиция блока «Поиск клиента»
Как видно из диаграммы, блок «Поиск клиента» разбивается на три блока:
Проверка информационных и рекламных ресурсов на заинтересованных
клиентов – менеджер по продажам производит проверку на оставленные
сообщения и заявки.
Обратный звонок клиенту для подтверждения заявки – менеджер
осуществляет обратную связь с потенциальным клиентом для того, чтобы
удостовериться в их заинтересованности в покупке.
Принятая заявка – если клиент подтвердил заинтересованность в покупке
в процессе обратной связи или находиться непосредственно в контакте с
менеджером лично, менеджер принимает заявку и назначает дату переговоров.
Диаграмма
декомпозиции
блока
«Переговоры
подтверждение заказа» представлена на рисунке 1.5
с
клиентом
и
22
Рисунок 1.5 – Декомпозиция блока «Переговоры с клиентом и подтверждение
заказа»
Как видно из диаграммы, блок «Переговоры с клиентом и подтверждение
заказа» разбивается на четыре блока:
Обсуждение особенностей и специфики желаемой клиентом мебели –
менеджер проводит переговоры с клиентом в назначенную дату для обсуждения
особенностей и специфики желаемой клиентом мебели и подтверждает намерение
клиента формировать заказ на покупку.
Выезд специалиста-замерщика на указанный клиентом адрес – если
стандартные размеры мебели не подходят клиенту, или есть какие-либо
особенности, которые он хотел бы предложить, производится выезд специалистазамерщика на указанный клиентом адрес.
Урегулирование последних недочетов и пожеланий клиента – менеджер
проводит дополнительные переговоры для того, чтобы удостовериться в
окончательной правильности и сформировать заказ.
Формирование заказа – создание заказа на покупку корпусной мебели.
Диаграмма декомпозиции блока «Создание документации» представлена
на рисунке 1.6
23
Рисунок 1.6 – Декомпозиция блока «Создание документации»
Как видно из диаграммы, блок «Создание документации» разбивается на
девять блоков:
Создание договора – создание менеджером договора купли-продажи “с
нуля”.
Заполнение договора – заполнение бланка договора в соответствии с
полученной информации от клиента и подписание компанией.
Печать и подписание договора компанией.
Подписание договора клиентом – подписание договора клиентом и
окончательное заключение договора.
Напоминающий звонок клиенту – при задержке предоплаты менеджер по
продажам напоминает клиенту о необходимости внесения предоплаты в срок.
Внесение предоплаты клиентом.
Создание акта о выполнении – создание бланка акта о выполнении «с
нуля».
Заполнение акта о выполнении – заполнение бланка акта о выполнении в
соответствии с полученной информации из составленного договора.
Печать и подписание акта компанией.
24
Диаграмма декомпозиции блока «Оплата и проведение работ по доставке
и установке» представлена на рисунке 1.7
Рисунок 1.7 – Декомпозиция блока «Оплата и проведение работ по доставке и
установке»
Как видно из диаграммы, блок «Оплата и проведение работ по доставке и
установке» разбивается на четыре блока:
Оплата основной части договора – оплата клиентом остальной части
договора купли-продажи.
Доставка мебели по адресу договора – после получения оплаты и закрытия
договора мебель доставляется на указанный клиентом адрес.
Сборка и Установка мебели.
Передача акта о выполнении клиенту – после проверки клиентом
целостности, качества и количества полученной мебели и её установки, сотрудник
установки отдает клиенту акт о выполнении для подписания.
Диаграмма декомпозиции блока «Процесс подписи акта о выполнении»
представлена на рисунке 1.8
25
Рисунок 1.8 – Декомпозиция блока «Процесс подписи акта о выполнении»
Как видно из диаграммы, блок «Процесс подписи акта о выполнении»
разбивается на два блока:
Подписание акта о выполнении работ клиентом – после завершения всех
работ клиент подписывает акт о выполнении.
Доставка акта в офис компании – подписанный акт доставляется в офис
компании, и акт купли-продажи считается закрытым и поставленным на
гарантию.
На рисунке 1.9 представлена декомпозиция процесса «Процесс
проведения акта продажи корпусной мебели» после внедрения
автоматизированного рабочего места (модель TO-BE).
26
Рисунок 1.9 – Диаграмма процесса «Процесс проведения акта продажи корпусной
мебели» после внедрения системы автоматизации
На диаграмме процесса представлено:
Заявка с сайта компании – заполненная на сайте компании клиентом
заявка, выражающая его желание купить корпусную мебель.
Сообщения из социальных сетей и групп – сообщения, оставленные в
рекламных или социальных ресурсах компании, выражающие желание клиента
купить корпусную мебель.
Заявка от клиента, пришедшего в офис лично – пришедший лично клиент,
узнавший о компании из рекламных ресурсов, и оставивший заявку.
Удачный телефонный звонок заинтересованному клиенту – звонок, после
которого собеседник заинтересовался в покупке корпусной мебели.
Денежные средства клиента – денежные средства, которые заплатит
клиент в процессе заключения договора в качестве предоплаты и оплаты за
полученную корпусную мебель.
Шаблон договора – заранее составленный и хранящийся в системе шаблон
договора купли-продажи.
27
Шаблон акта о выполнении – заранее составленный и хранящийся в
системе шаблон договора акта о выполнении работ.
Каталог мебели – каталог с ассортиментом мебели, присутствующей в
наличии или доступной для изготовления, который просматривает клиент для
составления заявки.
Действующее законодательство – документ, содержащий правила, общие
принципы, характеристики, касающиеся определенных видов деятельности или
их результатов, и доступный широкому кругу потребителей (пользователей).
Устав компании – документ, который определяет порядок и условия
работы и функционирования гостиницы.
Менеджер по продажам – сотрудник, ведущий процесс продажи.
АРМ – система автоматизации рабочего места.
Запись в списке договоров – запись с хранящейся информацией о
заключенных договорах для составления и ведения отчетности.
Запись в списке актов – запись с хранящейся информацией о выполненном
акте продажи для составления и ведения отчетности.
Запись в месячный отчет по продажам – запись, из которой в дальнейшем
будет составлен документ, хранящий информацию о размерах продаж за месяц.
Произведем дальнейшее разбиение на подсистемы для получения
диаграммы детализация процесса «Проведение процесса продажи корпусной
мебели» после внедрения системы АРМ.
На
рисунке
1.10
представлена
декомпозиция
процесса
«Процесс
проведения акта продажи корпусной мебели» после внедрения системы АРМ.
28
Рисунок 1.10 – Декомпозиция процесса «Процесс проведения акта продажи
корпусной мебели» после внедрения системы АРМ
Как видно из диаграммы, весь процесс разбивается на шесть блоков:
Поиск клиента – различными способами и с помощью информационных,
социальных и рекламных ресурсов менеджер по продажам находит людей,
заинтересованных в покупке корпусной мебели.
Переговоры с клиентом и подтверждение заказа – проведение переговоров
с клиентами в различных форматах для выяснения всех просьб и пожеланий, а так
же размеров и особенностей покупаемой корпусной мебели.
Создание документации – после получения сформированного заказа
менеджер по продажам создает документацию, удостоверяющую процесс
продажи.
Оплата и проведение работ по доставке и установке – клиент оплачивает
заказ по договору и получает купленную корпусную мебель в надлежащем
состоянии.
Заверка
акта
о
выполнении
–
клиент
подписывает
документ,
удостоверяющий, что корпусная мебель была доставлена в полном объеме и в
срок, не имела никаких изъянов, а также была правильно и надежно собрана.
29
Занесение информации из договора в отчет по продажам – менеджер
заносит информацию о закрытой сделке в отчет по продажам для составления и
ведения отчетности.
Диаграмма декомпозиции блока «Заверка акта о выполнении» после
внедрения системы автоматизации представлена на рисунке 1.11
Рисунок 1.11 – Декомпозиция блока «Переговоры с клиентом и
подтверждение заказа» после внедрения системы АРМ
Как видно из диаграммы, блок «Переговоры с клиентом и подтверждение
заказа» после внедрения системы автоматизации разбивается на четыре блока:
Обсуждение особенностей и специфики желаемой клиентом мебели –
менеджер проводит переговоры с клиентом в назначенную дату для обсуждения
особенностей и специфики желаемой клиентом мебели и подтверждает намерение
клиента формировать заказ на покупку.
Выезд специалиста-замерщика на указанный клиентом адрес – если
стандартные размеры мебели не подходят клиенту, или есть какие-либо
особенности, которые он хотел бы предложить, производится выезд специалистазамерщика на указанный клиентом адрес.
30
Урегулирование последних недочетов и пожеланий клиента – менеджер
проводит дополнительные переговоры для того, чтобы удостовериться в
окончательной правильности и сформировать заказ.
Формирование заказа – создание заказа на покупку корпусной мебели.
Как видно из диаграммы, внедрение системы автоматизации позволило
перенести основную работу, связанную с документацией, на систему, что
существенно сэкономит затрачиваемое время менеджера по продажам.
Диаграмма
декомпозиции
блока
«Создание
документации»
после
внедрения системы автоматизации представлена на рисунке 1.11
Рисунок 1.9 – Декомпозиция процесса «Создание документации» после внедрения
системы АРМ
Как видно из диаграммы, блок «Создание документации» разбивается на
семь блоков:
Заполнение договора – заполнение бланка договора в соответствии с
полученной информации от клиента и подписание компанией.
Печать и подписание договора компанией.
31
Подписание договора клиентом – подписание договора клиентом и
окончательное заключение договора.
Напоминающий звонок клиенту – при задержке предоплаты менеджер по
продажам напоминает клиенту о необходимости внесения предоплаты в срок.
Внесение предоплаты клиентом.
Заполнение акта о выполнении – заполнение бланка акта о выполнении в
соответствии с полученной информации из составленного договора.
Печать и подписание акта компанией.
Как видно из диаграммы, внедрение системы автоматизации позволило
полностью убрать блоки «Создание договора» и «Создание акта о выполнении».
Так же система позволила упростить процессы в блоках «Заполнение договора»,
«Печать и подпись договора компанией», «Заполнение акта о выполнении работ»
и
«Печать и подпись акта компанией»,
что существенно сэкономит
затрачиваемое время и ресурсы менеджера по продажам.
32
2 ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННОГО РАБОЧЕГО
МЕСТА МЕНЕДЖЕРА ПО ПРОДАЖАМ КОРПУСНОЙ МЕБЕЛИ.
2.1 Проектирование структуры системы
Структура автоматизированного рабочего места менеджера по продажам
представлена на рисунке 2.1
Рисунок 2.1 – Структура системы
Модуль редактирования справочников – модуль, позволяющий добавить,
редактировать или удалить информацию из форм справочников клиентов и
мебели.
Модуль формирования и корректировки информации о встречах компании
– модуль, позволяющий добавить, редактировать или удалить информацию в
форме встреч компании.
Модуль формирования и корректировки информации о договорах
компании – модуль, позволяющий добавить, редактировать или удалить
информацию о договорах в форме договоров компании.
Модуль
формирования
и
корректировки
информации
об
актах
выполненных работ компании – модуль, позволяющий добавить, редактировать
33
или удалить информацию об актах выполненных работ в форме актов
выполненных работ компании.
Модуль печати выходных документов – модуль, позволяющий получить
заполненный информацией из базы данных шаблон документа и произвести
последующую его печать.
2.2 Концептуальное проектирование схемы базы данных
База данных (БД) – совокупность специальным образом организованных
(структурированных) данных, хранимых в памяти вычислительной системы и
отображающих состояние объектов и их связей в предметной области.
Логическую структуру хранимых данных называют моделью представления
данных (моделью данных). Основные модели данных:

клиент;

иерархическая;

сетевая;

реляционная;

постреляционная;

многомерная;

объектно-ориентированная;

объектно-реляционная.
Для реализации базы данных была выбрана «Реляционная СУБД», так как
это наиболее распространенная СУБД, в которой присутствуют все необходимые
компоненты для выполнения поставленных задач.
При анализе информационных потоков процессов предметной области
были выделены следующие сущности:

клиент;

должность;

договор;

товар;
34

заказ;

акт о выполнении;

встреча;

отчет по продажам.
Рассмотрим сущность «Клиент». Данная сущность содержит информацию
о клиенте и обладает следующими атрибутами:

IdКлиент – идентификатор клиента (первичный ключ);

ФИО;

Организация или частное лицо;

Телефон.
Рассмотрим
сущность
«Встреча».
Данная
сущность
содержит
информацию о проведенных встречах и переговорах и обладает следующими
атрибутами:

IdВстреча – идентификатор записи встречи (первичный ключ);

Дата и время встречи;

Место встречи;

Формат встречи;

Результат встречи.
Рассмотрим сущность «Товар». Данная сущность содержит информацию о
товаре компании и обладает следующими атрибутами:

IdТовар – идентификатор товара (первичный ключ);

Артикул;

Название;

Стоимость;

Описание – краткая характеристика товара.
Рассмотрим сущность «Заказ». Данная сущность содержит информацию о
количестве и стоимости покупаемого товара и
обладает следующими
атрибутами:

IdЗаказ – идентификатор заказа (первичный ключ);
35

Название в заказе – название товара в заказе;

Вид;

Размеры;

Количество в заказе.
Рассмотрим
сущность
«Договор».
Данная
сущность
содержит
информацию о договорах компании и обладает следующими атрибутами:

IdДоговор – идентификатор договора (первичный ключ);

Номер договора;

Статус;

Дата подписания компанией;

Дата подписания клиентом;

Размер предоплаты;

Адрес доставки.
Рассмотрим сущность «Акт о выполнении». Данная сущность содержит
информацию об актах выполненных работ компании, и обладает следующими
атрибутами:

IdАкт о выполнении – идентификатор акта (первичный ключ);

Статус;

Дата подписания компанией;

Дата проведения работ и подписания клиентом;

Срок истечения гарантии.
Рассмотрим сущность «Отчет по продажам». Данная сущность содержит
информацию об отчетах по продажам компании и
обладает следующими
атрибутами:

IdОтчет по продажам – идентификатор отчета (первичный ключ);

Менеджер, проводивший сделку;

Выручка менеджера.
Рассмотрим
сущность
«Должность».
Данная
сущность
содержит
информацию о возможных должностях и обладает следующими атрибутами:
36

IdДолжность – идентификатор должности (первичный ключ);

Обозначение должности;

Чей представитель;
Для создания целостной структуры базы данных необходимо определить
связи между выделенными сущностями. В разработанной базе данных сущности
связаны между собой следующим образом:
Сущность «Товар» связана с сущностью «Заказ» связью «многие ко
многим». Данная связь реализуется путём введения дополнительной таблицы
«Заказ_has_Товар» и двух связей: таблица «Заказ» связана с таблицей
«Заказ_has_Товар» связью один ко многим и таблица «Товар» связана с таблицей
«Заказ_has_Товар»
связью
один
ко
многим.
Данные
связи
являются
идентифицирующими. Таким образом, один товар может присутствовать во
многих заказах, и один заказ может содержать в себе множество товаров.
Сущность
«Клиент»
связана
с
сущностью
«Договор»
неидентифицирующей связью один ко многим, так как один клиент может
заключить множество договоров.
Сущность
«Клиент»
связана
с
сущностью
«Встреча»
неидентифицирующей связью один ко многим, так как один клиент может
проводить множество встреч.
Сущность
«Клиент»
связана
с
сущностью
«Должность»
неидентифицирующей связью один ко многим, так как один клиент может иметь
множество должностей.
Сущность «Заказ» связана с сущностью «Договор» неидентифицирующей
связью один ко многим, так как один договор содержит один заказ, однако один
заказ может содержаться во многих договорах.
Сущность «Договор» связана с сущностью «Акт о выполнении»
неидентифицирующей связью один к одному, так как на один заключенный
договор приходится один акт о выполнении работ.
37
Сущность «Договор» связана с сущностью «Отчет по продажам»
неидентифицирующей связью один ко многим, так как все заключенные договора
заносятся в один отчет по продажам.
Схема базы данных на логическом уровне представлена на рисунке
2.2
Рисунок 2.2 – Логическая схема базы данных
Далее проведем реорганизацию логического уровня концептуальной
схемы в физический уровень.
В ходе реорганизации для атрибутов были прописаны следующие типы
данных:

атрибутам «IdClient», «IdProduct», «IdContract», «IdAct», «IdZakaz»,
«IdMeeting», «IdReport», «Art», «Cost», «ZTotalCount», «ZTotalCost», «ZCount»,
«CNumber», «CPreCost», «CTotalCost», «ActToContract»,
«Phone», «DoneProfit»
был присвоен тип INTEGER, так как все эти атрибуты содержат целочисленные
значения;

атрибутам «Name», «Description», «ZName», «FIO», «Organisation»,
«CStatus», «AStatus», «Addres», «MeetingPlace», «MeetingType», «PositionSale»,
«PositionBuy», «DoneManager» был присвоен тип VARCHAR, варьирующийся от
45 до 255 символов в зависимости от необходимой длины;
38

атрибутам «CDateCompSign», «CDateClientSign», «DateTimeMeeting»
был присвоен тип DATETIME, так как эти атрибуты содержат дату и время;

атрибутам «ActDateCompSign», «ActDateClientSign», «GDate» был
присвоен тип DATE, так как эти атрибуты содержат дату.

атрибутам «MeetingResult», «Position» был присвоен тип TEXT, так
как эти атрибуты содержат текст.
Схема базы данных на физическом уровне представлена на рисунке 2.3
Рисунок 2.3 – Физическая схема базы данных
2.3 Обеспечение целостности данных
Целостность БД есть свойство базы данных, означающее, что в ней
содержится полная, непротиворечивая, согласованная и адекватно отражающая
предметную область информация.
В базе данных, построенной на реляционной модели, задается ряд правил
целостности, которые, по сути, являются ограничениями для всех допустимых
состояний базы данных и гарантируют корректность данных.
Для ограничения целостности NOT NULL определяем ненулевые значения
для тех столбцов таблицы, которые действительно требуют, чтобы значение было
39
всегда. В таблице «Client» считается недопустимым, чтобы отсутствовало имя,
фамилия, отчество, адрес и телефон клиента.
Ограничение UNIQUE определяет вторичный ключ для таблицы. Это —
столбец или группа столбцов, которую можно использовать, как другой способ
уникальной идентификации строки.
Ограничение CHECK используется для проверки допустимости данных,
вводимых в конкретный столбец таблицы, т.е. ограничение CHECK обеспечивает
еще один уровень защиты данных.
Ограничения целостности CHECK задают диапазон возможных значений
для столбца или столбцов. В основе ограничений целостности CHECK лежит
использование логических выражений.
Ссылочная целостность – это ограничение базы данных, гарантирующее,
что
ссылки
между
неповрежденными.
данными
Ссылочная
являются
действительно
целостность
является
корректными
и
фундаментальным
принципом теории баз данных. Основная идея – база данных должна не только
сохранять данные, но и активно содействовать обеспечению их качества.
Основные стратегии поддержания ссылочной целостности:
RESTRICT – запрещающая; CASCADE – каскадная; SETNULL – задание
значения NULL.
Стратегия RESTRICT (запрещающая) – не позволяет модифицировать
ссылочные поля или удалять записи из родительской таблицы, если в потомке
есть связанные записи. При вставке или модификации потомка запрещает
значения атрибутов не соответствующих ссылочным полям.
Стратегия CASCADE (каскадная) – при удалении записи родителя
подразумевает удаление всех потомков. При модификации в родительской
таблице в потомках должны изменяться значения ссылочных полей на новые.
Каскад на вставку подразумевает вставку хотя бы одного потомка.
Стратегия SETNULL – при удалении родителя устанавливает значения
ссылочных полей потомка в Null. При этом данная стратегия не применима для
идентифицирующих связей, связей, не допускающих null значений и категорий.
40
Для обеспечения ссылочной целостности разработанной базы данных
были применены следующие стратегии:
Для сущности-родителя – стратегия CASCADE для добавления и
изменения атрибутов, стратегия RESTRICT для удаления атрибутов. Для
сущности-потомка – стратегия RESTRICT для добавления, стратегия CASCADE
для изменения атрибутов.
2.4 Обеспечение безопасности данных
Безопасность
данных
–
защита
данных
от
несанкционированной
случайной или намеренной модификации, разрушения или раскрытия.
В СУБД соблюдается 3 основных аспекта информационной безопасности:
a)
Конфиденциальность
–
необходимость предотвращения
разглашения, утечки информации.
b)
Целостность
c)
Доступность – обеспечение доступа к информации и связанным с
ней активам только авторизованным пользователям по мере необходимости.
1)
Управление безопасностью
В современных СУБД поддерживается как избирательный, так и
обязательный подходы к обеспечению безопасности данных.
В случае избирательного управления, некий пользователь обладает
различными правами, или привилегиями, и полномочиями при работе с
различными объектами. Поскольку разные пользователи могут обладать
различными правами доступа к одному и тому же объекту, такие системы очень
гибкие.
В случае обязательного управления, каждому объекту присваивается
некий квалификационный уровень, ну а каждому пользователю предоставляются
права доступа к тому или иному уровню; и соответственно, если у вас есть права
доступа на какой-то уровень — все, что на этот уровень записано, ко всему у вас
имеется доступ. Считается, что такие системы жесткие, статичные, но они проще
в управлении: легко всем объектам дать какой-либо номер (1,2,3,4…) и
41
пользователю потом присвоить доступ кому до 5-го, кому до 6-го, кому до 7-го
уровня и т.д. в порядке повышения приоритета.
В обычных СУБД для идентификации и проверки подлинности
пользователя применяется либо соответствующий механизм операционной
системы, либо то, что имеется в SQL-операторе connect (там есть специальные
параметры для доступа при подключении). В момент начала сеанса работы с
сервером базы данных пользователь идентифицирует контакт, или логин, своим
именем, а средством аутентификации служит пароль.
Идентификатор
пользователя
для
–
СУБД.
это
краткое
Является
имя,
основой
однозначно
систем
определяющее
безопасности.
Для
пользователей создаются соответствующие учетные записи.
Идентификация позволяет субъекту (т.е. пользователю или процессу,
действующему от имени пользователя) назвать себя, т.е. сообщить свое имя
(логин).
По средствам аутентификации (т.е. проверки подлинности) вторая сторона
(операционная система или собственно СУБД) убеждается, что субъект
действительно тот, за кого он себя выдает.
Под авторизацией понимается служба, гарантирующая, что пользователю
разрешен доступ к ресурсу. Эта служба устанавливает, имеет ли право
аутентифицируемый клиент на использование того или иного объекта.
Для особо уязвимых систем (например, банковских и т.п.) используются
более
сложные
системы
защиты.
Так,
например,
известны
системы
с
последовательным созданием нескольких вопросов личного характера, с
ограничением времени на их ответ и количества попыток (как в некоторых
мобильных приложениях).
В стандарте ANSI ISO вместо термина «идентификатор пользователя»
(user ID) используется термин «идентификатор прав доступа» (authorization ID).
Система безопасности на сервере может быть организована 3-мя
способами:
42
1.
Стандартная безопасность: когда на сервер требуется отдельный
доступ (т.е. в операционную систему вы входите с одним паролем, а на сервер
базы данных с другим);
2.
Интегрированная безопасность (достаточно часто используют):
входите в операционную систему с каким-то пользовательским паролем, и это же
имя с этим же паролем зарегистрировано в СУБД. Второй раз входить не надо.
Раз попал человек на сервер, ну да ладно, пусть пользуется всем, что есть.
3.
Смешанная система, которая позволяет входить и первым, и вторым
способом.
2)
Управление доступом
Обычно в СУБД применяется произвольное управление доступом: когда
владелец объекта (в крайнем случае, администратор базы данных, но чаще
владелец) передает права доступа (permissions) кому-нибудь. При этом права
могут передаваться отдельным пользователям, группам пользователей, или ролям.
1.
Учетная запись создается для отдельных пользователей с логином и
паролем. Как правило, это делает администратор базы данных.
2.
Группа – именованная совокупность пользователей, чаще всего в
группы объединяют на основе какой-либо организации (по отделам, по комнатам,
по бригадам и т.п.). Формально говоря, пользователь может входить в разные
группы и входить в систему с разной возможностью (должен указать от имени
какой группы он входит).
3.
Роль – некий, часто служебный, перечень возможностей. Например,
бухгалтер, кладовщик и т.п. Приходит человек на работу, ему присваивают такие
права доступа, и он с ними может входить. Такой вариант сейчас довольно
хорошо используется, т.к. это достаточно удобно оговорить на предприятии. При
желании можно пересмотреть эту роль, и она сразу всех потом поменяет. Как
правило, считается, что привилегии роли имеют приоритет перед привилегиями
групп[17].
В
функцией
разрабатываемой
аутентификации,
системе
управление
благодаря
которой
доступом
доступ
к
осуществляется
данным
будет
43
предоставляться только человеку, знающему имя пользователя и пароль для входа
в систему.
2.5 Разработка транзитивной сети диалога с пользователем
Перед
началом
реализации
экранных форм
системы
необходимо
тщательно продумать пользовательский интерфейс, т. е. разработать логику
диалога системы с пользователем. Исходя из специфики реализации системы в
выбранной среде разработки, логику диалога пользователя можно представить в
виде транзитивной сети. В данной транзитивной сети состояния соответствуют
различным формам, а дуги – переходам между состояниями с помощью кнопок на
этих формах.
Транзитивная сеть логики диалога пользователя представлена на рисунке
3.1
Рисунок 3.1 – Транзитивная сеть диалога пользователя
44
Состояния транзитивной сети приведены в таблице 3. Информация о
действиях, переводящих диалог из состояния в состояние, сведена в таблицу 4.
Таблица 3 – Описание состояний транзитивной сети
Состояние
Описание
S
Отображение формы авторизации (Начальное состояние)
F
Закрытие программы (финальное состояние)
S1
Главная форма
S2
Форма «Справочник мебели»
S3
Форма «Добавление нового пункта справочника мебели»
S4
Форма «Изменение пункта справочника мебели»
S5
Форма «Справочник клиентов»
S6
Форма «Добавление нового пункта справочника клиентов»
S7
Форма «Изменение пункта справочника клиентов»
S8
Форма «Список встреч»
S9
Форма «Добавление новой встречи»
S10
Форма «Изменение встречи»
S11
Форма «Договора компании»
S12
Форма «Добавление договора»
S13
Форма «Добавление заказа в договор»
S14
Форма «Добавление позиции в новый заказ»
S15
Форма «Изменение договора»
S16
Форма «Просмотр заказа в договоре»
S17
Отображение заполненного шаблона договора для печати
S18
Форма «Акты компании»
S19
Форма «Добавление нового акта»
S20
Форма «Изменение акта»
S21
Отображение заполненного шаблона акта о выполненной
работе для печати
S22
Форма «Отчет по продажам»
45
Продолжение таблицы 3
S23
Отображение заполненного шаблона отчета по продажам для
печати
Таблица 4 – Описание дуг транзитивной сети
Дуга
Описание
1
Нажатие кнопки «Авторизация» при верных данных
2
Нажатие кнопки «Справочник мебели»
3
Нажатие кнопки «Назад на главную»
4
Нажатие кнопки «Добавить»
5
Нажатие кнопки «Подтвердить добавление»
6
Нажатие кнопки «Изменить»
7
Нажатие кнопки «Подтвердить изменение»
8
Нажатие кнопки «Удалить»
9
Нажатие кнопки «Справочник клиентов»
10
Нажатие кнопки «Назад на главную»
11
Нажатие кнопки «Добавить»
12
Нажатие кнопки «Подтвердить добавление»
13
Нажатие кнопки «Изменить»
14
Нажатие кнопки «Подтвердить изменение»
15
Нажатие кнопки «Удалить»
16
Нажатие кнопки «Список встреч»
17
Нажатие кнопки «Назад на главную»
18
Нажатие кнопки «Добавить»
19
Нажатие кнопки «Подтвердить добавление»
20
Нажатие кнопки «Изменить»
21
Нажатие кнопки «Подтвердить изменение»
22
Нажатие кнопки «Договора компании»
23
Нажатие кнопки «Назад на главную»
46
Продолжение таблицы 4
24
Нажатие кнопки «Добавить»
25
Нажатие кнопки «Подтвердить добавление»
26
Нажатие кнопки «Добавить заказ»
27
Нажатие кнопки «Сформировать заказ»
28
Нажатие кнопки «Добавить позицию»
29
Нажатие кнопки «Подтвердить»
30
Нажатие кнопки «Удалить»
31
Нажатие кнопки «Занести в месячный отчет»
32
Нажатие кнопки «Изменить»
33
Нажатие кнопки «Подтвердить изменения»
34
Нажатие кнопки «Просмотреть содержимое заказа»
35
Нажатие кнопки «Назад»
36
Нажатие кнопки «Открыть для печати»
37
Нажатие кнопки «Добавить»
38
Нажатие кнопки «Подтвердить добавление»
39
Нажатие кнопки «Изменить»
40
Нажатие кнопки «Подтвердить изменение»
41
Нажатие кнопки «Удалить»
42
Нажатие кнопки «Открыть для печати»
43
Нажатие кнопки «Акты компании»
44
Нажатие кнопки «Назад на главную»
45
Нажатие кнопки «Просмотреть отчет по продажам»
46
Нажатие кнопки «Назад на главную»
47
Нажатие кнопки «Открыть для печати»
48
Нажатие кнопки «Удалить»
49
Нажатие кнопки «Выход»
47
3 РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОГО РАБОЧЕГО МЕСТА
МЕНЕДЖЕРА ПО ПРОДАЖАМ КОРПУСНОЙ МЕБЕЛИ
3.1 Анализ программных средств и технологий
В качестве среды разработки автоматизированного рабочего места была
выбрана программа Lazarus и СУБД Firebird SQL.
Lazarus — открытая среда
разработки
программного
обеспечения на
языке Object Pascal для компилятора Free Pascal (часто используется сокращение
FPC — Free Pascal Compiler, бесплатно распространяемый компилятор языка
программирования Pascal). Интегрированная среда разработки предоставляет
возможность кроссплатформенной разработки
приложений
в Delphi-подобном
окружении.
Основан на библиотеке визуальных компонентов Lazarus Component
Library (LCL). В настоящее время практически полностью поддерживает
виджеты Win32, GTK1, GTK2, Carbon, Qt. В разработке находятся
виджеты WinCE.
Основные функции среды разработки Lazarus:

Поддерживает преобразование проектов Delphi;

Реализован основной набор элементов управления;

Редактор форм и инспектор объектов максимально приближены к

Интерфейс отладки (используется внешний отладчик GDB);

Простой переход для Delphi программистов благодаря близости LCL

Полностью юникодный (UTF-8) интерфейс и редактор и поэтому
Delphi;
к VCL;
отсутствие проблем с портированием кода, содержащего национальные символы;

Мощный редактор, включающий систему подсказок, гипертекстовую
навигацию по исходным текстам, автозавершение и рефакторинг
48

Форматирование
исходного
текста
«из
коробки»,
используя
механизмы Jedi Code Format;

Поддержка двух стилей ассемблера: Intel и AT&T (поддерживаются
со стороны компилятора);

Поддержка множества типов синтаксиса Pascal: Object Pascal, Turbo
Pascal, Mac Pascal, Delphi (поддерживаются со стороны компилятора);

Имеет собственный формат управления пакетами;

Авто сборка самого себя (под новую библиотеку виджетов) нажатием
одной кнопки.
СУБД FireBird является одной из самых популярных в мире бесплатных,
кросплатформенных систем управления базами данных с открытым исходным
кодом. Она была разработана на основе исходного кода СУБД Interbase и
развивается сегодня независимым международным сообществом. По надёжности,
производительности и функциональным возможностям эта система мало в чём
уступает признанным лидерам своего класса - Oracle и Microsoft SQL Server.
Основные возможности СУБД:
1. Firebird полностью поддерживает стандартный ANSI в синтаксисе
языка SQL и может работать под управлением многих операционных систем Windows, Linux, MacOS, Solaris и различных Unix-платформах. Среди достоинств
этой системы использование очень развитого языка для хранимых процедур и
триггеров.
Предшественник
Firebird,
СУБД
Interbase
использовалась
в
информационных системах, начиная с 1981 года.
2. Firebird
это
свободный
проект,
поддерживаемый
многими
программистами и специалистами из других областей по всему миру. Его начало
было положено 25 июля 2000 года, когда корпорация Inprise Corp (ныне известная
как Borland Software Corp) открыла исходные коды своей СУБД Interbase, которая
использовалась в различных информационных системах, начиная с 1981 года.
3. Firebird полностью бесплатна, она не требует ни регистрации, ни
оплаты за поддержку. Исходный код этой системы открыт и любой желающий
49
может разрабатывать на его базе собственные некоммерческие проекты, при
условии соблюдения требований лицензии IDPL, по которой распространяется
Firebird.
Firebird (FirebirdSQL) — компактная, кроссплатформенная, свободная
система управления базами данных (СУБД), работающая на Linux, Microsoft
Windows и разнообразных Unix платформах.
Firebird основан на исходном коде InterBase 6.0 который был выпущен как
Open Source компанией Borland в августе 2000 года. История Interbase начинается
в 1984 году, таким образом, продукт является наследником более чем 20-летнего
опыта работы с реляционными базами данных
В качестве преимуществ Firebird можно отметить многоверсионную
архитектуру,
обеспечивающую
параллельную
обработку
оперативных
и
аналитических запросов (это возможно потому, что читающие пользователи не
блокируют пишущих), компактность (дистрибутив 5Mb), высокую эффективность
и мощную языковую поддержку для хранимых процедур и триггеров.
Firebird используется в различных промышленных системах (складские и
хозяйственные, финансовый и государственный сектора) с 2001 года. Это
коммерчески независимый проект C и C++ программистов, технических
советников и разработчиков мультиплатформенных систем управления базами
данных, основанный на исходном коде, выпущенном корпорацией Borland 25
июля 2000 года в виде свободной версии Interbase 6.0.
Firebird является сервером баз данных. Один сервер Firebird может
обрабатывать несколько сотен независимых баз данных, каждую с множеством
пользовательских
соединений.
Он
является
полностью
свободным
от
лицензионных отчислений даже для коммерческого использования.
3.2 Примеры экранных форм
При
открытии
программы
перед
пользователем
появится
окно
авторизации, в котором ему необходимо ввести имя пользователя и пароль для
50
входа. В целях соблюдения безопасности на форме все вводимые в поле «Пароль»
символы отображаются как «*». Форма авторизации представлена на рисунке 3.2
Рисунок 3.2 – Форма авторизации
При введении верных данных перед пользователем откроется главная
форма программы, представленная на рисунке 3.3
Рисунок 3.3 – Главная форма
При нажатии кнопки «Справочник мебели» или «Справочник клиентов»,
перед пользователем откроется форма справочника мебели или клиентов
51
соответственно, данные формы содержать подробную информацию о единице
номенклатуры или клиенте, с возможностью добавления, изменения и удаления
записи из формы. Форма справочника клиентов представлена на рисунке 3.4
Рисунок 3.4 – Форма «справочник клиентов»
При нажатии кнопки «Назад на главную» пользователь вернется на
главную форму.
При нажатии кнопки «Список встреч» перед пользователем откроется
форма назначенных менеджеров по продажам встреч, данная форма содержит
подробную информацию о встрече, с возможностью добавления, изменения и
удаления записи из формы. Форма списка встреч представлена на рисунке 3.5
52
Рисунок 3.5 – Форма «Список встреч»
При нажатии кнопки «Договора компании» (рисунок 3.6)
или «Акты
компании» (рисунок 3.7) пользователь перейдет на форму с договорами или
актами
компании
соответственно.
На
данных
формах
пользователю
предоставляется подробная информация о договоре или акте выполненных работ.
Дополнительно на форме «Договора компании» имеется возможность
занесения информации из договора в отчет по продажам за месяц.
Рисунок 3.6 – Форма «Договора компании»
53
Рисунок 3.7 – Форма «Акты компании»
Формы активных договоров и активных актов имеют возможность
добавления, редактирования и удаления информации.
Добавление нового договора на форму активных договоров представлено
на рисунке 3.8
Рисунок 3.8 – Форма «Создание нового договора»
54
Форма с добавленным договором представлена на рисунке 3.9
Рисунок 3.9 – Форма «Договора компании» после добавления
Нажатие кнопки «Открыть для печати» на формах активных договоров,
активных актов и месячного отчета по продажам откроет шаблон документа, в
котором заполнена информация из выбранной записи.
Заполненный
шаблон
договора
представлен
на
рисунке
Рисунок 3.10 – Заполненный для печати шаблон договора
3.10
55
Заполненный шаблон акта о выполнении представлен на рисунке 3.11
Рисунок 3.11 – Заполненный для печати шаблон акта о выполнении
Заполненный шаблон месячного отчета по продажам представлен на
рисунке 3.12
56
Рисунок 3.12 – Заполненный для печати шаблон акта о выполнении
57
Заключение
В результате выполнения выпускной квалификационной работы было
спроектировано и разработано автоматизированное рабочее место менеджера по
продажам корпусной мебели. Был проведен тщательный анализ предметной
области, процесса работы менеджера по продажам и бизнес-процесса компании.
На основе сравнения существующих аналогов было принято решение о
разработке собственной системы, выполняющей все необходимые функции.
В ходе проектирования и разработки были выполнены следующие этапы:
формулирование требований к системе, выбор и анализ средств реализации,
проектирование базы данных и архитектуры приложения, реализация приложения
с наглядными примерами форм.
В результате выполнения выпускной квалификационной работы все
поставленные цели можно считать достигнутыми.
58
Список литературы
1.
Архангельский, А.Я. Программирование в Delphi. Учебник по
классическим версиям Delphi. / А.Я. Архангельский. – М.: Бином-Пресс, 2008.
2.
Белов, В.В. Программирование в Delphi: процедурное, объектно-
ориентированное, визуальное: Учебное пособие для вузов / В.В. Белов, В.И.
Чистякова. - М.: РиС, 2014. - 240 c.
3.
Волков, В.Н. Требования к выполнению и оформлению выпускных
квалификационных работ (ВКР) [Текст] / В.Н. Волков, Н.А. Загородних, А.Ю.
Ужаринский, В.Ю. Преснецова; Рецензент – А. А. Стычук. – Орел ОГУ Именми
И.С. Тургенева, 2017.
4.
Глушаков, С.В. Базы данных. С.В. Глушков, Д.В. Ломотько. –
Москва: Издательство АСТ, 2002.
5.
Дейт, К.Дж., Введение в системы баз данных; пер. с англ., 6-е
изд./К.Дж. Дейт -К.: Диалектика, 2006.
6.
Мансуров, К.Т. Основы программирования в среде Lazarus./ К.Т.
Мансуров; Рецензенты – Сопуев А.С., Сотыбаев А.С., 2010.
7.
Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос /
К. Ларман. - М.: Издательский дом «Вильямс», 2001.
8.
"Основы современных баз данных". Кузнецов С.Д. Информационно-
аналитические
материалы
Центра
Информационных
Технологий.
www.citforum.ru.
9.
Осипов, Д. Delphi. Профессиональное программирование / Д. Осипов.
- СПб.: Символ-плюс, 2015. - 1056 c.
10. Программное
RAMUS
[Электронный
средство
структурного
ресурс]
/
НОУ
моделирования
«Интуит»,
[Режим
процессов
доступа:
http://www.intuit.ru/studies/courses/2195/55/lecture/15043].
11. Санников, Е. Курс практического программирования в Delphi.
Объектно - ориентированное программирование / Е. Санников. - М.: Солон-пресс,
2013. - 188 c.
59
12. Фараонов, В. В. Система программирования Delphi : [Наиболее полн.
рук.] / Валерий Фараонов. – СПб. : БХВ–Петербург, 2004. – 888 с. : ил.+ 24см. – (В
подлиннике). Предм. указ.: с. 873-888. Библиогр.: с. 871 – 872. – ISBN 5–94157–
294–8.
13. Харрингтон, Д.Л. Проектирование реляционных баз данных. [Текст]/
Джен Л. Харрингтон – Москва: Лори, 2006.
14. Черемных, С.В., Семенов И.О., Ручкин В.С. Моделирование и анализ
систем. IDEF-технологии: практикум. — М.: Финансы и статистика, 2006.
15. Эйдлина, Г.М. Delphi: программирование в примерах и задачах.
Практикум: Учебное пособие / Г.М. Эйдлина, К.А. Милорадов. - М.: ИЦ РИОР,
НИЦ ИНФРА-М, 2012. - 116 c.
16. Delphi: ActiveX/COM/CORBA [Электронный ресурс] : база данных
содержит сведения о работе с Word в Delphi. – Электрон. дан. – М., [2005]. –
Режим доступа: http://forum.vingrad.ru/index.php?showtopic=84634 – Загл. с экрана
(дата обращения 19.05.2017).
17. all4study.ru [Электронный ресурс] : Безопасность базы данных. –
Электрон. дан. – М., [2018]. – Режим доступа: http//:all4study.ru/bd/bezopasnostbazy-dannyx.html – Загл. с экрана (дата обращения 19.05.2017).
60
61
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
Наименование
группы атрибутов
атрибута
1. Описание
Обозначение документа
документа
(идентификатор(ы)
файла(ов))
Наименование документа
Характеристики документа
на электронном носителе
Презентация.ppt
Демонстрационные плакаты к
выпускной
квалификационной работе
Класс документа
ЕСКД
Вид документа
Оригинал документа на
электронном носителе
Аннотация
Демонстрационный материал,
отображающий основные
этапы выполнения выпускной
квалификационной работы
Использование документа Операционная система
Windows 7, Microsoft
PowerPoint 2010
2. Даты и время
Дата и время
20.06.2018
копирования документа
Дата создания документа 06.06.2018
Дата утверждения
20.06.2018
документа
3. Создатели
Автор
Легостаев А.С.
Изготовитель
Легостаев А.С.
4. Внешние ссылки Ссылки на другие
Удостоверяющий лист
документы
№ 140791/п
5. Защита
Санкционирование
ОГУ имени И.С. Тургенева
Классификация защиты
По законодательству РФ
6. Характеристики Объем информации
1 368 064Б
содержания
документа
62
7. Структура
документа(ов)
Наименование плаката
(слайда) №1
Наименование плаката
(слайда) №2
Наименование плаката
(слайда) №3
Наименование плаката
(слайда) №4
Наименование плаката
(слайда) №5
Наименование плаката
(слайда) №6
Наименование плаката
(слайда) №7
Наименование плаката
(слайда) №8
Наименование плаката
(слайда) №9
Наименование плаката
(слайда) №10
Титульный лист
Цели и задачи работы
Анализ предметной области
Сравнительный обзор
аналогов
Декомпозиция
бизнес-процесса
Логический уровень схемы
базы данных
Транзитивная сеть логики
диалога пользователя
Примеры экранных форм
Примеры экранных форм
Заключение
63
1/--страниц
Пожаловаться на содержимое документа