As customer interactions are rapidly moving to the digital channels, organizations need to address the inefficiencies in their content production processes. Shooting from the hip just won't cut it anymore, not even in the creative department. You have to have a disciplined approach to get the right product content produced and distributed to the right channels at the right time. Creating and distributing more content faster cannot be done efficiently using a brute-force approach or by simply adding more people. Instead, it needs to be done by working smarter rather than harder—and finding system support to help you achieve efficiency in your content production processes.
Does your organization require a solution for PIM, DAM, or both?
In their search for a solution that can help them to achieve the required efficiency, many organizations ask themselves if they need a solution to manage their product information (PIM) or one that manages their digital assets (DAM). There are some questions that we need to answer before we can decide that:
Products typically need to be described and augmented using numerous different types of information, such as specifications, USPs, descriptions, documents, up-sells, cross-sells, and much more. This information must be of high quality, be granular, and be very structured. Depending on the industry and product type it also needs to be a part of an ecosystem—for example, as a part of a bundle, solution, repair kit, look, or room. To have a complete and compelling product story it also requires an ever-increasing number of digital assets, from 360 spins and how-to-videos to regular static photos.
We can conclude that we must be able to manage product data and product-related digital assets at the same time. Thus, we cannot choose between PIM and DAM as we need both to support the creation and distribution of a complete and compelling product story. Simply put, a DAM cannot manage the product data and the product ecosystem, so as long as you're not selling images, going with just a DAM to manage your product information will not be sufficient. Do you need two separate solutions? To know that, we need to define more granular requirements.
If you do not manage large volumes of digital assets that are nonproduct-related and choose a PIM solution with strong built-in DAM capabilities, you most likely don't need a separate DAM. The built-in one will be sufficient and already tightly integrated. However, if you do manage large volumes of nonproduct-related digital assets, you should consider adding an enterprise DAM solution and integrate that with your PIM system. The integration with a PIM is necessary as it will drastically reduce the metadata maintenance and automate the distribution of the assets to the channels.
How to manage the selection and review of assets?
WIP, short for Work In Progress, usually represents the first step of the creative workflow, right after or during the photo shoot, but before final delivery to a PIM or a DAM. Sometimes I meet with organizations that believe they need a DAM, when in reality, they are need of a Work In Progress system. A tool that manages the WIP process can be used to streamline review and approval for digital assets and make the selection process easier and faster, so it makes sense that some DAM solutions have this built-in as a feature. Whether you choose to integrate a DAM or use the built-in one in your PIM, adding WIP process support can provide additional efficiency gains.
Whatever you do, don't hamper your sales by shooting from the hip in the content creation process.
Johan Boström, Co-founder and Evangelist, inRiver
I want to start with saying that this post contains a lot of technical and architectural thoughts around software design. This is a subject that I enjoy very much and therefore read a lot about. In this post I am going to give you an insight to how Microservices has help us as an organization but also how it enabled us to be quick and agile.
One important aspect of an organization is commitment and the consequences if you do not have the right commitment. If the implication of an action is hidden too many layers away from the one performing it, it will never create the right sense of urgency and you will never become an efficient organization.
A focus and a goal for any R&D team is to be productive and agile as we all know anything static in this world will go extinct. For us working with information logistics within the realms of marketing, we know everything changes very rapidly and our design needs to be able to do the same without us breaking anything. Our architecture stem from DDD (Domain Driven Design, Eric Evans), which means that we design everything around the business domain, instead of around functions like a database, persistence or other application layers. This for us is a better model for evolving and adding new features. With this mindset of changing often, quick and also moving to a new State-less mode (Cloud). We needed to break our architecture into more decoupled parts, to have less dependencies and not creating a big monolithic architecture, so for us it felt very natural to work with a Microservice model.
If you do not do this, you risk ending up with a big black box (monolith) where all new ideas get stopped because with every change needed/made everything has to be rebuilt from the ground. Even worse is if you build a black box all new ideas must be built by you and it is impossible to scale out and get help from a creative community with new features. This model will ultimately break under its own weight because it cannot be maintained over time (more on this topic….). For us thinking and working with a Microservice Architecture we can be more pragmatic and flexible in choosing where and how we want to add a new feature, because our community with thier great skill-set can solve some of these new feature requests. As our partners can replace a service, with their own built service and alter or extend the behavior of an operation. It will even be possible to implement service end-points where they have the power to build their own new UI on top of our services. For us this is a fantastic thing that the great inRiver community can be more involved in creating business value for our customers. A great example of this is our customer H&M that together with our partner Accenture will be using the Media Driver concept. They are storing all their media assets in a separate DAM (Adobe). For inRiver the assets will look as if they are still stored in inRiver and other services will continue to operate as if they were, this by just changing how our Asset Service is operating.
Two of my great inspirations when it comes to software designs, Martin Fowler from ThoughtWorks, in the same city Chicago as our North American HQ and Jimmy Nilsson from Factor 10, have both written inspirational and insightful pieces on this.
Martin Fowler´s Microservices - great post about what a Microservice Architecture is.
Jimmy Nilsson´s Chunk Cloud Computing - was written back in 2009 but to the point of what we are doing without calling it Microservices.
By adopting this style, our teams also became cross-functional, as everything is focused around a business domain and not a server operation or function. They now have full responsibility from the Database all the way up to the UI. This transfers knowledge in more natural way but also shares responsibility. The teams are responsible for what is actually executed all the way when a user is working with a released feature. We have even taken this one step further with inspiration from the above mentioned articles, with addition from one of my true house gods, Nassim Nicholas Taleb. If you are not careful when building a team, and not making sure everybody has "skin in the game", you will easily create an Agency problem, transferring risks. This they knew better in ancient times than we do now. The Code of Hammurabi is a well-preserved Babylonian law code of ancient Mesopotamia, dating back to about 1754 BC. It is one of the oldest deciphered writings of significant length in the world. One of the laws in this code states that if a house collapses and kills that first born of the family living in the house the first born of the builder must also be killed.
Now we have not taken it to this extremes, we settled with having the support within the R&D team, making sure that you are responsible and feel a sense of urgency all the way. If you are awakened 3:00 AM in the morning due to something you have written, you are more likely to not make the same mistake again because it has a direct impact on you and your sleep (well-being ;)).
One thing I would like to emphasize here at the end, if you are still reading, is that it is all the small decisions and actions made every day by individuals operating within a team that bring this to life and dictates what it is and what it will become – so from words to actions!
So a big thank you to a fantastic inRiver team and a great community!
-- Jimmy Ekbäck, CTO --
Polishing Up Your Products — Why PIM Really Matters
Telling A Consistent And Engaging Product Story Is Imperative
by Peter Sheldon
with Zia Daniell Wigder, Michele Goetz, and Rebecca Katz
summary written by Henrik Béen, CPO inRiver AB
In his latest report, Forrester analyst Peter Sheldon gives his view on “why PIM really matters” and the positive effects it has on Retailer’s sales. Recent Forrester research shows that 71% of all US online shoppers actively research product information online to help them make better purchase considerations. This of course puts pressure on the retailers to provide customers with rich, relevant, and consistent product information in all channels where they what to be present. Forrester concludes:
“For decades, product data has been the lifeblood of many large enterprises. Now, in the age of the customer, eBusiness leaders and marketers are critically reliant not only on their product data, but on curated product content to provide differentiated digital experiences. Key to this objective is telling engaging stories about the products being sold; however, many online retailers, brands and industrial manufacturers lack effective tools to streamline the product content creation process needed to efficiently create high quality, consistent product content. This report explores the role that product information management (PIM) systems have to play in telling compelling and contextual product stories, the primary drivers behind the investment in these systems and the steps necessary to steer clear of the hurdles that all too often derail these programs.”
Peter Sheldon means that PIM (Product Information Management) should be seen as the “gestation engine” where products are fully enriched and where they mature to be marketed and sold. With no proper PIM strategy and without governance and control, it is very likely that you end up having a “product horror story”. In his report he highlights some key benefits from deploying a PIM system in the organization. According to Peter, with a PIM system and process in place these companies can: