doc/METAMODEL/PROCESS/math/cross-through.md

## math for BPM
**Математический формализм для BPM-процессов**  
Есть большая проблема: BPM - это не научная дисциплина и все ее понятия "очень размыты". В направлении "Научный менеджмент 2.0" \ "BPM как математика" рассмотрим несколько формализмов: Cross-functional Process, end-to-end Process. Кросс-функциональный и сквозной процесс - два ключевых элемента в BPM. Как вариант развития идеи: переписать BPM CBOK через математический формализм.

### 1 cross-functional
Cross-functional Process
#### intro
Если в процессе (системе) участвует два подразделения, т.е. один под процесс (подсистему) выполняет одно подразделение (функциональное подразделение), а другой под процесс - другое, то имеем уже кросс-функциональный процесс.
#### 1t term
Ключевые термины: 
- [функция](https://www.multitran.com/ru/dictionary/english-russian/function) - применительно к "кросс-функциональный процесс" перевод строится от должность-должностные обязанности/ функциональный отдел-служба фактически являясь синонимом Департамент.  
Хотя более точно - речь идет о макро ["бизнес-функциях"](https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Glossary:Business_functions) / [Organisational Functions](https://smartlifeskills.co.uk/business-management-business-environment-organisational-functions/) - причем обфчно выделяю core: Marketing, Finance, HR, and Operations. Т.е. в контексте Cross-functional Process можно считать, что function - это самостоятельное структурное подразделение.
- function в ARIS (EPC) - это подпроцессс, операция, см. [ARIS Methods](https://bpm.ucoz.ru/_ld/0/67_ARIS_Methods.pdf)  
- функциональные колодцы - это плохо и нужно «сломать стены между подразделениями». Тут смысл в том, что чтобы что-то донести из одного колодца - нужно по всей иерархии колодца добежать вниз, взять что нужно и потом бежать вверх и только тогда это можно передать в следующий колодец. Только это сильно упрощено и как раз регламенты даже в функциональной структуре обеспечивают "слом стены между подразделениями" в рамках регламентированного кросс-функционального процесса. Тут скорее проблема в едином командовании \ единоначалии, т.е. у каждого колодца - свои руководитель, а из соседнего колодца рядовому сотруднику "не докричаться" до рядового в другом колодце - но это обычно проблема, когда нужно взаимодействовать вне утвержденного регламента, например, в форс-мажор.  
- [Силосная башня –«functional silo»](https://mainthing.ru/ru/item/368/):  после того, как крестьянин заложил скошенное сено в силосную башню, добраться он может только до небольшой части этого богатства – до верхнего слоя. Точно так же ресурсы, информация, знания, процедуры в иерархически организованной компании оказываются погребены в недрах функциональных подразделений. 
- [Enterprise Process Management(EPM, Cross-functional Process)](https://abpmp.org.ru/resource/bpm-glossary/#epm) - в глоссарии BPM CBOK - вообще странное определение. 
#### 1p problem
- Относительность "кросс-функциональности". Если на одной схеме VAD отобразили цепочку процессов с подписью исполнителей на уровне отделов и получили кросс-функциональный процесс, то на той же схеме, если показать не отделы, а департаменты и все отделы попадают в один департамент, то получим моно-функциональный процесс. Таким образом, в зависимости от обобщения иерархии  подразделения для ровно одной схемы процесса можем получить как кросс-функциональность, так и моно. Для строго формализма нужно это учитывать.    

#### 1.1 math for Cross-functional Process
##### mini
x^3 + x^2 + x = Y  
все в левой части - это три функции (три разных), образующих выражение. Y - это "значение процесса \ функции" процесс.  
Например,  
x^3 и x^2 – это функции куба и квадрата. Например, у одного подразделения выполняющего операцию «x^3» в функциональных обязанностях записано «возводить в куб», а у другого (с названием «Подразделение Кубов») – возводить в квадрат.  
Тогда, кросс-функциональный процесс (хотя бы два разных подразделения - две разные функции) будет:  
x^3 + x^2,  
а, не кросс-функциональный процесс - это например, x^3 + x^3  

##### math 
Обозначения:
*   **P** — Процесс (Process).
*   **fⱼ** — Элементарная функция (операция, задача), выполняемая одним исполнителем (ролью, подразделением). `f: I → I'`, преобразует входные данные. Где   
I — Входные данные (Input). Множество I = {i₁, i₂, ..., iₖ}.

Имеем:  
*   **Подразделение "Кубы" (`f_cube`):** `f₁(x) = x³`
*   **Подразделение "Квадраты" (`f_square`):** `f₂(x) = x²`
*   **Подразделение "Линейщики" (`f_linear`):** `f₃(x) = x`

**Кросс-функциональный процесс `P1` (разные функции - подразделения):**
`P1(x) = f₁(x) + f₂(x) + f₃(x) = x³ + x² + x = Y`

**НЕ кросс-функциональный процесс `P2` (в процессе выполняется одна и таже функция):**
`P2(x) = f₁(x) + f₁(x) = x³ + x³`   
Можно показать, что операции проводятся с разными заготовками \ входными данными:
`P2(x,y) = f₁(x) + f₁(y) = x³ + y³`   

Есть множество типов функций и мультимножество функций в составе процесса. Если в мультимножестве функций в составе процесса есть более одного типа функции, то процесс кросс-функциональный. 
Для справки: Множество (set) - это неповторяющийся и неупорядоыенный набор. МультиМножество - множество с повторением элементов. Кортеж - Упорядоченный набор с возможным повторением элементов.   
Multiset - Общее название для множества, где допускается повторение элементов, например, {A, A, B, C}.

## Формальное определение кросс-функционального процесса через множества

### Базовые множества:

1. **Множество всех возможных типов функций (операций):**
   ```
   T = {t₁, t₂, ..., tₖ}
   ```
   *Пример:* `T = {"кубирование", "квадратирование", "линейное_преобразование", "проверка", "согласование"}`

2. **Множество всех функций (подразделений с их операциями):**
   ```
   F = {f₁, f₂, ..., fₙ}
   ```
   *Пример:* `F = {"Отдел кубов", "Отдел квадратов", "Линейный отдел"}`

3. **Функция типа (отображение):**
   ```
   type: F → T
   ```
   которая сопоставляет каждой функции её тип:
   ```
   type(f₁) = t₁, type(f₂) = t₂, ...
   ```

### Процесс как упорядоченное множество функций:

**Определение 1 (Процесс):**
Процесс `P` длины `m` — это упорядоченное множество (или мультимножество) функций, участвующих в процессе:
```
P = {f₍₁₎, f₍₂₎, ..., f₍ₘ₎} ⊆ F
```
где `f₍ᵢ₎ ∈ F` — i-я функция в процессе (возможны повторения).

**Определение 2 (Множество типов процесса):**
Для процесса `P` определим множество **уникальных типов** функций, участвующих в процессе:
```
T(P) = {type(f) | f ∈ P}
```
*Примечание:* это множество, а не мультимножество — повторяющиеся типы учитываются один раз.

---

## Математический критерий кросс-функциональности

**Определение 3 (Кросс-функциональный процесс):**
Процесс `P` является **кросс-функциональным** тогда и только тогда, когда:
```
|T(P)| > 1
```
то есть множество типов процесса содержит **более одного элемента**.

**Определение 4 (НЕ кросс-функциональный процесс):**
Процесс `P` является **НЕ кросс-функциональным** (функционально однородным) тогда и только тогда, когда:
```
|T(P)| = 1
```
то есть все функции процесса принадлежат к одному типу.

---

## Примеры в формализме

### Пример 1: Кросс-функциональный процесс
```
T = {куб, квадрат, линейный}
F = {f₁, f₂, f₃} где:
  type(f₁) = куб
  type(f₂) = квадрат  
  type(f₃) = линейный

P₁ = {f₁, f₂, f₃}  # x³ + x² + x
T(P₁) = {куб, квадрат, линейный}
|T(P₁)| = 3 > 1 ⇒ КРОСС-ФУНКЦИОНАЛЬНЫЙ
```

### Пример 2: НЕ кросс-функциональный процесс
```
P₂ = {f₁, f₁}  # x³ + x³
T(P₂) = {куб}
|T(P₂)| = 1 ⇒ НЕ КРОСС-ФУНКЦИОНАЛЬНЫЙ
```

### Пример 3: Граничный случай
```
P₃ = {f₁, f₂}  # x³ + x²
T(P₃) = {куб, квадрат}
|T(P₃)| = 2 > 1 ⇒ КРОСС-ФУНКЦИОНАЛЬНЫЙ
```

---
Условно: P₂ - это взаимодейсвие внутри процесса внутри одного функционального колодца, а P₁ и P₃ - это взаимодейсвтие с разными функциональными колодцами. 

#### simply 1
Пусть:
T = {t1, t2, ..., tk} - множество типов функций.
F = {f1, f2, ..., fn} - множество всех функций (например, подразделений с их операциями).
type: F -> T - отображение, сопоставляющее каждой функции ее тип.

Процесс P длины m - это MultiSet (или кортеж - не принципиально) функций:
P = (f_{p1}, f_{p2}, ..., f_{pm}), где каждый f_{pi} ∈ F.

Определим множество типов функций, встречающихся в процессе P, как образ MultiSet через отображение type,
взятый как множество (без повторений):
T(P) = { type(f) | f ∈ {f_{p1}, f_{p2}, ..., f_{pm}} }

Критерий кросс-функциональности:
Если |T(P)| > 1, то процесс P кросс-функциональный.
Иначе (|T(P)| = 1) процесс не является кросс-функциональным.

Математически можно записать:

∀ P = (f_{p1}, f_{p2}, ..., f_{pm})
T(P) = { type(f) | f ∈ {f_{p1}, f_{p2}, ..., f_{pm}} }
(кросс-функциональный(P) ⇔ |T(P)| > 1)

Примеры:

Пример 1: P1 = (f1, f2, f3), где type(f1)=t1, type(f2)=t2, type(f3)=t3.
T(P1) = {t1, t2, t3}, |T(P1)|=3 > 1 ⇒ кросс-функциональный.

Пример 2: P2 = (f1, f1, f1), где type(f1)=t1.
T(P2) = {t1}, |T(P2)|=1 ⇒ не кросс-функциональный.

Пример 3: P3 = (f1, f2), где type(f1)=t1, type(f2)=t1.
T(P3) = {t1}, |T(P3)|=1 ⇒ не кросс-функциональный (все функции одного типа, даже если разные экземпляры).

Пример 4: P4 = (f1, f2), где type(f1)=t1, type(f2)=t2.
T(P4) = {t1, t2}, |T(P4)|=2 > 1 ⇒ кросс-функциональный.

#### simply 2 
## Упрощенный формализм 2

### Базовые определения

**Типы функций (роли):**
```
T = {A, B, C, ...}
```
Где A, B, C — различные типы операций (например: A="куб", B="квадрат", C="линейная")

**Функции-исполнители:**
```
F_A = {a₁, a₂, ...}  // функции типа A
F_B = {b₁, b₂, ...}  // функции типа B
...
```

**Мультимножество процесса:**
```
P = ⟅p₁, p₂, ..., pₘ⟆
где pᵢ ∈ F_A ∪ F_B ∪ ... (возможны повторения)
```

### Формальное правило кросс-функциональности

```
ЕСЛИ ∃pᵢ, pⱼ ∈ P (i ≠ j): type(pᵢ) ≠ type(pⱼ)
ТОГДА CrossFunctional(P) = TRUE
ИНАЧЕ CrossFunctional(P) = FALSE
```

Где `type(p)` определяется как:
- Если `p ∈ F_A`, то `type(p) = A`
- Если `p ∈ F_B`, то `type(p) = B`
- и т.д.

### Компактная запись

**Определение:**
Процесс `P` — кросс-функциональный, если:
```
∃X,Y ∈ T (X ≠ Y): |P ∩ F_X| ≥ 1 ∧ |P ∩ F_Y| ≥ 1
```

### Примеры

**Пример 1: Кросс-функциональный процесс**
```
F_A = {a₁, a₂}  // функции возведения в куб
F_B = {b₁}      // функции возведения в квадрат

P₁ = ⟅a₁, b₁, a₂⟆  // процесс использует a₁ и b₁ и a₂
type(a₁) = A, type(b₁) = B
∃(a₁, b₁): type(a₁) ≠ type(b₁) ⇒ КРОСС-ФУНКЦИОНАЛЬНЫЙ
```

**Пример 2: НЕ кросс-функциональный процесс**
```
P₂ = ⟅a₁, a₂, a₁⟆  // все функции типа A
∀pᵢ, pⱼ ∈ P₂: type(pᵢ) = type(pⱼ) = A ⇒ НЕ КРОСС-ФУНКЦИОНАЛЬНЫЙ
```

### Таблица истинности

| Процесс P (мультимножество) | Условие: ∃ разные типы? | Кросс-функциональный? |
|-----------------------------|-------------------------|---------------------|
| ⟅a₁⟆                         | Нет                    | Нет                 |
| ⟅a₁, a₂⟆                    | Нет (оба типа A)       | Нет                 |
| ⟅a₁, b₁⟆                    | Да (A и B)             | Да                  |
| ⟅a₁, a₂, b₁⟆               | Да (A и B)             | Да                  |
| ⟅a₁, b₁, b₂⟆               | Да (A и B)             | Да                  |
| ⟅a₁, b₁, c₁⟆               | Да (A, B, C)           | Да                  |


----

### 2 through = end-to-end
Сквозной процесс 

#### 2t term
Ключевые термины: 
- Не путать с [straight-through processing, STP, Сквозная обработка ](https://ru.wikipedia.org/wiki/%D0%A1%D0%BA%D0%B2%D0%BE%D0%B7%D0%BD%D0%B0%D1%8F_%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0):   
Термин "through процесс" (или "through processing") в русском языке чаще всего означает сквозной процесс, то есть автоматизированную, непрерывную обработку данных без ручного вмешательства. Поэтому лучше использовать для термина сквозной end-to-end, который к автоматизации не имеет отношщения.  
- глоссарии ru BPM CBOK на сайте: end-to-end \ Сквозной процесс - не нашел (там вообще сквозной часто упоминают: сквозная деятельность, моделирование, работы и т.п.). Например, 
*Понятие сквозной работы является принципиальным, в нем подразумевается вся работа, необходимая для создания потребительской ценности в полном объеме, не взирая на функциональные границы.*

Видимо предполагается, что все процессы (почему-то) сквозные, см. Определение [process](https://abpmp.org.ru/resource/bpm-glossary/#process)  
Процессы состоят из набора взаимосвязанных задач или действий, нацеленных на решение конкретной проблемы. В контексте управления бизнес-процессами «бизнес-процесс» определяется как сквозная работа, создающая потребительскую ценность. Понятие сквозной работы является принципиальным, в нем подразумевается вся работа, необходимая для создания потребительской ценности в полном объеме, не взирая на функциональные границы.
В тоже время сам BPM CBOK содержит [определения](https://github.com/bpmbpm/doc/blob/main/METAMODEL/PROCESS/term.md#%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F-%D0%B8-%D0%BA%D1%80%D0%BE%D1%81%D1%81-%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81)  
- в ARIS (EPC) более четкое определение сквозного процесса 
- [Цепочка создания ценности фрагмент книги](https://www.mann-ivanov-ferber.ru/assets/files/bookparts/business-processes/bp-mail_stamped.pdf?srsltid=AfmBOoqMXa58ZgB3Q7-XbdPD1hsntWzMp8RDoAM5807jWqnNQCq0wzYX)
- [E2E – End-to-end процесс из simpleone](https://simpleone.ru/glossary/end-to-end-process-e2e-end-to-end-process)

### 2p problem
- Очень длинный Сквозной процесс: от "самого-самого" начала до самого конца. С таким подходом можно считать, что в компании все один Очень длинный и "предельно сквозной процесс" типа [Нулевого процесса](https://github.com/bpmbpm/doc/blob/main/BPM/theory/company-wide-process.md)
- Сквозные (end-to-end) процессы нарезают так, как это удобно процессникам для классификации (по типу операций) \ учета \ контроля и т.п. Например, в банках никому в голову не придет сквозной процесс нарезать: от привлечения средств во вклад до выдачи (другому клиенту) кредита.  
Будут всегда отдельно процессы привлечения и размещения средств (нарезаны отдельно), хотя без (предварительного) привлечения ничего размещать коммерческому банку не получится (только Центробанк может напечатать и выдать кредиты без привлечения, а на основе эмиссии).
#### Условности
- end-to-end (end-to-end ver 1, как E2E в общем случае) говорит, что мы определяем два end: стартовый end и финишный end. Можем их задать произвольно и определеить сквозным даже "очень короткий" end-to-end, т.к. в общем случае - нет четких ограничений на выбор end. Главное, чтобы end1 был не равен end2.
- end-to-end ver 2 (E2Ev2). Введем условие для финального end: он должен реализовывать (давать на выходе) продукт из Каталога продуктов компании. Т.е. продукт из каталога продуктов реализуется процессом end_finish. Единственное условие к end_start чтобы оно не было равно end_finish. 

### 2.1 Math. base (end-to-end) process 
end-to-end в общем сучае E2Ev1 (version 1)
### Базовые понятия

**Множество всех функций процесса:**
```
F = {f₁, f₂, ..., fₙ}
```

**Процесс как упорядоченная последовательность:**
```
P = ⟨p₁, p₂, ..., pₘ⟩
где pᵢ ∈ F и m ≥ 1
```

**Определение концов процесса:**
```
Пусть:
start(P) = s, где s ∈ {p₁, ..., pₘ}  // стартовый end
end(P) = e, где e ∈ {p₁, ..., pₘ}    // финишный end
```

### Формальное правило сквозного процесса

**Процесс P является сквозным (end-to-end) относительно выбранных концов s и e тогда и только тогда, когда:**

```
start(P) ≠ end(P)
```

Или более формально:

```
∀P = ⟨p₁, p₂, ..., pₘ⟩:
  Сквозной(P, s, e) ⇔ (s ∈ P) ∧ (e ∈ P) ∧ (s ≠ e)
```

где `s ∈ P` означает, что `s` является элементом последовательности `P`.

### Расширенная форма с индексами

Если мы фиксируем индексы начала и конца в последовательности:

```
Пусть:
start_index = i, где 1 ≤ i ≤ m
end_index = j, где 1 ≤ j ≤ m

Тогда:
Сквозной(P, i, j) ⇔ (i ≠ j) ∧ (1 ≤ i ≤ m) ∧ (1 ≤ j ≤ m)
```

### Примеры

**Пример 1: Минимальный сквозной процесс**
```
P = ⟨f₁, f₂⟩
Выбираем: start(P) = f₁, end(P) = f₂
Условие: f₁ ≠ f₂ ⇒ ПРОЦЕСС СКВОЗНОЙ
```

**Пример 2: Несквозной процесс (концы совпадают)**
```
P = ⟨f₁, f₂, f₃⟩
Выбираем: start(P) = f₁, end(P) = f₁
Условие: f₁ = f₁ ⇒ ПРОЦЕСС НЕ СКВОЗНОЙ
```

### 2.2 Math. E2Ev2 process (version 2)
Дополнительное условие к базовой (первой, E2Ev1) версии к финальному end: он должен реализовывать (давать на выходе) продукт из Каталога продуктов компании.
## Формальное определение сквозного процесса версии 2 (E2Ev2) 

### Базовые структуры

**Множество функций:**
```
F = {f₁, f₂, ..., fₙ}
```

**Каталог продуктов компании:**
```
ProductCatalog = {prod₁, prod₂, ..., prodₖ}
```

**Функция выхода (результата) процесса:**
```
output: F → 2^{ProductCatalog}
```
где `output(f)` — множество продуктов, которые функция `f` реализует (может быть пустым).

**Процесс как последовательность:**
```
P = ⟨p₁, p₂, ..., pₘ⟩ где pᵢ ∈ F для всех i = 1..m
```

### Основное определение

**Процесс P является сквозным версии 2 (E2Ev2) тогда и только тогда, когда:**

```
∃i,j ∈ {1, 2, ..., m}: (i < j) ∧ (pᵢ ≠ pⱼ) ∧ (output(pⱼ) ∩ ProductCatalog ≠ ∅)
```

### Компоненты условия

1. **Разные позиции:** `i < j` — стартовая позиция раньше финишной
2. **Разные функции:** `pᵢ ≠ pⱼ` — стартовая и финишная функции различны (как элементы F)
3. **Продукт в каталоге:** `output(pⱼ) ∩ ProductCatalog ≠ ∅` — финишная функция реализует хотя бы один продукт из каталога

### Альтернативное определение (с явным указанием концов)

Для заданных индексов i и j:
```
E2Ev2(P, i, j) ⇔ (i < j) ∧ (pᵢ ≠ pⱼ) ∧ (output(pⱼ) ∩ ProductCatalog ≠ ∅)
```

### Примеры

**Пример 1: E2Ev2 процесс**
```
F = {f₁, f₂, f₃}
ProductCatalog = {ПродуктА}
output(f₁) = ∅, output(f₂) = {ПродуктА}, output(f₃) = ∅

P = ⟨f₁, f₂, f₃⟩
Проверяем пару (1,2):
- i=1 < j=2 ✓
- p₁ = f₁ ≠ p₂ = f₂ ✓
- output(f₂) ∩ ProductCatalog = {ПродуктА} ≠ ∅ ✓
⇒ E2Ev2(P) = TRUE
```

**Пример 2: Не E2Ev2 (нет продукта в каталоге)**
```
P = ⟨f₁, f₂, f₃⟩
output(f₁) = ∅, output(f₂) = {ВнутреннийОтчет}, output(f₃) = ∅
ProductCatalog = {ПродуктА}

Для всех пар:
- output(f₂) ∩ ProductCatalog = ∅
⇒ E2Ev2(P) = FALSE
```

**Пример 3: Не E2Ev2 (функции совпадают)**
```
P = ⟨f₁, f₁⟩
output(f₁) = {ПродуктА}
ProductCatalog = {ПродуктА}

Для пары (1,2):
- i=1 < j=2 ✓
- p₁ = f₁ = p₂ ✗ (условие pᵢ ≠ pⱼ не выполняется)
⇒ E2Ev2(P) = FALSE
```

**Пример 4: Не E2Ev2 (процесс длины 1)**
```
P = ⟨f₁⟩
output(f₁) = {ПродуктА}
ProductCatalog = {ПродуктА}

Нет пар i < j (требуется минимум 2 элемента)
⇒ E2Ev2(P) = FALSE
```

### Таблица истинности

| Процесс P | output(p₁) | output(p₂) | output(p₃) | Условия | E2Ev2? |
|-----------|------------|------------|------------|---------|--------|
| ⟨f₁, f₂⟩ | ∅ | {ПродуктА} | — | p₁≠p₂, output(p₂)∩Catalog≠∅ | Да |
| ⟨f₁, f₂⟩ | {ПродуктА} | ∅ | — | p₁≠p₂, но output(p₂)∩Catalog=∅ | Нет |
| ⟨f₁, f₁⟩ | {ПродуктА} | {ПродуктА} | — | p₁=p₁ (не различны) | Нет |
| ⟨f₁, f₂, f₃⟩ | ∅ | ∅ | {ПродуктА} | Существует пара (1,3) или (2,3) | Да |
| ⟨f₁⟩ | {ПродуктА} | — | — | Нет пары i<j | Нет |

### Связь с бизнес-процессами

**Практическая интерпретация:**
- `ProductCatalog` — перечень товаров/услуг, которые компания продает клиентам
- `output(pⱼ)` — результат выполнения функции (может быть промежуточным или конечным)
- E2Ev2 процесс гарантирует, что существует путь от некоторой начальной функции к функции, создающей продукт для клиента
- Можно задать дополнительное условие: сквозной процесс E2Ev2 должен быть кросс-функциональным (обратное не обязательно)

### 2.3 E2Ev1 & E2Ev2
Сквозные процнссы - это просто группирорвка. Возможен такой подход для формировании общей карты (пазла, исключающего "дыры") всех верхнеуровневых процессов компании, где проблема не только выделить сквозной процесс, но и назначить на него и владельца (проблема показана в НаФактический владелец процесса).  
На первом шаге формируем основные \ продуктовые процессы - это как раз и есть E2Ev2. В идеале сдеалать его как можно "длинее" (max E2Ev2), но под "Владельца" (в тех границах, в которых он соглашается). Остаток от разорванной цепочки "max E2Ev2" заполнить E2Ev1.  
Далее подобным образом переход к другим, например, каталогу продектов регулятору - там тоже E2Ev2, причем многие этапы подготовки отчета могут выполнять не бухгалтера.  
Если пазл не сложился, то делаем новые группировки и сновы пытаемся сложить пазл (в т.ч. убедить владельца расширить границы процесса).