PIM, Part 5: Why “smart” product catalog?
Why do we use the expression “smart” product catalog? We have already given much indication last time. A simple database may describe the offer of a simple e-shop. But for a complex e-shop with a constantly changing offer or even for the description of the products of a bank or a telecommunications operator we need a full-fledged modeling tool. It is no longer enough to just keep a list of the products on offer. It is also necessary to build some reasonable logic over these products. What is even more important is that this logic needs to change in time and adjust to new products and new customer expectations. It is therefore crucial whether such logic has to be programmed by a programmer, or defined by product managers themselves with a few clicks.
Why is it so important that the product logic can be maintained by a product manager without the help of programmers? Three good reasons: price, speed, independence.
- When a product manager must articulate his or her idea in an assignment for a programmer, both of them will spend a lot of time on that. And as everybody knows time is money. If, on the other hand, the product manager and the programmer do not have to write and study the assignment, both of them will be able to spend their time more usefully. The product manager will personally configure, try and test his or her ideas directly in the product catalog, correct any errors, and in a while will be able to present new products to customers. And if it is found out a few weeks later that the product is not as interesting for customers as it should be, the product manager will personally modify the product, change the logic or try something else.
- No company has a team of programmers ready to take an assignment and start working on it right away. Programmers have a job queue of their own, just like anybody else. This means that a product manager’s assignment will wait in the queue for some time. And the change made by the programmer will wait again to be tested by the product manger. And then one has to wait for the programmer to correct the errors. All of these steps considerably increase the time to market – the period from the moment when a product manager comes up with a new awesome product to the moment when such product is finally released to the market and the customers. But the competition does not sleep. And if they come up with the same idea sooner than we do, they will take over our customers.
- When changes in the logic of a system are implemented by a programmer, the company becomes dependent on him. It does not really matter whether one is dependent on an external supplier (vendor-lock) or an in-house programmer with absurd ideas such as a month holiday in South America. On the other hand, if the logic of a product catalog is stored in a configuration which may be managed by product managers themselves, it can easily be changed by any new product manager. Of course, it is important that the configuration is simple, clear and comprehensible. When the configuration of the logic is too complex, one can leave it up to programmers right away.
A simple rule is “Whatever product managers can think of, they should be able to configure”. Product definitions and parameters, as well as price calculations, are attributes defined by product managers, and it should be the product manager who should have the opportunity to input and change these attributes. On the other hand, things like integration with external systems cannot be done by a product manager – it is easier to have programmers deal with it. (Sincere apologies to those product managers who can write poems in JSON and draw XSL transformations on a beer mat 😉)
So let’s look at how product catalog logic can be easily configured. Different PIM systems approach this need in different ways. Many of them basically ignore it and only implement logic that is necessary for basic applications in a simple e-shop. More advanced systems allow for product logic to be configured using parameters or rules. And how exactly does WisePorter provide for this kind of “smartness”?
At the simplest level, it is possible to use the fact that the behavior of WisePorter is to a large degree driven by information contained in the catalog. This may include, for example, code lists or product relationships. Both can be changed by the system administrator – typically a trained product manager. In this way, the administrator may also change the behavior of the system. How is that possible? This is given by the fact that WisePorter is essentially a modeling system. Thus even the basic model (the fact that there is a certain hierarchy of products) can be changed and modified. Or, more often, extended in a suitable manner.
The second, more interesting level of management of product logic is the application of a rule engine. A rule engine is a tool that is able to assess rules. There are several types of rules (formulas, decision matrices, etc.) which may have various forms – e.g. an Excel table. The table has several input fields for the entry of parameters and one or more output fields for the result. And where does the power of such a rule engine lie? In the simplicity of rule descriptions and their assessment during operation.
The simplicity of a rule engine is given by the fact that the rules can really be defined as an Excel table. One does not need to write any program or teach product managers the syntax of any special script language. Almost anybody can create a calculation table in Excel. Look at the example on the attached picture – you will probably agree that after a short explanation even a grandma would be able to make this calculation. Once we have such a table, we can import it into the rule engine and use it in WisePorter for calculations and making operational decisions.
What does this look like in practice? Let’s say we are working on an on-line platform offering mortgages. The client enters the basic parameters: the estimated value of the real estate, the amount of the loan, and the repayment period. From the CRM system, we will get additional information – such as the client’s age and his or her credit rating. All this information constitutes the input for WisePorter. WisePorter searches its database for all mortgage products and finds one calculation rule for each of them. For each mortgage product, it calls the relevant ready-made rule in the rule engine and delivers the input parameters to it. Each rule will give the calculated amount of installments. WisePorter sorts out these results and displays (some of) them to the client.
Nothing special, you say? You are right, there’s really nothing more to it than that. The revolutionary thing is hidden under the surface and has already taken place. The revolutionary thing lies in the fact that this entire process was prepared without a programmer’s intervention. The business team came up with a series of mortgage products. One person created the calculations in Excel for all the products, attached names to these calculations, and uploaded them in the rule engine. Another person entered the products in the catalog and entered the name of the calculation for each of them in the rule engine. Two business persons without a trace of knowledge of programming entered into the system within a few hours a set of mortgage products, which can now be immediately offered to clients. That’s where the revolution happens, because in most banks this process involves an IT design and takes months. Here we have reduced the time to market by two orders of magnitude. And this is the reason why we refer to WisePorter as a smart product catalog and why it stands out among standard PIM systems.
About the WisePorter team:
Karel Krema is responsible in the WisePorter team for the product model. He describes his work as follows: “Every day I learn from practice how to reflect the data from the processes of our clients as accurately as possible in a data model. A well-prepared data model is one of the major key success factors; everything depends on it. It has to be designed well from the very start when many requirements are still unknown. Because it is very difficult to change later. Modeling must describe reality as faithfully as possible. The resultant product is then easy to work with and intuitive for users. Only a model which is based on well-understood business principles will withstand future changes and new requirements without causing troubles.”
