There are some good and some questionable practices when users are deciding how to build an enterprise and asset structure. In my blog posts series "Lessons learned from EAM Enterprise Structure and Master Data", I am documenting some of those.
I hope that a reader who is just starting in their SAP journey can avoid mistakes from the past, and the experienced reader can enhance the post so that we can all learn from each other.
In this post, I will talk specifically about functional locations and common mistakes that users make while building a FLOC hierarchy.
To ensure that the reader has a good understanding of what the functional location hierarchy is, let's start with some standard SAP definitions
Here is SAP's standard definition of a functional location:
You can read the rest of SAP's definition here
The SAP definition is a good starting point, but doesn't provide a sense of what the value behind a FLOC hierarchy is.
In my opinion, FLOCs provide value to the end user in three different ways:
This is useful when creating notifications, orders and maintenance items. Even if you have a different method for finding equipment records, it is always useful to navigate the hierarchy.
Most of the things that you can do with an equipment record, you can do with a functional location. Here are some examples:
There are some obvious things that you can't do on a functional location like uninstalling or serializing it.
Small piping systems are a good example of how a functional location can represent a full system. Here is why:
In my experience, this is the most valuable aspect of a well created functional location hierarchy. If you structure your FLOCs correctly, you will be able to easily group orders and notifications using list reports.
Your cost structure should not dictate how you structure your hierarchy. You should structure your hierarchy in a way in which it makes sense from a technical respective.
I have seen users try to create highly complex and unnecessary cost center hierarchies because they didn't structure their FLOC hierarchy correctly. I have also seen cases in which individual maintenance plants are created, when only functional location hierarchies were needed.
See the functional location hierarchy below
To get all open orders for all equipment records and/or functional locations under DEC01,all I have to do is go to IW38 and enter DEC01* in the Functional Location field. This will bring a list of all open orders for all FLOCS which start with DEC01.
Personally, I've tried using the standard PMIS reports and I just found them quite limited, they're largely ignored by my business users too. I'm always better off creating a report in either Excel or a Dashboard in MS Power BI to analyze PM data. With some good MS Power BI skills, you can create great dashboards using your hierarchy to clearly show maintenance metrics per each different level of the hierarchy.
1) Your FLOCs might or might not represent a physical space.
The FLOC hierarchy is a technical view of your assets. It might or might not completely match where the assets are physically installed.
Some users think "The plant has three floors. I want to have one FLOC per floor and install the equipment there. (....) Functional Locations are like "holes in the ground". This is a common mistake for users who are unfamiliar with the FLOC concept.
Pay attention to the three criteria which the SAP definition is using to describe how to structure the functional locations. The definition talks about functional criteria, process-related criteria and spatial criteria.
Some SAP users hear the phrase "the place at which a maintenance task is to be performed" and immediately think that a FLOC needs to have a direct relationship with a physical space; it does not.
2) Use all of your edit mask
When you're done building your hierarchy you might think "this is done". However, hierarchies might change over time, which means that you must set up your edit mask and labels in a way which allows new users to make changes if necessary.
If you create your floc labels so that the full edit mask is used even at the last level, you could expand your hierarchy in the future while keeping your FLOCS consistent.
3) Keep your FLOCS consistent
Always try your best to keep your FLOCS consistent in your hierarchy. Avoid having situations in which your hierarchy breaks.
Here is an example of what I consider a "broken" hierarchy
If you run IW28 using the top level FLOC and a wildcard (ROK*) you will never see any information for Flocs WND-001 and WND-002.
Fixing this issue using alternative labeling might be feasible, but you might run into some issues down the road if you keep two different labels. Read more about alternative labeling here
Keep in mind that SAP allows you to structure your hierarchy however you want, even if the edit masks have nothing in common with each other, or if you're using a different structure indicator. However just because you can, it doesn't mean that you should.
4) Make your labels descriptive, but make sure they won't have to change.
You can change your FLOC description any time, but you can't change the label unless alternative labeling is implemented. In my personal opinion, it's better if you do not need to activate it.
Here is a real life example of how making labels that are overly descriptive can backfire:
We installed some of our equipment on large buildings which do not belong to us. Someone decided to use the name of the building in the FLOC label. We had equipment installed on a Sears store, so the functional location label for some equipment was NTWK-SEARS.
Sears went bankrupt, the building was sold and got a new name. My technicians got confused when looking at that functional location hierarchy and really wanted it fixed. To fix it, I had to:
By doing this I ended up having two functional location hierarchies representing the same system, so the maintenance history was not consistent.
5) Keep your hierarchy simple by mapping only the assets that you need.
Some users believe that all assets need to be mapped and want to create either equipment records and/or FLOCS to represent them. Here are some of the issues I've seen from allowing too many assets to exist in SAP
I've seen FLOCS created for paint, lawns, sprinklers, driveways, fences, and etc .. with either 0 or 2 notifications or orders created in more than 20 years!
In summary,
What's your experience with FLOC hierarchies? Do you agree with the statements above? Is there something that you would like to add? Please add a comment to the post.
Do you have a specific question about FLOCs? Submit a question on the SAP community.
Thanks for reading!
I hope that a reader who is just starting in their SAP journey can avoid mistakes from the past, and the experienced reader can enhance the post so that we can all learn from each other.
In this post, I will talk specifically about functional locations and common mistakes that users make while building a FLOC hierarchy.
To ensure that the reader has a good understanding of what the functional location hierarchy is, let's start with some standard SAP definitions
Functional Location concept
Here is SAP's standard definition of a functional location:
The business object functional location is an organizational unit within Logistics, that structures the maintenance objects of a company according to functional, process-related or spatial criteria. A functional location represents the place at which a maintenance task is to be performed.
A functional location represents system area at which an object can be installed. Objects that can be installed at functional locations are called pieces of equipment in the SAP System.
You can structure functional locations according to the following criteria: Functional Criteria, Process-related criteria, Spatial Criteria.
You can read the rest of SAP's definition here
The value of a good Functional Location Hierarchy
The SAP definition is a good starting point, but doesn't provide a sense of what the value behind a FLOC hierarchy is.
In my opinion, FLOCs provide value to the end user in three different ways:
1. FLOCS help users find the correct technical object that they need in SAP.
This is useful when creating notifications, orders and maintenance items. Even if you have a different method for finding equipment records, it is always useful to navigate the hierarchy.
2. FLOCS can represent a group of assets or a unique system when equipment records are not needed, or can't be created.
Most of the things that you can do with an equipment record, you can do with a functional location. Here are some examples:
- Write notifications / PM Orders
- Save master data values
- Create classes & characteristics
- Use it in your maintenance plans
- Activate / Deactivate / Flag for deletion
- Use catalogs and codes
There are some obvious things that you can't do on a functional location like uninstalling or serializing it.
Small piping systems are a good example of how a functional location can represent a full system. Here is why:
- Unless you're using linear assets, you might not know precise information about each segment of the system.
- You probably don't care about tracking maintenance to each individual valve in your piping system either.
- You might want to know how many man hours and dollars you spend maintaining it.
- Users might need to report malfunctions on it
- You might need to create maintenance items for it
- You might need to run maintenance reports for compliance reasons
3. FLOCS provide the maintenance teams with technical driven reporting.
In my experience, this is the most valuable aspect of a well created functional location hierarchy. If you structure your FLOCs correctly, you will be able to easily group orders and notifications using list reports.
Your cost structure should not dictate how you structure your hierarchy. You should structure your hierarchy in a way in which it makes sense from a technical respective.
I have seen users try to create highly complex and unnecessary cost center hierarchies because they didn't structure their FLOC hierarchy correctly. I have also seen cases in which individual maintenance plants are created, when only functional location hierarchies were needed.
Quick example of how to use the hierarchy
See the functional location hierarchy below
To get all open orders for all equipment records and/or functional locations under DEC01,all I have to do is go to IW38 and enter DEC01* in the Functional Location field. This will bring a list of all open orders for all FLOCS which start with DEC01.
Personally, I've tried using the standard PMIS reports and I just found them quite limited, they're largely ignored by my business users too. I'm always better off creating a report in either Excel or a Dashboard in MS Power BI to analyze PM data. With some good MS Power BI skills, you can create great dashboards using your hierarchy to clearly show maintenance metrics per each different level of the hierarchy.
Common errors while creating a FLOC hierarchy and how to avoid them
1) Your FLOCs might or might not represent a physical space.
The FLOC hierarchy is a technical view of your assets. It might or might not completely match where the assets are physically installed.
Some users think "The plant has three floors. I want to have one FLOC per floor and install the equipment there. (....) Functional Locations are like "holes in the ground". This is a common mistake for users who are unfamiliar with the FLOC concept.
Pay attention to the three criteria which the SAP definition is using to describe how to structure the functional locations. The definition talks about functional criteria, process-related criteria and spatial criteria.
Some SAP users hear the phrase "the place at which a maintenance task is to be performed" and immediately think that a FLOC needs to have a direct relationship with a physical space; it does not.
2) Use all of your edit mask
When you're done building your hierarchy you might think "this is done". However, hierarchies might change over time, which means that you must set up your edit mask and labels in a way which allows new users to make changes if necessary.
If you create your floc labels so that the full edit mask is used even at the last level, you could expand your hierarchy in the future while keeping your FLOCS consistent.
3) Keep your FLOCS consistent
Always try your best to keep your FLOCS consistent in your hierarchy. Avoid having situations in which your hierarchy breaks.
Here is an example of what I consider a "broken" hierarchy
If you run IW28 using the top level FLOC and a wildcard (ROK*) you will never see any information for Flocs WND-001 and WND-002.
Fixing this issue using alternative labeling might be feasible, but you might run into some issues down the road if you keep two different labels. Read more about alternative labeling here
Keep in mind that SAP allows you to structure your hierarchy however you want, even if the edit masks have nothing in common with each other, or if you're using a different structure indicator. However just because you can, it doesn't mean that you should.
4) Make your labels descriptive, but make sure they won't have to change.
You can change your FLOC description any time, but you can't change the label unless alternative labeling is implemented. In my personal opinion, it's better if you do not need to activate it.
Here is a real life example of how making labels that are overly descriptive can backfire:
We installed some of our equipment on large buildings which do not belong to us. Someone decided to use the name of the building in the FLOC label. We had equipment installed on a Sears store, so the functional location label for some equipment was NTWK-SEARS.
Sears went bankrupt, the building was sold and got a new name. My technicians got confused when looking at that functional location hierarchy and really wanted it fixed. To fix it, I had to:
- Create new FLOCS
- Move equipment records to those new FLOCS
- Identify and modify all maintenance items, open orders and notifications assigned to the old FLOCS.
By doing this I ended up having two functional location hierarchies representing the same system, so the maintenance history was not consistent.
5) Keep your hierarchy simple by mapping only the assets that you need.
Some users believe that all assets need to be mapped and want to create either equipment records and/or FLOCS to represent them. Here are some of the issues I've seen from allowing too many assets to exist in SAP
- The hierarchy ends up having more levels than necessary or has plenty of FLOCS in the same level. This makes the hierarchy hard to navigate and understand.
- The technicians create notifications and orders, but after a while it becomes harder and harder for them to find the functional location or equipment record that they want use.
- Eventually technicians and planners stop trying to find the right equipment and just create notifications and order against upper level functional locations, so that they can get their job done.
- Management complains that the SAP reports don't work because they can't see notifications and orders at a granular level.
- Eventually, someone just decides that there is no value in tracking work in SAP and having individual orders, and they decide to enter time against "bucket" maintenance orders, or cost centers.
I've seen FLOCS created for paint, lawns, sprinklers, driveways, fences, and etc .. with either 0 or 2 notifications or orders created in more than 20 years!
In summary,
A consistent and simple FLOC hierarchy which is understood by your maintenance team can provide meaningful maintenance reporting, reduce the number of cost centers that are used, and provide your technicians with an easy way to find the assets that they need to create notifications for.
What's your experience with FLOC hierarchies? Do you agree with the statements above? Is there something that you would like to add? Please add a comment to the post.
Do you have a specific question about FLOCs? Submit a question on the SAP community.
Thanks for reading!
- SAP Managed Tags:
4 Comments
