Проектирование и разработка информационной системы, позволяющей повысить эффективность работы отдела по взаимодействию с клиентами

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

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

Квалификационная работа

Проектирование и разработка информационной системы, позволяющей повысить эффективность работы отдела по взаимодействию с клиентами

СИСТЕМА УПРАВЛЕНИЯ ВЗАИМОДЕЙСТВИЕМ С КЛИЕНТАМИ, НАСЫЩЕННОЕ ИНТЕРНЕТ ПРИЛОЖЕНИЕ, СИСТЕМА УПРАВЛЕНИЯ РЕЛЯЦИОННЫМИ БАЗАМИ ДАННЫХ.

Объектом разработки является информационная система позволяющая автоматизировать отдел по взаимодействию с клиентами.

Цель работы - проектирование и разработка информационной системы позволяющей повысить эффективность работы отдела по взаимодействию с клиентами.

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

Провести анализ состояния объекта автоматизации с цель выявления требований к проектируемой системе;

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

Реализовать спроектированную систему основываясь на современных тенденциях и технологиях;

Разработать дружественный интерфейс системы;

Проверить функционирование системы в тестовом режиме.

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

Содержание

• Введение
• 1.Анализ состояния
• 1.1 Сбор требований
• 1.2 Анализ требований
• 1.3 Анализ рынка продуктов
• 1.4 Определение потребности в собственной разработке
• 2. Разработка проекта
• 2.1 Выбор архитектуры
• 3. Реализация системы
• 3.1 Выбор языка программирования
• 3.2 Выбор платформы
• 3.3 Выбор коммуникационных методов
• 3.4 Выбор инструментов
• 3.5 Конструирование модулей
• 4. Экономическая эффективность.
• 4.1 Прямые экономические эффекты
• 4.2 Косвенные экономические эффекты
• 4.3 Снижение рисков
• 4.4 Расчет себестоимости внедрения.
• 4.5 Оценка экономического эффекта, получаемого за счет роста производительности сотрудников.
• 4.6 Определение показателей эффективности инвестиций
• 5. Безопасность жизнедеятельности
• 5.1 Негативное воздействие компьютера на человека
• 5.2 Компьютерное излучение
• 5.3 Организация рабочего места
• 5.4 Примечание к разделу
• Заключение
• Список литературных источников
• Приложения
• Введение
• В реалиях современной компании занимающейся продажей, каких либо услуг или товаров, менеджеру по работе с клиентами постоянно приходится сталкиваться с колоссальными объёмами информации, она представляет собой сведенья о клиентах, результаты проведённых переговоров и т.п. Высокая информационная нагрузка в данной области бизнеса зачастую приводит к невнимательности сотрудника, что в свою очередь может привести к финансовым потерям предприятия. Для того чтобы представить информацию в доступном и удобном виде и повысить эффективность работы сотрудников в компаниях занимающихся работой с клиентами применяются корпоративные системы управления взаимодействиями с клиентами, которые называются CRM системы. Данные системы обеспечивают автоматизацию стратегии клиентского обслуживания компании, в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процедур и последующего анализа результатов. Системы данного класса решают на предприятиях, данного вида, проблему «потерянных» клиентов возникающей в результате невнимательности сотрудников, вызванной информационной нагрузкой о которой говорилась ранние, а так же в целом поднимает уровень внимательности компании к клиентам.
• Таким образом, очевидно, что наиболее перспективной стратегией по налаживанию долговременных контактов с существующими и потенциальными клиентами, а так же снижение вероятностей ошибок сотрудников работающих в данном направлении является стратегия CRM, которая предлагает поставить клиента в центр внимания с целью удовлетворить его потребности наилучшим образом. В связи с этим вполне закономерным является рост внимания к CRM-системам как со стороны компаний-продавцов в качестве их потребителей, так и со стороны их поставщиков. Этот подход подразумевает, что при любом взаимодействии с клиентом по любому каналу, сотруднику компании доступна полная информация обо всех взаимоотношениях с этим клиентом и решение принимается на основе этой информации (информация о решении, в свою очередь, тоже сохраняется).
• В данный момент на рынке CRM систем существуют системы, занимающие все возможные ниши данного направления бизнеса. Это позволяет компаниям, в серьёз задумывающимся о современных методиках ведения бизнеса и успешном экономическом развитии, найти для себя наилучший вариант системы, отвечающий всем самым специфическим требованиям. Следовательно, данный сектор производства ПО является высокоперспективным для развития и вложения.
• 1. Анализ состояния
• Анализ состояния позволяет оценить положение дел на предприятии с целью выявления функциональных и не функциональных требований к ПО, которое в свою очередь будит являться инструментом автоматизации данного объекта.
• Выполнение же подобного анализа проводиться при помощи UML, IDEF, ARIS и других методологий подобного характера позволяющих представить собранную информацию о объекте автоматизации в виде конкретизированной модели с чёт определёнными участниками и функциями.
• Следует отметить, что анализ состояния в первую очередь базируется на одной из методик проектирования, таких как XP, RAD, RUP и MSF. Для подробного рассмотрения каждой из методик ниже в таблице 1.1 приведён их сравнительный анализ.
• Знак «+» в ячейке таблицы свидетельствует о том, что данная методика обладает выбранным свойством, а в противном случи ставиться знак «-». А такое сочетание знаков «+/-» свидетельствует о не полной реализации данного свойства в рассматриваемой методике.
• Таблица 1.1 - Сравнение методик проектирования

Свойства методик	Наименование методик
	MSF	RUP	RAD	XP
Объектно-ориентированный подход	-	+	+	-
Гибкость методики	+	-	+	+
Малый коллектив разработчиков	-	-	+	+
Отсутствие ограничений на технологии и инструменты	+	-	+/-	+
Удобство модификации и сопровождения	+	+	+	-
Планирование рисков на высоком уровне	+	+	-	-
Итеративность разработки	+	-	+	+

• На основе анализа данных и таблицы выше, для разработки автоматизированной системы управления складским хозяйством, была выбрана методика проектирования RAD, как наиболее удовлетворяющая заданному набору критериев. Так же следует отметить, что при использовании данной методики применяется удобный и понятный подход для специалиста, использующего данную методику впервые, по этой причине для построения диаграммы AS-IS и других диаграмм будет применяться методология ARIS.
• Следует отметить что проектируемая система будет носить массовый характер, а следовательно все требования должны быть представлены в усреднённом виде.

1.1 Сбор требований

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

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

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

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

Предприятие состоит из 5 отделов:

- Отдел клиентского обслуживания;

- Отдел маркетинга;

- Аналитический отдел;

- ИТ подразделение;

- Отдел рекламы.

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

К объектам автоматизации рассматриваемой организации относятся отдел клиентского обслуживания, отдел маркетинга и аналитический отдел.

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

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

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

Перечень документов

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

Знак «+» в ячейки таблице свидетельствует о принадлежности документа к определенному его типу, знак «-» говорит об обратном.

Таблица 1.2 - Перечень документов

Наименование документа	Тип документа
	Отчётный	Плановый	Учётный	Договор
Отчёт о проведенной встрече	+	-	-	-
Отчёт о прозвоне клиентов	-	+	-	-
Отчёт о проведенной презентации	+	-	-	-
Отчёт по продажам за неделю	-	+	-	-
Информационный свод маркетингового исследования	-	-	+	-
Отчёт по результатам маркетингового опроса	+	-	-	-
Отчёт о маркетинговом исследовании	-	+	-	-
Договор на оказании услуг/продажу	-	-	-	+

Первичные требования

Первичные требования к автоматизации представлены на ниже сформированном списке:

- организовать централизованную базу данных о клиентах с целью предотвращения сегментации данных;

- сформировать единое хранилище шаблонов документов для удобства к ним доступа, а так же ввести учёт печати данных документов;

- ввести историю всех продуктовых линеек;

- Обеспечить автоматизацию сводной отчётности;

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

- Формирование инструмента формирующего онлайн опросы для клиентов;

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

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

1.2 Анализ требований

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

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

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



Процессы объекта автоматизации

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

Таблица 1.3 - Описание процессов объекта автоматизации

Наименование	Описание	Участники	Документы	Возможная автоматизация
1	2	3	4	5
Привлечение	Проведение презентаций продукции для клиентов, прозвон клиентов	Руководитель и сотрудники отдела клиентского обслуживания	Отчёт о прозвоне, отчёт о презентации	Организация сопутствующей информации в единую структуру для решения проблемы сегментации, а так же добавление документов в единое хранилище для простоты доступа, разработка инструмента позволяющего отслеживать закрёплённых сотрудников за клиентом с целью предотвращения повторных обращений
Продажи	Проведение деловых встреч с клиентами с целью заключения договоров	Руководитель и сотрудники отдела клиентского обслуживания	Договор, отчёт о встрече
Ведение клиентской базы	Сбор информации о клиентах в единую базу данных	Руководитель и сотрудники отдела клиентского обслуживания, сотрудники отдела маркетинга	Сводная клиентская таблица	Создание электронной базы данных на основе СУБД для организации единого информационного хранилища
1	2	3	4	5
Аналитика продаж	Подсчёт количества действующих клиентов и количества продаж за определённый период	Руководитель и сотрудники аналитического отдела	Сводная таблица по продажам и клиентам	Автоматизация расчетов и свода информации о продажах по средствам единой СУБД
Маркетинговые исследования	Проведения исследования среди клиентской аудитории	Руководитель и сотрудники отдела маркетинга	Отчёт по результатам маркетингового опроса, отчёт по маркетинговому исследованию	Автоматизация сведения информации полученного из опроса.

Определение границ предметной области (концептуальное проектирование)

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

Таблица 1.4 - Функциональные и не функциональные требования к системе

Функциональные	Не функциональные
1	2
Возможность вносить в базу данных информацию о новых клиентах, а так же изменять информацию о старых	Выполнение запросов к системе должно занимать меньше минуты
Должна быть организованна возможность закрепления клиента за персональным менеджером	Модули для отдела маркетинга и ОКО должны быть разделены
Необходима возможность отслеживать задачи для сотрудников, а так же организовывать коллективные работы с равномерно распределённой нагрузкой.
По всем клиентам должна вестись история их взаимоотношений с компанией за счёт возможности занесения информации о результатах взаимодействия клиет-компания сотрудниками.	Вся отчётность для быстрой печати должна соответствовать формату А4.
Все должностные лица, через которых осуществляться связь с клиентом должны быть отражены в системе, т.е. их можно как добавлять, так и удалять	Доступ к системе должен быть организован только по должностным допускам.
Все документы необходимые для работы должны храниться в централизованном хранилище
Доступ в систему должен осуществляться по логинам и паролям	Интерфейс должен быть максимально простым и функциональным
В системе должно присутствовать разграничение прав
1	2
Все информация о клиентах должны быть представлена виде электронных таблиц с возможностью печати.	Доступ к системе должен осуществляться через веб интерфейс
Необходимо средство формирование электронных опросов через интернет.	Система должна поддерживать внесения информации как латиницей так и кириллицей.
Необходима автоматизация отчётности по продажам представляющая собой автоматическое составление и возможность их печати.

Область ответственности сотрудников объектаавтоматизации

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

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

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

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

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

- Аналитика продаж - заключается в анализе работы по продаже товара или услуги для дальнейшего реагирования на результаты продаж того или иного вида продукта;

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

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

AS-IS диаграмма

На основании всех выше приведённых сведениях необходимо построить диаграмму AS-IS (приложение А) которая представляет собой подробное моделирование бизнес процессов на объекте до начала автоматизации. Данная диаграмма будит изображена на основании методологии ARIES по принципу eEPC, что позволит отразить на ней все аспекты дел на данном объекте с высокой точностью.

Определение степени автоматизации (области охвата)

На основании диаграммы AS-IS следует отметить аспекты, данного объекта которые стоит подвергнуть автоматизации для обеспечения более эффективной работоспособности предприятия. Результатом данной операции станет перечень функций, которые необходимо подвергнуть автоматизации (таблица 1.6).

Таблица 1.6 - Перечень аспектов для автоматизации

Наименование	Результат	Уровень/Причина
1	2	3
Свод различной информации о клиентах, продажах и маркетинговых исследованиях	Все информация хранящаяся в системе автоматически сводиться в глобальные таблицы.	Полная автоматизация. Причиной полной автоматизацией послужили высоки время затраты на выполнение данной операции.
Актуальность информации	Всякое изменение информации о клиенте или о какой другой сущности важной для выполнения бизнес задач доступна в режиме реального времени.	Полная автоматизация. Так как передача информации является одной из первоочерёдных задач в любой бизнес-системе, то ей отводится особое значение в вопросах скорости и корректности пересылки информации
Сохранность информации о клиенте	Централизованное хранилище информации, каждый день производиться резервное копирование с целью избежать ситуаций её утраты.	Полная автоматизация. Для данного направления бизнеса, сохранность информации о клиенте является первоочерёдной задачей.
1	2	3
Автоматическое напоминание о событиях	Автоматическое напоминание сотрудникам о важных задачах которым следует уделить особое внимание.	Полная автоматизация Одним из важных факторов любого бизнеса является своевременное выполнение определённых действия.
Сохранность рабочих документов	Централизованное хранилище документов и шаблонов.	Полная автоматизация Удобный способ доступа к данным такого характера прямапропарционально влияет на эффективность заключения договоров.
Разделение информации	Уровень доступа к данным системы разграничен по предписанию должностных инструкций	Полная автоматизация. Организация рабочего процесса на основании должностных инструкций является основной задачей должностных разграничений.

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

1.3 Анализ рынка продуктов

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

На основании диаграммы TO-BE были сформированы следующие основные требования к CRM системе для автоматизации направления клиентского обслуживания:

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

- Управление продажами -- набор интегрированных приложений для автоматизации продаж;

- Управление маркетинговыми акциями -- решения, позволяющие провести сбор информации для маркетинговых исследований;

- Управление взаимоотношениями с клиентами -- данное решение представляет собой единую базу клиентов, в которой содержится вся информация о взаимодействии с ними;

- Управление взаимоотношениями с сотрудниками -- модуль, позволяющий значительно усовершенствовать штатное обучение, качество работы сотрудников;

- Маштабируемость - возможность расширения системы;

- Адаптируемость - возможность адаптации системы под конкретные условия;

- Наличие API.

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

- SalesLogix;

- Oracle Siebel CRM;

- Terrasoft CRM Bank;

- Microsoft Dynamics CRM/

Анализ перечисленных систем представлен в таблице 1.7.

При полном соответствии функционала требованию в таблице ставиться «+», при превышении его «++», при не полной его реализации «+/-»,егоотсутствии



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

В пункте 1.3 было проведено сравнение лицензируемых CRM систем по результатам которого можно выбрать Oracle Siebel CRM и Microsoft Dynamics AX. Но прежде чем останавливаться на лицензируемой CRM следует определить целесообразность её использования в данном случи по сравнению с индивидуальной разработкой. Для это следует сравнить данные решения по следующим критериям:

- Цена - стоимость применения данного решения;

- Соответствие требованиям - соответствие функциональным и не функциональным требованиям заказчика;

- Технические требования - требование к оборудованию для работы продукта;

- Срок внедрения - срок за который данная система будит развёрнута на объекте автоматизации;

- Специалисты по сопровождению - персонал который будит сопровождать данную систему.

Таблица 1.8 - сравнение индивидуальных и лицензируемых CRM

Критерий	Лицензируемая CRM	Индивидуальная CRM
Цена	Высокая стоимость лицензий, большой риск переплаты за лишний функционал. Риск закупок сопутствующих лицензий (например ОС)	Цена прямо зависит от функционала.
Соответствие требованиям	Не полное соответствие требованием, так как система не разрабатывается с нуля, а стоиться на уже готовых модулях.	Полное соответствие
Технические требования	Высокий риск закупки дорогостоящего оборудования отвечающего требованиям лицензируемого продукта.	Соответствие возможностям заказчика
Срок внедрения	Зависит от объёма лицензируемого решения	Зависит от объёма разрабатываемого решения
Специалисты по сопровождению	Сертифицированные специалисты фирмы подрядчика	Возможность проведения обучения персонала совместно с разработкой

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

проектирование система программирование себестоимость

2. Разработка проекта

Разработка проекта по методологии RAD объединяет в себе детализированное проектирование, построение (кодирование и тестирование), также поставку программного продукта заказчику за определённое время. Сроки выполнения этой фазы в значительной мере зависят от использования генераторов кода, экранных генераторов и других типов производственных инструментальных средств.

2.1 Выбор архитектуры

Работа традиционных веб-приложений сконцентрирована вокруг клиент-серверной архитектуры с тонким клиентом. Такой клиент переносит все задачи по обработке информации на сервер, а сам используется лишь для отображения статического контента (например, HTML-кода). Основной недостаток этого подхода в том, что все взаимодействие с приложением должно обрабатываться сервером, что требует постоянной отправки данных на него, ожидания ответа сервера и загрузки страницы обратно в браузер. При использовании технологии запуска приложений на стороне клиента, RIA могут обойти этот медленный цикл синхронизации за счет большего взаимодействия с пользователем. Сравнение принципов работы веб-приложения и RIA-приложения представлено на рисунке 2.1.



Рисунок 2.1 - Сравнение классического HTML-приложения и RIA-приложения

Основными достоинствами и преимуществами RIA-приложений являются:

- RIA предлагают пользовательский интерфейс, не ограниченный лишь использованием языка HTML, применяемого в стандартных веб-приложениях;

- интерфейсы RIA более интерактивны, чем стандартные интерфейсы веб-браузеров, которые требуют постоянного взаимодействия с удаленным сервером;

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

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

- приложения, доступные через браузер, не требуют установки;

- кросс-платформеность и кросс-браузерность;

- автоматическое обновление версий (версия программы обновляется на сервере);

- частичная возможность работы в режиме offline.

Выше приведенная характеристика архитектуры позволяет судить о её полном соответствии требованиям, представленным в приложении Б.

Логическая структура

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

Рисунок 2.2 - Логическая структура.

Физическая структура

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

- Сервер СУРБД - служит для хранения данных информационной системы;

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

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

На рисунке 2.3 приведена физическая структура разрабатываемой системы.

Рисунок 2.3 -- физическая структура информационной системы

Таблица 2.1 - Сравнение систем хранения данных.

Свойство	Система хранения
	XML	OLAP-кубы	PlainText	СУРБД
Совместимость с php	полная	Полная (при условии использование в качестве платформы Oracle.)	полная	полная
Максимальный размер таблицы	4 гигабайта	В среднем 5 терабайт	4 гигабайта	В среднем 5 терабайт
Удобство представления информации	Высокое (данная схема обладает строго определённой структурой, с высокой наглядностью)	Низкое (информация представлена в сжатом и зашифрованном виде)	Высокое (разработчик сам выбирает способ представления информации)	Низкое (информация представлена в сжатом и зашифрованном виде)
Скорость выборки	Средняя	Максимальная (данная система ориентирован на максимальную скорость доступа к информации)	Низкая (функционал обеспечивающие выборки являются стандартными строчными функциями)	Высокая (напрямую зависит от аппаратных характеристик сервера)

На основании выше приведённого сравнения в качестве системы хранения данных была выбрана СУРБД. Выбор так же основан на требовании приведённых в приложении Б и методики проектирования RAD, которое предписывает использовать для разработки те средства, которыми владеет команда разработчиков. Разработанная информационная система может работать с СУРБД Oracle.

Для реализации структуры хранилища данных была выбрана схема Снежинки, которая представляет собой реляционную OLAP структуру (ROLAP). Преимуществами данного метода являются следующие позиции:

- Реляционные СУБД имеют реальный опыт работы с очень большими БД и развитые средства администрирования. При использовании ROLAP размер хранилища не является таким критичным параметром;

- При оперативной аналитической обработке содержимого хранилища данных инструменты ROLAP позволяют производить анализ непосредственно над хранилищем (потому что в подавляющем большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД);

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

- Системы ROLAP могут функционировать на достаточно не производительных серверах, поскольку основная вычислительная нагрузка в них ложится на сервер, где выполняются сложные аналитические SQL-запросы, формируемые системой;

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

Структура хранилища данных приводится в приложении В.

Атрибуты качества

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

Так как в качестве системы внешних данных была выбрана СУРБД, этот факт позволяет наращивать производительность данной системы путём увеличения аппаратной конфигурации сервера и увеличения их числа. А использование ROLAP структуры в значительной мере повышает скорость выполнения запросов. По причине того что в качестве платформы была выбрана ORACLE безопасность данной системы является высокой за счёт автоматического восстановления данной СУБД при непредвиденных перезагрузках и зависаниях системы. К тому же в требованиях к системе чётко оговорено разграничения доступов пользователей к информации на основании должностных обязанностей и инструкций.

3. Реализация системы

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

- Языки программирования;

- Платформы;

- Коммуникационные методы;

- Инструменты.

3.1 Выбор языка программирования

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

Язык программирования PHP обладает всеми необходимыми средствами для создания современной RIA системы. Методика проектирования RAD предполагает такой подход к разработке, при котором приложение делится на программные модули. Модули являются независимыми друг от друга. Такой подход достижим лишь при полноценной поддержке объектно-ориентированного подхода и пространств имен в программировании. Такими техническими возможностями обладает версия 5.3. данного языка.

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

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

Для реализации web-страниц были использованы язык разметки XHTML, являющийся расширением стандартного языка разметки web-страниц HTML и язык CSS.

Поскольку в разделе 2.1.2 в качестве хранения была выбрана СУРБД Oracle, то языком запросов будет SQL.

3.2 Выбор платформы

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

Выбор операционной системы

Так как для разработки была предпочтена RIA архитектура, информационная система является кроссплатформенной. В процессе разработке система была сконструирована таким образом что бы она поддерживала ОС типа Windows и Unix. Так же является теоретически возможной работа информационной системы на Mac OS.

Выбор framework средств

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

В качестве framework для программирования клиентской бизнес логики, интерфейса и ajax запросов, был использован JQuery Framework. Выбор этого framework обоснован подходом методики проектирования RAD, требующим использовать для разработки те средства, которыми владеет команда разработчиков. Основным применением этого framework стало построение запросов ajax, использование селекторов, управление css свойствами HTML тегов и работа с DOM.

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

- jQuery UI - сборник плагинов отвечающих за оформление и анимации выполняемых на странице действий пользователем;

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

3.3 Выбор коммуникационных методов

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

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

Рисунок 3.1 _ Блок-схема работы технологии AJAX

Помимо обеспечения интерактивности интерфейса, технология AJAX обладает следующими преимуществами:

- Экономия трафика - для обновления данных web-страницы, загружаются только необходимые данные, а не вся страница;

- Уменьшение нагрузки на сервер - сервер генерирует только запрашиваемые данные, а не всю web-страницу в целом;

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

3.4 Выбор инструментов

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

Выбор среды разработки

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

- Семантическая и синтаксическая поддержка языков программирования PHP, Javascript, HTML, CSS;

- Интеллектуальное автозавершение кода;

- Навигатор проекта и функций;

- Бесплатное распространение продукта.

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

Выбор графического редактора

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

- Возможность работы, как с векторной, так и растровой графикой;

- Поддержка jpeg, png, gif и других широко распространенных форматов;

- Бесплатное распространение продукта.

В качестве графического редактора был выбран Gympt, поскольку она удовлетворяет всем предъявленным требованиям.

3.5 Конструирование модулей

При использовании методики проектирования RAD, следует разрабатывать все модули информационной системы в виде независимых объектов. Для обеспечения объектно-ориентированного подхода при разработке приложения, была разработана программная архитектура информационной системы. Данная структура базируется на использовании php составляющей, как коммутирующего средства между СУБД и пользовательской частью пересылающей информацию либо виде JSON массивов, либо обычных текстовых строк. Клиентский же интерфейс строиться и обрабатываться на основании Java Script.

В JSON массивах содержаться информация необходимая для формирования таблиц. Строящихся при помощи функций из библиотеки DataTables. Данные функции выступают в роли шаблонизатора таблиц и их минимальных инструментов управления. Функции же из библиотеки jQuery UI отвечают за анимацию меню и автоматическую вставку даты при заполнении соответствующих модулей.

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

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

В роли прямого контроллера доступа к СУБД выступает php class DATABASE. Его основная роль заключается в структурировании системы взаимодействия СУБД и приложения. Введение подобного класса необходимо для внесения чёткого формировании запросов при обращении к системе, а так же для обеспечения удобного интерфейса для разработки новых модулей. А так же в перспективе доработки класса для применения данной системы на базе какой либо ещё СУБД платформе, а так же других источников данных. Часть листинга данного класса приведена на рисунке 3.2, полный листинг приведён в приложении Г.

function ConstructOCI8() {

if (($this->select == true) and ($this->from == true))

{

$this->construct = "select $this->select

from $this->from

$this->where

$this->join " ;

return $this->construct;

}

}

Рисунок 3.2 - Часть листинга файла DataDaseClass.php

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

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

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

а) Клиентское обслуживание;

1) Юридические лица;

2) Физические лица;

3) Встречи;

4) Сотрудники;

5) События;

6) Конструктор акций

б) Маркетинговые заделы;

Модуль клиентского обслуживания

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

Данный модуль разделён на 7 составных частей:

- Юридические лица;

- Физические лица;

- Встречи;

- Сотрудники;

- События;

- Личный кабинет;

- Конструктор акций.

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

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

Рисунок 3.3 - Физическая структура модуля клиентского обслуживания

PHP обработчик представляет собой множество различных исполняемых файлов, задачей которых является произведение запросов к СУБД, по средствам класса DATABASE и передача структурированной информации шаблонизатору. Часть листинга функции из данного файла приведена на рисунке 3.4, полный листининг приведён в приложении Г.

$avtCon->SelectOCI8('*');

$avtCon->FromOCI8('PROF_P');

$avtCon->WhereOCI8(" ID_P != $vivod ");

$res = $avtCon->resultOCI8();

$nrows = oci_fetch_all($res, $prazn);

for ($i = 0; $i < $nrows; $i++ ) {

echo" <option value='"

.$prazn['ID_P'][$i]."'>".$prazn['NAME'][$i].

"</option>";

}

Рисунок 3.4 - Часть листинга файла Editing.php отвечающего за конструирования формы для редактирования.

Контроллер событий обращающийся к данному файлу представляет собой JavaScript функцию которая по средствам AJAX производит запрос на необходимую информацию. Листининг одной такой функции приведён на рисунке 3.5, полный же листинг данного файла приведён в приложении Г.

function ShowError(code) {

HideError();

switch (code) {

case 0:

$('#error0').html(er0).slideDown();

break;

case 1:

$('#error0').html(er1).slideDown();

break;

case 2:

$('#error0').html(er2).slideDown();

break;

case 3:

$('#error1').html(er3).slideDown();

break;

case 4:

$('#error2').html(er4).slideDown();

break;

case 5:

$('#error2').html(er5).slideDown();

break;

}

}

Рисунок 3.5 - Листинг функции ShowError, отвечающей за вывод ошибок

Пример графической реализации данного модуля приведён в приложении Д.

Подмодуль Юридические лица

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



Рисунок 3.6 - Логическая структура подмодуля Юридические лица

Физическая структура подмодуля представлена на рисунке 4.7.

Рисунок 3.7 - Физическая структура подмодуля Юридические лица

Подмодуль Физические лица

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



Рисунок 3.8 - Логическая структура подмодуля Физические лица

Физическая структура подмодуля Физические лица представлена на рисунке 3.9.

Рисунок 3.9 - Физическая структура подмодуля Физические лица

Подмодуль Встречи

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



Рисунок 3.10 - Логическая структура подмодуля Встречи

Физическая структура подмодуля Встречи представлена на рисунке 3.11.

Рисунок 3.11 - Физическая структура подмодуля Встречи

Подмодуль Сотрудники

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



Рисунок 3.12 - Логическая структура подмодуля Сотрудники

Физическая структура подмодуля Сотрудники представлена на
рисунке 3.13.

Рисунок 3.13 - Физическая структура подмодуля Сотрудники

Подмодуль События

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



Рисунок 3.14 - Логическая структура подмодуля События

Физическая структура подмодуля События представлена на
рисунке 3.15.

Рисунок 3.15 - Физическая структура подмодуля События

Подмодуль Личный кабинет

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



Рисунок 3.16 - Логическая структура подмодуля Личный кабинет

Физическая структура подмодуля Личный кабинет представлена на
рисунке 3.17.

Рисунок 3.17 - Физическая структура подмодуля Личный кабинет

Подмодуль Акции

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



Рисунок 3.18 - Логическая структура подмодуля Акции

Физическая структура подмодуля Акции представлена на рисунке 4.19.

Рисунок 3.19 - Физическая структура подмодуля Акции

Модуль Маркетинговые заделы

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

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

Пример графической реализации данного модуля приведён в приложении Д. Логическая структура представлена на рисунке 4.20.



Рисунок 3.20 - Логическая структура модуля маркетинговые заделы

Физическая структура модуля маркетинговые заделы представлена на рисунке 3.21.

Рисунок 3.21 - Физическая структура модуля маркетинговые заделы

4. Экономическая эффективность

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

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

Рисунок 4.1 - Экономические эффекты от внедрения CRM

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

Итак, разделим экономические эффекты на три условные категории:

- Прямые экономические эффекты;

- Косвенные экономические эффекты;

- Эффекты снижения рисков.

4.1 Прямые экономические эффекты

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

Таблица 4.1 - Прямые экономические эффекты категории повышения доходов.

Состояние до внедрения	Изменения	Краткосрочные эффекты после внедрения	Долгосрочные эффекты после внедрения
Единая база клиентов не ведется. Возможности сегментации по разным показателям (в том числе динамическим) отсутствуют	Сегментация клиентов	Рост продаж за счет фокусировки на доходных/прибыльных клиентах	Повышение доходов компании за счет выявления наиболее прибыльных сегментов и предложения им лучшей потребительской ценности Повышение доходов компании за счет кросс-продаж
Функциональная структура организации, нет ответственных за отношения с клиентами

Страница:

•  1 
•  2 
дипломная работа "Проектирование и разработка информационной системы, позволяющей повысить эффективность работы отдела по взаимодействию с клиентами" скачать



Подобные документы

• Информационная система компании "Радуга-ТВ". Отдел продаж

  Анализ принципа работы отдела продаж на примере "Радуга-ТВ". Математическое моделирование работы с клиентами отдела продаж. Выбор архитектуры информационной системы, средств ее проектирования. Выбор системы управления базой данных, программные требования.
  
  дипломная работа [1,7 M], добавлен 20.07.2014
  

• Защита информационной системы криптографическими алгоритмами

  Разработка информационной системы, позволяющей повысить эффективность управления деятельностью автосервиса за счет использования современных компьютерных технологий. Построение базы данных в Microsoft SQL Server. Описание пользовательского интерфейса.
  
  дипломная работа [417,5 K], добавлен 27.01.2009
  

• Проектирование автоматизированной информационной системы магазина компьютеров и ноутбуков "Джей"

  Анализ проектирования автоматизированной информационной системы компьютерного магазина "Джей". Разработка базы данных на языке Transact-SQL в системе управления базами данных Microsoft SQL Server 2000. Расчет себестоимости и цены программного продукта.
  
  курсовая работа [2,3 M], добавлен 16.08.2012
  

• Проектирование и разработка автоматизированной информационной системы туристического агентства ООО "Управляющая компания"

  Разработка и внедрение автоматизированной информационной системы (АИС) работы с клиентами туристической фирмы (приема и обработки заявок). Технико-экономическая оценка туристического агентства, алгоритм и схема интерфейса программного обеспечения его АИС.
  
  дипломная работа [4,0 M], добавлен 21.07.2011
  

• Разработка информационной системы для отдела грузоперевозок ОАО "Кричеврайагропромтехснаб"

  Проектирование многопользовательской информационной системы для автоматизации работы диспетчера отдела грузоперевозок. Выбор среды программирования. Разработка программного обеспечения, таблиц базы данных АСОИ. Построение диаграмм классов и деятельности.
  
  курсовая работа [298,1 K], добавлен 03.06.2014
  

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

  Цель создания информационной системы. Автоматизированная информационная система "Строительное предприятие". Использование вычислительной техники и программного обеспечения для создания автоматизированной информационной системы управления на предприятии.
  
  курсовая работа [2,5 M], добавлен 04.01.2011
  

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

  Выбор языка и среды программирования, технологий доступа и взаимодействия с источниками данных. Требования к разработке информационной системы. Проектирование базы данных информационной системы учета и взаимодействующего с ней приложения .NET Framework.
  
  курсовая работа [1,3 M], добавлен 17.05.2013
  

• Разработка АИС управления взаимоотношениями с клиентами

  Разработка автоматизированной информационной системы управления взаимоотношениями с клиентами Токаревского мясокомбината, анализ и выбор используемых средств. Проектирование структуры базы данных и пользовательского интерфейса, генерации отчетов.
  
  дипломная работа [2,3 M], добавлен 05.07.2009
  

• Проектирование автоматизированной системы "Деятельность автосервиса"

  Разработка автоматизированной системы, которая позволит повысить эффективность и качество работы автосервиса. Автоматизация процессов оказания консультационных услуг клиентам и закупки запчастей. Моделирование фрагментов системы в стандарте IDEF3.
  
  курсовая работа [657,5 K], добавлен 19.06.2013
  

• Разработка информационной системы учета призывников в администрации (на примере администрации с. Казинка)

  Разработка требований к программному обеспечению отдела воинского учета, методология проектирования информационной системы. Реализация и аттестация информационной системы, взаимодействие приложения с источниками данных, его экономическая эффективность.
  
  дипломная работа [1,3 M], добавлен 30.11.2010
  

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

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам