This document describes the data flow for objects in the technical space.
| Sub-Area | Details | Example KPIs | Comments |
|---|---|---|---|
| TECPRO - Signavio Process Manager | Signavio is the source of truth for which task is performed by which process role using which executable (e.g. Fiori app, transaction, report, etc.). However Signavio does not provide sufficient reporting capability to meet the needs of various downstream consumers of this information, who need to use information from the process models to answer various questions in order to perform subsequent work. Examples include:
| N/A The reporting is focused on comparing versions of data |
The models covered under this DDFS will cater for the requirements raised though the following Jira Requests:
Standard extractors do not need to be documented unless extended.
Where custom extractors / extensions are required, reference the FSD for that enhancement.
| Extractor Name | Build Jira Ref For Extension Information | Comment |
|---|---|---|
| TBC Signavio Report | Data is extracted from Signavio using a report written by SAP. It will post data to CPI which, in turn, will make this data available to via a REST API. The functionality to extract data from REST APIs is not available till the Q2 2026 release which (at time of writing) has not yet been delivered. |
Inbound layer objects only need documentation if some field adjustment is made (over and above the standard load date / time and source system stamp).
The table will receive fields delivered by the SAP report:
Process ID
Process name
Revision number
L1-L4 decomposition
Process Owner
Last change date
Last changed by
POD
Release
Sub-Function
Task name
Task type
Task ID
Pool name
Lane name
IT System title
IT System category name
LeanIX Link
Executable name
Executable category name
App ID
App name
App type
UI technology
Application component
Dictionary Link
An additional column 'export timestamp' is appended to the data. This is added to the file header by the Signavio report and applied by CPI.
Every table will have it's own harmonization view. This only needs to be documented if field adjustments are required. E.g. Conversion of data field / type.
Where actions are performed to improve reusability, e.g. joining header and item tables, details of the join (left outer, which is left, which is right, fields to join with, cardinality etc) should listed.
Each node inside the view will appear as a heading 3 in this document detailing what it does and, if not obvious, why.
Calculated dimension CD_PLANT to change length of field 'Plant' from 4 to 5 to align with WHM plant. (Ubiquitously true, reusable change made at lowest level possible).
Calculated measure: CM_PRICE = Value / Quantity. (Ubiquitously true, reusable change made at lowest level possible).
Purpose: Join PO header and item to create reusable view at item level that contains all fields from PO header
LHS: 2VR_S4H_C_PurchaseOrderDex
RHS: 2VR_S4H_C_PurchaseOrderItemDex
Join Field: POHeader to POHeader
Join type: Left outer join
Cardinality: 1: Many
Remove fields that occur in both PO Header and Item views leaving fields from PO Header side.
A line item level calculation which applies specific business rules that are owned by the POD would be added here.
Purpose: etc
Purpose: etc
Purpose: To bring in values from PO level alongside lower level granularity documents
| Target Field | Source1-Field | Source2-Field |
|---|---|---|
| PO | PO | PO |
| POItem | POItem | POItem |
| MaterialDocument | - | MaterialDocument |
List objects where material master associations are to be made.
Source Current data
Filter
IT System Category is Null - Only steps executed by humans
Projection
Remove all fields not relevant to swimlanes
Source Previous Snapshot
Filter
IT System Category is Null - Only steps executed by humans
Calculation
Rename all fields relevant to Swimlanes to DCD_ to identify separately in join
Projection
Remove all fields not relevant to swimlanes
Union
Fields
Calculation
Reorder fields such that field equivalents are alongside each other.
Link to FSD (Each Analytic model should have its own FSD).
Include technical details for:
Detail restrictions
Detail rate type, from currency
Link to FSD (Each Analytic model should have its own FSD).
Include technical details for:
Detail restrictions
Detail rate type, from currency