Для примера разобъём командировку на следующие стадии. Их сформулируем по принципам event-storm из DDD.

• Задумана. Получаем согласие организации (чаще всего — через руководителя с полномочиями) выделить финансирование,
• Запланирована / оформлена. Выбираем и покупаем билеты, выпускаем необходимые приказы, выдаём деньги,
• Начата. Наступил день командировки,
• Окончена. Отчитываемся за расходы, получаем или возвращаем деньги,
• Закрыта. Проводим все затраты, архивируем документы.

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

Перечислим так же то, что будет входит в командировку:

• Авиа, ЖД транспорт (в виде билетов)
• Такси или наземный транспорт
• Место проживания
• Место осуществления цели командировки
• Деньги
• Служба подбора билетов и гостиницы
• Служба заказа такси

Пока все просто. Теперь на примере авиабилетов разберёмся с цепочкой создания в типовой организации:

• Авиабилеты нужно а) выбрать, желательно удобные и б) купить,
• Чтобы это осуществить, необходим какой-то сервис-провайдер выбора билетов и их покупки. Для этого
  • Необходим действующий контакт на работу с сервис-провайдером и какой-то интерфейс взаимодействия (человек, почта, софт).

Из этого получаются достаточно длинные цепочки создания, которые должны отработать, чтобы заказать билет.

Со стороны бэк-офиса в деловой поезде будут задействованы:

• Руководитель командируемого для авторизации командировки,
• HR,
• Бухгалтерия, налоги и расчёт ЗП,
• Юристы,
• Экономическая безопасность,
• Казначейство,
• Документооборот.

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

Из этого вытекает то, что бэк-офис должен предоставлять сервисы в режиме «готовы к использованию», с достаточным уровнем SLA. В нашем примере это будет означать следующие сервисы:

• Сервис учёта командировок
• Сервис, который оркестрирует все вызываемые в каком-то порядке сервисы
• Сервис получения денег мгновенно. Например, в виде корпоративной кредитной карты. Есть банк, с ним есть договор, кредитная карта выпущена, на ней есть достаточно денег.
• Сервис заказа такси и оплаты по безналу. Например, через мобильное приложение, которое привязано к корпоративному аккаунту.
• Сервис проверки контрагентов и заключения / продления договоров. Чтобы в момент «вызова» сервиса необходимый контрагент был проверен, был заключен договор, не было задолженности итп.
• Сервис документоборота
• Сервис оплаты за все услуги
• Сервис удаленной работы (вне офиса) для ИТ-систем
• Сервис бухгалтерского, налогового и кадрового учёта
• Сервис поддержки в командировке
• ... и т. п.

Открытые вопросы:

1. В каком состоянии должны быть сервисы бэк-офиса? Что такое «минимально достаточный уровень SLA»? Какие там должны быть метрики?
2. Каким образом организовывать оркестрацию работ этих сервисов, чтобы поток деловых поездок не прерывался? По-хорошему, без их учёта будет сложно наладить нормальную работу.
3. Как обеспечить развитие всех используемых служб, чтобы система организации командировок продолжала корректно работать?
4. У всех вызываемых для командировки сервисов есть свои правила / политики. Каким образом отслеживать их исполнения? Как сделать такие политики, которые будут непротиворечить и работать быстро?
5. Таких повторяющихся кейсов в организации много, есть ли там общая онтология, как про это можно компактно думать?