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

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

Работа авиакомпании заключается в эффективном управлении собственным флотом или самолётами в управлении. Авиакомпания занимается:

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

1. Коротко о задаче

После успешного внедрения информационного портала для некоторых клиентов — собственников бизнес-джетов, руководство авиакомпании поручило мне внедрить систему ARINCDIRECT FOS, разработанную американской компанией ROCKWELL/COLLINS.

Я присоединился к проекту как бизнес-аналитик на этапе возникновения трудностей при внедрении системы консалтинговой компанией — партнёра американского разработчика в Европе. Формально система должна была заработать сразу после отъезда консалтинговой компании с объекта заказчика, но этого не случилось.

2. Использование Business Analysis Body of Knowledge (BABOK) v 3

Сложность задачи требовала системного подхода с применением лучших достижений бизнес-аналитиков, собранных в стандарте A Guide to the Business Analysis Body of Knowledge.

Помимо этого мне помогали материалы Jeremy Aschenbrenner — тренера и бизнес-аналитика. Его лекции помогали мне правильно интерпретировать информацию, представленную в BABOK. Благодаря чётко структурированному подходу удалось преодолеть множество преград при внедрении системы ARINCDIRECT FOS.

3. Сбор данных о схеме AS-IS и построение в системе BPMN

Оказалось, что до этого авиакомпания безуспешно внедряла автоматизированную систему OpenSky российского разработчика РИВЦ Пулково также значительно похожую на ARINCDIRECT FOS, но она не была внедрена ни в одном подразделении компании. Поэтому первоочередной задачей было узнать причины провала внедрения этой системы.

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

Stakeholders по отделам при внедрении системы управления полётами.

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

Единственная система, которая использовалась в рамках организации полётов, была значительно "допиленная" 1С, администратор и разработчик которой находился за штатом компании, был физическим лицом и имел полную ставку в другой компании. Данная система не объединяла подразделения компании, большая часть взаимодействия осуществлялась посредством телефона и электронной почты. Ключевым отделом, связывающим другие подразделения компании, был НиПДС (планово-диспетческий).

Упрощённая схема AS-IS, при которой взаимодействие между отделами разрозненное.

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

4. Разбор бизнес-процессов и построение UML диаграмм

Для систематизации информации о взаимодействии между пользователями и внедряемой системой было решено составить UML диаграммы (использовалась версия 2.5). Изначально предполагалось внедрить SaaS версию системы, поэтому было решено сосредоточиться на систематизировании взаимодействия будущих пользователей системы с интерфейсом и модулями программы.

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

Черновая схема взаимодействия TO-BE, при котором все производственные процессы происходят в единой системе ARINCDIRECT FOS, имеющие модули.

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

После исследования AS-IS — TO-BE стал понятен масштаб действий, требования к бизнес-аналитику и опасности для проекта. Задача оказалась не просто техническая, но и политическая.

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

Use Case диаграмма взаимодействия TO BE по одному из модулей системы ARINCDIRECT FOS

В процессе согласования функционала с заинтересованными лицами Use Case диаграммы постоянно изменялись и благодаря облачному сервису LucidChart все эти изменения отражались визуально с небольшими вложениями сил и времени. Благодаря визуализации удалось пресечь «хождение по кругу» при обсуждении функционала системы и сотрудников.

5. Сбор требований к функционированию системы

Для сбора требований к новой системе управления полётами и производством требовалось провести встречи и консультации практически со всеми подразделениями компании из-за всеобъемлющей структуры системы ARINCDIRECT FOS.

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

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

Помимо этого от системы, заточенной на американские требования FAA и европейские требования EASA, требовалось соответствие ФАПам Росавиации. Нужно было настраивать систему с нуля, а также искать выходы из-за отсутствия поддержки кириллицы. Также в системе отсутствовали некоторые типы российских самолётов, находящиеся в эксплуатации авиакомпании.

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

Наложение функционала системы ARINCDIRECT FOS на функционал OpenSky. Множество совпадений функционала.

6. Выбор модели внедрения системы

После сбора требований стало понятно, что требуется помодульное внедрение системы ARINCDIRECT FOS для минимизации рисков сбоя в функционировании авиакомпании. Руководством компании было утверждено условие нулевого влияния внедрения на безопасность полётов, что могло быть достигнуто только дублированием систем — старая и новая на этапе внедрения дублировали друг друга.

Была выбрана СПИРАЛЬНАЯ МОДЕЛЬ как наиболее подходящая для минимизации рисков. Она подразумевает итеративность в добавлении функционала с большим вовлечением заинтересованных сторон, строгой регламентацией требований и результатов. Эта модель отлично подходит для дробления большого проекта на небольшие задачи, что удобно при внедрении модульных систем.

Спиральная модель разработки и внедрения системы. Она сочетает последовательность и итеративность, минимизируя риски

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

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

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

7. Создание документа бизнес-требований

Ключевым документом бизнес-аналитика является документ бизнес-требований, в котором фиксируется вся информация, касающаяся проекта: от глоссария до технических требований. Авиакомпания строго следовала требованиям IS-BAO — международного стандарта управления полётами в бизнес-авиации, поэтому документ бизнес-требований приобретал особенную значимость.

В документе бизнес-требований указывались следующие данные:

Глоссарий

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

Заинтересованные лица

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

Допущения и ограничения

Такой список определял, какой функционал ожидается от системы и какие накладываются на неё ограничения.

Варианты использования

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

Бизнес-требования

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

Последовательность операций бизнес-процесса

Набор диаграмм, иллюстрирующих схему бизнес-процессов в компании между отделами и сотрудниками. Она помогала определить функционал AS-IS и желательный функционал TO-BE.

8. Проверка системы целевым требованиям

Финальным этапом внедрения системы была проверка функционирования системы ARINCDIRECT FOS в соответствии с утверждёнными бизнес-требованиями. Для этого нужно было проверить инструкцию пользователя, правильно ли она толкуется сотрудниками авиакомпании и выдаёт ли система ожидаемый отклик при взаимодействии с ней.

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

Сразу после внедрения системы был начат процесс подготовки к будущей переаттестации компании на соответствие требований IS-BAO Stage II, которая требовала приведение документации авиакомпании к изменившимся бизнес-процессам.

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

9. Результаты проекта

Внедрение системы в процесс производства полётов авиакомпании

Главная задача — начало использования самой мощной системы для авиакомпаний бизнес-авиации — была выполнена.

Улучшение качества обслуживания клиентов

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

Преодоление противодействия изменениям внутри компании

Главная опасность — скепсис и безразличие сотрудников и некоторых stakeholders — была нивелирована за счёт системного подхода.

Повышение прозрачности работы авиакомпании

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

Улучшение качества отчётности компании

Благодаря мощному инструментарию Crystal Reports, встроенному в систему, стало возможным оперативно получать отчётность по деятельности компании и принимать data driven решения.

Повышение эффективности работы диспетчеров

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

Построение единой системы, доступной для руководства компании

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

Дополнительный маркетинговый повод

Авиакомпания стала первой и единственной в России и СНГ организацией, внедрившей системы ARINCDIRECT FOS, что позитивно сказалось на репутации.

10. Сложности, с которыми столкнулся в процессе внедрения

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

Отсутствие поддержки со стороны стейкхолдеров

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

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

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

Жёсткие бюджетные и временные рамки вместе с политикой нулевого влияния на риски

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

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

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

Невысокий уровень поддержки со стороны поставщика системы

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

Автор: Андрей Кулешов

По всем вопросам свяжитесь со мной любым удобным способом:

E-mail: 7341414@bk.ru
Телефон: +7 905 734-14-14
Соцсети: Facebook | LinkedIn