Taking apart a floorplan in Blue Yonder Floor Planning: the object hierarchy

Blue Yonder Floor Planning is powerful software that aids in merchandising management for entire stores, otherwise known as “macro space”. The floorplans in Floor Planning often work hand-in-hand with planograms in Space Planning to allow merchandisers to control every aspect of store layout from individual products on shelves all the way to how the entire building appears.

Floor Planning has a huge amount of flexibility to support any merchandising scenario. With this power comes some necessary complexity, which can be daunting at first glance. Between the information necessary to visually represent a store, KPIs and other custom data, there are well over 1,000 distinct kinds of information that makes up a floorplan in Floor Planning.

By the end of this article, you’ll know how data is structured in floorplans so that you can use it better in your merchandising and analytics.

How the hierarchy works

Each different kind of information is stored in a field. For example, a floorplan’s name is stored in a field called, fittingly, “Name”. These fields are then organized into objects. Each object represents either a physical component of a floorplan (for example: shelf fixturing), or a concept that connects two components (for example: various metrics on how well a planogram’s assortment is selling on a specific floorplan.) To keep track of how objects relate to each other, they are organized into a hierarchy.

In this article we’ll work through this hierarchy one step at a time by starting at the top and delving down from there. As we go, we’ll illustrate the relationships between objects by drawing lines between them.

When two objects are related, the higher object is the parent of the lower object. For example, a floorplan object is a parent of the fixture object. The parent-child relationship here is one-to-many: one parent can have multiple children, but a child can only have one parent. For example, a floorplan object can have multiple child fixture objects, but a fixture object can have only one parent floorplan object.

To begin, let’s start with what you first see when opening a floorplan in Floor Planning. A window displays with a top-down view of a floorplan. If you open multiple floorplans at once, the window will have several tabs at the top, with one tab per floorplan. No matter how many floorplans are in the window, the window represents the very top-level concept in Floor Planning’s object hierarchy: the project.

Project

The project object holds data that is shared among all the floorplans you have open in the same window. Settings for textures, models and layouts, whether to use inches or centimeters, and other custom pieces of information are stored in this object.

When saving a floorplan to a .PFA file, a file will contain everything within a single project object. When using floorplans in CKB, the project object is optional and may not have data present in all fields.

Digging into the project

Floorplan

A project contains one or more floorplans. These are exactly as you expect–virtual representations of how a store’s merchandising is laid out. A specific name, dimensions, texture and color, the time period the floorplan is in use at the store, aggregations of KPIs from components within a floorplan, and more are stored at this level.

Planogram

A project also contains one or more planograms. These are also exactly as you expect–physical representations of a way a category could be merchandised at a store.

Planograms in Floor Planning can serve as a direct link to the same planograms used in Space Planning. When working with floorplans in flat PFA files, planograms can be linked to a flat PSA file. When working with floorplans in CKB, planograms are automatically linked to the corresponding planogram in CKB with the same DBKey.

Because of this linking capability, information about planogram objects is shared among all floorplans in the project. For example, the Height field in the planogram object will be the same value in all places the planogram is used in the project, and indeed changing a planogram’s height when looking at it in one floorplan in a project will change it in every other floorplan for that project. Further, changing a planogram’s height when working in CKB will also change it for the planogram when viewed in Space Planning. Care needs to be taken when altering planogram values to avoid cascading mistakes.

Combining floorplan and planogram data

Keeping planogram dimensions in one place seems to make sense, but a planogram object may also have KPIs that could vary from floorplan to floorplan, such as total sales volume. So how do you have floorplan-specific data for a planogram? This is where the performance object comes in.

Performance

A performance is the combination of a floorplan and a planogram. Data in this object applies to a specific planogram on a specific floorplan. The values at the performance object level will be unique for each planogram/floorplan combination, and changes will not affect other floorplan or planogram objects.

Inside the floorplan

Department

A department is a way of dividing a floorplan into smaller areas, which can help with arranging fixturing as well as organizing categories of planograms that share an overarching purpose or placement (e.g., frozen foods, baked goods, baby needs, etc.)

Fixture

A fixture is a physical object that represents the permanent fixturing used for merchandising in the store. Things like aisle gondolas, tables, endcaps and cases. Fixtures can also be created to identify unmerchandisable blockages in a store, such as building support columns. Most of the fields here involve what the fixture should look like and if/how planograms can be merchandised on it.

Fixtures can be attached to a department, so they also have a link to department.

Drawing

A drawing is a visual aid added to the planogram that is not meant to be physically present in the actual store. Things like notes, lines and shapes can be placed to add supplemental details and context to a floorplan. Fields are focused on the appearance of the drawing and what text it contains.

Drawings can be attached to a department, so they also have a link to department.

Things on the shelf

Section

A section is the actual placement of a planogram (or a portion of a planogram) on a floorplan. Most of the fields here involve how the planogram should be merchandised, such as orientation, size, and what portion of the planogram is represented.

Because sections are also a combination of a planogram and floorplan, they have a link to performance.

Segment

A segment tells how a planogram can be broken up into smaller portions. This allows a single planogram to be merchandised as multiple sections on a floorplan. The size of the segment and aggregations of KPIs from components within the segment are stored here.

Note that the segment object is only linked to the planogram object. This means that modifying a segment in a planogram will modify that segment for all uses of that planogram.

A way to understand the difference between a segment and a section is that a segment says how a planogram can be broken into pieces, and a section says which of those pieces are being used in a specific spot.

Data Point

A data point is a measure used by Floorplan Generator. Each data point specifies an alternative size for a planogram that can be used on a floorplan along with a number representing the associated value for that size. The exact value you wish to use is up to you to decide—it could be profit, sales volume, or any other space productivity metric. These values are used by Floorplan Generator to make decisions on which size of planogram should be placed on a floorplan such that the overall value across all the planograms placed is maximized.

A data point is always specific to a floorplan and planogram combination, so it is linked to the performance object.

Less common things, but they’re there!

These objects are also seen across Floor Planning’s interface but are used less often.

Configuration

The Configuration object is the single highest object of the hierarchy. It represents the Floor Planning application itself and actually sits above the project object. Options that you can find under File > Settings > Settings in Floor Planning are stored here.

OLE Embedded Object

OLE Embedded Object is mostly present for compatibility with older versions of Floor Planning. It exists to allow you to embed documents from other applications like Word or Excel into a planogram. Seems pretty cool, but Cantactix recommends against this practice. Embedded documents can be tricky to work with and can really bloat the size of a floorplan, negatively affecting performance. This functionality is also specific to Windows operating systems, so it does not support embedding documents from things such as Office 365.

Pulling it all together

Knowing how objects are related in the object hierarchy makes it much easier for you to prepare, merchandise and analyze floorplans. When you have floorplan-specific planogram metrics you need to load into the floorplan, you now know that loading to the performance object is the right place. If you need to find out where a planogram is placed and what portion of it is there, the section object is your go-to. If you need to know how long of a run of coolers and freezers you have, the fixture object holds that information. Lastly, you’ll now understand those terms as they appear in Floor Planning’s interface!

If you found this article useful, you should check out our overview of the Space Planning object hierarchy!