Информационная система автоматизации информационного оповещения сотрудников и клиентов ИТ-компании

3. Проектирование информационной системы автоматизации информационного оповещения сотрудников и клиентов ИТ-компании

3.1 Сравнительный анализ аналогов

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

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

Многокритериальный поиск в базе данных

Возможность создания массовых рассылок

Собственный почтовый клиент

Описание рассматриваемых систем

Почтовый клиент «Эпос»

Почтовый клиент «Эпос»

Автоматизированная информационная система «Почтовый клиент «Эпос» предназначена для автоматизации формирования и обмена как открытой, так и конфиденциальной кор­респонденцией, в распределенной глобальной сети или любой закрытой сети, поддерживающей протоколы SMTP/POP3.

Почтовый клиент «Эпос» позволяет решить следующие основные задачи:

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

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

обеспечить автоматический прием почтовой корреспонденции и разнесение этой корреспонденции по заранее настроенным папкам;

обеспечить поиск писем по неполной информации.

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

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

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

ePochta Mailer

ePochta Mailer имеет простой и интуитивно понятный интерфейс. Импортируйте удобным вам способом список e-mail адресов, добавьте текст письма, нажмите кнопку <Рассылка> - и начнется процесс рассылки. Приложение работает в многопоточном режиме, что обеспечивает высокую скорость работы - в дополнение к широким возможностям настроек SMTP, Proxy и ротаций текстов - рассылки дают отличный результат!

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

Возможности использования SMTP-серверов - встроенный SMTP, партнерские или внешние SMTP

Поддержка Proxy - поддержка прокси для анонимности рассылок

Поддержка SSL/TLS - для e-mail аутентификации

Вставка виджетов Facebook и Twitter - сделайте ваши рассылки более социальными

Вставка ссылки "Отписаться" - создания процесса и ссылки отписки

Вставка Spin-текста - возможность разнообразить текст

Спам-тест - убедитесь, что ваше письмо дойдет по назначению

Поддержка текстового и HTML форматов e-mail писем - широкие возможности оформления

Мастер Отписки - автоматизирует процесс удаления e-mail адресов отписавшихся получателей

Мониторинг рассылки - следите за статистикой с помощью Google Analytics или ePochta Tracker

Детальные отчеты - различные виды отчетов о текущем статусе отправки email сообщений

Встроенное управление базой e-mail адресов - базовые возможности по управлению списками адресов

Полная интеграция с прочими продуктами ePochta - моментальный обмен данными с другими программами ePochta

Модуль «Почтовые рассылки» (Host CMS)

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

Основные функции

управление неограниченным количеством рассылок;

персональное письмо для каждого пользователя;

возможность пользователям управлять рассылками (или отказываться от всех рассылок);

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

если пользователь с таким e-mail адресом не зарегистрирован -- при подписке он автоматически регистрируется (нет необходимости тратить время на заполнение формы регистрации);

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

подготовка рассылки в двух версиях -- текстовой и HTML;

автоматическое создание текстовой версии рассылки из HTML версии (по желанию редактора);

использование шаблона рассылки (для размещения приветствия и подписи) с возможностью подстановки данных пользователя;

копирование выпуска рассылки;

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

Сравнительный анализ систем почтовой рассылки

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

Для целей выбора наиболее оптимальной системы определим критерии сравнения:

Максимальное число адресов в одном письме;

Формирование списков рассылки;

Почтовый клиент;

Стоимость;

Удобный интерфейс.

Присвоим наиболее важному критерию оценку 100 баллов. Исходя из попарного отношения критериев по важности, дадим в баллах оценку каждому из критериев (таблица 13):

Таблица 13. Оценка критериев

Критерии	Баллы
Максимальное число адресов в одном письме	100
Формирование списков рассылки	85
Почтовый клиент	65
Стоимость	50
Удобный интерфейс	45

Сложим полученные баллы. Произведём нормировку весов критериев, разделив присвоенные баллы на сумму весов:



где A_i - баллы критерия,

n - количество критериев.

Результаты нормировки приведены в таблице 14

Таблица 14. Нормированные оценки критериев

Критерии	Баллы	Нормировка весов
Максимальное число адресов в одном письме	100	0,28985507
Формирование списков рассылки	85	0,24637681
Почтовый клиент	65	0,1884058
Стоимость	50	0,14492754
Удобный интерфейс	45	0,13043478
сумма баллов	345	1

Измерим значение каждой альтернативы по каждому из критериев по шкале от 0 до 100 баллов.

Измерим значение каждой альтернативы по каждому из критериев по шкале от 0 до 100 баллов.

Таблица 15. Оценка альтернатив

Альтернативы	Критерии
	Максимальное число адресов в одном письме	Формирование списков рассылки	Почтовый клиент	Стоимость	Удобный интерфейс
Эпос	75	100	95	95	60
ePochta Mailer	65	85	75	90	75
Почтовые рассылки	85	95	85	60	80

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

Таблица 16. Общая оценка альтернатив

Альтернативы	Критерии	Общая оценка
	Максимальное число адресов в одном письме	Формирование списков рассылки	Почтовый клиент	Стоимость	Удобный интерфейс
Эпос	21,739130	24,637	17,8985	13,768	7,8260	85,869
ePochta Mailer	18,840579	20,942	14,1304	13,043	9,7826	76,739
Почтовые рассылки	24,637681	17,898	16,0144	8,6956	10,434	77,681

Выберем как лучшую альтернативу, имеющую наибольшую общую оценку - это система «Эпос», которая станет прототипом проектируемой мною системы.

3.2 Выбор архитектуры проектируемой информационной системы

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

Таблица 17. Типовые компоненты информационной системы

Обозна-чение	Наименование	Характеристика
PS	Presentation Services (средства представления)	Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими результаты обработки.
PL	Presentation Logic (логика представления)	Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды в меню, нажатии кнопки или выборе элемента из списка.
BL	Business or Application Logic (прикладная логика)	Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.
DL	Data Logic (логика управления данными)	Операции с базой данных (SQL-операторы), которые нужно выполнить для реализации прикладной логики управления данными.
DS	Data Services (операции с базой данных)	Действия СУБД, вызываемые для выполнения логикиу правления данными, такие как: манипулирование данными, определение данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения.
FS	File Services (файловые операции)	Дисковые операции чтения и записи данных для СУБД (файловые операции) и других компонентов. Обычно являются функциями операционной системы (ОС)

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

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логики обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.

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

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логики BL и DL - на клиенте. Двухуровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД - на сервере.

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

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

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

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней:

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

средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с базой данных DS;

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

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

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

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

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

Критериями оценивания описанных выше трех альтернатив будут:

Простота реализации;

Простота обновления ПО;

Затраты на эксплуатацию и установку.

Присвоим наиболее важному критерию оценку 100 баллов. Исходя из попарного отношения критериев по важности, дадим в баллах оценку каждому из критериев (таблица 18):

Таблица 18. Оценка критериев

Критерии	Баллы
Простота реализации	100
Простота обновления ПО	85
Затраты на эксплуатацию и установку	75

Сложим полученные баллы. Произведём нормировку весов критериев, разделив присвоенные баллы на сумму весов:

где A_i - баллы критерия,

n - количество критериев.

Результаты нормировки приведены в таблице 19.

Таблица 19. Нормированные оценки критериев

Критерии	Баллы	Нормировка весов
Простота реализации	100	0,384615385
Простота обновления ПО	85	0,326923077
Затраты на эксплуатацию и установку	75	0,288461538
сумма баллов	260	1

Измерим значение каждой альтернативы по каждому из критериев по шкале от 0 до 100 баллов.



Таблица 20. Оценка альтернатив

Альтернативы	Критерии
	Простота реализации	Простота обновления ПО	Затраты на эксплуатацию и установку
Файл-сервер	90	70	95
Клиент-сервер	85	85	90
Многоуровневая	75	80	75

Определим общую оценку каждой альтернативы, используя формулу взвешенной суммы баллов общая оценка альтернативы - , где В_i оценка альтернативы по каждому критерию (таблица 21)

Таблица 21. Общая оценка альтернатив

Альтернативы	Критерии
	Простота реализации	Простота обновления ПО	Затраты на эксплуатацию и установку	Общая оценка
Файл-сервер	34,6153846	22,8846153	27,4038461	84,9038461
Клиент-сервер	32,6923076	27,7884615	25,9615384	86,4423076
Многоуровневая	28,8461538	23,0769230	21,6346153	73,5576923

Выберем как лучшую альтернативу, имеющую наибольшую общую оценку - это архитектура Клиент-Сервер.

3.3 Описание автоматизируемых функций

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

Цели и задачи информационной системы автоматизации почтовых рассылок:

упрощение работы;

увеличение производительности труда;

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

понижение затрат;

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

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

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

отвечать требованиям заказчика;

обеспечивать минимальные затраты;

поднять производительность труда;

быть надежной в эксплуатации;

окупиться в заданные сроки;

легкость внедрения и доведения до персонала.

Функции информационной системы автоматизации почтовых рассылок:

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

предоставление информации о подписанных изданий;

вывод бланка квитанции об оплате для заказа издания;

редактирование и корректировка БД;

обеспечение быстрого доступа к информации.

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



3.4 Функциональная модель процесса информационного оповещения

Модель процесса информационного оповещения представлена с использованием функциональной модели DFD и основана на технологии подписок (Data Flow Diagram) (Рисунок 8). Данный метод позволяет провести структурный анализ потоков данных, произвести выделение атрибутов и перейти к конструированию базы данных. Для анализа потоков данных используются диаграммы потоков данных.

Рисунок 8. Контекстная DFD диаграмма первого уровня

Декомпозиция DFD диаграммы первого уровня представлена на (Рисунке 9):



Рисунок 9. Декомпозиция DFD диаграммы первого уровня

3.5 Проектирование базы данных методом «Сущность - Связь» для разработанной функциональной модели

Выделим сущности:

Подписчик (клиент)

Рассылка

Редакции

Сущность подписчик будет содержать информацию о подписчике и выбранном им издании.

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

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

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

Связь между сущностями Рассылка и Редакции: «один к одному», так как одна рассылка, будет, работает с одной редакцией.

Если степень связи 1:1(один к одному), и класс принадлежности одной сущности обязательный, а второй необязательный, то формируется два отношения под каждую из сущностей. К отношению, сущность которого имеет класс принадлежности обязательный добавляется ключ сущности с необязательным классом.

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

Подписчик (ID_ подписчика, ID_ Рассылки),

Рассылка (ID_ Рассылки).

Подписчик (ID_подписчика, ID_ редакций),

Редакции (ID_ редакций).

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

3.6 Информационная модель проектируемой системы

Информационная модель, построенная ER методом, может быть получена при помощи CASE-средства фирмы Computer Associates International: ERWin 3.5.2. ERWin 3.5.2 позволяет автоматизировать процессы создания логической и физической моделей данных.

Построенная логическая модель базы данных представлена на (рисунке 10):

Рисунок 10. Логическая модель базы данных



На основе логической модели данных ERWin была сгенерирована физическая модель, которая имеет следующий вид (рисунок 11):

Рисунок 11. Физическая модель базы данных

3.7 Определение ключей (первичных и внешних)

В таблице «PODPISHIK» первичным ключом является поле «ID_PODPISHIK», так как информация, находящаяся в этом поле, является уникальной.

Данная таблица является родительской для таблицы «RASSILKA» и «REDAKCII». Поля «ID_RASSILKA», «ID_REDAKCII» таблиц «RASSILKA» и «REDAKCII» ссылаются на поля таблицы «PODPISHIK». При этом осуществляется каскадная ссылочная целостность, то есть при удалении кода в таблице «PODPISHIK» удаляются все связанные записи в дочерней таблице.

3.8 Состав и описание таблиц БД

В данной автоматизированной системе используется база данных, состоящая из трёх таблиц: Подписка, Рассылка, Редакции.

Таблица 22. Список полей таблицы «Подписчик»

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
ID_подписчика	Integer		NOT NULL
Имя	Character	20
Фамилия	Character	20
Дата рождения	Data
Адрес	Character	50
Дата регистрации	Data
ID_рассылки	Integer
ID_редакции	Integer

Таблица 23. Список полей таблицы «Рассылка»

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
ID_рассылки	Integer		NOT NULL
Имя	Character	20
Фамилия	Character	20
Должность	Integer

Таблица 24. Список полей таблицы «Редакции»

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
ID_редакции	Integer		NOT NULL
Название редакции	Character	20
Наименования изданий	Character	20
Способ отправления	Character	20

4. Реализация информационной системы автоматизации информационного оповещения сотрудников и клиентов ИТ-компании

В результате решения поставленных задач было разработано 9 общих модулей, 4 общие формы, 5 справочников, 5 документов, 1 журнал документов, 3 перечисления, 2 регистра сведений, а так же дополнен интерфейс программы «1С: Предприятие 8.2».

4.1 Разработка общих форм и модулей

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

Общие модули разрабатываемой подсистемы и их свойства представлены в таблице 25.

Таблица 25. Модули информационной системы

Название модуля	Свойства
Взаимодействия	Сервер Внешнее соединение Вызов сервера
Взаимодействия Вызов Сервера	Сервер Вызов сервера
Взаимодействия Клиент	Клиент (управляемое приложение) Клиент (обычное приложение)
Взаимодействия Клиент Переопределяемый	Клиент (управляемое приложение) Клиент (обычное приложение)
Взаимодействия Клиент Сервер	Клиент (управляемое приложение) Сервер Внешнее соединение Клиент (обычное приложение)
Взаимодействия Клиент Сервер Переопределяемый	Клиент (управляемое приложение) Сервер Внешнее соединение Клиент (обычное приложение)
Взаимодействия Переопределяемый	Сервер Внешнее соединение Клиент (обычное приложение)
Управление Электронной Почтой	Сервер Внешнее соединение Клиент (обычное приложение) Вызов сервера
Управление Электронной Почтой Клиент	Сервер Внешнее соединение Клиент (обычное приложение) Вызов сервера

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

Общая форма Адресная Книга.

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



Рисунок 12. Создание формы АдреснаяКнига

Рисунок 13. Свойства формы АдреснаяКнига



4.2 Создание форм документов подсистемы

Начнем с добавления в общий полный интерфейс программы «1С: Предприятие» интерфейса разрабатываемой подсистемы, после чего в настройки пунктов будут добавляться создаваемые документы.

Рисунок 14. Добавление дополнительного интерфейса

Рисунок 15. Свойства элемента интерфейса

4.2.1 Журнал документов «Взаимодействия»

Журнал документов будет обладать следующими свойствами для работы с попадающими в него документами:

Установка режимов отображения списка

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

Установка группировки списка

Назначение ответственного

Установка флага "отработано"

Определение предмета взаимодействия

Откладывание отработки взаимодействий

Загрузка входящей электронной почты

Рисунок 16. Создание формы журнала документов «Взаимодействия»

Рисунок 17. Журнал документов «Взаимодействия» в Конфигураторе и его свойства



4.2.2 Документ «Электронное письмо входящее»

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

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

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

Запланировать взаимодействие с клиентом. Планирование взаимодействия производится при нажатии на кнопку "Взаимодействие". Можно запланировать встречу, телефонный звонок и т.д.

Рисунок 18. Создание формы документа «Электронное письмо входящее»



Рисунок 19. Документ «Электронное письмо входящее» в Конфигураторе и его свойства

4.2.3 Документ «Электронное письмо исходящее»

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

Электронное письмо исходящее может быть создано на основании ранее оформленного взаимодействия, контакта или предмета взаимодействий. Если электронное письмо исходящее оформляется на основании взаимодействия или предмета взаимодействий, то в форме письма автоматически заполняется информация о предмете письма. Информация о предмете письма может быть добавлена и в момент оформления нового письма (поле "Предмет").

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

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

На основании исходящего электронного письма пользователь может зарегистрировать взаимодействие с клиентом.

Рисунок 20. Создание формы документа «Электронное письмо исходящее»



Рисунок 21. Документ «Электронное письмо исходящее» в Конфигураторе и его свойства

4.3 Создание справочников и регистров сведений

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

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

Рисунок 22. Ошибка при обращении к созданным справочникам



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

Состав справочников и их свойств представлен на рисунке 23.

Рисунок 23. Состав справочников Присоединенных файлов и их свойства

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

В подсистеме разработано 2 регистра сведений:

Идентификаторы Полученных Электронных Писем - служит для хранения адресов отправителей электронных писем и даты их получения;

Наличие Присоединенных Файлов - служит для определения наличия во взаимодействиях присоединенных файлов.



Рисунок 24. Разработанные регистры сведений

4.4 Настройка почтового сервера

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

Для удобства справочник «Учетные записи электронной почты» вынесен в Главное меню --- Директ-маркетинг

Сведения о пользователе:

имя - имя владельца учетной записи, например Иван Сергеевич

почтовый адрес - адрес электронной почты учетной записи в формате пользователь@почтовый сервер

Сведения о сервере:

POP3 сервер - адрес POP3 сервера (сервера входящих сообщений)

SMTP сервер - адрес SMTP сервера (сервера исходящих сообщений)

Аутентификация:

пользователь - имя пользователя учетной записи (login)

пароль - пароль учетной записи

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

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

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

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

Рисунок 25. Настройка учетной записи электронной почты

4.5 Загрузка входящих электронных писем

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

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

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

Рисунок 26. Форма выбора Документа «Электронное письмо входящее»



Рисунок 27. Вид входящего электронного письма

4.6 Формирование исходящих электронных писем

Создание электронного письма на основании контакта

Исходящее электронное письмо может быть создано из карточки контакта. При создании письма на основании контакта в список получателей письма добавляются записи, соответствующие контактной информации партнера с типом "e-mail". Если эта информация не определена, добавляется запись с заполненными реквизитами Контакт и Представление.

Создание электронного письма на основании предмета взаимодействия

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

Создание электронного письма на основании взаимодействия

При создании электронного письма на основании телефонного звонка копируется реквизит Предмет, в список получателей письма добавляются записи, соответствующие контактной информации контакта звонка с типом "e-mail". Если эта информация не определена, добавляется запись с заполненными реквизитами Контакт и Представление.

При создании электронного письма на основании встречи копируется реквизит Предмет. Список получателей письма заполняется контактной информацией участников встречи с типом "e-mail".

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

Исходящее письмо может быть создано из входящего нажатием кнопки:

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

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

Переслать. В этом случае получатели не заполняются.

Формирование электронного письма

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

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

Отложенная обработка

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

Для отправки письма используется кнопка Отправить.

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

Рисунок 28. Форма выбора и создания документа «Электронное письмо исходящее»

Рисунок 29. Создание исходящего электронного письма



Рисунок 30. Форма выбора контактов из Адресной книги и заполнения контактов из файла



5. Социальный аспект использования информационной системы автоматизации информационного оповещения

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

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



Заключение

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

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

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

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

Список использованной литературы

1. Сулейменова Б.М. Система продвижения товаров и услуг как один из инструментов комплекса маркетинга. Маркетинг в России за рубежом. 2008.

2. Котлер Ф. Основы маркетинга. Краткий курс: Пер. с англ. - М.: Издательский дом "Вильямс", 2007.

3. Бачило С.В., Есинова И.В., Мишина Л.А. Директ-маркетинг: учебно-практическое пособие// Издательство: Дашков и К, 2008.

4. Романов А.А., Панько А.В. Маркетинговые коммуникации - М.: Эксмо, 2006.

5. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0 - М.: Диалог-МИФИ, 2002

6. Габец А.П., Гончаров Д.И., Козырев Д.В., Кухлевский Д.С., Радченко М.Г. Профессиональная разработка в системе 1С: Предприятие 8. - М.: 1С-Паблишинг, 2007.

7. Кашаев С.М. 1С: Предприятие 8.2. Программирование и визуальная разработка на примерах// Издательство: БХВ-Петербург, 2011.

8. Радченко М.Г., Хрусталева Е.Ю. 1С: Предприятие 8.2. Практическое пособие разработчика. Примеры и типовые приемы. - М.: 1С-Паблишинг, 2009.

9. Радченко М.Г. 1С: Предприятие 8.2. Коротко о главном. Новые возможности версии 8.2- М.: 1С-Паблишинг, 2009.

10. Методические материалы слушателя Сертифицированного курса фирмы «1С». Введение в конфигурирование в системе «1С: Предприятие 8». Основные объекты. Версия 8.2. - М.: 1С-Учебный центр № 3, 2010.

11. Методические материалы слушателя Сертифицированного курса фирмы «1С». Конфигурирование в системе «1С: Предприятие 8». Решение оперативных задач. Версия 8.2. - М.: 1С-Учебный центр № 3, 2011.

12. Клуб профессионалов 1С - Все об 1С. www.1c.proclub.ru.

13. Фирма 1С [Электронный ресурс]. www.1c.ru.

14. Бабикова А.В., Корсаков М.Н. Методические указания по выполнению технико-экономического обоснования дипломных работ студентов инженерных специальностей. - Таганрог: Изд-во ТТИ ЮФУ, 2010.

15. Бакаева, Т.Н. «Безопасность жизнедеятельности»: Учебное. Пособие. Таганрог: ТРТУ, 2005.

Размещено на Allbest.ru

...