Summary
Do you also work on one of those "historically grown" SAP BW Systems?
Are you using the system for several years and keep upgrading from one version to the next. ? Your chances are good, that many things have piled up, that you actually don't do not need anymore!.
Why should you I clean up?
- Because if If it complicates your structure!.
- You stumble across those objects from time to time and you do not know why they are still around.
- or you You actually want at some point to upgrade to SAP BW on HANA or even SAP BW/4HANA.
As memory is precious (and "expensive") you only want to take objects with you, that you actually need.
Errors
No real errors here.
As this these are usually manual tasks take , it takes quite some effort.
In addition, there is always the "fear" to break something , just – just because of your good intentions to cleanup clean up something!
Especially For the actual decision and of course needed analysis , if something can be deleted and does not break anything else, you need a thorough analysis.
Often people plan to do this "later" , when you they have "more time", which unfortunately does not happen, but in real life, the "later" is actually a never, as new topics keep coming and coming!
After a project or change request is before the next of itone.
Cause
Most tasks are manualdone manually.
Many things aspects have to come together be considered for housekeeping activities to work outbe successful.
Identify cleanup candidates, understand dependencies, and understand soft factors/information relevant to those elements and so on.
Solution
With the help of the products of the Docu Performer Suite, we can mitigate minimize your fear of taking a decision and cleaning up your SAP BW systems.
Check out how the Docu Peformer Performer and the System Scout can support you to:
Phase | Activities | How to support them with the Docu Performer | Possible Saving
(on each Activity) |
|---|
Analysis
(System Scout) | - Identify unneeded objects that can be deleted. This also includes the search for inactive DTPs, because the depending process chains would fail (1c).
- Identify Queries that have not been used for a long time.
- When working with reporting objects and not being careful with transports it might happen that you accidentally generate objects with the same technical name but with different GUIDs. This leads to confusion and mistakes.
- As you have identified the objects to be candidates for deletion you need to understand the dependencies from this specific SAP BW Object to nearly all other elements (including ABAP/AMDP).
- Specifically for Queries, you can immediately check the structure of the query to evaluate the dependency and the type of usage (free characteristic vs. selection vs. filter, etc.).
- You want to use consistent Naming Conventions.
- Understand if there are any other implications for the objects you want to delete. In addition, you can preserve your knowledge for later use, changes in team structure, etc. so that colleagues don't have to go through the same process ("We cannot cleanup clean up this object because ...")
- If you don't do not want to use anymore any more queries that are for example having have complex definitions, are for example or input ready, but should be (anymore), then you have to find all those different elements in your system.
- Find ABAP "BreakPoints"/"Select Single"/"..." that could be a problem for SystemLog or Performance or ....
- Understand what is on which system available. Are all Queries/InfoProviders/etc. transported and available in all Systems? All Are all emergency changes from PROD maintained in DEV as well? Can elements be deleted?
| - There are several functions for that:
- List InfoProvider without Usage in Data Flows
- Last Load and Usage Analysis
- Show inactive ObjectsData Loads and Usages
- Inactive Entities
- Unused InfoObjects
- Variables Variable Analyzer
- Use "Grid View" with "Column Chooser" and the column "Last Used Date": Column Chooser
- Show Entities with identical tech. NameRedundant Reporting Elements
- Usage of BW Entities
- Analyze /and Compare Elements/wiki/spaces/DPUM191/pages/437979234
- Naming Conventions
- BW Commenting
- Selections by special Components
- /wiki/spaces/DPUM191/pages/437979286Queries with specific Components
- BW Code Scan
- Mass comparison: /wiki/spaces/DPUM191/pages/437979240 System Comparison. Individual comparison: /wiki/spaces/DPUM191/pages/437979266 Analyze and Compare (can be also triggered form from the mass comparison for individual elements; mass detailed comparison coming soon)
| - 20%-50%
- ~5%
- 5%-15%
- at least 15% depending on how well used later!
- ~5%
- 5%-15%
- ~5%
- 10%-20%
- 10%-15%
- 50%-80%
|
|---|
| Design | If you have a good idea, please let us know how we can support you even more and create a feature-request! |
|
|
|---|
Implementation
(Docu Performer) | While doing all the changes, you can easily add and preserve your results and special knowledge for later use. So when somebody is ill, on vacation or the team changes, everybody knows what to to do and why things happen. So you avoid repeated work and save time and money.
| - BW Commenting
| - 10%-40%
|
|---|
| Testing | If you have a good idea, please let us know how we can support you even more and create a feature-request! |
|
|
|---|
| Deploy | For deployment procedures, e.g. what needs to happen before/after transporting, any special steps needed, etc., have a look to at the documentation... If you have a good idea, please let us know how we can support you even more and create a feature-request! |
|
|
|---|
| Support | See documentation... If you have a good idea in addition, please let us know how we can support you even more and create a feature request! |
|
|
|---|
Documentation
(Docu Performer) | - Just with a little added effort, you can create documentations documentation for different target groups (Functional Department, Audits, IT, etc.) to inform about the different changes that happend happened through the cleanup.
| - BW Documentation especially: Scenarios
| - 10%-40%
|
|---|
