Проектирование бизнес-процесса «Обеспечение послепродажного обслуживания»

Содержание:

Введение

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

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

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

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

Цель курсовой работы - спроектировать реализацию операций бизнес-процесса «Обеспечение послепродажного обслуживания».

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

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

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

- разработка рекомендаций по оптимизации послепродажного обслуживания клиентов в системе предприятия.

Объектом работы является проектирование бизнес-процесса «Обеспечение послепродажного обслуживания».

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

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

Глава 1. Аналитическая часть

1.1. Выбор комплекса задач автоматизации

Курсовая работа рассмотрена на примере общества с ограниченной ответственностью «Интер-Прайм» (далее ООО «Интер-Прайм»). ООО «Интер-Прайм» создано в соответствие с Гражданским кодексом Российской Федерации и Федеральным законом Российской Федерации «Об обществах с ограниченной ответственностью». Компания ООО «Интер-Прайм» работает с 2016 года, специализируясь на продаже программного обеспечения. Целями деятельности ООО «Интер-Прайм» являются расширение рынка товаров и услуг, а также извлечение прибыли.

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

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

Таблица 1.

Основные показатели деятельности компании

№ п\п	Наименование характеристики (показателя)	Значение показателя за 2016 год (руб)
1	Количество обслуженных клиентов	600 человек
2	Прибыль	3 240 000
3	Средняя цена реализации	3000
4	Количество сотрудников	10
5	Среднемесячная заработная плата	20 000

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

Рассмотрим организационную структуру управления (рис.1).

Рисунок 1. Организационная структура управления предприятием

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

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

На бухгалтера возлагаются следующие функции:

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

В функции менеджеров по продажам входят:

• Поиск клиентов;
• Сопровождение продаж;
• Оформление документации, отчетности.

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

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

В функции IT-отдела входят следующие функции:

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

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

На рисунке 2 представлена контекстная диаграмма послепродажного обслуживания.

Рисунок 2. Контекстная диаграмма деятельности послепродажного обслуживания

1.2. Характеристика существующих бизнес-процессов

Отображение бизнес-процессов лучше оформить согласно методологии IDEF0^[1].

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

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

Рисунок 3. Деятельность организации.

Каждая IDEF0-диаграмма содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.

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

Таким образом, можно выделить три класса процессов протекающих в компании:

• планирование;
• выполнение заявок;
• управление.

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

Планирование.

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

Рисунок 4. Планирование

Выполнение заявок.

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

Рисунок 5. Выполнение заявок

Рисунок 6. Работа с клиентами

Управление.

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

Рисунок 7. Управление

1.3. Характеристика документооборота, возникающего при решении задачи

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

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

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

Поток документооборота на предприятии ООО «Интер-Прайм» делится на три составляющие:

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

2.Документы, отправляемые в другие организации/клиентам (исходящие),

3.Документы, используемые в процессе управления организацией (внутренние).

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

На рис. 8. представлена схемы документооборота послепродажного послегарантийного обслуживания.

Оформление заявки на обслуживание

Менеджер -Клиент

Прием оплаты от клиента

Кассир - Клиент

Оформление документов, согласование заявки

Оператор - начальник отдела

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

Системный инженер

Обработка решения (доработка/исправление ошибок)

Инженер

Выносится решение о доработке или отказе

Технический директор (начальник отдела)

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

на обслуживание

Технический директор

Протокол об исправленных ошибках

Заказ / счет

Документ об оплате

Заказ / документ об оплате

Заключение

Решение о доработке

Рисунок 8. Схемы документооборота послепродажного послегарантийного обслуживания

1.4. Обоснование проектных решений по информационному обеспечению

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

Обоснование проектных решений по информационному решению включает следующие пункты:

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

Обоснование состава и содержания входных и выходных документов, метода их построения.

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

Обоснование состава и методов построения экранных форм.

Формы ввода должны быть реализованы в удобном для пользователя виде и позволять изменять любые хранимые данные.

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

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

Обоснование способа организации информационной базы.

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

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

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

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

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

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

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

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

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

- тактовая частота процессора;

- разрешение монитора;

- объем оперативной памяти.

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

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

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

1.5. Обоснование проектных решений по программному обеспечению

Программное обеспечение (далее ПО) включает совокупность программ, реализующих функции и задачи ИС и обеспечивающих устойчивую работу комплексов технических средств. В состав программного обеспечения входят общесистемные и специальные программы, а также инструктивно-методические материалы по применению средств программного обеспечения^[3].

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

При выборе комплекса технических средств для разработки системы, одним из важнейших критерием является выбор операционной системы. Операционная система управляет техническими средствами компьютера, поддерживает запуск и выполнение тех или иных программ и приложений, обеспечивает защиту данных, выполняет различные сервисные функции. Каждая программа пользуется средствами, предоставляемыми операционной системой. Таким образом, выбор операционной системы очень важен, так как он определяет набор программ и формат исполняемых файлов, а также их взаимодействие с операционной системой^[4].

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

- операционные системы семейства Windows от фирмы Microsoft (Windows 7/8/10, Windows XP),

- операционные системы Linux/BSD семейства (UNIX подобные) от различных фирм – разработчиков (Red Hat, Debian, Novel, Mandrake soft, Gentoo, Slackware, IBM, Oracle, NetBSD, OpenBSD, FreeBSD).

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

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

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

Выбор системы управления баз данных (далее СУБД) представляет собой сложную многопараметрическую задачу и является одним из важных этапов при разработке приложений баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды^[5].

Наиболее простой подход при выборе СУБД основан на оценке того, в какой мере существующие системы удовлетворяют основным требованиям создаваемого проекта информационной системы. Более сложным и дорогостоящим вариантом является создание испытательного проекта на основе нескольких СУБД и последующий выбор наиболее подходящего из кандидатов. Но и в этом случае необходимо ограничивать круг возможных систем, опираясь на некие критерии отбора. В данном случае можно выделить несколько групп критериев^[6]:

• • Моделирование данных
  • Особенности архитектуры и функциональные возможности
  • Контроль работы системы
  • Особенности разработки приложений
  • Производительность
  • Надежность
  • Требования к рабочей среде
  • Смешанные критерии

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

Процедуру выбора СУБД следует проводить в три этапа:

• • На качественном уровне оценить предлагаемые программные продукты на предмет пригодности;
  • Оценка технических характеристик отобранных систем;
  • Оценка производительности программных продуктов.

К числу основных показателей пригодности программных продуктов относятся:

• • вид программного продукта;
  • категории пользователей (профессиональные программисты, администраторы БД, квалифицированные пользователи, разрабатывающие приложения, конечные пользователи, различные комбинации перечисленных категорий);
  • удобство и простота использования (понятные процедуры установки программных продуктов, удобный и унифицированный интерфейс конечного пользователя, простота выполнения обычных операций: создания БД, навигации, модификации, подготовки данных, выполнения запросов и отчетов и ряда других; наличие интеллектуальных подсистем подсказок, помощи в процессе работы и обучения, включая примеры);
  • модель представления данных. Наиболее распространенной является реляционная модель данных. Перспективными являются модели с объектной ориентацией, поскольку они обладают большими возможностями отражения семантики предметной области;
  • качество средств разработки. При оценке качества средств разработки учитывается следующее: возможности создания пользовательских интерфейсов, мощность языка создания программ, автоматизация разработки различных объектов: экранных форм, отчетов, запросов. Предпочтение отдается системам, имеющим полнофункциональные генераторы и обеспечивающим удобство работы пользователя;
  • качество средств защиты и контроля корректности базы данных. Доступ к функциям защиты должен предусматриваться на уровне средств разработки программ и на уровне пользователя. К важнейшим функциям контроля корректности относятся: обеспечение уникальности записей БД по первичному ключу, автоматический контроль целостности связей между таблицами во время выполнения операций обновления, вставки и удаления записей, проверка корректности значений в БД;
  • качество коммуникационных средств. При оценке качества коммуникационных средств обращают внимание на следующие свойства программных продуктов:
  • поддержку сетевых протоколов,
  • поддержку стандартных интерфейсов с БД,
  • наличие средств групповой работы с информацией БД,
  • способность использовать и модифицировать БД других форматов без импортирования или преобразования;
  • фирма – разработчик. Солидность фирмы-разработчика пакета, как правило, дает следующие преимущества:
  • высокое качество продукта,
  • наличие документации и методических материалов
  • наличие «горячей линии» для консультаций по возникающим проблемам

Оценка производительности производится методом тестирования с помощью эталонных тестов из набора AS3AP (ANSI SQL Standard Scalable and Portable). В них контролируется широкий спектр часто встречающихся операций БД и моделируются однопользовательские и многопользовательские среды.

Глава 2. Проектная часть

2.1. Информационная модель и её описание

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

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

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

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

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

Рисунок 8. Информационная модель

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

• редактирование справочника объекты;
• редактирование справочника пользователей.

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

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

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

Область 4 отображает то, что моделируема ИС предоставляет на выходе:

• клиент получает результатный документ, содержащий параметры совершённого события и проделанной работе.
  • Из справочника «Спр «Клиенты»» используем текстовое наименование клиента;
  • Из справочника «Спр «Событие»» получаем текстовое наименование События.
  • Из таблицы «Т «Работы»» остальные реквизиты.
• клиент может получить выписку о событии и работах.
  • оператор по окончании какого-либо периода получает файл(реестр) событий.

2.2. Характеристика нормативно-справочной, входной и оперативной информации

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

1) Данные о типе документа;

2) Данные о документах;

3) Данные об отделах;

4) Данные о сотрудниках;

5) Данные о контроле;

6) Данные о поручениях;

7) Данные о исполнении.

Данные типа документа. Содержит данные о типах документах на предприятии. Поступает в бумажном виде. В документе содержатся показатели:

• Номер типа;
• Название типа.

Данные об отделах. Содержит данные об отделах. Поступает в бумажном виде. В документе содержатся показатели:

• Название отдела;
• Руководитель;
• Телефон.

Данные сотрудника. Содержит данные о сотрудниках – составителях и исполнителях документов. Поступает в бумажном виде. В документе содержатся показатели:

• ФИО;
• Дата рождения;
• Телефоны;
• Адрес;
• Должность;
• Отдел.

Данные документа. Содержит данные о документах – корреспонденции, внутренних приказах. Поступает в бумажном виде. В документе содержатся показатели:

• Название документа;
• Содержание;
• Организация, приславшая или кому отсылают;
• Вид документа (входной, выходной);
• Создатель документа;
• Исполнитель (кому направлен);
• Тип документа;
• Руководитель;
• Дата создания.

Данные о контроле документа. Содержит данные о документах – контроле. Поступает в бумажном виде. В документе содержатся показатели:

• Дата контроля;
• Номер документа;
• Номер контроля;
• Выводы.

Данные о исполнении документа. Содержит данные об исполнении документов. Поступает в бумажном виде. В документе содержатся показатели:

• Номер документа;
• Исполнитель;
• Фактическая дата исполнения;
• Отчет об исполнении.

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

• Номер документа;
• Поручитель;
• Кому поручено;
• Поручение;
• Дата поручения;
• Дата исполнения.

2.3. Характеристика результатной информации

В данном разделе описан документ, поучаемый в результате выполнения всех запросов данной задачи и произошедших событий. Результативным документом (в электронной форме) является “Данные в архив”.

Выходной документ «Данные в архив» содержит следующие данные:

• Фамилия заказчика
• Имя заказчика
• Отчество заказчика
• Пол заказчика
• Фамилия оператора
• Имя оператора
• Отчество оператора
• Пол оператора
• Дата события
• Телефон или факс
• Электронный адрес
• Номер подразделения (отдела)
• Название подразделения.

Данный выходной документ является, по сути, более уточненным входным документом “Бланк заказа”, но в отличие от него в “ Данные в архив ” уточняется специалист, который зафиксировал событие. Данные в электронном виде хранятся в БД в таблице «Данные» Табл.3.

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

Таблица № 2

Перечень обозначений типов полей записи базы данных

Наименование типа поля записи	Полное название	Краткое обозначение
Символьный тип	Char	С
Числовой тип	Int	I
Календарная дата	Date	D

Таблица № 3

Структура справочника «Данные» в БД

№	Наименование поля	Идентификатор	Тип	Количество символов
1	ID заказа	ID	I	4
2	Ф.И.О. клиента	FIO_K	C	25
3	Пол заказчика	POL_K	I	1
4	Ф.И.О. разработчика	FIO_R	C	25
5	Пол разработчика	POL_R	I	1
6	Дата заказа	DAT	D	10
7	Электронный адрес	EMAIL	C	20
8	Телефон клиента	TEL	С	5
9	Номер отдела	NUM_OTD	I	3

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

2.4. Общие положения (дерево функций и сценарий диалога)

В процессе создания автоматизированной системы на стадиях жизненного цикла, связанных с требованиями, по ГОСТ 34.602-89 разрабатываются следующие модели:

1. цели системы;
2. смежные системы;
3. границы системы;
4. пользователи системы;
5. связи системы со смежными системами;
6. типовые функциональные требования;
7. связи между подсистемами;
8. схема функциональной структуры;
9. описание автоматизируемых функций;
10. нефункциональные требования;
11. печатные документы;

Инструментарием для создания моделей требования в данной курсовой работе является Case средство Enterprise Architect(далее EA)^[8].

EA является одним из немногих UML инструментов, который интегрирует этап управления требованиями с другими этапами разработки программного обеспечения, создавая требования непосредственно в модели. Вот некоторые отличительные черты ЕА^[9]:

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

Для разработки выше перечисленных моделей в браузере ЕА необходимо создать четыре простые области просмотра (simple view) (рис.9):

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

Рисунок 9. Области просмотра модели в браузере EA

Для разработки модели «Цели системы» используется диаграмма классов (class diagram).

Рисунок 10. Модель «Цели системы»

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

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

Для разработки модели «Пользователи системы» должна использоваться диаграмма функций (use case diagram).

Модель пользователей системы представлена на рис11.

Рисунок 11. Пользователи системы

Целью разработки модели «Границы системы» является отображение системы и взаимодействующих с ней смежных систем.

Для разработки модели «Границы системы» должна использоваться настраиваемая диаграмма (custom diagram).

Рисунок 12. Модель «Границы системы»

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

Целью разработки модели «Типовые функциональные требования системы» является многократное их применения в процессе разработки, внедрения и функционирования системы с целью уменьшения трудоемкости разработки, сроков и затрат на создание системы, ее частей, упрощения процедуры использования системы пользователями^[10].

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

На рис. 13 представлен состав типовых функциональных требований.

Рисунок 13. Состав типовых функций

На рис.14. показаны используемые печатные формы

Рисунок 14. Печатные документы

На рис. 15 изображены требования к системе в целом.

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

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

Для разработки модели «Схема функциональной структуры» используется настраиваемая пользователем диаграмма (custom diagram).

При использовании пакета для изображения подсистемы используется стереотип <<subsystem>>, для изображения модуля – стереотип <<module>> или <<component>>.

Подсистемы системы представлены на рис. 16.

Рисунок 16. Изображения подсистем

Функциональные требования к подсистеме представлены на рис. 17, 18, 19.

Рисунок 17. Изображения требований выдачи заказов

Рисунок 18. Изображения требований приема заявок

Рисунок 19. Изображения требований формирования отчета

Для разработки модели автоматизируемой функции используется диаграмма деятельности (activity diagram).

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

При разработке описания функции работы пользователя с системой поле диаграммы деятельности разбивается на области ответственности с использованием следующих разделительных линий (SwimLines – в контекстном меню):

• пользователь;
• система;
• экранная форма.

Описание функции представлено на рис. 20 и 21.

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

Рисунок 21. Описание функций с использованием диаграммы деятельности

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

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

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

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

2.5. Характеристика базы данных

Систем использует одну базу данных, состоящую из 6 таблиц: Client, Config, Data, Event, Job, Object.

Структурная схема базы данных «Послепродажное обслуживание ПО» представлен на рис. 22.

Рисунок 22. Структурная схема БД

User – в данной таблице содержится информация о пользователях, настройках подключения и авторизации в системе, к каждому пользователю создается отдельная строка в таблице с полями: user- (уникальное имя выданное организацией разработчиком и сопроводителем системы), name- ФИО пользователя, tel – телефон пользователя, address –его адрес, далее идет ссылка на object^[11].

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

Рисунок 23. Визуализация таблицы.

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

- тип события;

Status – какие события произошли в данном сообщении;

Object- ссылка на структуру объект;

JOB -cсылкa на таблицу.

JOB – системная таблица хранения процедур, использующихся в системе, в настоящее время в таблице храниться только одна процедура – Периодический опрос объектов^[12].

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

Data – основная таблица системы, используется для хранения всех данных, полученных от объектов с GPS – радиостанций, по мере работы база данных увеличивается в размерах, что увеличивает время поиска а так же время ответа БД на запросы. По этой причине производится обрезание базы данных. При увеличении базы данных более чем на 2 Гб, администраторами сервера производится обрезание данных, оставляя в таблице данные за три последних месяца. Остальные данные помещаются в архив. Таблица Data состоит из следующих полей^[13]:

GMT – время и дата подачи заявки;

Status – какие события произошли в данном сообщении;

Path – процент выполненной работы;

Moto – предположительное время работы;

Parv – дополнительные параметры, например содержат конфигурацию пользователей и др. параметры

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

2.6. Контрольный пример реализации проекта и его описание

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

Начало функционирования информационной системы от сущности «Клиент» начинается с этапа занесения информации о клиента в справочник «Клиенты».

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

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

Начало

Занесение данных о клиента в БД

CASE: Выбор операции

Предпродажные услуги

Регистрация заявки клиента

Послепродажные услуги

Оказание услуги клиенту на основании заказа клиента

Формирование отчетности:

1.Состояние заказов

2. Прибыль компании

3. Продажи компании

Конец

Определение приоритета заказа

CASE: Выбор операции

Гарантийное обслуживание

Послегарантийное обслуживание

Оплата услуг

Рисунок 24 Алгоритм функционирования всей системы

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

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

После чего, можно рассмотреть отчеты «Клиентская база», «Первичная связь с клиентом», «Обратная связь с клиентом».

Заключение

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

В данной курсовой работе были рассмотрены бизнес-процессы обеспечения послепродажного обслуживания на предприятии, построена модель «AS-IS» в стандарте IDEF0 для объекта «Обеспечение послепродажного обслуживания» для определенного горизонта времени, а также была проанализирована разработанную функциональную модель AS–IS с точки зрения возможности автоматизации функций и разработать требования к будущей автоматизированной системе в виде модели требований в среде Enterprise Architect.

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

1. Буч Г. и др. Язык UML. Руководство пользователя/Г. Буч, Дж. Рамбо, А. Джекобсон: Пер. с англ. – М.: ДМК, 2000.
2. Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика.
3. Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. Пособие. – М.: Финансы и статистика, 2006.
4. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. И доп. – М.: Финансы и Статистика, 2006. – 544 с.
5. Грекул В.И., Коровкина Н.Л., Куприянов Ю.В. Проектное управление в сфере информационных технологий – М.:Бином. Лаборатория знаний , 2013.- 336 с.
6. Карташов, С.С. Образование и XXI век : информационные и коммуникационные технологии : учебное пособие / С.С. Карташов. – М. : Наука, 2005. – 191 с.
7. Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite. – 2-е изд., – М.: Издательство Диалог-МИФИ, 2007 – 400 с.
8. Смирнова Г. Н. , Сорокин А. А. , Тельнов Ю. Ф.  Проектирование экономических информационных систем: Учебник под ред. Ю. Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с.
9. Уткин В. Б. Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В. Б. Уткин, К. В. Балдин. — М.: Издательский центр «Академия», 2004. — 288 с.
10. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА принт, 2006. – 736 с.
11. Хансен, Г. База данных. Разработка и управление : учебник / Г. Хансен, Дж. Хансен. – М. : Беном, 2007. – 148 с.

1. Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. Пособие. – М.: Финансы и статистика, 2006 ↑

2. Смирнова Г. Н. , Сорокин А. А. , Тельнов Ю. Ф. Проектирование экономических информационных систем: Учебник под ред. Ю. Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с ↑

3. Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. Пособие. – М.: Финансы и статистика, 2006 ↑

4. Карташов, С.С. Образование и XXI век : информационные и коммуникационные технологии : учебное пособие / С.С. Карташов. – М. : Наука, 2005. – 191 с ↑

5. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА принт, 2006. – 736 с. ↑

6. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА принт, 2006. – 736 с. ↑

7. Карташов, С.С. Образование и XXI век : информационные и коммуникационные технологии : учебное пособие / С.С. Карташов. – М. : Наука, 2005. – 191 с ↑

8. Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика ↑

9. ↑

10. Грекул В.И., Коровкина Н.Л., Куприянов Ю.В. Проектное управление в сфере информационных технологий – М.:Бином. Лаборатория знаний , 2013.- 336 с. ↑

11. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА принт, 2006. – 736 с. ↑

12. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА принт, 2006. – 736 с. ↑

13. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / под. Ред. Проф. А. Д. Хомоненко. – 5-е изд., доп. – М.: Бином-Пресс; СПб.: КОРОНА принт, 2006. – 736 с. ↑