CC BY
140
РАЗДЕЛ 2. ЭКОНОМИКА И ПРЕДПРИНИМАТЕЛЬСТВО
С. А. Глушенко, А. И. Долженко, Д. В. Малеев
РАЗРАБОТКА СИСТЕМЫ HELPDESK ДЛЯ ОТДЕЛА СОПРОВОЖДЕНИЯ ООО «ЭЛЕКТРОННАЯ МЕДИЦИНА»1
Аннотация
В статье обосновывается целесообразность разработки системы Helpdesk (Service desk) для отдела сопровождения ООО «ЭЛЕКТРОННАЯ МЕДИЦИНА» Описывается процесс проектирования и использования системы, а также проводится анализ рисков на этапе разработки. Моделирование рисков осуществляется посредством системы поддержки принятия решений управления рисками ModelingFuzzySet.
Ключевые слова
Helpdesk, service desk, риск, нечеткая продукционная модель, система поддержки принятия решений.
S. A. Glushenko, A. I. Doljenko, D. V. Maleev
DEVELOPMENT SYSTEM HELPDESK FOR MAINTENANCE DEPARTMENT
OF «ELECTRONIC MEDICINE»
Annotation
The article explains the development system helpdesk for maintenance department of «ELECTRONIC MEDICINE». It describes the process of design and application of the system, as well as risk analysis in the encoding step. Risk simulation is performed by the decision support system of risk management ModelingFuzzySet.
Keywords
Helpdesk, service desk, risk, fuzzy production model, decision support system.
ООО «Электронная медицина» специализируется на создании и внедрении информационных систем в медицинские учреждения . Отдел сопровождения компании занимается обработкой
заявок клиентов, обновлением эксплуатируемого программного обеспечения и установкой медицинских информационных систем (МИС) новым клиентам.
Процесс работы отдела представлен на рисунке 1.
1 Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта № 16-31-00285 мол_а «Методы и модели нечеткой логики в системах принятия решений управления рисками»
Рисунок 1 — Схема работы отдела сопровождения
При поступлении заявки от клиента диспетчером формируется задача (инцидент), которая фиксируется в регистрационном журнале, классифицируется, определяется её приоритет и назначается на конкретного исполнителя работ. Основная задача сотрудника отдела - скорейшее восстановление сервиса путем взаимодействия с клиентом, помогая ему в решении возникшей проблемы. После того как инцидент разрешен, исполнитель закрывает его. Под закрытием инцидента понимается пометка о завершении работ, в том случае если клиент подтвердил восстановление сервиса.
Со временем количество клиентов фирмы стало увеличиваться, что привело к возрастанию количества обращений и сотрудников в отделе. Это послужило причиной тому, что диспетчеры перестали корректно оценивать занятость ис-
полнителей и проводить оценку необходимого времени на закрытие инцидента. Указанные обстоятельства побудили автоматизировать работу отдела путем внедрения системы Helpdesk или Service desk (от англ. help desk, справочный стол) — информационная система технической поддержки, которая позволит фиксировать все обращения клиентов, связанные с аппаратным и программным обеспечением, хранить их в единой базе данных и осуществлять контроль занятости сотрудников отдела [6].
Постановка задачи для системы Helpdesk
Исходя из потребностей сотрудников и плана развития отдела к системе были сформированы следующие требования:
1. Создание, просмотр и редактирование обращений. Диспетчер должен
иметь возможность создавать, просматривать и редактировать обращения.
2. Создание, просмотр и редактирование задач по обновлению МИС. Диспетчер должен иметь возможность создавать задачи, связанные с обновлением программного обеспечения в медицинской организации с указанием версии и количества модулей, входящих в это обновление.
3. Назначение сотрудников ответственными за модули МИС в медицинской организации. Начальник отдела должен иметь возможность назначить исполнителя ответственным за определённые модули в конкретных медицинских организациях.
4. Контроль занятости сотрудников отдела сопровождения. Начальник отдела и ответственный за распределение заявок сотрудник должны иметь возможность контролировать количество активных задач и текущую занятость сотрудника.
5. Отображение входящего звонка сотруднику с одновременным созданием задания для работника отдела. При поступлении повторного звонка сотруднику отдела система должна определить клиента, создать задание и назначить работника в качестве исполнителя.
6. Формирование базы знаний по выполненным задачам для более быстрого решения однотипных проблем.
7. Формирование отчетности. Начальник отдела должен иметь возможность создавать отчеты по различным категориям.
На данный момент имеется множество готовых решений для отдела сопровождения. Сотрудниками отдела был проведен анализ рынка систем
HelpDesk и на основе требований сформирован следующий перечень:
1. KayakoResolve [7].
2. CerberusHelpDesk [8].
3. osTicket [9].
Первая система имеет наибольшую функциональность по сравнению с остальными, а также базу знаний, веб портал для клиентов, API для интеграции с другими сервисами. Вторая система больше нацелена на обеспечение эффективного сотрудничества между коллегами и на создание персонально настраиваемого рабочего места сотрудника. Однако обе системы имеют большую стоимость и недостаточно гибкую систему лицензий.
Третья система бесплатная с открытым исходным кодом, имеет хорошо реализованный базовый функционал, а также позволяет настраивать API для взаимодействия со сторонними сервисами. Недостатком osTicket является отсутствие возможностей распределения и приоритизации задач и массового создания задач по критериям, что не согласуется с выдвинутыми ранее требованиями к системе Helpdesk.
Также стоит отметить, что у всех трех систем отсутствует русскоязычный интерфейс и документация.
Таким образом, руководством компании было принято решение о собственной разработке системы, которая будет удовлетворять требованиям отдела сопровождения.
На этапе проектирования была построена диаграмма вариантов использования (Use Cases), охватывающая функциональные требования системы. Диаграмма вариантов использования представлена на рисунке 2.
Рисунок 2 — Диаграмма UseCase
На рисунке 3 изображена диаграмма деятельности, на которой показан процесс управления инцидентами в системе Helpdesk. Первый шаг этого цикла — обнаружение инцидента и его фиксация в системе. Зафиксировав заявку, диспетчер формирует задачу и классифицирует её, устанавливая важность и срочность. Затем задача передает исполнителю — сотруднику отдела для выполнения. После того как задача
выполнена, сотрудник вносит информацию об инциденте в базу данных, фиксируя время выполнения и дополняя его необходимой информацией, и закрывает задачу, сообщая клиенту об исполнении. В дальнейшем начальник отдела получает сводную информацию о работе сотрудников, контролируя незавершённые задачи и занятость сотрудников, а также производит анализ статистики инцидентов.
Рисунок 3 — Диаграмма деятельности
Разработка качественной системы Helpdesk во многом зависит от архитектурных решений, принятых в процессе
её проектирования [10]. На рисунке 4 приведена общая схема архитектуры системы.
Рисунок 4 — Схема архитектуры приложения
Сервис обработки вызовов отвечает за передачу информации о вызове от телефонной станции к сервису обработки данных. Сервис обработки данных осуществляет работу с базой данных, обеспечивает взаимодействие между сотрудниками и систематизирует полученную информацию о вызовах, поступивших от клиентов. Клиентская часть приложения формирует перечень текущих задач и оперативно распределяет их между сотрудниками отдела, которые в свою очередь получают информацию о созданных задачах в форме оповещений, а также указывают текущую занятость.
Оценка рисков проекта
В процессе реализации данного программного проекта командой был
Полученная информация была использована в качестве входных данных для нечеткой продукционной модели анализа рисков (рис. 5), Модель построена в дизайнере системы поддержки
выполнен анализ рисков, использована методология анализа рисков А. И. Дол-женко [3]. Методология предполагает использование методов и моделей нечеткой логики, которые позволяют реализовать комплексный учет как качественных, так и количественных факторов риска [4]. На этапе разработки актуальными являются такие риски, как: «Компетентность разработчика», «Архитектурный» и «Технический», низкий уровень которых определяют стабильность проекта на данном этапе. Экспертами предметной области были определены уровни факторов риска, оказывающих влияние на указанные риски (табл. 1).
принятия решений (СППР) нечеткого моделирования ModelingFuzzySet [5]. Методика применения СППР для моделирования проектных рисков изложена
в [1, 2].
Таблица 1 — Идентифицированные факторы риска проекта
Обозначение Наименование фактора риска Значение и описание уровня фактора риска Степень уверенности
ЛП01 Уровень зрелости разработчика Высокий — управляемый, когда в компании принимаются количественные показатели качества как программных продуктов, так и процесса 0,8ц
ЛП02 Квалификация команды разработчиков Высокий — полностью соответствует требованиям проекта 0,9ц
ЛП03 Состав команды разработчиков Высокий — команда разработчиков полностью укомплектована и мобильна 0,7ц
ЛП04 Документация по проекту Средний — документация имеется, но недостаточно детальная, и плохо отражаются изменения документации для различных фаз проекта 1,0ц
ЛП05 Фаза проекта Средний — построение 0,9ц
ЛП06 Полнота требований к проекту Высокий — полные и детальные 0,8ц
ЛП07 Аппаратная поддержка Высокий — полностью соответствует задачам проекта, имеет потенциал развития 0,8ц
ЛП08 Программное обеспечение Средний — имеется небольшой опыт разработки проектов с использованием конкретного программного обеспечения 0,9ц
ЛП09 СУБД Средний — обеспечивает реализацию задач и модели данных системы, но имеет ограниченный потенциал развития 0,7ц
Рисунок 5 — Нечеткая продукционная модель анализа рисков проекта
Результаты нечеткого моделирования выходных лингвистических пе-
ременных (показателей риска) приведены в таблице 2.
Таблица 2 — Результаты моделирования показателей риска проекта
Обозначение Наименование показателей риска Ранг Значение терма Значение показателя риска Степень уверенности
ЛП10 Компетентность разработчика 4 СОР 50 0,79ц
ЛП11 Архитектурный 3 СОР 50 0,7ц
ЛП12 Технический 3 НОР 19,5 0,8ц
ЛП13 Интегральный риск проекта 5 НОР 19,5 0,7ц
Полученные значения проектных рисков использовались СППР для формирования следующих решений:
• провести детальное документирование и независимое рецензирование программного кода;
• повысить степень покрытия модульными тестами функциональность системы.
Принятые меры были внесены в план управления проектом, что позволило минимизировать уровень риска проекта и продолжить его реализацию на данной стадии в нормальном режиме.
Применение разработанной системы
Обращения клиентов в отдел сопровождения поступают практически
всегда в телефонном режиме, поэтому было принято решение реализовать возможность создания задач при приеме вызова. Диспетчер формирует сведения о клиенте, которые в дальнейшем будут использованы системой для определения звонящего. Список задач автомати-
чески пополняется, им назначаются приоритеты и ответственные исполнители. Разработанная система позволяет отслеживать занятость каждого сотрудника и количество незавершенных задач как конкретного сотрудника, так и всего отдела в целом (рис. 6).
Рисунок 6 — Список задач, назначенный на сотрудника
Реализована возможность учета времени, затраченного на исполнение задачи. Сотрудник отдела формирует очередность выполнения работ и указы-
вает, какую задачу будет выполнять в данный момент. В момент закрытия активной задачи система рассчитывает и фиксирует время её выполнения (рис. 7).
Рисунок 7 — Очередь выполнения задач
Реализована возможность массового создания задач после выхода обновления для МИС. Диспетчер указывает вид обновления и количество включенных в него модулей, по данным параметрам система автоматически формирует список клиентов, создает задачи и назначает в качестве исполнителей закрепленных за ними сотрудников.
Таким образом, разработанное и внедренное приложение значительно улучшило качество работы сотрудников отдела сопровождения, а именно: начальник отдела в реальном времени может отслеживать занятость каждого сотрудника и вести более точный учет затрат времени выполнения и количества завершенных задач, сотрудники
отдела своевременно получать задачи, не осуществляя дополнительных рутинных действий, а диспетчер может эффективно распределять задачи между исполнителями.
Система обладает гибкой настройкой, простотой использования, а открытый код системы позволяет вносить необходимые изменения и осуществлять постоянное её обновление.
Библиографический список
1. Глушенко, С. А., Долженко, А. И. Система поддержки принятия решений нечеткого моделирования рисков информационной безопасности организации // Информационные технологии. — 2015. — № 1. — С. 68-74.
2. Глушенко, С. А., Долженко, А. И. Система нечеткого моделирования рисков инвестиционно-строительных проектов // Бизнес-информатика. — 2015. — № 2 (32). — С. 48-58.
3. Долженко, А. И. Методология анализа рисков при проектировании информационных систем с использованием нечетких сетей // Вестник Ростовского государственного экономического университета «РИНХ». — 2007. — № 2. — Т. 24. — С. 148-155.
4. Долженко, А. И. Модель анализа риска потребительского качества проектов экономических информационных систем // Вестник СевероКавказского государственного технического университета. — 2009. — № 1. — Т. 18. — С. 129-134.
5. Долженко, А. И. , Глушенко, С. А., Чередниченко, А. С., Калугян, К. Х., Лозина, Е. Н. Система моделирования продукционной нечеткой сети (ПРОНЕС) // Свидетельство «О государственной регистрации программы для ЭВМ» № 2010614659 по заявке № 2010612952 от 25.05.2010. — М. : РОСПАТЕНТ, 2010.
6. Долженко, А. И. Управление информационными системами : учеб.
пособие / Рост. гос. эконом. ун-т «РИНХ». — Ростов н/Д, 2009. — 208 с.
7. Официальный сайт системы Kayako Resolve [Электронный ресурс]. — Режим доступа: http://www.kayako.com/ product/tour (дата обращения: 07.04.2016).
8. Официальный сайт системы Cerberus HelpDesk [Электронный ресурс]. — Режим доступа: http://www.cerberusweb.com (дата обращения: 07.04.2016).
9. Официальный сайт системы osTicket [Электронный ресурс]. — Режим доступа: http://osticket.com (дата обращения: 07.04.2016).
10. Уокер, Р. Управление проектами по созданию программного обеспечения. Унифицированный подход. — М. : Лори, 2002. — 424 с.
Bibliographic list
1. Glushenko, S. A., Dolzhenko, A. I. Sistem of support of adoption of solutions of indistinct modeling of risks of information security of organization // Information technologies. — 2015. — № 1. — P. 68-74.
2. Glushenko, S. A., Dolzhenko, A. I. Sistem of indistinct modeling of risks of investment and construction projects // Business informatics. — 2015. — № 2 (32). — P. 48-58.
3. Dolzhenko, A. I. Metodology of risk analysis when designing information systems with use of indistinct networks // Vestnik of Rostov state economic university «RINH». — 2007. — № 2. — T. 24. — P.148-155.
4. Dolzhenko, A. I. Model of risk analysis of consumer quality of projects of economic information systems // Bulletin of North Caucasian state technical university. — 2009. — № 1. — T. 18. — P. 129-134.
5. Dolzhenko, A. I., Glushenko, S. A., Cherednichenko, A. S., Kalugyan, K. H., Lozina, E. N. System of modeling of pro-ductional indistinct network (CARRIED
BY) // Certificate «About State Registration of Computer Program» № 2010614659 according to the request № 2010612952 of 25.05.2010. — M. : ROSPATENT, 2010.
6. Dolzhenko, A. I. Management of information systems : textbook / Rostov state university of economics «RINH». — Rostov-on-Don, 2009. — 208 p.
7. Official site of the Kayako Resolve system [Electronic resource]. — Mode of access: http://www.kayako.com/ product/tour (date of access: 07.04.2016).
8. Official site of Cerberus Help Desk system [Electronic resource]. — Mode of access: http://www.cerberus web.com (date of access: 07.04.2016).
9. Official site of the osTicket system [Electronic resource]. — Mode of access: http://osticket.com (date of access: 07.04.2016).
10. Walker, R. Management of projects on creation of program providing. Unified approach. — M. : Lory, 2002. — 424 p.
А. В. Зубков, М. В. Тиссен
ОРГАНИЗАЦИЯ И ЭКОНОМИЧЕСКАЯ ЭФФЕКТИВНОСТЬ ХРАНЕНИЯ
ФРУКТОВ И ЯГОД В СЕЛЬСКОХОЗЯЙСТВЕННЫХ ОРГАНИЗАЦИЯХ
РОССИИ
Аннотация
Проанализировано текущее состояние хранения фруктов и ягод в специализированных садоводческих организациях России. Выявлено, что большинство товаропроизводителей имеют холодильные камеры, которые морально и физически изношены и лишь немногие организации располагают современными холодильными установками с регулируемой атмосферой (РА), в том числе с ультранизким содержанием кислорода (ULO). Учитывая опыт сельскохозяйственных организаций, определены организационные и экономические условия, обеспечивающие повышение экономической эффективности хранения фруктов и ягод. Показаны факторы, сдерживающие внедрение хранилищ с РА, среди которых наибольшее значение имеет их высокая стоимость. Возможности использования данных хранилищ имеются преимущественно у крупных сельскохозяйственных товаропроизводителей. Установлено, что успешное функционирование рынка продукции садоводства в России во многом определяется дальнейшим совершенствованием технологий хранения фруктов и ягод.
Ключевые слова
Рынок, продовольственная безопасность, хранение, хранилища с регулируемой атмосферой, организация хранения, экономическая эффективность.
A. V. Zubkov, M. V. Tissen
ORGANIZATION AND ECONOMIC EFFICIENCY STORAGE OF FRUITS AND BERRIES IN RUSSIAN AGRICULTURAL ORGANIZATIONS
Annotation
To analyze the current state of the storage of fruits and berries in specialized horticultural organization in Russia. It was found that most producers have refrigerators that are mentally and physically worn out and only a few organizations have modern refrigeration units with controlled atmosphere (RA), including ultra-low oxygen (ULO). Given the experience of
