В субботу, 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. И тут может быть самое разные учеты

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

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