| Status |
| |
| Owner | ||
| Stakeholders |
Issue
Syensqo has close to 700 non-standard/custom units of measure created in the system.
- These non-standard units of measure might cause data consistency issues as the definitions and the conversions are not standardised
- These custom units of measure cause issues with integrations with other SAP modules or 3rd party systems that do not recognise these units
Recommendation
It Based on the evaluation of the solution options, it is recommended to use only the standard UoMs available within the S/4HANA system and other linked systems to ensure consistency ease of maintenance Use SAP / ISO Standard UoMs and conversions. This follows the Simplification/Standardisation approach of the project and ensures consistency and ease of integration across the landscape.
Suppliers, customers, and any internal processes that require the use of non-standard UoMs should be reviewed and the custom UoMs replaced with standard UoMs - adhering to the ISO standard.
Any For legacy data using non-standard UoMs these will have to be mapped and switched to standard UoMs at the point of during data migration to ensure legacy data is compatible with the S/4 system.
Background & Context
Syensqo has close to 700 non-standard/custom units of measure created in the system. These units are historically created to cater to UoM's published by suppliers in various catalogs and also as a workaround to support certain business processes. Below are some of the issues faced currently
- Incorrect Conversion Factors - Missing or incorrect conversion factors between non-standard UoM's sometimes cause calculation errors e.g., in pricing, inventory etc.
- Reporting and Analysis Errors - Non-standard UoM's create issues in reporting and analytics, leading to miscalculations or inaccurate data representation and aggregations
- Incompatibility with SAP Standard Functions - Some SAP standard functions (e.g., MRP, ATP checks) do not fully support non-standard UoM's, or require additional customisation
- User Confusion and Data Entry Mistakes - Non-standard UoM's sometimes lead to user confusion and result in data entry mistakes, especially when the same unit of measure is shared across multiple business units
Scale of Issue
Below table provides the statistics of non-standard UoM's in the system along with the usage of the same.
| System | Non-Standard UoM's | POs in past 5 years | PO's with non-Standard UoM | % | UoM's used in affected POs | Materials changed in 10 Years | Materials with Non-Standard UoM | % | UoM's used in Material Masters |
| QF2 | 404 | 4,642,346 | 184,587 | 4% | 66 | 613,651 | 27,648* | 5% | 32 |
| WQ2 | 357 | 2,877,450 | 82,007 | 3% | 73 | 567,413 | 5,995 | 1% | 51 |
As a part of the above analysis, though there are ~700 non-standard UoM's that are existing in the system, there are only ~200 of them are currently active and being used in material master and Purchase Orders.
Assumptions
- Business processes are simplified and standardised and will not have any requirements for non-standard units of measure
- Punch-out catalogs used by Syensqo will have standard ISO units of measure - In case of any exceptions, the unit of measure in the catalog can will be mapped to a standard unit of measure in SAP
Constraints
N/A
Impacts
Data Migration
- All dependent master data ex: Material master, BOM's etc.. will be updated with the standard unit of measure (All the quantities in these data objects ex: BOM Header quantity, MOQ in material master will be updated based on the conversion factors)
- Stock quantities ex: Inventory, Stock in transit etc.. will adjusted based on the standard UoM before migrating to the new system
- Prices ex: Info records, pricing conditions etc.. will be adjusted based on the standard UOM before migrating to the new system
Downstream systems
- Any downstream system using the master data with non-standard UoM will be updated with new UoM and conversions. Mapping table will be used in case the UoM updates are not possible
Communication
- Communication along with the mapping for non-standard to Standard UoM's will be sent to the relevant customers / Vendors / 3rd party systems
Business Rules
All the master data and Business processes use only Standard SAP / ISO Units of Measure Measure
Options considered
Following are the options considered.
Option 1: Use SAP / ISO Standard UoMs and conversions
As a part of this option, all the master data and business processes use only the standard SAP/ISO unit of measures available in the system. Non-standard UoM's are not permitted to be created / used. Mapping activity will be carried out when the master data / transactional data is migrated from the legacy systems to the new S/4 HANA system.
Advantages:
- UoM's and conversions are standardised across all the master data objects and business processes
- No additional effort / customisations required to enable the standard SAP functionality
- Uniform and Simplified reporting as the UoM's and conversion factors are standardised
- Standard integrations without any additional data mappings with other modules of SAP, SAAS systems and any other 3rd party applications
Disadvantages:
- One time data conversion effort to map the master and transactional data with standard UoM
- One time data conversion / mapping of the non-standard UoM's in the downstream systems
- Business processes that require creation of the non-standard UoM needs to be remediated
Option 2: Allow the use of non-standard UoM's
As a part of this option, the existing As-Is active non-standard UoM's are migrated to the new S/4 Hana system.
Advantages:
- UoM Problems that are already solved / mapped do not re-occur
- No issue with legacy data that use custom UoMs (if any)
- No impact on suppliers/customers that submit non standard UoMs
Disadvantages:
- The existing processes can continue without any changes
- No data migration/mapping effort except when there is de-duplication of master data
Disadvantages:
- No standardisation of the UoM's across master and transactional data
- Complex governance process to govern the non-standard UoM's and the conversion factors
- User errors due to confusion and unfamiliarity of the non-standard UoM's
- Customisations and data mappings required for integrations to any SAAS or 3rd party applications
- Not all standard functionalities will be able to support the non-standard UoM's
- Potential incorrect reporting and aggregations
- Need to replicate custom UoMs across landscape
- Maintenance burden as custom UoMs will need to be supported and .
- Any pre-existing issues (e.g. in reports due to unexpected UoMs) will also re-occur (if we dont correct the data)
- May have an impact on other standard tools or integrations
- Need to develop a process to transfer UoMs
- Risk of conflicts with standard UoMs and future upgrades or integrations with other systems.
- Potential confusion due to unexpected downstream use of non-standard UoMs
- Need to review data to see which UoMs are actually in use to avoid taking over defunct ones
Evaluation
Based on the evaluation of the solution options, it is recommended that the "Use only SAP Standard" approach is used as a starting position.Option 1: Use SAP / ISO Standard UoM's and conversions is recommended. This follows the Simplification/Standardisation approach of the project and minimises any maintenance burden going forward.We can react to any UoM exceptions that cannot be switched to Standard
| Criteria | Option 1: Use SAP / ISO |
|---|
Impact on 3rd Parties
Suppliers and Customers should not be using non standard ISO Codes going forward and should be pushed to stop doing so
Impact on Legacy Data
Need to see how many custom UoMs are used in the legacy data and take action (remap etc) where needed.
Option 1: Use only SAP Standard UoMs, do not copy over any custom UoMs
Option 2: Carry over any active custom UoMs from As Is
Only Std Used
standard and custom UoMs used
Suppliers/Customers need to correct to SAP Std or cant use them
Standard UoM's and conversions | Option 2: Allow the use of non-standard UoM's | |
|---|---|---|
| Alignment with project charter - Standardization and Simplification |
|
|
| Integration |
| |
| Data Migration |
| |
| Reporting |
|
|
Need to map non Std UoMs to Std on legacy data
no enhancement required
any supplier already fixed by custom UoM will break
Std only - no impact
Benchmark comparison
The project team have worked on other implementation projects where 700+ custom UoMs were successfully converted to ISO standards without any exceptions, so an approach to align to standard seems feasible.
Data from other standardisation projects shows that typically non-standard UoM usage occurs for one of 3 reasons:
See also
| Attachments | ||||
|---|---|---|---|---|
|
Change log
| Change History | ||
|---|---|---|
|
Workflow history
| Workflow Report | ||||||
|---|---|---|---|---|---|---|
|