Performance
We did an apples to apples comparison with the leading Gartner magic quadrant CPQ vendor and the results were clear: Veloce engine performed 20x plus faster per click on the same exact data. If you have a performance problem with your current CPQ or would like to give it a boost, Veloce can provide a much faster user experience. Veloce is much faster per click and on top of that we reduce the number of clicks required to get to a solution. That’s because our intelligent solver resolves what normally takes many user interactions in traditional CPQ systems into a single click. Think of it as a compression of the CPQ process with a 20:1 ratio. That’s what we can do.
How are we able to provide such fast performance?
First, the way we model your products is concise, abstract and primarily constraint-based. This streamlines how our configurator operates for any given user request versus other rules-based technologies. Our configurator doesn’t have to traverse nearly as many data structures as a traditional rules-based engine has to. And, by the way, the unfortunate truth is that CPQ vendors abuse the term ‘constraint’, terribly.
Secondly, our solver technology – which includes a goal-specific optimization engine – reduces the number of user clicks dramatically.
Third, our configurator offers different modes of interaction with different computational/time lag costs. So depending on the computational needs of your application, we can optimize which mode is invoked for each user request. For example, a simple rules validation requires much less effort from the engine than solving for a 20,000 line BOM for a network of data center racks. We only apply just enough effort to get the job done.
Fourth, our core configuration solving algorithm is designed to be super efficient. That part is our secret sauce so don’t ask how we do it. We are just letting you know of its existence so you know how and why we are superior to other CPQ technologies.
Final reason, as a stateless cloud-based microservice, we scale extremely well under multiuser loads and we never run out of compute resources while running on self-scaling clouds like Google Cloud Platform.
Personalization
Veloce has a UI Design Tool that allows your UI/UX team to pick from a set of templates that they can customize through an intuitive drag and drop interface.
Our UI Designer also allows you to enhance your UI template with standard web technologies: HTML, CSS, JS, and even AngularJs to achieve any UI your team can imagine.
Multiple Channels
With Veloce, you can create an unlimited number of UIs for a single product model. So you can tailor user experience depending on your users. In effect, Veloce supports a true omnichannel solution.
Historically, CPQ systems have not been suitable for eCommerce due to performance, scalability, and user experience limitations. Veloce is ideally suited to break this tradition since we have solved all three of those problems. With our UI Designer you can create a consumer-grade UI along with consumer-grade performance to meet the challenges of eCommerce.
This combination of speed and beauty Veloce offers is unique in the world of CPQ.
Easy CPQ Maintenance
You may be familiar with this scenario. You just spent 6-12 months developing your CPQ solution on top of your vendor’s CPQ platform. You are in your first release and surprised it took this long but relieved it’s finally out the door and available to your users. Now, without mentioning the myriad issues you are having with performance, functionality and adoption, you find there is another problem you did not anticipate: the system is rigid and fragile making it difficult to update or add new products. You were sold on the beautiful concept of “clicks not code” thinking how this will be easy. The reality, however, couldn’t be more different.
At Veloce we’ve met with companies who are running top tier Gartner magic quadrant CPQ solutions and who are having big trouble adding new products to their CPQ system. We’re not talking about changing the system or adding new functionality or visualizations. We are talking about basic product updates and additions.
Without going into the hows and whys of these common problems with system maintenance, we can explain how our system works better.
First off, from our experience when companies are buying CPQ they simply do not look enough at the problem of system maintenance. They see the end result in slick product demos but may never see how the product was developed. The administration is the last thing vendors show. It’s a bit don’t ask, don’t show. So naturally companies are surprised when they find system maintenance becomes a pain point.
At Veloce we thought a lot about system maintenance when designing our product. Our product administration makes it easy to build powerful configuration and pricing models quickly in a single web-based admin IDE. This is very different from leading vendors who rely entirely on Salesforce object data set up. Please pay attention here because our team has worked extensively with both approaches and there is a huge difference that impacts your ability to run your business.
Conceptually it may seem like a good idea to use Salesforce objects to store all your configuration logic. Your CPQ admin is also a Salesforce admin so this seems like a no brainer. However, there are several problems with this approach. Problems that are not obvious and are easily missed during your buying process.
True, your Salesforce admin will know how to work with CPQ custom objects. That’s about the end of the advantage and frankly, this ability can be learned in a few hours. The key problem when setting everything up in disparate object views, is it quickly becomes difficult to see what you are doing. There is no way to get an overview of your product model. As an admin, you are continually bouncing between single object views. Since the human brain typically can only hold a few objects in memory, it becomes unwieldy to remember how objects map to each other and what data you set up prior. I personally found this approach maddeningly difficult compared to having a single location where you can see your model.
Second problem, object field data cannot by itself describe complex logic or mathematical formulas. This is where “clicks not code” really begins to break down.
Although you are technically entering data in Salesforce object fields, the actual data you are entering happens to look a lot like, guess what, code! In order to support even rudimentary logic, you have to define that logic. There’s no real way to express an expression without putting it in some textual format. Einstein said “simplify as much as possible and no more.” The guy was a genius, by the way. Of course we all, including Veloce, want to make things as simple as possible. However, clicking on simple entities runs into limits of expressiveness. It’s like saying, you can say whatever you want but only in three word sentences.
To make things worse, there may be little in the way of syntax checking or standard syntax completion and highlighting that would be available in an honest IDE.
Aside from it being difficult to write this logic without adequate tools, these expressions end up buried inside of Salesforce data fields. This clicks not code paradigm in effect, ends up forcing you to hide anything that looks like code. You’d be far better off admitting the need to write expressions and giving some assistance to this process and making the existence of such expressions transparent to the system maintainer.
The other solution is to keep things super simple and not allow logic or mathematical expressions in Salesforce object fields. But this severely limits your ability to define logic or expressions. The truth is, and certainly in our experience, CPQ is complex. No sense pretending otherwise. Customer big or small, they all require logic. Otherwise they wouldn’t need a CPQ! No matter how “simple” your CPQ problem, you will need to have some constraints, rules, and mathematical formulas to support your business process, product configuration requirements, and pricing.
The Veloce Solution: Product Model Administration IDE
At Veloce we have created a product model administration that makes it easy, intuitive and quick to build configurators that can solve simple to very complex product configuration problems.
The foundation of our intuitive administration — that is, why it’s quick and easy — is our product modeling language. We call our product modeling language PML for short. Veloce PML describes an object oriented configurator system.
The most basic element of PML is a type. Types are much like classes in an object oriented programming language like say java. Types can be concrete or abstract. And they support inheritance. Inheritance is very convenient because it allows you to make your model both concise and precise at the same time. You are able to say exactly what each type is: no more, no less. Types contain attributes. Attributes can be of a variety of data types like numeric integer or string. The PML describes relationships between types in the form of rules and constraints. And types can contain other types as children. This enables you to build a runtime hierarchy of types that are dynamically created at runtime based on nested structure of the types in your PML and the configurator end user’s selection path. That covers the essentials of PML.
Our product model administration allows a modeler to create everything just described above. It is a point and click interface that a modeler can use to create a set of types along with type attributes, type inheritance hierarchy, type runtime hierarchy, and relationships between attributes within a single type or across sibling, parent, or child types.
These basic building blocks of PML allow you to describe literally any kind of configuration problem. Our product modeling tool makes it simple to create PML without knowing PML syntax. However, from our experience, we know that modelers will quickly learn PML syntax and find it convenient and sometimes easier to write PML directly. To that end, we allow both point and click PML creation and we provide an interface for the modeler to write PML directly. Our PML editor has syntax checking and intelligent auto-complete to help modelers write PML quickly and correctly. Moreover, PML syntax is easy. Anyone who works with Veloce product model administration will learn syntax pretty quickly.
The last quality of PML that makes Veloce modeling easy that you can do a lot with just a little PML. The Veloce solver engine does much of the work a modeler would have to do herself in a traditional rules based CPQ. In effect, someone modeling in Veloce has to do less work, because the engine does more for you at runtime.
To summarize the advantages of Veloce product model administration, it is a web-based tool that allows anyone to create an object oriented configurator system in a quick, easy and intuitive point and click interface. It also allows experienced modelers to write PML directly with a syntax checking and intelligent auto-complete. Veloce product model admin provides a convenient single place where you can see your entire model and how all the parts inter-relate. This is much easier to work with than CPQ products that rely Salesforce object data alone. Why? Because Salesforce is designed to show data in individual slices or views. You can see lists of Salesforce data records and you can view the details of any individual record. But you cannot see how the records inter-relate. This is a huge hindrance when trying to create something as complex as a CPQ product model. It’s very difficult or pretty much impossible to understand how the individual slices of data inter-relate. The modeler is forced to work with complex data structures from memory. This is a very poor way to do things, quite frankly. And hinders productivity let alone creativity in modeling. Working strictly with Salesforce data you quickly lose track of what you are doing compared to modeling Veloce PML in a single cohesive modeling environment.
Another major advantage of Veloce PML is the ability to create abstract types. Why is this important? Abstraction means you only define things once. It reduces your data size and complexity. It simplifies your product data and makes it possible to create an intuitive product data maintenance system. So simple, in fact, your non-technical business product SME or subject matter expert can maintain the data without IT.
Simple Attributes-based Data Maintenance for Fast Time to Market
Here’s the kicker, by combining these four elements: 1. product model abstraction, 2. solver technology, 3. clear separation of concerns, and 4. concise constraint logic, we can create a highly data-driven maintenance system that requires only infrequent changes to your product model. The system will run mostly on business data.
This has huge implications for your time to market. So please pay attention.
The concept of abstraction is missing from leading CPQ vendors running in Salesforce. But abstraction is critical in developing a data-driven solution that requires no modeling to update and add new products in a time efficient manner without IT involvement.
Here’s why. Let’s see an example of a blade server configurator. The problem involves finding a space optimized layout of set of blade servers within a container (a blade server chassis). It’s critical is that product model does not know upfront the specific size of the chassis or the sizes and numbers of the servers. That way we do not have to write any specific rules about any specific servers or chassis. The model only defines the simple ideas of a chassis, blade servers, and the general constraints that must be respected for this configuration to be done right.
Once you have to define all the particulars, you run into a maintenance nightmare. And that is what the leading CPQ vendors require.
Let’s see how Veloce solves it. First let’s see the chassis. It has four shelves each with two slots. So a total of 8 slots.
Now let’s add a couple blade servers with different dimensions. We can start with two blades: the half blade that occupies one half-shelf wide slot and a full blade that occupies an entire shelf.
The problem: given a chassis size and a set of blade quantities, we need to solve for a space optimal layout of the blades within the chassis.
Here’s our model:
Chassis
Size: totalSlots, number of slots in the chassis
Blade Server
Size: number of slots it occupies
Slot Number: slot in chassis where Veloce decides to put it
We make the blade server a child of the chassis by placing it in “port” within the chassis.
Chassis
Blade Server Port
In the Blade Server Port we create a constraint to sum up the slots occupied by the blade servers in the chassis. This tells the Veloce engine how full the chassis is so it knows what space is available for the next blade server it will place within the chassis.
Blade Server Port
sumSlotsOccupied = sum(slots)
Then we add a constraint to tell the configurator to add the requested blade quantities to the chassis.
Chassis
Constraint: totalSlots = Qty FullBlade + Qty HalfBlade
Now we add a constraint to limit slots filled so it doesn’t overflow beyond the capacity of the chassis:
Chassis
Constraint: totalSlots = qtyFull + qtyHalf
Constraint: sumSlots <= totalSlots
Finally we need to add what’s called a sequential rule. Sequential rules are used when a rule must be done enforced in sequence or after the complete execution of the last instance of the rule. In this case, we have to solve for each blade placement in the chassis individually, run all validations while completely propagating all dependent rules and constraints before moving on to the next blade. This ensures each blade is configured correctly and we avoid clashes between blade configurations (ie. no blades overlap within the chassis).
Chassis
Constraint: totalSlots = qtyFull + qtyHalf
Constraint: sumSlots <= totalSlots
Sequential Rule: Slot.SlotNumber, Slot.slots
We are done now and that is the complete product model.
In Veloce, we have the unique ability to solve this problem very elegantly with a tiny product model. In our solution you do not have to touch the product model to add new blade servers. That’s because we created everything the Veloce engine needs to know in an abstract “Blade Server” model. We write the abstract model once and only need to feed it data for any specific blade server.
This makes system maintenance seamless and easy for your business product owners to manage directly without IT involvement for product changes or additions. Keep in mind, without the Solver and product model abstraction this would simply not be possible. And that is the situation with leading CPQ vendors that rely on more simplistic rule engines.
They cannot support such a seamless and data-driven product administration because each new product or changes to products require working with the product model rules. They cannot manage it through product data attributes. And once you get into writing rules, things get complicated. Why? Because rules tied directly to products must take into consideration all the products. You end up developing inter-product dependencies in your rules. This is a huge problem for system maintenance, because new product introductions affect your existing rules-base and you may have to re-think and re-write your existing rules to incorporate the new product.
To understand this illustrate this problem in a concrete example. Let’s re-write the Blade server model we described above within a rules engine implementation without Solver technology.
The most efficient way to do this would be using rule tables. Rule tables are a common feature of CPQ rules systems and we support them in Veloce as well. Keep in mind, Veloce encompases all possible approaches to solve CPQ problems from highly generalized constraints to simple if then rule statements. That’s because from our experience sometimes you need a bit of both to solve a given CPQ problem. We realized that and make them both available in our product model.
The first and most obvious way to solve the problem using rules tables would be to create one large table that specifies how to place the server blades in the chassis. This is easy to imagine and has the advantage of taking all possible combinations into consideration. It has the advantages of clarity, specificity, predictability, and precision. That is, you know exactly what will happen in every case. So we create this rule table with the quantities of blades and the outcomes in the chassis placement of the blades.
Chassis Layout Rule Table
Above are just the first 8 rows of the solution table. The rule modeler has to complete all the rows to specify the combinations of half and full blades. This is pretty clear and simple. But also painful because you have to painstakingly specify all the permutations. If you miss one permutation, your chassis will not be populated in that scenario and your configuration will fail. In reality, this approach quickly becomes a maintenance nightmare.
And what happens if you add a new blade? In the Veloce model you can add the new blade to the system the Solver will figure out how to place it based on generalized constraints. But in this rules engine approach, your model is now broken. You will need to create a new table to incorporate the new blade server. This new table will be much larger because the number of scenarios has just grown. As you can see this approach is not scalable for adding new products.
But this is exactly what rules engines run into with this type of complex requirement.
In the end, the most likely implementation solution will be to write custom code to solve the problem. This is the dirty little secret CPQ vendors won’t talk about during pre-sales.
