В статье описывается выбор методологии внедрения мобильного приложения для интеграции с Helpdesk системой ИТ-предприятия. В данной работе устанавливаются требования к приложению и в соответствии с характеристиками проекта определяется наиболее рациональная стратегия внедрения.
Ключевые слова: техническая поддержка, мобильное приложение, Helpdesk система, внедрение программного обеспечения.
В деятельности ИТ-компании, которая занимается разработкой и поддержкой продуктов фирмы «1С», центральное место занимает техническая поддержка клиентов. Она включает в себя прием заявок, уточнение требований и согласование сроков, постановку задачи исполнителю, выполнение и отчет по результатам работы. [1] Все задачи фиксируются сотрудниками в системе управления обработкой заявок клиентов (Helpdesk).
Причем первый и последний этапы производятся вживую, по телефону или электронной почте. Сейчас данные со всех каналов вручную заносятся в Helpdesk систему, на что тратится дополнительное время, а сделать это во время выезда к клиенту зачастую невозможно. Кроме того, в существующей ситуации у клиентов нет возможности получать актуальную информацию о статусах задач. В связи с этим в организации было принято решение о создании мобильного приложения для автоматического поступления задач в Helpdesk систему. Целью данной работы является выявление требований для нового мобильного приложения и поиск наиболее рациональной стратегии его внедрения.
Ввиду отсутствия источников, описывающих подходящие мобильные приложения, было решено выработать функциональные и технические требования вместе с заказчиком. Во-первых, приложение должно предоставлять пользователям возможность постановки задач, которые будут создаваться в системе для дальнейшего назначения исполнителя сотрудниками техподдержки, с их описанием и прикрепленными файлами. Во-вторых, клиенты смогут просматривать статусы, количество, описание и сроки выполнения текущих задач. В-третьих, определенная группа пользователей сможет просматривать информацию об актуальных договорах на абонентское обслуживание и выставленных счетах. Что касается, технических требований, так как Helpdesk система на предприятии является самописной разработкой на платформе «1С:Предприятие 8.3», то разработка должна осуществляться с использованием мобильной платформы «1С:Предприятие 8.3». Так как пользователей устройств с Android гораздо больше [2], ведь в основном это сегмент бюджетных мобильных устройств, в качестве целевой операционной системы была выбрана Android. К другим немаловажным требованиям относятся:
– сроки — совокупное время на реализацию,
– стоимость — затраты на приобретение, подписку или оплату труда,
– возможность самостоятельной доработки приложения под требования, которые скорее всего появятся в будущем.
Для того, чтобы при реализации приложения были выполнены все функциональные и технические требования, а также минимизированы сроки и финансовые затраты ИТ-компании, необходимо обратиться к существующим методологиям внедрения информационных систем.
Методологии внедрения, как правило, разрабатываются лидерами в производстве информационных систем с учетом особенностей их программных продуктов, а также области внедрения. Главное преимущество таких стандартов — их практическая направленность. Они представляют собой глубоко проработанные, проверенные, многократно апробированные рабочие инструкции и шаблоны проектных документов. Такие стандарты обычно далеки от теоретических абстракций, ориентированы на особенности конкретных систем, содержат наилучший опыт. Однако у стандартов есть и отрицательные аспекты: даже методологии, предназначенные для систем, близких по классу, не взаимозаменяемы. [3]
Для выбора рациональной стратегии внедрения разрабатываемого приложения рассмотрены следующие методологии:
– «Business Solutions Partner Methodology»,
– «MSF (Microsoft Solutions Framework)»,
– «ASAP (Accelerated SAP)».
«Business Solutions Partner Methodology» — это методология, разработанная компанией «Microsoft» для поддержки внедрения систем группы Microsoft Business Solutions. В ней основной акцент делается на нуждах бизнеса Заказчика, которому, в конечном итоге, необходимо решение для эффективной работы бизнеса. Использование в процессе внедрения этой методологии позволяет обеспечить высокую эффективность проекта для Заказчика и реальное достижение тех целей внедрения, ради которых Заказчик и начал проект. Методология обеспечивает регулярный контроль хода проекта на всех этапах, что направлено на снижение проектных рисков.
В рамках данной методологии вводятся понятия концептуального (ориентированного на бизнес-пользователя) и детального (ориентированного на разработчика) дизайна системы, что обеспечивает последовательность и преемственность в формировании пользовательских и системных требований к решению.
Появляются требования о выделении отдельной среды для разработки программного продукта, среды для тестирования, рабочей среды для интеграции результатов в рабочую систему. [3]
Содержание этапов проекта в данной методологии представлено в таблице 1. [3]
Таблица 1
|
Этап проекта |
Характеристика этапа |
|
Диагностика |
Анализ и описание бизнес-процессов. Выявление основных потребностей бизнеса. Оценка функциональной применимости базового программного продукта. Определение ожидаемых результатов, сроков, границ и бюджета проекта. |
|
Анализ |
Организация проекта. Детальное обследование и описание предприятия Заказчика. Изучение требований к внедряемому решению. Документирование функциональных требований, создание полного перечня требуемых модификаций и доработок функциональности. |
|
Дизайн |
Описание создаваемого решения, детальное проектирование модификаций и доработок функциональности. Планирование изменений бизнес-процессов. Уточнение подходов к разработке и испытаниям проектируемого решения. |
|
Разработка и тестирование |
Реализация и первичное тестирование модификаций и доработок функциональности. Установка и настройка системы. Планирование и проведение испытаний. Доработка решения по результатам испытаний. |
|
Развертывание |
Подготовка и настройка рабочей системы. Разработка пользовательской документации. Тренинг конечных пользователей. Планирование и запуск в рабочую эксплуатацию. Сдача-приемка проекта. |
|
Начальное сопровождение |
Сопровождение функционирования системы в режиме рабочей эксплуатации. Устранение выявленных несоответствий. Переход к режиму работы Заказчика в рамках контракта на регулярное сопровождение. |
Методология Microsoft Solutions Framework (MSF). В отличие от «Business Solutions Partner Methodology», которая ориентирована на внедрение готовых информационных систем, построенных на базе определенных программных продуктов, MSF носит универсальный характер и может использоваться для внедрения произвольной разрабатываемой в ходе проекта системы.
Особенностью этой методологии является глубокая проработка различных аспектов организации проекта внедрения (определение этапов и контрольных точек проекта, состава команды проекта, распределения задач и пр.), что может оказаться весьма полезным при проектировании собственных корпоративных процедур управления проектом.
Модель процессов MSF отражает интегрированную (общую) методологию разработки и внедрения ИТ-решений. Под ИТ-решением в MSF понимается скоординированная поставка набора элементов (таких как программно-технические средства, документация, обучение и сопровождение), необходимых для удовлетворения некоторой бизнес-потребности конкретного заказчика.
В отличие от решений, программные продукты разрабатываются для нужд массового рынка, поставляются в качестве дистрибутивных пакетов или загружаемых файлов и не требуют организации процесса внедрения.
Универсальность модели MSF определяется тем, что благодаря своей гибкости и отсутствию жестко установленных связей и процедур она может быть применена при разработке весьма широкого круга систем: традиционного программного обеспечения, ERP-систем, решений в области электронного бизнеса, распределенных сетевых приложений и пр.
Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной и спиральной [4] (см. рисунок 1).
Рис. 1. Модель жизненного цикла решения MSF
В основе методологии MSF лежит итеративный интегрированный подход к созданию и внедрению решений, базирующийся на фазах и вехах.
Итеративность подхода предусматривает поэтапное создание всех элементов проекта: программного кода, документации, дизайна, планов. Реализацию проекта рекомендуется начинать с построения, тестирования и внедрения базовой функциональности системы. Затем к решению добавляются все новые и новые возможности. Такой подход к процессу разработки подразумевает достаточную гибкость в ведении документации. Проектные документы должны изменяться по мере эволюции проекта. Их пересмотр не прекращается до конца проекта и производится после каждой итерации. Такой подход существенно отличается от принципов ведения документации в каскадной модели, где процесс разработки начинается лишь после того, как готовы и зафиксированы все требования и спецификации.
Интеграция в рамках одного проекта процедур разработки и внедрения системы позволяет более полно сосредоточиться на нуждах Заказчика (даже если разработка решения прошла удачно, заказчики не увидят отдачи до тех пор, пока оно не запущено в эксплуатацию), улучшить взаимодействие с командой сопровождения.
Фазы проекта определяют последовательно решаемые задачи, а вехи — ключевые точки проекта, характеризующие достижение какого-либо существенного результата. [4]
«ASAP (Accelerated SAP)» — это улучшенная методология «Процедурной модели SAP», разработанная компанией «SAP» в 1996 г. с целью ускорения процесса внедрения при постоянной оптимизации. Основная составляющая ASAP — это методология Сетевого графика (Roadmap), который связан с такими инструментами, как IMG (Implementation Guide, «Руководство по внедрению»). Стоит учесть, что ASAP задумывалась специально для средних и малых предприятий, которые не могут обеспечить продолжительное внедрение информационных систем.
В методологию ASAP входит множество различных списков контрольных вопросов, таблиц, опросных листов, рекомендаций, шаблонов документов и т. п. Помимо общих вопросов, в ASAP существуют руководства по огромному количеству технических вопросов, связанных инфраструктурой, установкой, настройкой и операциями SAP. Благодаря контрольным вопросам ASAP можно контролировать не только ход проекта, но также и стабильность системы на всех стадиях внедрения информационной системы. На рисунке 2 показаны основные этапы внедрения методологии ASAP. [5]
Рис. 2. Основные этапы внедрения информационной системы по методологии ASAP
Для управления изменениями в организации, вызванными внедрением SAP, используются инструменты, описанные в методологии Сетевого графика (Roadmap). Сетевой график выступает как проводник проекта, который уточняет этапы внедрения информационной системы, необходимые границы и задает общий темп всего проекта с целью получения работоспособной системы в максимально сжатые сроки, с максимальным качеством и в рамках заявленного бюджета. Сетевой график ASAP состоит из следующих этапов: подготовка проекта, концептуальное проектирование, реализация, окончательная подготовка, запуск и поддержка, оптимизация. [5]
Методологии ASAP и MSF обладают особенностями, которые в текущем проекте выступают как недостатки. Так, ASAP не отображает реально процесс разработки и внедрения программного обеспечения: отдельные фазы строго связаны с определенными действиями, что отличается от реальной работы коллектива разработчиков. Кроме того, методология основана на документации (акселераторах), а, следовательно, количество документов может быть избыточным. MSF, как и другие спиральные модели, слишком сложна для небольших проектов и может быть достаточно дорогой в использовании. А подверженность постоянным изменениям и более глубокий анализ рисков требуют высоких затрат при внедрении.
В текущем проекте определены весьма конкретные требования, которые не будут изменяться до его завершения. Объемная проектная документация не требуется, так как проект реализуется внутри компании. Риски проекта вполне предсказуемы и не обладают высоким влиянием на конечный результат.
По результатам проведенного анализа в качестве источника внедрения мобильного приложения для автоматизации деятельности технической поддержки ИТ-компании была выбрана методология «Business Solutions Partner Methodology». Она позволяет создать решение, наиболее соответствующее требованиям, а также минимизировать сроки и затраты на внедрение. Однако в силу того, что разрабатываемое решение для пользователей представляет собой установочный файл, не требующий дополнительных настроек и обучения пользователей, этап развертывания системы может быть пропущен. В ходе дальнейшей работы на основе этой методологии будет составлена структура работ проекта и определена последовательность их выполнения.
Литература:
- Моделирование процесса обработки заявок в службе технической поддержки сложных технических систем / Р. В. Иванов, А. В. Маятин, А. Е. Михайленко // Научно-технический вестник Санкт-Петербургского государственного университета информационных технологий механики и оптики — СПб НИУ ИТМО — 2017.
- Анализ операционных систем для сотовой мобильной связи и перспективы развития / А. С. Пилипенко, А. В. Григорьев // Современные информационные технологии в образовании и научных исследованиях — Донецкий национальный технический университет — 2017.
- Методологии внедрения компании Microsoft // Национальный открытый университет ИНТУИТ URL: https://intuit.ru/studies/courses/2196/267/lecture/6796 (дата обращения: 06.03.2022).
- Унифицированная модель организации внедрения решений в методологии Microsoft Solutions Framework (MSF) // Национальный открытый университет ИНТУИТ URL: https://intuit.ru/studies/courses/2196/267/lecture/6798?page=1 (дата обращения: 06.03.2022).
- Основные методологии внедрения информационных систем от ведущих компаний // Е. А. Лукиянчук, А. Г. Степанов // Информационные технологии в экономике и менеджменте c.47
