От экспертов «1С‑Рарус»: Концепция NO CODE на примере внедрения 1C:ERP World Edition в авиакомпании

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

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

На одном из зарубежных проектов нам нужно было разобраться с интересной задачей — автоматизацией авиакомпании. Этот бизнес очень сложный в силу сильной зарегулированности и при этом высококонкурентный. Нам было предложено разработать систему учета на базе «1С:Предприятие» в соответствии с бизнес-требованиями, изложенными в BRD (Business Requirement Document) проекта. Далее перечислены требования, которые оказали наибольшее влияние на проектные решения и архитектуру системы в целом.

Анализ прибыльности направлений и рейсов

Основа деятельности авиакомпании — это карта полетов. Для планирования важно знать, какие направления наиболее востребованы и есть ли зависимость пассажиропотока на конкретном направлении от времени суток.

Иерархию авиарейсов можно представить следующим образом:

• Сегмент (Segment) перелёта: внутренний (domestic) или международный (international).
  • Маршрут (Route) — определяется парой аэропортов, между которыми выполняются перелёты. Обычно какой-то аэропорт является хабом, поэтому в наименовании маршрута он может указываться дважды, как точка вылета и возврата. Например, маршрут DME-LED-DME указывает на то, что перелёты осуществляются по направлению Домодедово (Москва) — Пулково (Санкт-Петербург) — Домодедово (Москва).
    • Сектор (Sector) — направление перелёта по маршруту, определенное аэропортом вылета и аэропортом прилёта. Например, DME-LED. По одному сектору может выполняться несколько перелётов в день.
      • Рейс (Flight) — перелёт по определенному сектору в определенное время, как правило у рейса есть уникальный номер.

Пример:

ETD (Estimated Time of Departure) — ожидаемое (запланированное) время отправки.

ETA (Estimated Time of Arrival) — ожидаемое (запланированное) время прибытия.

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

Анализ доходов и расходов по воздушным судам

Производственные мощности авиакомпании — это ее флот. Стоимость среднемагистрального самолета составляет примерно 100–120 млн USD, поэтому чаще всего воздушные суда (в/с) находятся в лизинге и лизинговые платежи составляют существенную часть расходов на флот. Кроме этого есть ряд затрат, связанных с конкретным самолётом — расходы на техническое обслуживание и ремонт (ТОИР, по-английски MRO — Maintenance, Repair and Overhaul), страховка (Insurance) и т. д. У каждого самолёта есть свой уникальный бортовой номер воздушного судна (англ.«Tail Number» — номер на хвосте в/с).

В бизнес-требованиях было указано, что расходы конкретного самолета (Tail Number) должны распределяться на себестоимость рейсов, выполненных этим воздушным судном, причем базой распределения могут быть лётные часы Flight Hours (FH) или блок-часы Block Hours (BH) рейсов.

• Block Hour — это время от снятия до установки парковочных колодок.
• Flight Hour — это время от взлета до посадки.

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

Система учета должна обеспечивать возможность анализа как доходов, так и всех расходов по Tail Number, то есть конкретным воздушным судам.

Учет доходов по тарифам и классам

Для пассажира (PAX — passenger) стоимость билета на рейс определяется двумя параметрами: типом и классом обслуживания. Тип пассажира (PAX Type) — взрослый (Adult), ребенок (Child) или младенец (Infant). Класс обслуживания или тарифный класс (fare class) определяет уровень сервиса и набор преимуществ. Обычно самый низкий тариф предлагается в рамках какой-то промо-акции (в нашем примере это будет Promo), далее идет эконом-класс (в нашем примере Economy), а самые высокие классы обслуживания предоставляются пассажирам первого или бизнес-класса (в нашем примере Business).

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

Учет CARGO-перевозок

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

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

Прямые затраты рейса

Есть затраты, которые можно однозначно отнести на конкретный рейс. Например, авиационное топливо, зарплата персонала и т. д. Такие расходы нужно относить к прямым производственным затратам по соответствующим статьям калькуляции.

Причем зарплату команды пилотов (Flight Crew) и бортпроводников (Cabin Crew) нужно отражать по отдельным статьям.

Задержки рейсов

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

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

Неявка пассажира на рейс

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

Прочее

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

Проектирование и идеальное внедрение типового решения 1С

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

Всем этим требованиям удовлетворяло решение 1C:ERP World Edition.

В целом алгоритм выработки проектных решений и тестирования гипотез такой:

1. Определяем базовые объекты НСИ.
2. Пропускаем процессы через эти объекты.
3. Смотрим через отчеты на соответствие результата бизнес-требованиям.

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

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

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

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

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

Так мы пришли к концепции выработки проектных решений без кодирования.

Что мы понимаем под NO CODE в 1С

Перед тем, как описывать проектные решения, сделаем небольшое отступление и объясним, что мы называем NO CODE подходом для «1С:Предприятие 8».

NO CODE — это разработка без написания кода с помощью специальных платформ.

Обычно такая платформа представляет визуальный конструктор, когда используя drag’n’drop можно разработать схему системы из доступных элементов и компонентов. А no-code платформа преобразует эту схему в систему.

Но является ли наличие визуального конструктора обязательным для того, чтобы применять no-code подход для разработки информационной системы?

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

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

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

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

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

Более тщательное проектирование может существенно сократить, а в некоторых случаях даже исключить этап программирования, как это предлагается в концепции NO CODE.

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

Главный этап проектирования

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

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

Это, наверное, можно назвать модным словом цифровизация. В ходе проектирования создается модель предприятия (можно сказать «цифровой двойник») и его процессов с использованием функциональности типового решения 1С.

Концептуальные проектные решения

Номенклатура авиаперевозок

Главный вопрос: что производит и продаёт авиакомпания? Услуги по авиаперевозке пассажиров и грузов. Очевидно, что для этого наиболее подходит справочник «Номенклатура». Но что указать в параметрах настройки НСИ и разделов, и самого справочника «Номенклатура», чтобы выполнить бизнес-требования описанные выше в постановке задачи?

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

Переход к набору готовых решений может показаться резким, т. к. мы не описываем все итерации. Итерации продолжались до тех пор, пока комбинация проектных решений не начала удовлетворять всем бизнес-требованиям оставляя нетронутой саму конфигурацию 1C:ERP.

В результате работы экспертного совета мы пришли к решению, что основной продукцией авиакомпании, с точки зрения ERP, является работа воздушного судна, то есть элемент справочника «Номенклатура», у которого вид номенклатуры имеет тип «Работа» с необходимым набором характеристик. Рассмотрим более подробно реализацию этого проектного решения.

Справочник «Виды номенклатуры»

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

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

Для пассажирских авиаперевозок мы ввели специальный вид номенклатуры Air transportation PAX.

Не менее важным была возможность использования набора характеристик, общих для вида номенклатуры. Именно в виде номенклатуры определяется набор и порядок использования характеристик.

Мы использовали следующий набор реквизитов характеристик:

• Tail Number,
• PAX type,
• PAX class.

Tail Number — это бортовой номер воздушного судна, реквизит типа «Объекты эксплуатации», то есть ссылка на справочник основных средств, где хранятся сведения о воздушных судах:

Справочник «Основные средства»:

Использование типа «Объект эксплуатации» в составе характеристики номенклатуры дает нам возможность анализировать прибыль от услуг, выпускаемых конкретным воздушным судном (Tail Number):

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

PAX type (Тип пассажира) — Adult (Взрослый), Child (ребенок), Infant (младенец). Значения этого реквизита введены в справочник «Дополнительные значения»:

PAX class — тариф или класс обслуживания пассажира. В нашем примере мы будем рассматривать три класса обслуживания — Business, Economy, Promo. Значения этого реквизита введены в справочник «Дополнительные значения».

Вроде бы всё — есть набор реквизитов, который позволит выпускать и отражать реализацию услуг в разрезе бортовых номеров воздушных судов, типов и классов обслуживания пассажиров. Но в бизнес-требованиях есть необходимость особого учета пассажиров не явившихся на рейс. Даже если авиакомпания выполнила все свои обязательства, но пассажир по каким-то причинам не прошёл регистрацию на рейс, то такая ситуация классифицируется как NO SHOW — неявка и это внереализационный доход. Теоретически любой авиабилет может превратиться NO SHOW, это нельзя запланировать ни при продаже, ни при планировании производства.

Для таких случаев мы добавили еще один реквизит характеристики No-show типа «Булево» — пассажир или явился на рейс или нет:

Это мы можем узнать только тогда, когда КВС (капитан воздушного судна) предоставит отчет о полете. Если пассажир не явился на рейс, то в наименование характеристики добавляется NO SHOW, если явился — то в наименовании характеристики ничего не меняется.

Итак, полный набор реквизитов характеристик — Tail Number, PAX type, PAX class, No-show:

Cargo-грузы перевозятся на одном рейсе с пассажирами. Для CARGO авиаперевозок такой набор реквизитов будет явно излишним, поэтому мы создали еще один вид номенклатуры Air transportation CARGO для характеристик с одним реквизитом Tail number. Важным будет использование того же самого реквизита характеристики из набора Air transportation PAX:

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

Справочник «Номенклатура»

Созданные виды номенклатуры позволят нам использовать только два элемента справочника «Номенклатура» для основной деятельности — пассажироперевозки PAX transportation и грузоперевозки Cargo transportation.

Элемент PAX transportation — авиауслуга перевозки одного пассажира PAX transportation. Вид номенклатуры — Air transportation PAX, единица измерения — PAX (пассажир):

Для этого элемента нужно ввести новую единицу измерения — PAX (пассажир):

Элемент Cargo transportation — услуга авиаперевозки одной тонны груза Cargo transportation. Вид номенклатуры — Air transportation CARGO, единица измерения — t (тонна):

Карта маршрутов

Аналитику «Направление перелета» решили организовать на справочнике «Направление деятельности», в англоязычном варианте Line of businesses.

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

Сегмент (Segment) — это группа самого верхнего уровня для разделения внутренних и международных рейсов.

Группы второго уровня будут соответствовать маршрутам (Route), хаб (узловой аэропорт авиакомпании) указывается дважды — как аэропорт вылета и возврата в исходную точку.

На третьем уровне будет элементы справочника, которые соответствуют номерному рейсу по конкретному направлению (сектору маршрута) перелёта.

То есть получаем такую иерархию:

• Segment
  • Route
    • Flight

Элемент справочника «Направления деятельности»:

Обратите внимание на реквизиты Flight Hour и Distance. Этих реквизитов нет в типовой поставке, мы их добавили через механизм «Дополнительные реквизиты и сведения»:

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

Например, ASK и ATK:

• ASK (Available Seat Kilometers) — максимально доступный пассажирооборот.
  • Мера пассажирской емкости, которой располагает авиаперевозчик, обозначает перемещение одного пассажирского кресла на расстояние один километр, измеряется в кресло-километрах (ккм).
• ATK (Available Tonne Kilometers) максимально доступный тоннокилометраж.
  • Мера измерения грузо-пассажирской провозной емкости, которой располагает авиаперевозчик. Обозначает провозную емкость из расчета перемещения одной условной тонны груза (пассажиров и/или коммерческого груза) на расстояние один километр, измеряется в тонно-километрах (ткм).

Чем больше у авиакомпании воздушных судов и, чем шире карта полётов, тем выше ASK и ATK, фактически это показатель операционной мощности авиаперевозчика.

Производство авиаперевозок

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

Для производства основных услуг мы использовали позаказную схему производства:

Один заказ на производство соответствует одному рейсу конкретного воздушного судна по заданному маршруту с известным составом услуг авиаперевозки:

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

Выпуск осуществляется в один этап, т. к. всё происходит за один производственный цикл:

На вкладке «Основное» указана продукция только первой строчки производственного заказа, но это не важно — полный список услуг содержит табличная часть на вкладке «Выпуск»:

Большой интерес представляют данные о прямых затратах рейса — это вкладки «Трудозатраты», «Обеспечение» и «Расход».

На каждом рейсе работают две бригады — Flight Crew (пилоты) и Cabin Crew (бортпроводники):

Затраты на оплату труда разносятся по разным статьям калькуляции — ФОТ пилотов на Labor Cost — Flight Crew, ФОТ бортпроводников на Labor Cost — Cabin Crew:

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

Разумеется, мы должны будем оформить выработку сотрудников и внести величину расходов на ФОТ:

Прямые материальные затраты указаны на вкладках «Обеспечение» и «Расход»:

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

Затраты топлива относим на статью калькуляции Fuel:

С затратами на топливо всё достаточно прозаично, но скорее всего вызывает недоумение наличие Block Hour JL-A122 и Flight Hour JL-A122 в прямых затратах, которые относятся на статью калькуляции Cost Allocation Driver.

Это и есть проектное решение в парадигме NO CODE для решения задачи по распределению косвенных затрат конкретного воздушного судна на коммерческие рейсы этого воздушного судна.

Рассмотрим на примере лизинговых платежей, т. к. они относятся к конкретному самолету.

Это ежемесячные платежи, которые после получения первичных документов относятся на статью затрат Aircraft Leasing by Tail Number.

Настройки статьи затрат:

• Расходы возникают:
  • В иных процессах, включая общепроизводственные и общехозяйственные.
• Относятся:
  • На себестоимость производства (распределяемые).
• И распределяются согласно правилу распределения расходов:
  • Cost allocation base «Block Hours» (Tail Number).
• Тип аналитики расходов:
  • Объект эксплуатации.
• Статья калькуляции:
  • Cost of Aircraft Leasing.

Ключевая настройка содержится как раз в правиле распределения расходов, в которой есть возможность распределения на партии. В случае производства номенклатуры типа «Работа» партией является этап производства — рейс. То есть у нас есть алгоритмы распределения затрат по рейсам. Осталось только придумать, как распределять на рейсы конкретного воздушного судна:

Когда мы указываем распределение на партии (рейсы) по правилу в настройках есть возможность указать вариант «Между партиями по базе: Количество материалов». Вопрос в том, какой материал указать.

Мы придумали, что можно указать виртуальный материал, который будет означать блок-часы конкретного воздушного судна:

Например, Block Hour JL-A122, единица измерения — час:

Аналогичные настройки сделаны для другой базы распределения по летным часам (Flight Hour).

Причём выпускать свои BH (Block Hour) и FH (Flight Hour) может воздушное судно по нулевой стоимости, т. к. для распределения нам нужно только количество и таким образом мы не будем вносить искажения в производственную себестоимость.

Выпуски оформляем через производство без заказа, указывая в качестве назначения конкретный этап производства (рейс):

Распределение расходов происходит при закрытии периода с помощью соответствующего документа:

При признании затрат в качестве подразделения-получателя мы указывали операционный департамент, поэтому указываем вариант распределения «Распределять на: текущее подразделение»:

Наверняка возникает вопрос, почему мы не применяем характеристики для служебной номенклатуры Block Hour и Flight Hour, а вводим для каждого в/с свою пару элементов. Ответ очевиден из настройки — в отборе нельзя указывать характеристики номенклатуры.

Непредвиденные расходы на рейс

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

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

На первый взгляд не типовая ситуация достаточно просто решается типовыми средствами.

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

Для таких случаев у нас есть специальная статья расходов Delay extra cost, на которую мы отнесем затраты на размещение пассажиров:

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

Даже если мы забудем про эти затраты, программа при закрытии месяца выдает сообщение, что есть нераспределенные затраты:

При формировании документа указываем, что партия (рейс) будет указана вручную:

И при ручном подборе указываем нужный этап (рейс) производства:

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

В самом этапе желательно указать причину задержки и в поле «Комментарий» дать более детальное описание:

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

Выручка от реализации

Для целей управленческого финансового учета не было предъявлено специфичных требований к отражению продаж. В авиакомпаниях обычно применяются системы управления доходами, это решения класса RMS (Revenue Management System). Поэтому для отражение реализации мы выбрали самый простой вариант отражения через документ «Реализация товаров и услуг» (Customer invoice), где в качестве клиента указывается служебный элемент справочника «Клиенты».

В качестве подразделения-отправителя указывается производственное подразделение:

На вкладке «Дополнительно» обязательно указать направление деятельности, т. к. этот реквизит определяет, на какой рейс будут отнесены доходы от оказания услуг авиаперевозки:

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

Отчет по валовой прибыли/Gross Profit

Отчет по валовой прибыли можно формировать в разрезе характеристик, а точнее отдельных составляющих характеристики — по классам, по типам и по Tail Number (бортовым номерам воздушных судов):

Отчет по классам и типам пассажиров (Gross profit by Class and Type)

Как видно, по тарифу Promo у нас только убытки, что вполне типично для отрасли. Поэтому будьте терпеливее к лоукостерам — они работают буквально на грани рентабельности.

Отчет по воздушным судам (Gross profit by Tail Numbers)

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

Отчет по маршрутам (Gross profit by Routes)

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

Отчет по себестоимости

Структуру себестоимости анализируем через соответствующий отчет Actual Product Cost:

Здесь мы видим себестоимость в разрезе самолётов и их работ, по статьям калькуляции.

Если вывести в группировку партии (рейсы), то можно видеть существенные отклонения по каким-то рейсам:

Видим нетипично большую себестоимость одного рейса и пытаемся разобраться что случилось. В комментарии указано «Задержка рейса из-за погодных условий» и есть статья калькуляции Delay extra cost. Это рассмотренный выше случай дополнительных расходов из-за задержки рейса.

Отчет по топливу (Fuel Uplift and Consumption)

Топливо — одна из самых существенных статей затрат у авиакомпаний. У лоукостеров доля затрат на топливо может достигать 25–30% себестоимости. Поэтому к топливу всегда пристальное внимание.

В отчете вы видим Uplift — заправки воздушных судов топливом и Consumption — расход топлива в соответствии с полетными документами.

NO CODE ожидания и LOW CODE реальность

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

Система не существует сама по себе, а работает в гетерогенном ИТ-ландшафте. Поэтому, как минимум, нужны будут интерфейсы обмена данными.

Заказы на производство должны подгружаться из системы управления и планирования полётами. Данные о продажах из систем бронирования. При этом нужно будет следить за актуальностью данных и НСИ.

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

Но эти доработки можно отнести к Low Code, потому что мы НЕ переписываем фундаментальные механизмы ERP уровня «изменение расчета себестоимости», а делаем «обвязку» для встраивания системы в существующий ИТ-ландшафт. Такие доработки могут быть достаточно сложными, требующими высокой квалификации в соответствующих ИТ-экспертизы. Поэтому уместно будет сделать оговорку — это статья о задачах внедренцев. При этом следует помнить, что для запуска и обслуживания системы нужны не только внедренцы.

Заключение

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

Принимая во внимание концепцию NO CODE можно прийти к парадоксальному выводу: идеальный внедренец не пишет код! Идеальные внедренцы это те, кто внедряют типовые решения без кодирования.

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

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

Достигается это только с опытом.