Akeneo PIM for Projects of Any Size: A Guide to Data Structures

A teacher once imprinted on me that organization is the key to success. When applied to e-commerce, I appreciate the organization inherent in product information management (PIM) systems which help companies small and large become more successful (or at least more organized!).

When considering how to implement a PIM, there are several things to consider:

• Where is business being done? Will it expand?
• How diverse are current product offerings?
• What distinguishes the products from each other?
• What is considered a necessary piece of information for a particular product?
• What is considered necessary for a group of products?
• How many users and what kind of use?
• What are common setbacks in current use patterns?
• What can be simplified when logging any product information?
• How big is this project expected to be now? In the future?

EXAMPLE CUSTOMER BACKSTORY

For an example scenario, let us consider the fictional organization Demeter Farmer’s Co-Op.

A farming co-op is like a farmer’s market but setup within a single store where sellers can come together to offer goods to local shoppers. Demeter operates in a single state with customers in three of the state’s counties.

Twenty-five people staff the Demeter store. Five are fulltime employees with one Supply Manager and the rest are volunteers who help categorize, sell, and distribute the goods. Suppliers are also present, busily updating their products week-to-week. Of those products, several have unique qualities that need to be noted for both customers and Demeter staff–both require organized, logical and up-to-date product information at Demeter.

The current inventory and product information system lives on a homemade conglomerate of excel spreadsheets and a simple web store with an older database. Staff and volunteers update inventory weekly upon receipt to prepare for the web store. Customers make orders once a week after the product inventory is available.

The co-op inventory consists of produce, dairy, meat, health products, pet products, gardening seeds, ready-to-eat foods, baked goods, and beverages. Each of those product groups has different characteristics that need to be accounted for in the PIM. Some groups share those traits. For example, each product having a name, SKU, and description. Others, however, may have dissimilar traits such as storage procedures which do not apply to gardening seeds but are a must for perishables.

In short, all information needs classification. On a granular level, the information will need to define itself–some fields are required while others are optional and need more information to be considered complete. Most importantly, the PIM system needs to be easy enough to use so that Demeter staff can classify things as they would envision them on a physical shelf (or even a digital storefront).

While the co-op has done well thus far, the increasing number products and customers is indicating that they are outgrowing their current system. The current system is difficult to understand for non-technical users and error-prone requiring many technical overrides. Demeter is hoping to remedy this by introducing an Akeneo PIM so they can enjoy an easier to use system without advanced technical knowledge and ensure data integrity with minimal maintenance. They hope to keep their products and vendors better organized as business grows.

Based on what we know thus far, we will evaluate the best fit solution using the number of products Demeter currently sells and the estimated number of system users. We will also evaluate whether Akeneo Community Edition or Enterprise Edition is better suited to their needs.

Let us look at the data types within Akeneo and how that will drive the solution.

AKENEO DATA STRUCTURES

Channel

The first thing we need to do is establish the channels. Understood informally as the “where” of the project, the official Akeneo definition of a channel can be found here. A channel refers to where business is done so that things like currency, locale, language, and categories are setup logically.

Since the co-op is in the U.S. in a single state, the channel can be set to use U.S. English as the locale, the Imperial system for measurements, and U.S. dollar as the currency. If Demeter were to expand into other regions, such as Canada, then we can add Canadian English to address any spelling changes, Canadian dollars for the currency, and likewise metric measurements and French language. Channel automatically converts imperial measurements into metric which makes it a powerful tool for assuring products are represented with accurate information.

One final item to note is that the channel is linked to only one category tree and determines completeness for each product.

Attributes

One of the core activities of any Akeneo project is the collection of attributes that are key to defining groups of products. You need attributes to build control structures in Akeneo which establish what a product is and what a product is not.

An attribute is data that describes something, such as a SKU or quantity of a product, or a vendor’s name. There are 17 attribute types within Akeneo. You can learn more about the attribute types here.

Attributes are data type driven, localizable, and can include other parameters such as being required or allowing decimals or negative numbers for numeric types. When setting up the PIM, we will have to examine how the data can translate or display so that it is logical and intuitive to someone using the system.

At Demeter Farmer’s Co-Op, each product has the following traits:

• SKU
• Description
• Perishable
• Vendor
• Price
• Discount Price
• Quantity
• Product Type
• Expiration Date
• Sell by Date
• Received Date
• Pickup or Delivery Date
• Weight
• Size
• Storage Procedures
• Age Limit
• Possible allergens
• Special certifications (such as pasture-raised for meats)

Since the co-op operates in a small area, the PIM only needs one locale and one currency. Now if we transpose the above traits to Akeneo attributes, here is how it might look:

Families

The next item to consider is families. Families determine how attributes are grouped in Akeneo. Using families is best practice in Akeneo–classifying products by what makes them unique. The official Akeneo definition further explains that families are like a product template. The product template helps determine whether a product is complete or incomplete.

For example, the family “produce” will have all the attributes listed above excluding size. If a product is missing a piece of required information, such as weight for a produce item, the product will be incomplete until that attribute is accounted for.

Categories

Similar to families, categories are another method to classify products. Categories are different from families because categories are independent of attributes. In other words, you do not need to define any attributes to make a category.

Interestingly, you may employ families as a way to begin assembling your categories. For example, we can use the produce family as a branch and then split that branch to have fruits and vegetables, then make smaller branches such as berries, citrus, and stone fruits under the fruits category. Remember, there can only be one category tree per channel.

Reference Entities

The next data type is reference entities which have a one-to-many relationship with products.

In a PIM, a one-to-many relationship refers to one record being associated with one or more records in another table. For example, a vendor-product relationship is a one-to-many relationship. One of Demeter’s vendors, Paradise Citrus Company, provides Demeter with citrus fruits, juices, and essential oils, so vendors are a good candidate for a reference entity because many products come from a single vendor who has their own traits such as the name, address, and phone number for the vendor which live independently of the product itself, yet is necessary information tied to the vendor.

Reference entities can also have a many-to-many relationship as mentioned earlier. Some products can have more than one vendor in a PIM, for example, so there can be multiple links. In Demeter, citrus fruits and juices can be provided by not only Paradise, but also from four other suppliers.

Another reference entity example includes discounts. If there was a holiday special on certain products such as essential oils, it would apply to several products. It also has characteristics of its own that are necessary knowledge such as the dates for how long the discounts apply. Great for larger projects, reference entities come built into Akeneo.

The reference entity relies on the relationship to products. This is accomplished through the reference entity link attribute type as the PIM gets set up. A reference entity link is a distinctive feature of EE. That attribute takes a value straight from a table which has a piece of information tied to a product, yet some possess information that live independent of the product data.

Here is an example of how Demeter’s discounts reference entity functions:

• Discount Name = text attribute, required
• Discount Start Date = date attribute, required
• Discount End Date = date attribute, required
• Discount percentage = number attribute, required with positive, non-decimal numbers only
• Resulting price = number, required with decimal numbers allowed and only positive values
• Discount type = single select, required. This can be something like “Holiday Special”, “End of Season” as options.

These can be linked to products easily in the interface once development work is complete.

Reference Data

Suitable for large and small projects alike, reference data is included in Akeneo Community Edition.

For our example, we can setup vendor to have the necessary attributes of:

• Name, a text field required for all
• Address, another text field required
• Phone Number, another required text field
• Website, a text field but not required
• Email, another text field that’s required
• Contact person a required text field
• Contact person email, a required text field
• Contact person phone number, a required text field
• Vendor type, such as a dairy farm or artisan bakery which can be a single select for Dairy, Produce, Health Goods, Meats, etc.

Custom development work is needed for this to work properly but as you can see the data can still retain its full meaning in each attribute.

If reference data needs to be changed to reference entities later on in a project, such as migrating to Enterprise Edition, that is also possible.

Assets

Included in Enterprise Edition, assets give you the ability to store unique files or information for each product such as instructions, images, or links to YouTube videos. Separate from images, assets are a special data type and are not required. Furthermore, assets need to be linked to specific products and defined on a family-by-family basis.

CASE STUDY PROCESS: HOW DOES ALL THIS FIT?

For our case study, we can present all this information to Demeter. First, with the ability to set certain attributes as required and accept that data only when properly formatted, the co-op’s need for data integrity is met. Categories enable the volunteer users to classify products in the online store without needing technical knowledge while employees can operate within a simple workflow–enter a product SKU, assign to a family, and update as needed. Finally, the interface allows the manager to audit the products regularly.

Since they are a small co-op for now with basic data needs, Demeter is best suited for Akeneo Community Edition but they see themselves growing in the future and possibly evolving into Enterprise Edition since their customers, users, and vendors are showing measurable growth each quarter.

Demeter will be using the reference data type for their vendor and discounts data. In place of assets, they will use the image data types for anything needing pictures until they are ready to upgrade to Enterprise Edition. Moreover, there are other farms and suppliers wanting to provide more goods in new counties so Demeter may have to take advantage of reference entities in the not-too-distant future. Some products, such as ready-made dishes, have preparation instructions and images which assets will keep organized as operations expand.

There are several things to consider when it appropriate to upgrade to Enterprise Edition:

• Are the products increasing in diversity? If so, more attributes will be used in Akeneo and more families will result as the catalog expands.
• Is there greater complexity in the data? As more vendors join, it may be time to consider using Enterprise Edition because the reference entity is a built-in method for handling complexity.
• Are the products getting more detailed supplementary information? This is where assets can increase efficiency particularly since the assets have a simple interface for users to accomplish tasks quickly.

Closing Remarks

In this look at Demeter co-op, we’ve illustrated that an Akeneo PIM can fit projects of any size and is indeed scalable. Ease of use is an advantage with Akeneo because a simple workflow is helpful for every user. Data integrity is also critical–ensuring everything in the PIM can be trusted or easily and quickly corrected.

It is a snap to use Akeneo to get organized, even if you are not Marie Kondo. Sitation provides expertise in all these areas for Akeneo projects and can implement and develop a PIM that will check all the boxes.