36
Пользователи
Справочники
Документы
Отчеты
Администратор
Полный доступ
Полный доступ
Полный доступ
Руководящий персонал
Чтение
Добавление
Редактирование
Формирование
Предварительный
просмотр
Печать
Формирование
Предварительный
просмотр
Печать
Пользователи
Просмотр
Печать
Просмотр
Печать
Просмотр
Печать
Эти меры обеспечат надежную защиту информации.
1.3. Анализ существующих разработок и выбор стратегии
автоматизации «КАК ДОЛЖНО БЫТЬ»
1.3.1. Анализ существующих разработок для автоматизации задачи
Осуществим комплексный анализ систем, которые пригодны для
использования на конкретно взятом предприятии.
OTRS
Open Ticket Request System — бесплатная helpdesk система, качественно
написанная на языке perl с поддержкой множества СУБД. OTRS
используют такие гиганты, как Яндекс, Mail.RU, REG.RU, Mikrotik, RU-
CENTER и многие другие.
Что в OTRS хорошего?
Систему возможно установить как на windows так и на linux системы
Возможность интеграции с LDAP
Возможность создавать отделы (очереди обращений)
Эскалация обращений
Личный кабинет для пользователей
Гибкая настройка прав пользователей
Простой шаблонизатор (особенно в 4 версии)
«Безграничный» поиск
Русская локализация (по факту доступно 34 языка)
Поддержка ITIL, так же есть ITSM версия
«Личный кабинет» для клиентов, где видна вся история обращений
37
Гибкая система отчетов и многое другое.
Существует очень удобная документация и русское сообщество
Рисунок 1.7. Интерфейс OTRS
GLPI
GLPI — это не совсем helpdesk система, это скорее система для работы с
заявками и инцидентами, система для инвентаризации компьютерного
оборудования и ПО. Сама система написана на PHP.
Что она умет:
учет компьютеров, периферийного оборудования, сетевых устройств,
обычных принтеров и связанных с ними компонентами через интерфейс OCS
инвентаризации или FusionInventory
назначение задач, планирование и т.д.
управление лицензиями
назначение оборудования по географическим регионам для пользователей
и групп
управление деловой и финансовой информацией
управление статусом работы оборудования.
управление заявками о помощи для всех видов оборудования
использование нескольких интерфейсов, позволяющих пользователю
отправить запрос в службу поддержки (web, e-mail)
управление документами, договорами, и связанных с ними товарно-
материальных ценностей
резервирование оборудования
создание часто задаваемых вопросов «FAQ» и «Базы знаний»
38
генератор отчетов: аппаратное обеспечение, сети, тех. поддержки и т.п.
GLPI имеет много плагинов для добавления дополнительных функций
Рисунок 1.8. Интерфейс GPLI
hd.rustem
Это HelpDesk веб-система, для организации учёта выполнения задач
(заявок) между структурными подразделениями и пользователями или
клиентами организации.
Написана система на PHP.
Перечислим то, что она умеет:
Многоуровневая система прав пользователей
JQuery-ориентированая структура интерфейса
Возможность регистрации в системе из «белого списка» e-mail адресов
Извещение о новых заявках по e-mail, sms, и другим системам
Пользовательские настройки
Поддержка языков: Украинский, Русский, Английский
Всплывающие сообщения о событиях с заявками (как в VK)
Центр знаний — раздел для файлов документации, инструкций и хелпов
со структурой прав
Блокнот — личный блокнот пользователя с возможностью делиться
ссылкой
39
Статистика заявок
«Умное» создание заявок по номеру, ФИО, логину клиента
Приоритеты заявок
Комментарии и чат в заявке
Полное логирование всех действий всеми пользователями заявки
Рисунок 1.9. Интерфейс hd.rustem
osTicket
Неплохая, бесплатная система организации технической поддержки
пользователей написанная на php. Данная система имеет еще и русскоязычное
сообщество (http://osticket.ru/), хотя есть предположение, что его немного
забросили.
Умеет она следующее:
Запросы могут быть созданы по email, через онлайн форму или по
телефону (создается персоналом). Гибкая конфигурация и отображение.
Автоматическая отправка сообщения когда открыта новая заявка или
получено сообщение. Настраиваемые почтовые шаблоны.
Готовые ответы для часто задаваемых вопросов.
Добавление внутренних сообщений к заявкам для персонала
Настройте темы обращения для веб заявок.
Гибкая система уведомлений
40
Гибкая система настройки доступов
Назначение заявок сотруднику или отделу.
Нет необходимости в регистрации пользователей (для входа используется
ID/email).
Сохраняются все запросы и ответы.
Масса языковых пакетов и плагинов
Настраиваемые дополнительные поля
Гибкая настройка маршрутизации входящих заявок
Система отчетов
Так же эта система имеет платную SAAS версию.
Рисунок 1.10. Интерфейс odTicket
Примером также может служить система «Идеальный вариант: Интернет
услуги», в которой могут быть реализованы существенно значимые
возможности:
осуществление проведения операций «Подключение», «Отключение»;
осуществление учета различных заявок при подключении клиентов;
осуществление перекрестного поиска между различными заявками и
описанием клиентов;
осуществление учета всех отложенных или совершенных сделок;
41
осуществление создания различных произвольных форм отчетов;
осуществление произвольных запросов по различным параметрам;
осуществление экспорта различных данных в форматы Excel, txt, csv и
xml
осуществление обмена различными данными между удалёнными
офисами посредством использования e-mail, ftp или дискету, диск;
осуществление предоставления потенциальному клиенту информации,
которая должна быть передана в «безопасном» виде (наличие возможности для
сокрытия коммерческой информации)
осуществление управления доступом пользователей к различным
режимам и определенным значимым функциям программы
осуществление просмотра данных на вэб-сайте в сети интернет
осуществление комплексной поддержки одновременной работы для
неограниченного числа пользователей
наличие достаточно мощной и быстрой для реализации базы данных;
наличие простого и удобного интерфейса
наличие подробной документации, которая должна быть встроенной в
программу
наличие доступной консультационно-справочной службы
Самой эффективной системой является система «Идеальный вариант:
Интернет услуги».
По своей структуре автоматизированная система «Идеальный вариант:
Интернет услуги» громоздкая и достаточно сложная в применении. Указанная
система имеет возможность получения от пользователя достаточно высокой
квалификации, при этом также требуются администрирование и достаточно
сложная настройка.
Существенно зиачимым является фактор наличия достаточно высокой
стоимости автоматизированной системы «Идеальный вариант: Интернет
услуги». При этом на фактор стоимости воздействие оказывает необходимость
осуществления найма со стороны квалифицированного специалиста при
максимальной поддержке и обслуживании СУБД.
42
Это может быть отражено на обучении пользователей, на невозможности
экстренной технической поддержки из-за наличия достаточно сильной
удаленности конкретного разработчика. Отсутствует необходимость в
практическом применении большого количества различных функций данной
системы.
Таким образом, можно считать нецелесообразным использование
рассмотренных систем для автоматизации деятельности ЗАО «МИЛТА ПКП
ГИТ» при осуществлении решения узко специализированных задач по созданию
комплексной автоматизированной информационной системы. Более быстрыми
темпами и максимально недорого возможно осуществить создание отдельного
приложения, которое решает данную задачу, представляя собой приложение,
которое простое в установке и последующем использовании. Данное
предложение легко приспосабливается к требованиям, которые необходимы к
определенной компании.
1.3.2. Выбор и обоснование стратегии автоматизации задачи
В настоящее время имеется четыре основных варианта стратегии
автоматизации:
- процесс кусочной (хаотичной) автоматизации;
- процесс автоматизации по определенным участкам;
- процесс автоматизации по определенным направлениям;
- процесс осуществления комплексной автоматизации.
Осуществление кусочной автоматизации представляет возможности
приобретения конкретно взятым предприятием без применения конкретного
стратегического плана ряда различных фрагментов информационной системы,
которые не могут быть способными оказать значимую пользу при развитии
предприятия в целом. Дальнейшее развитие всей информационной системы
предприятия может также быть связано с новыми, существенно значимыми
затратами.
Процесс осуществляемой автоматизации по отдельно взятым участкам
должен предусматривать комплексную автоматизацию отдельных
43
производственных участков, которые объединены по набору основных
выполняемых функций. Данный способ процесса автоматизации может быть
выбран при условиях, когда существуют участки, при которых применение
различных автоматизированных систем может дать значительный
экономический эффект, примером чего может явиться сокращение персонала.
Осуществление автоматизации по направлениям представляет собой
автоматизацию ряда отдельно взятых направлений деятельности конкретной
организации. В данном случае организация будет получать достаточно полную
автоматизацию работы, к которой можно отнести кадровую службу,
производство, бухгалтерию или логистику. Предлагаемый подход к
автоматизации основных процессов может быть вполне нормальным и в
дальнейшем осуществляемая интеграция уже автоматизированных направлений
в рамках данного предприятия не может быть связана с серьезными
препятствиями.
Использование хаотичной стратегии (кусочная стратегия) не может
подойти, учитывая тот факт, что происходит автоматизация целого отдела, но
при этом может быть использовано несколько элементов, которые составляют
АИС, к которым можно отнести веб сервер, субд, клиент серверное приложение,
также нет возможности для автоматизации части из них, эффекта в данном
случае от данного процесса будет ноль.
В данной ситуации использование полной стратегии автоматизации также
не может быть целесообразно, учитывая то, каким образом будет
автоматизировать одно из представленных направлений деятельности конкретно
взятого предприятия.
Выбрана стратегия автоматизации по участкам.
Осуществление стратегических изменений процесса автоматизации по
различным участкам лучше всего использовать в данном дипломном проекте,
учитывая то, что происходить процесс автоматизации деятельности отдела
информационных технологий. При осуществлении автоматизации указанного
процесса возможно сокращение численности указанного отдела без понижения
продуктивности его работы.
В разработке программного обеспечения, стадии разработки
44
программного обеспечения используются для описания степени готовности
программного продукта. Также стадия разработки может отражать количество
реализованных функций, запланированных для определённой версии
программы. Стадии либо могут быть официально объявлены и
регламентируются разработчиками, либо иногда этот термин используется
неофициально для описания состояния продукта. Следует отметить, что стадии
Beta и Alpha (Pre-Alpha) не являются показателями нестабильности релиза так
как присваиваются программе один раз или один раз за серию (серией, в данном
случае, считается число до первой точки), в зависимости от системы разработки.
Они могут присваиваться нескольким релизам подряд. Релизом в данном случае
считается завершённая версия.
Анализ требований к проекту. На этом этапе формулируются цели и
задачи проекта, выделяются базовые сущности и взаимосвязи между ними.
То есть, создается основа для дальнейшего проектирования системы. В
рамках данного этапа не только фиксируются требования заказчика, но и
проводится их формирование – клиентам подбирается оптимальное решение их
проблем, определяется необходимая степень автоматизации, выявляются
наиболее актуальные для автоматизации бизнес-процессы. При анализе
требований определяются сроки и стоимость разработки ПО, формируется и
подписывается ТЗ на разработку программного обеспечения.
Проектирование. На основе предыдущего этапа проводится
проектирование системы. Эта методология проектирования соединяет в себе
объектную декомпозицию, приемы представления физической, логической, а
также динамической и статической моделей системы. Во время проектирования
разрабатываются проектные решения по выбору платформы, где будет
функционировать система языка или языков реализации, назначаются
требования к пользовательскому интерфейсу, определяется наиболее
подходящая СУБД. Разрабатывается функциональная спецификация ПО:
выбирается архитектура системы, оговариваются требования к аппаратному
обеспечению, определяется набор орг. мероприятий, которые необходимы для
внедрения ПО, а также перечень документов, регламентирующих его
использование.
45
Проектирование представляет собой существенно значимый процесс для
определения архитектуры, различных компонентов, интерфейсов и прочих
характеристик системы либо конкретной её части (ISO 24765).
Основной
результат проектирования представляет собой целостную совокупность
представленных моделей, различных свойств или достаточно значимых
характеристик, которые описываются в форме, пригодной для реализации
системы.
Проектирование, наряду с анализом требований, является частью большой
стадии жизненного цикла системы, называемой определением. Результаты этой
стадии являются входной информацией для стадии реализации (воплощения)
системы.
Проектирование системы направлено на представление системы,
соответствующее предусмотренной цели, принципам и замыслам; оно включает
оценку и принятие решений по выбору таких компонентов системы, которые
отвечают её архитектуре и укладываются в предписанные ограничения.
В настоящее время существует сильная тенденция рассматривать
архитектурное и детальное проектирование как различные виды деятельности;
делаются попытки определить их как отдельные практики, однако эти виды
проектирования в значительной мере «переплетены». Архитектурные решения в
сравнении с «обычными» проектными решениями рассматриваются как более
абстрактные, концептуальные и глобальные; они нацелены на успех всей миссии
и на наиболее высокоуровневые структуры системы. Детальное проектирование,
в свою очередь, определяется как процесс детализации и расширения
предварительного проекта (архитектуры) до такой степени, при которой проект
полностью готов к реализации.
Реализация. Данный этап разработки системы организован в соответствии
с моделями эволюционного типа жизненного цикла ПО. При разработке
применяются экспериментирование и анализ, строятся прототипы, как целой
системы, так и ее частей. Прототипы дают возможность глубже вникнуть в
проблему и принять все необходимые проектные решения еще на ранних этапах
проектирования. Такие решения могут затрагивать разные части системы:
внутреннюю организацию, пользовательский интерфейс, разграничение доступа