Tuesday, November 26, 2013

Basic Overview: What you should consider before you decide about a new Product Configuration Tool

We start with clarifying what a Product Configuration Tool is.

Product Configuration Tools are a key tool in the sales process that help to "customize" or "personalize" a product. They can be used by Sales Reps or by End Customers.
The underlying idea is that certain configuration rules (e.g. If a tool user selects Product A then Product B has to be added automatically) are too complex and unknown to the user and so these tools help the user to build and order complex products correctly.
Various tools have various capabilities but they all put their rules in a "Knowledge Base" also referred to as a KB.

Below is a screen shot from Dell.com that I will use to clarify the Product Configuration Tool basics. This Product Configuration Tool can be used by the End Customer and/or the Sales Reps.

The screen shot below shows a Dell laptop - Latitude 15 3000 Series. The 3 different options below the picture are different "starting points" for the Latitude 15 3000 Series base model. All of them have different selections and different price points. It follows a basic good/better/best approach (from left to right).


In addition to that Dell also shows a chat window that will allow the user to chat with a Sales Rep. There is the possibility to lease the product and the information about the lease rates, it also shows savings/discounts (meaning there is a List Price and there is a discount for this product even to an unnamed account, there is shipping information and finally the user can either buy the product as is or can "customize" it. Customizing refers to changing default selections.

Now since we all have a basic understanding on what a Product Configurator is let's look at the 5 W's   (Who, What , When, Where, Why).

  1. Who is using the Product Configuration Tool?
    • Sales Force (Pre-Sales, Field Sales, Inside Sales, maybe Product Management, Product Marketing).
      • Do they use the tool offline and/or online?
      • How much information do they need in the tool? e.g. do they need to see pricing options while they configure a product? Or is it sufficient to show the pricing afterwards (in the quote part of the tool) ? Do they need to see any pictures of the product?
      • The complexity of the products will determine who is using the Product Configuration Tool
    • Channel Partners (e.g. in the case of Dell they might work with Arrow to sell their computers)
      • While the basic Product Configuration Rules (e.g. If user selects Product A then Product B is added automatically) apply to every Channel Partner, each Channel Partner will have their own prices. Hence they need a capability to upload these prices (e.g. List Price, Discounts, Surcharges) into the Product Configuration Tool.
      • Channel Partners might want to add other products (e.g. in our Dell example above they might want to add some products from Hewlett Packard or Lenovo)
    • End Customers
      • They will use online configuration tools like the Dell example above
      • Product Configurations can be saved in the "shopping cart" for a certain period of time. When a product becomes obsolete there needs to be an agreed upon logic to replace them or empty the shopping cart
  2. What products are used in the Product Configuration Tool?
    • simple products (e.g. laptops, ultra books, desktops)
      • This will also determine who is using the tool. If the products are simple more users can use the tool. Keep training requirements in mind 
    • complex products (e.g. servers, Racks of servers, networking products)
    • Hardware/Software/Service products (e.g. Service products that require a Service Level Agreement (SLA) are not the best fit for a Product Configuration Tool)
  3. When is the Product Configuration Tool used?
    • Online
      • I already mentioned this above. If a configurator is only used online a cloud product configurator like Apttus could be used 
    • Offline
      • If the tool will be used offline or (e.g. for security reasons or because the Sales Rep does not have Internet connection while he is with the client) , then this will require a different tool
  4. Where is the Product Configuration Tool used?
    • Tied into a CRM environment (e.g. Use of Apttus from Salesforce.com)
    • Tied into an ERP environment (e.g. Use of SAP Variant Configurator in SAP eCC). Is this the same tool as in the CRM environment? 
    • As a standalone tool 
    • On the Internet
  5. Why is the Product Configuration Tool used?
    • To simplify ordering customized/personalized products
    • To ensure correct materials/skus are selected and with them the correct prices are retrieved
    • To streamline the ordering process (e.g. check if a Software Customer is eligible to upgrade from 50 to 75 users by checking the "installed base" information in the configuration tool, for HW it might check if a product is available before it is shown in the product configurator)
If you are not very well versed in these tools it is a good idea to engage specialists who can help you to ensure you are selecting the right tool(s) for your situation.

Some examples of Product Configuration Tools.
Note: Keep in mind that all these tools need to be able to integrate with your backend system (e.g. SAP eCC, Oracle)
  • Apttus
  • Cameleon Software
  • BigMachines
  • Axonom
  • SAP Variant Configuration / SAP SSC (Solution Sales Configuration) / SAP IPC (Internet Pricing & Configurator)
  • NetPRM
  • Configure One
  • NetformX
  • Experlogix
Hope this Overview helps to shed some light on the CPQ (Configure, Price, Quote) area. 

Wednesday, November 20, 2013

Change Management - Do you do it?

"Change is the only constant" Herclitus, Greek philosopher

For this blogpost I refer to Change Management as the Methodology that is used to execute organizational change (vs. personal change).  There are many more definitions for Change Management (e.g. check these Whatis.com or the Oxford Dictionary etc.) on the internet so go ahead and check it out. In any case a well thought through Change Management approach is key to any successful organizational change effort! What do you do in your programs/projects to deal with change? Do you have a dedicated team or team member to think about change management? How do you ensure support for the changes that you and your team are implementing?

Based on my experience it seems that many organizational change efforts are not living up to their potential because the Change Management efforts are not really fully thought through, supported and implemented. Let's look at an example: A tech company wants to change their CRM System from salesforce.com to SAP CRM. The change has been discussed between executive Managers and some other senior leaders. This specific change effort will have a  big impact on the Sales Team (and other teams like Sales Operations etc.). In order to make a change like this successful we need to spend considerable time and effort to come up with a clear plan on how we plan to make this change management effort successful. We need to determine what success looks like and this does NOT only include that we have all the required functionality in SAP CRM at the end of this program/project. This needs to include much more than gathering the business requirements for the new system, determine what functionality will change for the Sales Reps (e.g. instead of the Sales Ops Team entering a value in a field now the Sales Team will do it) and how we plan to educate the Sales Team (and others) about these changes in the most effective way (Training / Enablement).
The most popular change management approach probably comes from John Kotter, in his book "Leading Change" but there are many others approaches (see this link). As you would expect the big consulting companies have their own change methodologies as well and many practitioners add their own flavor to these methodologies. This is not an exact science but more an art that needs to be mastered.
Bottom line is that many companies still treat Change Management as an afterthought or something that is just not as important as many other tasks (e.g. in the example above it seems to be more important to have the functionality in SAP CRM instead of having the Sales Team on board to use the system afterwards).
I suggest that if the change management approach is not well thought through every project/program can still fail. Hence Change Management is something that should be front and center for every program or project that requires considerable changes and should have dedicated resource(s).
What does your company do in this area?

Wednesday, November 13, 2013

Quote to Cash Overview - Part 4

This is the last part of the Quote to Cash Overview and we'll cover Professional Services and Enterprise License Agreements today.

Let's first cover Professional Services. What I refer to when I talk about Professional Services is Consulting Services and Education Services. Consulting Services includes all the consulting offerings we might sell for our Software Products (e.g. SAP is selling Consulting Services to install their SAP CRM 7.0 solution at a customer site). Education Services includes all the training that we might sell for our products (e.g. SAP is offering training classes to learn more about certain parts of their CRM solution and these classes are scheduled at various times with a "fixed" price)

Professional Services can generally come in two flavors.
  1. They don't require a Statement of Work (SOW) and might have a fixed price
  2. They require a Statement of Work (SOW) and the price needs to be determined
In case # 1 this is an offering that could be sold on a website without requiring more customer info. An example is an SAP Consultant that wants to get more training on SAP eCC SD - Pricing. They can go to the SAP training website and order that training course for $ x . The handling of this service is similar to that of a HW or SW product. The difference here is that the Revenue Recognition might be different because the training course/service was sold today (November 13, 2013) but our customer attends the course next year (February 2014). The question now is when can the selling company recognize the revenue (November 2013 or February 2014).

In case # 2 the process becomes more complex. Note that in this case there is no fixed price that we can put on a website. Let's assume a customer is asking us (company x) to implement SAP CRM 7.0 to support our business transformation from a system point of view as an example. Our company needs to first spend some time and effort to determine for which price we can offer this service. That means before we can prepare any quote for the customer we need to approve some money (pursuit budget) to determine if we want to make an offer and what the offer details should look like. e.g. Do we make a "fixed price" offer or do we make a "Time and Material" offer? We basically need to determine the following requirements
  • Resource Management - (How many people will we need?)
  • Time Management - (How long will this Project go? What are the planned milestones?)
  • Expense Management - (What expenses will we occurs when we run this project? Who is paying for them?)
  • Project Management - (We will need to setup a Project Schedule to plan the Project)
  • Billing Requirements - (When are we going to bill the customer? What amounts are we going to charge?)
  • Project Collaterals - (We need some materials to communicate our plans to the customer)
  • Financial & Reporting Requirements - (What kind of reporting do we need to provide?)
  • Revenue Recognition - (How and when will we recognize revenue for this project)
  • Regional Calendars - (In case we do the project in several regions we need to consider the various holidays and their impact)
  • Multi Currencies - (If we do the project in several regions we might have to deal with multiple currencies)
  • Partner Involvement - (Do we have other partners that we need to involve. E.g. for our project maybe IBM and HP both offer servers for the software. Which partner do we want to/have to involve?
  • Opportunity impact - (If we pursue this offer, what impact does that have on other opportunities. Is this the best use of our time and resources?)
There are probably a number of other requirements but I think this gives you a good idea on what needs to be considered. Only after these questions have been addressed can we make an offer/quote to our customer. The result of these investigations will be put into a Statement of Work.

Now let's shortly address Enterprise License Agreements (ELA). They might have different names in different companies but it basically refers to a case where a customer buys a part of the product portfolio from another company. Example: Customer A buys the following products from Microsoft MS-Outlook and MS-Office. They could buy this for a certain number of users (e.g. 5,000 user get the license) or for a certain amount of Dollars (licenses can be obtained for up to $2,000,000) and/or for a certain period of time (e.g. the agreement is valid for 1, 2 or 5 years). Note that there can be multiple flavors of these agreements. What I describe above is a simplification.
The challenge here is that many processes and system steps are unique (e.g. at the time when the ELA is signed the customer will not make selections for one specific laptop but more generally state that 10 laptops are included in the ELA).  Hence many steps might be manual since no system solution fully supports this. Some other specialties are
  • potentially long quotes/orders since many product numbers might need to be listed there (Note: In most cases it will be simplified for the customer BUT we probably have to have all the details anyway even though they are not visible to the customer)
  • special features on websites to download all the Software Products when needed
  • follow up at the end of the ELA to determine if the agreed upon products/services were really used by the customer (true up).
Again, these are only some few examples to ensure the general challenges become clearer. There is much more detail once we would dig into this.
Note that these are mostly big or very big deals and so they will in most cases only be available for certain (very good/big) customers.

I hope this 4 part overview over the Quote to Cash area was helpful. It should have a least shown you that this area crosses many teams and subject areas and hence to ensure success in this area (for any process improvement, Business Transformation etc.) it is key to closely align with the affected teams.

Tuesday, November 5, 2013

Quote to Cash Overview - Part 3

Let's continue our short overview of the Quote to Cash area today with a look at upfront support for Hardware and Software Products as well as Support Renewal quotes and orders.

What is upfront Support? That is a support service that is sold with the first or initial sale of a product. An example is the sale of 24x7 support service for a Software Product. The duration of this support service might vary (e.g. 1 year, 2 years, 3 years etc.). Usually the Product (HW or SW) that is sold has a default support service which the user (e.g. on a website) or the sales rep (e.g. on internal sales tools) can change. For Software companies the support price might be between 16 - 21% of the Software Product price. Example: Software Package A costs $100 and the 1 year support service that it is sold with goes for $18 (this is 18% of the Software Product price). This brings the total price to $118. If the customer is qualified to get a discount it is important to note that the price of the Software Product and the price of the support service are interdependent and subject to VSOE and Revenue Recognition regulations. Example: Our customer in the example above requests a 20% discount for the $118 Software Package A and 1 year support service. It might not be possible to discount the Software Product and the support service in the same way without doing a carve out. Since I'm not an expert on this topic I leave it at that but note that this topic can be fairly complex and requires the guidance of a Finance expert to ensure VSOE and Revenue Recognition compliance.
Ideally we want to have one system that allows us to sell Hardware Products, Software Products and Professional Services. This system should determine VSOE compliance automatically in every region/country.
Note: Some companies will make it mandatory that with every Software or Hardware Product Sale a support service product is sold and others will leave it as optional. This can be enforced in various systems and processes (e.g. add a support service in the product configuration tool every time a software product is selected).
What customers usually also request is a possibility to co-term support services. This refers to the ability to align various support services to one timeline.
Example: Software Package A was bought on June 15, 2013. The one year support service runs from June 15, 2013 - June 14, 2014. On November 15 the customer wants to buy Software Package B also with a one year support service but he wants to align the support service for both products from June 15, 2013 - June 14, 2014 (instead of having the support service for Software Package B from November 15, 2013 - November 14, 2014). This will highly simplify the handling on the customer side and the seller side.

Support Renewal quotes and orders: What I mentioned above is the initial sale. Once the support service is expired it will come up for renewal. Example: Software Package A was bought on June 15, 2013. The one year support service runs from June 15, 2013 - June 14, 2014. On June 15, 2014 the contract will expire. We want to go back to the customer well ahead of time (e.g. in April 2014) to renew the support services (e.g. extend them by 2 years).
Support Renewal services represent a considerable part of many businesses and so it is critical that the business processes and systems in this area support this critical need.
Some challenges in this area are finding the correct products to renew (Example: 12 months ago Hardware Product A  was sold with sku's (Stock Keeping Units) ABC, DEF, GHE. In the meantime sku ABC is no longer available. Now we need to determine the replacement sku(s) for ABC. If several NPI (New Product Introduction) cycles are skipped this becomes obviously more complex.)
In order to enable this capability in a system something called an Installed Base is needed. The installed base provides information which products are installed at the client side.
There are many more details that could be added but for our short overview this should suffice.

Next week we continue with --> Professional Services (Consulting and Education Services) and Enterprise License Agreements