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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В субботу, 27 мая 2023, прошла первая лаборатория по новому курсу. Рабочее название «Системное администрирование предприятия».

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

Поговорили про сам курс системного администрирования предприятия и его связку с системной инженерией и менеджментом. Пример: в архитектуре есть форма записи решений ADR, есть паттерны (готовые решения), которые принимаются в рамках разработки софта. Предлагается в рамках функционирования бэк-офиса как набора сервисов там тоже будет свои «ADR — administrative decision records», свои «паттерны». И мы должны принимать решения (как в момент создания сервиса бэк-офиса, так и в момент оказания этими сервисами работ.) Это приводит к мысли, что

• Решения должны быть в явном виде. Дальше должна быть фитнес-функция (плохо слово, но пока так). Разработчик пишет это на языке паттернов
  • Govenrance — в том числе в автоматическом виде
  • Mentoring — всех научить следовать правилам.
• Онтология должна строится на базе domain driven design.

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

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

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

• Тренд1: нельзя терять связь с теми, кто установил риск по каждому объекты. Это разговор о том, что риски нужно пересматривать: со временем, риски приходят и уходят, изменяется их оценка и влияние на организацию / бизнес. Сюда так же можно добавить, что контекст конкретной бизнес-операции так же может по-разному влиять на оценку риска. Например, договоры ниже Х рублей заключается по простой форме.

• Тренд2: с точки зрения администратора бэк-офиса, идут постоянно тесты: архитектурные, функциональные и т. п. Это походе на фитнес-функции при разработке софта. Тут важно понять, какие из этих тестов должны выполнятся строго в момент операции, то есть синхронно, а какие — можно выполнять в фоновом режиме и «поднимать флаг», когда действительно есть проблема

Документирование бизнес-правил.

• Очевидно, что есть стандарты, нужно в них посмотреть. Например, SBVR — https://www.omg.org/spec/SBVR/.
• БОльшая часть формулировки правил — это онтология, то есть какие объекты в бизнесе мы выделяем, как мы их понимаем (и одинаково ли). Например, для документов это могут быть разнообразные статуса как по линии документооборота (получен, отправлен, архивирован и т. п.), так и по юридической (подписан, не подписан, какой стороной и т. п.). Возникают вопросы:
  • Что делать с этой онтологией на уровне предприятия? Например, при проектировании моделей данных попытки для целей аналитики, попытка спроектировать единую концептуальную и логическую модель данных приводит к невозможности вносить изменения.
  • Как выбирать необходимый и достаточный уровень единых объектов в предприятии? Как этим управлять?

Поговорили про то, что в бизнесе очень много бывает правил (чаще они забываются «политиками» и содержат в очень общем виде какие-то нормы практики). Тут выход проще — нужно делать исполняемые чек-листы.

• Гипотеза: правила документируем в исполняемых чек-листах (хоть машиной, хоть человеком)
• Правила — это способ наложить какое-то ограничение на поток работ / на функционирование организации.
• Убеждаемся, что в существующих описаний объектов (например, сделок или мероприятий) хватает необходимых атрибутов в явном виде. Это позволяет проводить тестирование / проверку исполнения правила не только человеком
• Типы правил (драфт)
• Ограничивающие правила
  • Вычислимые.
    • Принятия решений — здесь отлично справляется табличная нотация DMN https://camunda.com/dmn/. Позволяет распутывать достаточно сложные правила. Некоторые BPMS-движки поддерживают нотацию в явном виде
  • Правила вывода (форма передачи знаний)
    • Если клиент не пользовался счётом 2 года, то считаем его неактивным

  Язык бизнес-правил — https://www.rulespeak.com/en/

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

  • Сервисы функционируют по определенным бизнес-правилам
  • Бизнес-правилами управляют отдельные службы-провайдреы
  • Подразделения — модули, которые на внешней границу предоставляют какой-то сервис
  • Оркестрируется обычно либо людьми, либо процессной / документооборотной системой.

  Поговорили про учёт как центральное понятие. Сказали, что из учёта нужно выкидывать слово «финансовый» и смотреть на новую онтологию от Партриджа + связку с REA https://en.wikipedia.org/wiki/Resources,_Events,_Agents. И тут может быть самое разные учеты

  • Учёт бизнес-правил
  • учет прав доступа (безопасность — это те же проблемы учёта). Ведение реестров, ведение списков: кому что можно.
  • Учёт полномочий — в договорах
  • Учёт кто кого заменяет и по каким вопросам
  • Учёт прав доступа
  • Учёт сотрудников (кадровый учёт)
  • Учёт документов (первичных, договоров и т. п.)
  • Учёт авторизаций (например, на закупку чего-либо)
  • И т. п.

  Основная сложность в организации: все эти «учёты» проходят в разных информационных системах, в том числе Экселях. Это геренит «по-умолчанию» проблемы: разные описания одного и того же, каких-то важных описаний вообще нет (есть только в голове у эксперта предметной области).