Информационная система автоматизации регистрации и мониторинга заявок от контрагентов

Размещено на http://www.allbest.ru/

На тему: "Информационная система автоматизации регистрации и мониторинга заявок от контрагентов ООО "ФонтанГрад"



Аннотация

В работе разрабатывается проект информационной системы автоматизации регистрации и мониторинга заявок от контрагентов ООО "ФонтанГрад", основной задачей которой является учет взаимоотношений с постоянными клиентами.

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

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

В работе были рассмотрены вопросы безопасности и экологичности проекта, приведено технико-экономическое обоснование проекта.



Реферат

114 стр., 25 рис., 12 таб., 20 библиогр.

ИНФОРМАЦИОННАЯ СИСТЕМА, ОТДЕЛ ПО РАБОТЕ С КЛИЕНТАМИ, УПРАВЛЕНИЕ ВЗАИМОДЕЙСТВИЕМ, МОНИТОРИНГ ЗАЯВОК

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

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

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

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

В четвертом разделе описывается реализация информационной системы.

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

В шестом разделе выполняется технико-экономическое обоснование проекта.

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

Основные результаты работы отражены в заключении.



Содержание

Введение

1. Исследование деятельности ООО "ФонтанГрад"

1.1 Характеристика предприятия и его деятельности

1.2 Характеристика комплекса задач, задачи и обоснование необходимости автоматизации

1.3 Сценарий процесса регистрации и мониторинга заявок от контрагентов ООО "ФонтанГрад" 26

1.4 Математическая модель оценки временных затрат на процессы регистрации и мониторинга заявок от контрагентов ООО "ФонтанГрад"

1.5 Проблемы предметной области

1.6 Постановка цели и задач дипломной работы

2. Моделирование и оптимизация бизнес-процессов регистрации и мониторинга заявок от контрагентов ООО "ФонтанГрад

2.1 Определение оптимальных показателей математической модели и формирование образа решения проблем

2.2 Выбор и обоснование средств моделирования

2.3 Модели оптимизированных бизнес-процессов

3. Проектирование информационной системы автоматизации регистрации и мониторинга заявок от контрагентов ООО "ФонтанГрад"

3.1 Требования к разрабатываемой ИС

3.2 Обзор и анализ существующих систем взаимодействия с клиентами и с проектируемым решением

3.3 Выбор архитектуры ИС

3.4 Информационная модель системы и её описание

3.5 Программное обеспечение задачи

4. Описание реализации информационной системы автоматизации регистрации и мониторинга заявок от контрагентов ООО "ФонтанГрад"

4.1 Проектирование интерфейса

4.2 Внедрение спроектированной системы в ООО "ФонтанГрад"

5. Социальная значимость проекта

Заключение

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



Введение

В двадцать первом веке автоматизация бизнес-процессов -- это не роскошь.

Это мероприятие, в необходимости и эффективности которого убедились руководители большинства успешных компаний не только Европы и Америки, но также и России.

Чаще всего следствием автоматизации деловых процессов компании выступают:

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

· повышение скорости выполнения задач, связанных с разного рода учетом;

· снижение количества ошибок в документации, отчетах и т. д.

· повышение эффективности учета, приводящее к увеличение рентабельности предприятия;

· удобство осуществления деловых процессов и документооборота.

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

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

Последний мировой финансово-экономический кризис наглядно показал, что высокой конкурентоспособностью и устойчивостью обладают именно те предприятия, где внедрена и развита система автоматизации. К примеру, четкая разработка и грамотное внедрение системы автоматического учета в Инвестиционной компании "MG Securities" (г. Москва) в конце 2008 - начале 2009 гг. решила целый ряд проблем, которые до этого снижали скорость и эффективность документооборота, процессов учета и управления сделками.

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

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

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

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

Поставленная цель предопределила постановку и решение ряда взаимосвязанных задач:

1. Изучение существующей схемы работы с постоянными клиентами и партнерами ООО "ФонтанГрад" и выявление факторов, способствующих понижению/повышению эффективности работы;

2. Разработка автоматизации регистрации и мониторинга заявок от постоянных клиентов и партнеров ООО "ФонтанГрад";

3. Обоснование экономической эффективности и практической значимости автоматизации регистрации и мониторинга заявок от постоянных клиентов и партнеров ООО "ФонтанГрад".

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



1. Исследование деятельности ООО "ФонтанГрад"

1.1 Характеристика предприятия и его деятельности

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

К задачам, которые решает "ФонтанГрад" относится прием заказов от физических и юридических лиц, выполнение работ по заказу клиента, уточнение требований заказчика, обеспечение его своевременной информацией о состоянии выполнения заказа [1].

"ФонтанГрад" выполняет следующие функции:

· Строительство фонтанов;

· Проектирование фонтанов;

· Реконструкция фонтанов;

· Ремонт фонтанов;

· Услуги перевозки крупногабаритных грузов и строительных материалов;

· Услуги лаборатории по контролю качества;

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

Рисунок 1.1. Организационная структура "ФонтанГрад"

Опишем организационную структуру на основе приведенной диаграммы (см. таблицу 1.1)

Таблица 1.1. - Организационно-функциональная структура "ФонтанГрад"

№	Наименование подразделения	Функции подразделения
1	Производственно-технический отдел (ПТО)	подготовка и составление проектно-сметной документации на все виды работ
2	Отдел материально-технического снабжения (ОМТС)	обеспечение производственных подразделений предприятия материально-техническими ресурсами, подготовка и заключение договоров на поставку материально-технических ресурсов, организация рационального использования материально-технических ресурсов
3	Бухгалтерия	Формирование полной и достоверной информации о деятельности предприятия и его имущественном положении, необходимой внутренним и внешним пользователям бухгалтерской отчетности, предотвращение отрицательных результатов хозяйственной деятельности предприятия и выявление внутрихозяйственных резервов обеспечения финансовой устойчивости
4	Отдел сбыта	Осуществление сделок с клиентами, документирование сделок, взаимодействие с клиентами по вопросу выполнения заказов, поиск новых клиентов, развитие клиентско-партнерских связей, обеспечение бухгалтерии информацией о сделках
5	Аппарат управления (АУП)	сбор, систематизация, передача и обработка информации, выработка команд по управлению и реализацией выработанных решений, обеспечение предприятия кадрами, юридическое и правовое обеспечение функционирования предприятия
6	Отдел по работе с клиентами	Организация взаимодействия с клиентами, учет сделок, обеспечение долговременного сотрудничества
7	Участок транспорта и механизмов (УТиМ)	Разработка годовых, квартальных, месячных и оперативно-календарных планов-графиков транспортных перевозок на основе плана отгрузки готовой продукции и выполнения плана производства структурными подразделениями предприятия, контроль за своевременным выполнением планов поставок транспортных средств, тары, планов погрузочно-разгрузочных работ, обеспечение приема на склад, подготовки, хранения и отгрузки готовой продукции в номенклатуре и в сроки, установленные договорами, Оформление сопровождающей транспортные операции документации, организация рационального использования привлеченного транспорта общего пользования и контроль фактически выполненных им объемов работ
8	Линейный персонал	выполнение основных работ, осуществляемых "ФонтанГрад"

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

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

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

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

Схема бизнес-процессов приведена на рисунке 1.2.

Рисунок 1.2. Схема бизнес-процессов "ФонтанГрад"

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

Далее в таблице 1.1 приведен статистический обзор заявок со стороны постоянных клиентов и партнеров за 2009 год.



Таблица 1.1 Заявки от постоянных клиентов и партнеров ООО "ФонтанГрад" за 2013 год

Наименование показателя	Количество сделок-заявок 2009, шт.	% от общего поступившего количества 2009	Фактически исполненный оборот заявок 2009, руб.	Потенциальный оборот заявок 2009, руб.	Средняя цена договора по отношению к количеству заявок 2009, руб.
Контрагент - Клиент	6 985	86%	6 308 512	7 410 247
ЮЛ	суммарно	4 343	54%	4 016 012	4 389 929
исполненные заявки-сделки	4 004	50%	4 016 012	4 016 012	1103
неисполенные заявки-сделки	339	4%	-	373 917
	непрочитанные (просрочка)	42	1%	-	46 326
	отложенные (просрочка)	194	2%	-	213 982
	конфликтные заявки	103	1%	-	113 609
ФЛ	суммарно	2 642	33%	2 292 500	3 020 318
исполненные заявки-сделки	1 836	23%	2 292 500	2 292 500	903
неисполненные заявки-сделки	806	10%	-	727 818
	непрочитанные (просрочка)	195	2%	-	176 085
	отложенные (просрочка)	403	5%	-	363 909
	конфликтные заявки	208	3%	-	187 824
Контрагент - Партнер	1 103	14%	561 400	772 100
ЮЛ	суммарно	1 103	14%	561 400	772 100
исполненные заявки-сделки	802	10%	561 400	561 400	700
неисполенные заявки-сделки	301	4%	-	210 700
	непрочитанные (просрочка)	67	1%	-	46 900
	отложенные (просрочка)	171	2%	-	119 700
	конфликтные заявки	63	1%	-	44 100
ИТОГО ЗАЯВОК принятых и исполненных	6 642	82%	6 869 912	6 869 912
ИТОГО ЗАЯВОК принятых: исполненных и неисполненных	8 088	100%	-	8 182 347



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

1.2 Характеристика комплекса задач, задачи и обоснование необходимости автоматизации

Выбор комплекса задач автоматизации и характеристика существующих бизнес-процессов

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

Учитывая специфику деятельности каждого подразделения, основные бизнес-процессы "ФонтанГрад" будут выглядеть следующим образом:

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

· Определение менеджером специалиста, ранее работавшим с клиентом/партнером по запрашиваемому виду услуг;

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

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

· Отправка менеджеру специалистом подтверждения о получении заявки с указанием факта готовности ее исполнения (готов/не готов), с указанием объяснительных причин - в случае неготовности исполнения;

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

· В случае отказа клиента о прохождении повторного цикла заявки - закрытие заявки;

· В случае согласия клиента на прохождение повторного цикла заявки - направление менеджером повторной заявки специалисту;

· В случае готовности исполнения специалистом заявки или в случае согласия клиента на прохождение повторного цикла заявки - исполнение заявки специалистом по схеме утвержденного технического задания;

· Мониторинг менеджером сроков исполнения заявки и существенных условий технического задания;

· Мониторинг начальником соответствующего подразделения сроков, существенных условий и профессионального качества выполнения технического задания;

· Отправка специалистом результата выполнения заявки начальнику соответствующего подразделения и менеджеру, от которого поступила заявка в отдел;

· Пересылка менеджером, принявшим заявку и получившим результат ее выполнения, результата и/или отчета об окончании выполнения работ/оказанию услуг клиенту/партнеру;

· В случае неудовлетворительного согласования результатов исполнения заявки, передача менеджером ответственности за устранение разногласий начальнику соответствующего подразделения с указанием претензий клиента и его контактов и уведомление менеджером директора по работе с клиентами и партнерами о факте конфликта интересов;

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

· В случае удовлетворительного согласования результатов исполнения заявки, выставление менеджером клиенту/партнеру счета на оплату;

· Контроль менеджером факта оплаты клиентом выполненных работ/оказанных услуг;

· Сбор и передача менеджером в бухгалтерию всех необходимых первичных документов от клиентов/партнеров;

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

· Закрытие заявки.

1.1.1. Определение места проектируемой задачи в комплексе задач и ее описание

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

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

· Трудность в проведении объективной оценки эффективности работы менеджеров по работе с клиентами и партнерами;

· Отсутствие прямого контроля работы менеджеров по работе с клиентами и партнерами со стороны директора соответствующего подразделения. Снижение скорости обработки заявок от постоянных клиентов и партнеров на фоне общего роста запросов;

· Рост ошибок "человеческого фактора" (ошибки менеджеров) при обработках заявок от постоянных клиентов и партнеров на фоне повышения загруженности и увеличения объемов работ;

· Увеличение штрафных выплат вследствие задержки и/или некачественного исполнения заявки;

· Сложность мониторинга и оценки эффективности исполнения заявок специалистами "от А до Я" (в разрезе каждого этапа выполнения);

· Сложность в выявлении ответственных лиц, виновников "торможения" исполнения заявок.

Все представленные трудности оказывают негативное влияние на общую работу ООО "ФонтанГрад", выявляются во время проведения внутреннего контроля и анализа бизнес-процессов, берут свое начало при регистрации, обработке и мониторинге заявок от клиентов и партнеров.

Обоснования необходимости использования вычислительной техники для решения задачи

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

Рисунок 1.3 Схема документооборота в ООО "ФонтанГрад"

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

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

Временные характеристики описанных процессов приведены в таблице 1.2.



Таблица 1.2 Характеристики описанных процессов

Действие	Среднее количество за рабочий день	Время, необходимое для выполнении одного действия, минут	Общее время, минут
Регистрация заявки	10	15	150
Поиск необходимой информации	5	30	150
Анализ информации за период	0,5	60	30
ИТОГО, минут:	330

Таким образом, ежедневно, в среднем, 330 минут или 5 часов 30 минут, сотрудник занят занесением необходимых сведений в книги учета, а также, при необходимости анализом и поиском нужных сведений. Учитывая, что продолжительность рабочего дня составляет 8 часов, делаем вывод, что на выполнение остальных обязанностей (то есть непосредственную работу по решению проблем клиента и выработке необходимых мероприятии) остается менее 40 % рабочего времени, что крайне неэффективно.

Для данного способа также характерны следующие недостатки:

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

· Неэффективное использование рабочего времени.

· Слабый контроль работы сотрудника.

· Бюрократия - увеличивающийся "поток" бумажной работы.

· Усталость служащих - усиление негативного воздействия человеческого фактора.

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

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

Проведем расчет ожидаемого эффекта от внедрения средств автоматизации.

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

Таблица 1.3 Расчет эффекта внедрения

Действие	Среднее количество за рабочий день	Время, необходимое для выполнения одного действия, минут	Общее время, минут
Просмотр заявки	10	1	10
Поиск необходимой информации	5	2	10
Анализ информации за период	0,5	5	2,5
ИТОГО, минут:	12.5

Таким образом, ожидаемая экономия рабочего времени составляет около 5 часов ежедневно, что позволяет увеличить эффективность работы сотрудников ООО "СВ-Логистик". Кроме того, другими преимуществами автоматизации рассматриваемого бизнес-процесса будут:

· централизованное хранение данных

· исключение потери данных

· структуризация данных

· более оперативная обработка данных

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

· легкое изменение данных

· система авторизации

· сокращение времени оформления документов



1.3 Сценарий процесса регистрации и мониторинга заявок от контрагентов ООО "ФонтанГрад" 26

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

1. Прием заказа (встреча с клиентом, выявление его пожеланий). На данном этапе с клиентом работает офис-менеджер, который и выявляет требования к заказу. Данные о его заказе в лучшем случае вносятся в книгу Excel, в худшем записываются на бумаге. На основании этих данных офис-менеджер приступает к оформлению документов. Анкетные данные не фиксируются.

2. Оформление договора. Договор оформляется на основе готового шаблона в текстовом редакторе, куда заносятся данные о клиенте и вид оказываемых услуг.

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

При повторном обращении клиента вся схема работы производится заново, что отнимает время и силы работников компании. Само собой возможность поощрения лояльного клиента отсутствует ввиду того, что офис-менеджер просто не в состоянии помнить всех клиентов ООО "ФонтанГрад".

Сценарий, соответствующий описанию, показан на рисунке 1.4

Рисунок 1.4 - Сценарий процесса регистрации и мониторинга заявок от контрагентов ООО "ФонтанГрад"

1.4 Математическая модель оценки временных затрат на процессы регистрации и мониторинга заявок от контрагентов ООО "ФонтанГрад"

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

Составим формулу, по которой мы сможем оценить среднее время на взаимодействие с клиентом в ООО "ФонтанГрад".

Для начала рассмотрим, какие возможны случаи обращения:

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

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

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

Для указанных трех случаев составим формулу, по которой рассчитаем среднее время T на взаимодействие с клиентом в ООО "ФонтанГрад":



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

Дадим пояснения относительно составляющих формулы и приведем их средние значения (см. таблицу 1.4)

Таблица 1.4 Описание составляющих формулы расчета временных затрат

Параметр	Описание	Значение
tк	Временные затраты на консультацию клиентов	10 минут
tз	Временные затраты на принятие заказа	5 минут
tд	Временные затраты на оформление договора	15 минут
tи	Временные затраты на поиск истории взаимодействия с клиентом	20 минут
tл	Временные затраты на определение льготы	5 минут

Таким образом, получим:

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

Рисунок 1.5 - Сопоставление временных затрат

1.5 Проблемы предметной области

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

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

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

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

Организационные проблемы:

1. Отсутствие как таковой системы ведения истории взаимоотношений с клиентами;

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

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

Социальные проблемы:

1. Риск снижения доходности предприятия, который может отразиться на заработных платах сотрудников;

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

1.6 Постановка цели и задач дипломной работы

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



2. Моделирование и оптимизация бизнес-процессов регистрации и мониторинга заявок от контрагентов ООО "ФонтанГрад

2.1 Определение оптимальных показателей математической модели и формирование образа решения проблем

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

Клиент, обратившийся впервые, тратит на пребывание в ООО "ФонтанГрад" 30 минут. Таким образом, постоянный клиент должен тратить на это же действие не более 30+30*0,1=33 минут.

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

Зная соотношение tи и tл определим их новые значения:

Отсюда tи = 10,4 минуты, tл = 2,6 минуты.

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

Оптимизированный сценарий бизнес-процессов показан на рисунке 2.1:

Рисунок 2.1 - Оптимизированный сценарий процесса регистрации и мониторинга заявок от контрагентов в ООО "ФонтанГрад"

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

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

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

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

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

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

2.2 Выбор и обоснование средств моделирования

Выбор средств моделирования

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

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

Структурный подход

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

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

SADT (Structured Analysis and Design Technique). Для новых систем SADT (IDEF0) применяется для определения требований (функций) для разработки системы, реализующей выделенные функции. Для уже существующих - IDEF0 может быть использована для анализа функций, выполняемых системой. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры, представляющая собой самое общее описание системы. После описания системы в целом проводится разбиение ее на крупные фрагменты (функциональная декомпозиция).

DFD (Data Flow Diagrams) диаграммы потоков данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Как правило, диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.

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

ER (Entity-Relationship Diagrams) диаграммы "сущность-связь". Методология описания данных (IDEF1X).

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

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

Выводы по диаграммам:

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

Модели SADT (IDEF0) наиболее удобны при построении функциональных моделей. Они наглядно отражают функциональную структуру объекта: производимые действия, связи между этими действиями. Таким образом, четко прослеживается логика и взаимодействие процессов организации. Главным достоинством нотации является возможность получить полную информацию о каждой работе, благодаря ее жестко регламентированной структуре. С ее помощью можно выявить все недостатки, касающиеся как самого процесса, так и то, с помощью чего он реализуется: дублирование функций, отсутствие механизмов, регламентирующих данный процесс, отсутствие контрольных переходов и т.д. архитектура клиент сервер математический

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

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

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

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

Объектно-ориентированный подход

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

Рисунок 2.2 - Сравнительный анализ объектно-ориентированной и функционально-ориентированной декомпозиций

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

Язык UML (Unified Modeling Language) представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем.[2,3]

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

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

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

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

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

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

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

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

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

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

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

Методология ARIS

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

Методология ARIS включает большое количество методов моделирования, в том числе известных как диаграммы Чена ERM, язык UML (Unified Modeling Language), методики ОМТ (Object Modeling Technique), BSC (Balanced Scorecard) и т.п.

К преимуществам методологии ARIS разработчики относят следующие:

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

· богатство методов, позволяет моделировать широкий спектр систем;

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

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

1. Часто у аналитиков знакомящихся с методологией ARIS возникает чувство, что ARIS может все, она решает все проблемы. Это ошибочное мнение. Методология ARIS решает совершенно конкретный круг задач. Если потребности сильно отличаются от возможностей ARIS (например, сбор требований), то подойдет более специализированное и дешевое решение. ARIS в значительно большей степени предназначен для целей управленческого консалтинга и последующей поддержки решений. Использование ARIS в рамках проекта автоматизации противоречит целям, положенным в основу этой методологии ее создателем.

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

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

4. В случае принятия решения о качественной необходимости использования методологии необходимо иметь ввиду, что ARIS нельзя отнести к интуитивно понятным, она требует времени на изучение, на осмысленное применение (вопрос хотя бы в том, что методология содержит больше 100 моделей!). Для успешного применения должны быть разработаны внутренние соглашения о моделировании и документировании.

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

1. Целей проекта;

2. Требований к информации необходимой для анализа и принятия решений в рамках конкретного проекта;

3. Возможностей подхода с учетом требований п. 2;

4. Особенностей разрабатываемой/внедряемой информационной системы.

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

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

Выбор инструментариев моделирования

Существует множество средств моделирования автоматизированных систем. За последние десятилетия сформировалось новое направление в программотехнике - CASE (Computer-Aided Software/System Engineering) на основе методологии структурного системного анализа и проектирования. CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки программного обеспечения (ПО) и сопровождения информационных систем, поддержанную комплексом, взаимосвязанных средств автоматизации [4]. CASE - это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки ПО.

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

Для построения моделей в методологии IDEF0 и IDEF1x использовании CASE-средства BPwin\ERwin от компании Computer Associates. [5] Данные средства по своим функциональным возможностям полностью соответствуют поставленным критериям и при этом обладают удобным интерфейсом.

Остановимся подробно на выборе CASE-средства, для построения моделей по методологиям UML 2.0 и IDEF0. На российском рынке представлен большой набор программных продуктов, поддерживающих эти методологии, наиболее известными из которых являются следующие средства:

1. Microsoft Visio 2007.

2. AllFusion Modeling Suite;

3. Aris Toolset.

1. Microsoft Visio 2007. Это наиболее простое и доступное средство моделирования. Данный продукт имеет стандартные, привычные всем панели управлении в стиле MS Office и легко интегрируется с любыми приложениями этого пакета, что упрощает работу с ним для неопытных пользователей.

CASE-средство Microsoft Visio 2007 поставляется в комплекте с базовым пакетом Microsoft Office и не требует дополнительных затрат на приобретение. Помимо этого данный продукт поддерживает все виды диаграмм языка UML.

2. AllFusion Modeling Suite - пакет инструментальных средств разработанный компанией Computer Associates International, Inc. (CA), пакет поддерживает все этапы разработки информационных систем, в этот пакет входит пять продуктов:

AllFusion Process Modeler - "BPwin" (позволяет облегчить проведение обследования предприятия и построить функциональные модели).

AllFusion ERwin Data Modeler - "ERwin" (позволяет создавать модели данных и генерировать схему баз данных).

AllFusion Data Model Variator - "ERwin Examiner" (позволяет производить поис и исправление ошибок модели данных).

AllFusion Model Manager - "ModelMart" (система организации коллективной работы и хранилище моделей BPwin и ERwin).

AllFusion Component Modeler - "Paradigm Plus" (инструмент создания обьектных моделей).

Рассмотрим продукты которые нам понадобятся в проектировании:

AllFusion Process Modeler - "BPwin": основан на методологии IDEF и предназначен для функционального моделирования и анализа деятельности предприятия. Методология IDEF, являющаяся официальным федеральным стандартом США, представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Возможности BPwin: поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ).

Эти три основных ракурса позволяют:

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

Позволяет оптимизировать процедуры в компании.

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

Позволяет облегчить сертификацию на соответствие стандартам качества ISO9000; интегрирован с ERwin (для моделирования БД), Paradigm Plus (для моделирования компонентов ПО) и др.; содержит собственный генератор отчетов; позволяет эффективно манипулировать моделями - сливать и расщеплять их; имеет широкий набор средств документирования моделей, проектов.