This app template was built for the SAP Ariba Sourcing process. This is an end-to-end process which usually starts with the creation of a sourcing project. Then, the standard project events are created and executed. These events comprise the basic steps needed for a sourcing project, such as:
Finally a contract is generated and the sourcing project is completed.
Please note that when creating a sourcing project in SAP Ariba, the user must select one Template for the project. These templates include predefined Phases and its Tasks, plus the Documents and Events that will be included in the project.
The following list shows the usual Activities that will be performed in an SAP Ariba sourcing project. All of them happen after the first activity which is Create sourcing project. These activities are also divided into several Phases as shown below:
Phase: Project Planning
Phase: Strategy Development
Phase: Supplier Identification
Phase: Execution and Award
Phase: Closeout
The graphic below briefly shows a standard template sourcing process in SAP Ariba:
The following tags are available by default.
| Tag | Description |
|---|---|
| Sourcing projects with baseline spend changes | Cases where the Baseline spend was either increased or decreased. |
| Sourcing projects with project reason changes | Cases which include an activity where their Description indicates the sourcing project reason has changed. |
| Sourcing projects reopened | Cases which include an activity where their Description indicates the sourcing project reason has been reopened. |
| Sourcing projects with more than one RFP | Cases which contain more than one 'RFP' event. |
| Sourcing projects with more than one RFI | Cases which contain more than one 'RFI' event. |
| Sourcing projects with more than one RFQ | Cases which contain more than one RFQ event. |
| Sourcing projects without contract associated | Cases which do not contain contracts. |
The following due dates are available by default.
| Due date | Description |
|---|---|
| Sourcing project start due date | Compares the date when the sourcing project should start (planned start date) with the date it actually started. |
| Sourcing project ended after planned due date | This due date compares the date when the sourcing project should finish (planned end date) with the date it actually ended. |
The data extraction is developed for SAP Ariba v.2301.
SAP Ariba is a Software as a Service (SaaS) and it gets constant updates that are deployed quarterly, naming its versions with the last two digits of the year directly followed by the month of the release (i.e. January 2023 release: v.2301).
As mentioned before, this app template was built and tested to work with SAP Ariba v.2301. However, it was designed to work with tables that are the backbone of the sourcing process so it is probable that it will remain compatible with the next multiple iterations of the system. It is recommended to review the documentation of each new release to be aware of the changes that could happen in the tables.
SAP Ariba Strategic Sourcing module is mandatory.
All other tables used (basically for master data purposes) are part of the backbone of any SAP Ariba implementation and they were added to this app template. That means there is no further requirement for any SAP Ariba implementation. The only caveat is that these tables, like any other, could be purged or archived.
There are no SAP Ariba environmental settings required.
The user who sets up the APIs in SAP Ariba Developer Portal should be administrator of the system and have DSC (Designated Support Contact) permissions.
An extractor is developed in Python that allows to extract data from SAP Ariba in CSV format using Ariba APIs. Note that due to limitations of the Ariba APIs regarding the number of requests and the number of records extracted per request, this extraction might take longer than expected.
For the extractor and its documentation, download the SAP_Ariba_Sourcing_Extractor.zip.
The following table provides an overview of the different field types and their default format settings.
| Field type | Description |
|---|---|
| boolean | true, false, 1, 0 |
| date | yyyy-mm-dd |
| datetime | yyyy-mm-dd hh:mm:ss[.ms], where [.ms] is optional |
| double | Decimal separator: . (dot); thousand separator: none |
| integer | Thousand separator: none |
| text | N/A |
The following tables are extracted from the source system:
Contains sourcing projects transactional information.
| Field | Type | Description |
|---|---|---|
| InternalId | text | Unique identifier of the sourcing project |
| BaselineSpendAmount | double | Indicates the amount had to spend in the sourcing project |
| BaselineSpendCurrency | text | Indicates the currency of the baseline spend amount in the sourcing project |
| ClientDescription | text | Used to specify the department in the organization involved in the project |
| CommodityName | text | The commodity of the sourcing project, an organization might refer to commodities as categories (e.g. suppliers categorization) |
| OwnerName | text | The user who owns the sourcing project |
| ParentDocumentInternalId | text | Indicates the unique identifier of the predecessor document related to the sourcing project. (e.g. another sourcing project ID; a sourcing request ID) |
| RegionDescription | text | The geographic region belonging to the sourcing project |
| Status | text | Sourcing project state in the process |
| TimeCreated | timestamp | Timestamp on which the sourcing project was created |
| Title | text | User-friendly name of the sourcing project |
Filtering: Sourcing_projects is the only table that has a date-time filter. This table will then provide the Sourcing_project_IDs that will be used as a filter for all the other transactional tables. Master data tables, as usual, are not being filtered.
Stores sourcing projects attributes information.
| Field | Type | Description |
|---|---|---|
| internalId | text | Unique identifier of the sourcing project |
| beginDate | timestamp | Date when the project actually started |
| endDate | timestamp | Date when the project actually ended |
| plannedEndDate | timestamp | The date planned to end the project |
| plannedStartDate | timestamp | The date planned to start the sourcing project |
| templateProjectTitle | text | Predefined model that the sourcing project uses as a base to be created |
Contains information of all sourcing project related documents such as RFPs, RFIs, RFQs and Contract workspaces.
| Field | Type | Description |
|---|---|---|
| internalId | text | Unique identifier of the project documents, events and contracts |
| createDate | timestamp | Date on which the project document was created |
| description | text | Description of the project event |
| docType | text | General type name for the project documents (e.g. Event) |
| iconType | text | Actual type of project document (e.g. RFP) |
| owner | text | User who created the project document |
| projectId | text | Unique identifier of the sourcing project associated to the event |
| status | text | State of the project document in the process |
| title | text | User-friendly name of the project document |
| type | text | General categorization code of the project documents (e.g. RFx) |
Stores historical information of the sourcing projects.
| Field | Type | Description |
|---|---|---|
| id | text | Unique identifier of the activity |
| description | text | System description of the activity executed |
| details | text | Indicates the status of the activity (e.g. Completed, Canceled) |
| ProjectId | text | Sourcing project unique identifier related to the historical record |
| realUserName | text | Name of the user who performed the activity |
| timestamp | timestamp | Date on which the activity was executed |
| title | text | User-friendly name of the activity |
| type | text | System categorization of the activity (e.g. Task, Team, etc.) |
Stores all currency conversion rates available in the system.
| Field | Type | Description |
|---|---|---|
| FromCurrency | text | Currency code from which the conversion is done |
| TimeCreated | timestamp | Timestamp on which the record was created |
| ToCurrency | text | Currency code to which the conversion needs to be done |
| Rate | double | Exchange rate of the currency conversion |
This seed file has two purposes. The first one is to populate the activity attributes that cannot be obtained from any Ariba tables. The second purpose is to set a preferred activity name when the native name is not wanted.
| Field | Type | Description |
|---|---|---|
| Native_activity_name | text | Primary key of the table. Name automatically given to the activity by the model. This field is the concatenation of the activity title, plus its status. |
| Event_cost | double | Cost of executing the activity. |
| Activity_name | text | Name manually given by the analyst to the activity. |
| Activity_order | integer | Order on which the activity should happen in the process. |
| Activity_type | text | Categorization of the activity (e.g. Classification by Phase) |
| Automated_activity | boolean | Flag which indicates if the activity gets executed automatically or not. Valid values are 1, 0 or blank; the last 2 values mean FALSE. |
Note on Activities variability: The app template comes with the Activity_configuration_raw seed file pre-populated for a standard project template. In SAP Ariba, activities change depending on the template used for the sourcing projects creation. These templates can be customized as much as the business wants; therefore, it will always require adjustments.
This file has an auxiliary model Activity_configuration_auxiliary that was created to help analyst setup the app template. This auxiliary model was created based on Events_base and the seed file Activity_configuration. Then, it groups all events by their Native_activity_name and lists all their attributes.
This auxiliary model will be useful for the following:
| Field | Type | Description |
|---|---|---|
| Activity_status | text | Status for which an activity goes through in the process. |
After an updated csv file is loaded into the Seeds folder, the analyst needs to run the following dbt codes to process the latest changes: dbt seed first and then dbt run. This should be done whenever a change is done to any of the seed files.
| Variable | Type | Description |
|---|---|---|
| display_currency | text | All monetary values will be converted to the selected display_currency. |
| use_document | boolean | When TRUE, all document-related activities will be generated in the app template. By default it is set to FALSE to reduce the amount of activities that are being generated. Too many activities could cloud the view of the Process mining analyst. However, it may be useful for particular clients. |
| use_phase | boolean | This variable is similar to the previous one. It gives the possibility to bring activities related to Phases. This variable may help deepening the analysis, and also could help giving certain sense of order to the process. It is set as FALSE by default to avoid the creation of too many activities. |
| Entity | Input Data |
|---|---|
| Sourcing_projects | Currency_conversion_rates, Sourcing_project_events, Sourcing_projects, Sourcing_project_details. |
The app template follows 2 approaches for creating activities:
Each approach follows a different logic in the app template.
Approach 1: activities that can be created from transactional tables.
This activity has a specific model where it was created and the name of the model derived from the activity name.
Sourcing_project_creation_events
| Entity | Native_activity_name | Description |
|---|---|---|
| Sourcing Projects | Create sourcing project | Event of creation of the sourcing project. The date comes from the Sourcing_projects transactional table. |
Approach 2: activities that can be created from historical table.
These activities have a specific model where they all were created. By default all of them are based on Ariba Tasks. And it can also add activities based in Phases and Documents.
Relevant considerations:
The activities present in the app template are based on the standard predefined template in SAP Ariba for the sourcing process. However, it is not possible to known in advance which activities will be used across implementations.
The most standard activities were set up in advance in the Activity_configuration_raw seed file mentioned in Seed files. For new activities, the analyst should add them following the steps described in that section.
The Native_activity_name is automatically generated by the model concatenating Title (Task name) with Details (status: created, completed, approved, etc.). If this Native_activity_name does have an Activity_name set in the Seeds file, it will use the latter instead.
As a guideline for naming Native_activity_names that have a status 'Completed' we suggest to name them avoiding their status. Therefore, whenever an activity is actually completed, its name refers to the Title only. This is done to increase clarity in the displaying name of the activities.
Example 1:
Native_activity_name: 'Approval for Final Sourcing Strategy Completed'
Activity_name: 'Approve final sourcing strategy'
On the other hand, all other statuses remain in the activity name.
Example 2:
Native_activity_name: 'Approval for Final Sourcing Strategy Denied'
Activity_name: 'Deny final sourcing strategy approval'
The lack of setups for a particular activity will not break the model.
Sourcing_project_history_events
Below, there are examples of activities derived from the standard template, the entity, the activity name assigned to them and their descriptions.
| Entity | Native_activity_name | Activity_name | Description |
|---|---|---|---|
| Sourcing Projects | Approval for Final Sourcing Strategy Approved | Approve final sourcing strategy | Final approval done to the sourcing project strategy |
| Sourcing Projects | Evaluate RFI Responses Reviewed | Review evaluation of RFI responses | Review done to the evaluation of the RFI responses |
Sourcing project versions:
In SAP Ariba, whenever some header attributes are changed to a Sourcing Project, the system automatically generates a new version of it, with the same Sourcing_project_ID. The system also keeps a copy of the older version by creating a new Sourcing_project_ID, which is not available in the front end of Ariba (it is only stored in the back end). That new Sourcing_project_ID will not have any historical information; it will only keep the original attributes of the project. However, SAP Ariba APIs can still pull these projects. Therefore, the APIs continue extracting the transactional record for the older versions of the same Sourcing project (this is unwanted). To avoid this issue of duplicating Sourcing projects due to versioning, an inner join was done in Sourcing_projects model. This inner join will bring only Sourcing projects with historical information associated.
Repeated timestamps: In SAP Ariba many activities could happen at the same time, in many stages of the process (e.g. the creation of the Tasks such as 'Assign project team' are automatically done when the Sourcing Project is created). The activity orders for all standard template activities are already populated. It is important that the Analyst populates the Activity_order field for new ones in the Activity_configuration_raw seed file.
Same activities with different name: In SAP Ariba, the same activity can have many different Native activity names. This happens because the field Title, which is the first part of the Native_activity_name field (Native_activity_name = Title + Details), could vary across sourcing projects, depending on the name assigned to the task by the system.
Example:
The activity 'Review RFP Approved'
could have a native name as:
'Review RFP 001 Approved',
'Review Request for Proposal 02 Approved', etc.
To avoid this problem, the Analyst should populate the Activity_name field in the Activity_configuration_raw seed file.
Example:
The previous Native activity names can be renamed as: 'Approve RFP review'.
New Event/document added to the project after the fact: If, for any reason, a new document is added to the project, it means that the Template did not create any Task associated to it, therefore, the user must create them manually (Create document, Approve document, etc). If this is not done, it could happen that all the activities related to that document are going to be missing in the app template. Enabling the variable 'use_document' for displaying document-type activities could potentially solve this problem. Please refer to Dbt variables.