Проектирование базы данных информационной системы Online-доступа ООО "Мика-Сервис"

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 05.11.2017
Размер файла 1,7 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Реферат

106 стр., 33 рис., 19 таб., 14 библиогр.

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

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

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

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

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

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

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

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

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

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

Содержание

Введение

1. Определение границ предметной области

1.1 Цели и предмет деятельности ООО «Мика-Сервис»

1.2 Организационная модель ООО «Мика-Сервис»

1.3 Функциональная модель ООО «Мика-Сервис»

1.4 Информационная модель ООО «Мика-Сервис»

1.5 Основные бизнес-процессы ООО «Мика-Сервис»

1.6 Сценарий проблемного бизнес-процесса организации работы по обслуживанию заявки клиента

1.7 Выявление причины появления проблем во время обслуживания заявки клиента в ООО «Мика-Сервис»

1.8 Содержательная постановка задачи

2. Системное исследование ООО «Мика-Сервис»

2.1 Математическая модель и ее оптимизация

2.2 Оптимизированный сценарий уведомления клиента о состоянии работ по его заявке

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

2.4 Модели бизнес-процессов ООО «Мика-Сервис»

2.5 Формирование требований к информационной системе Online-доступа к сведениям о состоянии обслуживания и ремонта компьютерной и оргтехники в ООО «Мика-Сервис»

3. Проектирование информационной системы Online-доступа к сведениям о состоянии обслуживания и ремонта компьютерной и оргтехники в ООО «Мика-Сервис»

3.1 Обзор информационных систем автоматизации сервис-центров

3.1.1 «Управление сервисным центром» от компании Айти-Лаб

3.1.2 «Сервисный центр» от компании Inlinesoft

3.1.3 Naumen Service Desk

3.1.4 Сравнительный анализ информационных систем автоматизации сервис-центров

3.2 Информационные связи информационной системы Online-доступа к сведениям о состоянии обслуживания и ремонта компьютерной и оргтехники в ООО «Мика-Сервис»

3.3 Выбор архитектуры информационной системы Online-доступа к сведениям о состоянии обслуживания и ремонта компьютерной и оргтехники в ООО «Мика-Сервис»

3.4 Проектирование структуры информационной системы Online-доступа ООО «Мика-Сервис»

3.5 Проектирование базы данных информационной системы Online-доступа ООО «Мика-Сервис»

4. Реализация информационной системы Online-доступа к сведениям о состоянии обслуживания и ремонта компьютерной и оргтехники в ООО «Мика-Сервис»

4.1 Выбор средств реализации информационной системы Online-доступа к сведениям о состоянии обслуживания и ремонта компьютерной и оргтехники в ООО «Мика-Сервис»

4.1.1 Операционная система

4.1.2 Система управления базами данных

4.1.3 Среда разработки

4.1.4 Технические средства

4.2 Прототип интерфейса информационной системы Online-доступа к сведениям о состоянии обслуживания и ремонта компьютерной и оргтехники в ООО «Мика-Сервис»

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

Введение

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

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

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

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

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

1. Определение границ предметной области

1.1 Цели и предмет деятельности ООО «Мика-Сервис»

В уставе основной целью ООО «Мика-Сервис» обозначено получение прибыли за счет оказания сервисных услуг на возмездной основе [1].

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

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

1. гарантийный ремонт компьютерной и офисной техники (копиров, принтеров, факсов, мониторов)

2. постгарантийный ремонт компьютерной и офисной техники (копиров, принтеров, факсов, мониторов)

3. перепрограмирование и заправка картриджей для офисной техники

1.2 Организационная модель ООО «Мика-Сервис»

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

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

Основные функции сервисного центра:

1. Предоставление качественного сервиса

2. Своевременно проведение ремонтных работ в полном объеме

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

4. Продажа оригинальных запасных частей и комплектующих

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

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

Рисунок 1. - Организационная модель сервисного центра ООО «Мика-Сервис»

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

1.3 Функциональная модель ООО «Мика-Сервис»

На данном этапе необходимо создать функциональную модель предприятия, которая должна отражать:

1. Взаимодействие предприятия с внешней средой (партнеры, клиенты, и т.д.);

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

3. Взаимодействие отделов предприятия в ходе производственной деятельности.

Состоит модель из двух частей:

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

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

Рисунок 2. - Функциональная модель сервисного центра ООО «Мика-Сервис» (внутренняя)

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

Рисунок 3. - Функциональная модель сервисного центра ООО «Мика-Сервис» (внешняя)

1.4 Информационная модель ООО «Мика-Сервис»

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

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

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

Если ремонт был по гарантии, то клиент не вносит оплату за отремонтированное оборудование.

Рисунок 4. - Информационная модель сервисного центра

1.5 Основные бизнес-процессы ООО «Мика-Сервис»

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

Бизнес-процессы бывают трех видов:

1. Управляющие - бизнес-процессы управляющие функционированием системы.

2. Операционные - бизнес-процессы, создающие основной поток доходов.

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

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

В работе сервисного центра выделим бизнес-процесс «Заявка на ремонт» с первым условным номером. Клиент подает заявку на ремонт. Приемщик предлагает клиенту оформить данную заявку документально, путем ручного заполнения документов. Оформленная заявка остается у приемщика, копия заявки отдают клиенту, а оборудование отдают на ремонт специалисту. По завершении ремонта клиента оповещают, а его оборудование отдают уже отремонтированное со склада, после оплаты ремонта (в случае ремонта не по гарантии) (Рис. 5).

Рисунок 5. - Бизнес-процесс «Заявка на ремонт»

Бизнес-процесс с условным номером два - «Заказ детали». Мастеру после диагностики (в случае неисправности детали) нужна деталь, в этом случае он делает запрос на нужную деталь. Запрос поступает на склад, где уже определяют заказывать деталь или же она уже есть на складе. Если детали на складе нет, оформляют заказ на необходимую деталь, поставщик принимает заказ, и отправляет деталь. Когда деталь поступает на склад, её передают мастеру (Рис.6).

Рисунок 6. - Бизнес-процесс «Заказ детали»

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

Рисунок 7. - Бизнес-процесс «Ремонт»

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

Оценки бизнес-процессов (Таблица 1).

Бизнес-процессы

Скорость обработки информации

Удобство обслуживания

Потери и ошибки

Средний балл

Заказ детали

3

3

5

3,6

Ремонт

3

2

5

3,3

Заявка на ремонт

2

3

3

2,6

1.6 Сценарий проблемного бизнес-процесса организации работы по обслуживанию заявки клиента

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

Рисунок 8. - Сценарий работы сервисного центра ООО «Мика-Сервис»

Опишем сценарий.

Клиент

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

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

Менеджер приемки

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

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

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

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

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

Если техника не подлежит ремонту, то производится ее возврат клиенту с соответствующей отметкой в программе.

Сервис-инженер

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

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

Менеджер склада

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

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

Как только поступает ЗИП от поставщиков, менеджер склада выдает ее сервис-инженеру для использования

Офис-менеджер

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

1.7 Выявление причины появления проблем во время обслуживания заявки клиента в ООО «Мика-Сервис»

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

Рисунок 9. - Сценарий проблемного бизнес-процесса

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

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

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

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

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

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

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

Эта система заменит в большинстве случаев менеджера приемки при общении с клиентами по телефону. Полученный эффект от использования информационной online-системы будет связан с сокращением потерь рабочего времени менеджером приемки на 20-25%.

1.8 Содержательная постановка задачи

Задача моей работы - это улучшение процессов взаимодействия с клиентами ООО «Мика-Сервис» по вопросам процесса обслуживания и ремонта сданной ими техники. В частности, оптимизация будет направлена на сокращение потерь рабочего времени менеджером приемки на 20-25%.

2. Системное исследование ООО «Мика-Сервис»

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

2.1 Математическая модель и ее оптимизация

Выполним математическое моделирование процессов работы ООО «Мика-Сервис», в частности процесса работы менеджера приемки, в котором он взаимодействует с клиентами.

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

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

В таких СМО каждой заявке назначается некоторый приоритет. Если в очереди находятся заявки с разными приоритетами, то первыми на обслуживание поступают заявки с более высоким приоритетом.

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

Приоритеты заявок могут быть относительными или абсолютными.

В СМО с относительными приоритетами заявка, поступившая на обслуживание (т.е. в канал), всегда обслуживается до конца, даже если в это время поступает заявка с более высоким приоритетом.

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

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

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

Подготовленные результаты наблюдений за работой ООО «Мика-Сервис»: online доступ заявка обслуживание

1. Количество людей, обращающихся в день лично: 61

2. Количество звонков от клиентов: 41 в день

3. Среднее время, затраченное менеджером приемки на ответ на телефонный звонок: 3 минуты т.е. часа.

4. Среднее время, затраченное менеджером приемки на работу с посетителями: 5 минут, т.е. часа

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

Интенсивность поступления заявок с 0 приоритетом (звонков)

Интенсивность поступления заявок с 1 приоритетом (личных обращений)

Интенсивность обслуживания звонков

Интенсивность обслуживания личных обращений

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

Нагрузка на менеджера, создаваемая личными обращениями

Общая нагрузка на менеджера приемки:

Среднее время пребывания в очереди телефонного звонка:

Среднее время пребывания в очереди посетителя ООО «Мика-Сервис»:

Среднее время пребывания телефонного звонка в СМО (включая обслуживание и ожидание в очереди)

Среднее время пребывания посетителя ООО «Мика-Сервис» в СМО (включая обслуживание и ожидание в очереди)

Среднее число заявок в СМО

Среднее число заявок на обслуживании

Среднее число заявок в очереди

Пропускная способность СМО

Вероятность простоя СМО

Коэффициент загрузки СМО

Коэффициент загрузки СМО превышает допустимые 0,85 пунктов, что говорит о перегрузке СМО, то есть о повышенной нагрузке в работе менеджера приемки.

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

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

То есть в среднем менеджер приемки будет иметь дело с 21 (41*0,5=20,5) телефонным звонком в сутки.

Покажем изменения в показателях СМО:

1. Количество людей, обращающихся в день лично: 61

2. Количество звонков от клиентов: 21 в день

3. Среднее время, затраченное менеджером приемки на ответ на телефонный звонок: 3 минуты т.е. часа.

4. Среднее время, затраченное менеджером приемки на работу с посетителями: 5 минут, т.е. часа

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

Интенсивность поступления заявок с 0 приоритетом (звонков)

Интенсивность поступления заявок с 1 приоритетом (личных обращений)

Интенсивность обслуживания звонков

Интенсивность обслуживания личных обращений

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

Нагрузка на менеджера, создаваемая личными обращениями

Общая нагрузка на менеджера приемки:

Среднее время пребывания в очереди телефонного звонка:

Среднее время пребывания в очереди посетителя ООО «Мика-Сервис»:

Среднее время пребывания заявки в очереди:

Среднее время пребывания телефонного звонка в СМО (включая обслуживание и ожидание в очереди)

Среднее время пребывания посетителя ООО «Мика-Сервис» в СМО (включая обслуживание и ожидание в очереди)

Среднее число заявок в СМО

Среднее число заявок на обслуживании

Среднее число заявок в очереди

Пропускная способность СМО

Вероятность простоя СМО

Коэффициент загрузки СМО

Коэффициент загрузки СМО после оптимизации лежит в допустимых пределах 0,75<0,767<0,85, что говорит о нормальном режиме работы менеджера приемки, без простоев и перегрузок.

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

Таблица 1 - Результаты математического моделирования

Обозн.

Название

Значение до оптимизации

Значение после оптимизации

л0

Интенсивность потока заявок с высшим приоритетом (звонков)

5,125 в час

2,625 в час

л1

Интенсивность потока заявок с низшим приоритетом (посетителей)

7, 625 в час

7, 625 в час

x0

Время обслуживания одной заявки с высшим приоритетом (телефонного звонка)

0,05 часа

0,05 часа

x1

Время обслуживания одной заявки с низшим приоритетом (посетителя)

0,084 часа

0,084 часа

м0

Интенсивность обслуживания звонков

20 в час

20 в час

м1

Интенсивность обслуживания личных обращений

12 в час

12 в час

с0

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

0,25625

0,13125

с1

Нагрузка на менеджера, создаваемая личными обращениями

0,63542

0,63542

с

Общая нагрузка на менеджера приемки

0,892

0,767

щ0

Среднее время пребывания в очереди телефонного звонка

0,017 часа

0,00755 часа

щ1

Среднее время пребывания в очереди посетителя ООО «Мика-Сервис»

0,85 часа

0,308 часа

t0

Среднее время пребывания телефонного звонка в СМО (включая обслуживание и ожидание в очереди)

0,067 часа

0,058 часа

t1

Среднее время пребывания посетителя ООО «Мика-Сервис» в СМО (включая обслуживание и ожидание в очереди)

0,934 часа

0,392 часа

k

Среднее число заявок в СМО

7,469

3,143

q

Среднее число заявок в очереди

6,578

2,376

г

Пропускная способность СМО

12,75 заявок в час

10,75 заявок в час

P0

Вероятность простоя СМО

0,108

0,233

U

Коэффициент загрузки СМО

0,892

0,767

Важно,что сократилось время ожидания посетителей в очереди с 0,85 часа до 0,308 часа. То есть в очереди клиенты теперь будут находиться не 50 минут, а всего 18. Также в очереди будет находиться вместо 7-8 человек всего 2-3, что также является плюсом.

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

2.2 Оптимизированный сценарий уведомления клиента о состоянии работ по его заявке

Обеспечить улучшение можно за счет изменения механизма взаимодействия с клиентами (рисунок 10).

Рисунок 10. - Сценарий улучшения процесса работы с клиентами

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

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

1. Возможность удаленной выдачи данных по запросу

2. Возможность идентификации пользователей

3. Присутствие механизмов взаимодействия с другими автоматизированными информационными системами

4. Возможность учета выполненных действий

5. Возможность получения претензий и пожеланий клиентов

6. Составление отчетов

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

В настоящее время на российском рынке представлено достаточно большое количество CASE-систем, многие из которых позволяют, так или иначе, создавать описания (модели) бизнес-процессов предприятий. Очевидно, что выбор системы в значительной мере определяет весь дальнейший ход проекта. Рациональный выбор системы возможен при понимании руководством компании, и ее специалистами нескольких аспектов [4]:

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

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

3. возможностей CASE-систем по описанию процессов с учетом требований п.2.

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

Нотация ARIS eEPC [5] расшифровывается следующим образом - Extended Event Driven Process Chain - расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером.

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

1. каждая функция должна быть инициирована событием и должна завершаться событием;

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

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

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

Нотация IDEF0 [6] была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий. Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур. Семантика построения моделей IDEF0 и IDEF3 предполагает соблюдение четких правил. Детальную информацию о построении моделей в IDEF0,3 можно узнать в стандартах и книгах (см. литературу).

В нотации IDEF3, так же как и в нотации ARIS eEPC, используются символы логики, отражающие ветвление процесса.

Сравнительный анализ нотаций ARIS и IDEF приводится в следующей таблице.

Таблица 2 - Сравнительный анализ ARIS и IDEF

Критерии сравнения

ARIS

IDEF0

IDEF3

1

Принцип построения диаграммы / логика процесса

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

Принцип доминирования

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

2

Описание процедуры процесса

Объект на диаграмме

Объект на диаграмме

Объект на диаграмме

3

Входящий /исходящий документ

Используется отдельный объект для описания («документ»)

Стрелка слева, стрелка сверху

Нет (может быть отражен в модели только привязкой объекта-комментария)

4

Входящая /исходящая информация

Используется отдельный объект для описания («кластер», «технический термин»)

Стрелка слева, стрелка сверху

Нет (может быть отражен в модели только привязкой объекта-комментария)

5

Исполнитель процедуры

Используется отдельный объект для описания («позиция», «организационная единица»)

Стрелка снизу

Нет (может быть отражен в модели только привязкой объекта-комментария)

6

Используемое оборудование

Используется отдельный объект для описания

Стрелка снизу

Нет (может быть отражен в модели только привязкой объекта-комментария)

7

Управление процедурой

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

Стрелка сверху

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

8

Контроль выполнения процедуры

Нет. Может быть отражен указанием входящих документов

Стрелка сверху

Нет.

9

Обратная связь по управлению/контролю

Нет. Может быть отражена только символами логики (последовательность выполнения процедур)

Стрелка сверху

Нет.

Функциональные возможности инструментальных средств моделирования ARIS Toolset и BPwin можно корректно сравнивать только по отношению к определенному кругу задач. В моей работа рассматривается задача формирования моделей (описания) бизнес-процессов ООО «Мика-Сервис». Каждая из рассматриваемых систем имеет свои преимуществ и недостатки. Сравнение функциональных возможностей систем приводится в следующей таблице.

Таблица 3 - Сравнение функциональных возможностей CASE-средств

Возможности/Инструментальная среда

ARIS Toolset 5.0

BPwin 4.0

1

Поддерживаемый стандарт

- (частично - DFD, ERM, UML)

IDEF0, IDEF3, DFD

2

Система хранения данных модели

Объектная база данных

Модели хранятся в файлах

3

Ограничение на размер базы данных

Нет. (ограничивается вычислительными ресурсами)

Нет. (ограничивается вычислительными ресурсами)

4

Возможность групповой работы

Есть. Используется ARIS Server.

Есть. Используется ModelMart.

5

Ограничение на количество объектов

Нет.

От 2 до 8.

6

Возможность декомпозиции

Неограниченная декомпозиция.

Неограниченная декомпозиция.

7

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

Не регламентируется

Стандартный бланк IDEF

8

Удобство работы по созданию моделей

Сложная панель управления, есть выравнивание объектов, есть undo.

Простая панель управления, нет выравнивания объектов, нет undo.

9

UDP - свойства объектов, определяемые пользователем

Большое, но ограниченное количество свойств, количество типов ограничено.

Количество UDP не ограничено. Количество типов ограничено.

10

Возможность анализа стоимости процессов

Есть. Возможность использовать ARIS ABC.

Упрощенный анализ стоимости по частоте использования в процессе. Возможность экспорта в Easy ABC.

11

Генерация отчетов

Создание отчетов на основе стандартных и настраиваемых пользователем макросов Visual Basic.

RPT Win, возможность визуальной настройки отчетов, включая расчет по формулам с использованием UDP

12

Сложность разработки нестандартных отчетов

Сложно

Просто

Сравнивая две системы, следует сразу отметить, что для хранения моделей в ARIS используется объектная СУБД, и под каждый проект создается новая база данных. Для удобства пользователя модели (объекты моделей) могут храниться в различных группах, организованных в зависимости от специфики проекта. В ARIS-е предусмотрены различные функции по администрированию базы данных: управление доступом, консолидация и т.п. В BPwin данные модели хранятся в файле, что существенно упрощает работу по созданию модели, но с другой стороны ограничивает возможности по анализу объектов модели. В ModelMart так же предусмотрено администрирование базы данных.

BPwin отличается простотой в использовании, и достаточной строгой регламентацией при создании диаграмм (стандарт IDEF и рекомендации по его применению, бланк IDEF для создания диаграммы, ограниченное количество обязательно заполняемых полей, ограничение количества объектов на одной диаграмме и т.д.). ARIS, безусловно, является более «тяжелым» инструментом, по сравнению с BPwin, но это в итоге оборачивается значительными трудностями и высокими затратами на его эксплуатацию.

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

Таблица 4 - Экспертная оценка ARIS и BPWin

Задача/Инструментальная среда

ARIS Toolset 5.0

BPwin 4.0

Разовый проект по описанию бизнес-процессов, например:

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

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

 

3

3

 

5

5

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

5

3

Разработка системы автоматизации:

1. описание функциональных возможностей системы;

2. создание логической модели данных;

3. создание физической модели данных.

 

3

3

-

 

5

BPwin + ERwin + Paradigm Plus

Позиционирование систем можно провести по отношению к решению задачи моделирования бизнес-процессов (см. рисунок 11).

Рисунок 11. - Позиционирование CASE-средств

Таким образом, для ведения небольших по масштабам (малые и средние предприятия, 2-5 человека в группе консультантов) и длительности (2-3 месяца) проектов рационально использовать BPwin. Для крупных и/или длительных проектов (например, внедрение системы непрерывного улучшения бизнес-процессов, ISO, TQM) больше подходит ARIS. В этом случае подготовительные работы по созданию регламентирующей документации могут занять 1-3 месяца, но это является необходимым элементом последующей успешной работы [4].

2.4 Модели бизнес-процессов ООО «Мика-Сервис»

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

Рисунок 12. - График загрузки менеджера приемки

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

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

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

Рисунок 13. - Контекстная диаграмма

Бизнес-процессы ООО «Мика-Сервис» производятся на основе получения необходимой информации, источники ее получения и характер информации могут быть различны, так что в общем случае напишем «Обращения клиентов». Клиенты приносят свою неисправную технику, гарантийный талон (если таковой имеется), если хотят пройти сервисное обслуживание или ремонт. Клиенты приносят квитанции о приемке товара на ремонт, когда хотят забрать технику обратно. Поэтому в контекстной диаграмме А-0 Модель бизнес-процессов ООО «Мика-Сервис» стрелками входа являются

· Обращения клиентов

· Неисправная техника

· Квитанции о приемке техники

· Гарантийные талоны

Механизмы - ресурсы, которые выполняют работу. В данном случае стрелкой механизма являются «Сотрудники ООО «Мика-Сервис»».

На выходе имеем разнородные потоки:

· Гарантийные талоны (с отметками о ремонте)

· Ответы на обращения

· Квитанции о приемке техники

· Чеки/счета на оплату услуг ООО «Мика-Сервис»

· Отремонтированная техника

· Неисправная техника (если клиент отказался от ремонта или ремонт невозможен)

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

Приступим к декомпозиции нулевого уровня.

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

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

Прием клиента.

Процесс от момента входа клиента в двери ООО «Мика-Сервис» (звонка по телефону) до полного уточнения цели его визита (звонка).

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

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

Прием техники на ремонт.

Менеджер приемки диагностирует (предварительно) причину поломки, выдает необходимые бумаги о том, что ООО «Мика-Сервис» принял на ремонт такую-то технику.

Выдача техники клиенту.

По окончанию ремонтных (сервисных) работ или по требованию клиента, ему выдается сданная техника. Урегулируются финансовые вопросы, выдаются необходимые документы.

Анализ работы ООО «Мика-Сервис».

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

Продолжим декомпозицию с процесса «Выяснение состояния дел по сданной технике».

Покажем изменения, произошедшие внутри процесса выдачи информации.

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

Видно, что структура процесса серьезно переработана и в ней теперь не участвуют сотрудники ООО «Мика-Сервис», то есть экономится время менеджера приемки.

Система на основе заложенной логики работы определяет какие действия надо совершить с поступившем запросом.

· Если это отчет, то запускается функция записи информации.

· Если это запрос отчета, то запускается их формирователь.

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

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

Степень снижения количества звонков будет зависеть от популярности интернета у клиентов и от подробности выдаваемой клиенту информации. Но уже сейчас можно утверждать, что более 80% клиентов ООО «Мика-Сервис» являются активными пользователями сети интернет, а следовательно такая оптимизация будет успешной.

Уточнение марки и модели техники.

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

Поиск в базе программного обеспечения.

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

Запрос информации у сервис-инженеров.

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

Формулировка ответа.

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

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

Продолжим декомпозицию процесса. Возьмем процесс «Прием техники на ремонт».

Рисунок 16 - Диаграмма бизнес-процесса Прием техники на ремонт»

Декомпозиция процесса привела к следующим результатам (в виде бизнес-процессов).

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

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

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

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

Подготовка и выдача документов.

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

Передача на ремонт сервис-инженеру.

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

Проблем в этом процессе, на мой взгляд, нет. Оптимизации не требуется

Продолжим декомпозицию процесса. Возьмем процесс «Выдача техники клиенту».

Рисунок 17 - Диаграмма бизнес-процесса «Выдача техники клиенту»

Декомпозиция процесса привела к следующим результатам (в виде бизнес-процессов).

Проверка документов.

Менеджер приемки проверяет личность пришедшего и право его на получение техники (есть ли в наличии квитанция о приемке, талон и т.д.).

Поиск техники на складе.

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

Фиксация факта выдачи.

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

Учет.

Менеджер приемки делает в журнале соответствующую пометку о сдаче техники клиенту, сроках ее пребывания в ООО «Мика-Сервис».

Проблем в этом процессе, на мой взгляд, нет. Оптимизации не требуется.

2.5 Формирование требований к информационной системе Online-доступа к сведениям о состоянии обслуживания и ремонта компьютерной и оргтехники в ООО «Мика-Сервис»

По факту оптимизации можно назвать требования к информационной системе Online-доступа к сведениям о состоянии обслуживания и ремонта компьютерной и оргтехники в ООО «Мика-Сервис». Все они сводятся к наличию соответствующих систем

1. Система хранения и выдачи данных по запросу

2. Система идентификации пользователей

3. Система взаимодействия с другими автоматизированными информационными системами

4. Система учета выполненных действий

5. Система учета претензий и пожеланий клиентов

6. Система составления отчетов

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

3. Проектирование информационной системы Online-доступа к сведениям о состоянии обслуживания и ремонта компьютерной и оргтехники в ООО «Мика-Сервис»

3.1 Обзор информационных систем автоматизации сервис-центров

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

...

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

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.