Some thoughts on Business Transformation efforts

First of all I think the term "Business Transformation" is somewhat overused therefore let's first clarify what Business Transformation means.

Definition from the business directory (see this link) : In an organizational context, a process of profound and radical change that orients an organization in a new direction and takes it to an entirely different level of effectiveness. Unlike 'turnaround' (which implies incremental progress on the same plane) transformation implies a basic change of character and little or no resemblance with the past configuration or structure.

Who is responsible to drive the Business Transformation?
There are different thoughts on this which range from CEO, CMO to CIO. You can search the web for various points of view. In any case it should be very clear at the beginning of a business transformation effort who owns it. Whoever it is in your company they should actively support it.

Define in what environment a business transformation takes place.

• In case of a growing business
• Most likely the old processes and tools are no longer sufficient to deal with the challenges of a growing business. See this link to explore that in more detail
• In case of a mature business (and a growing business as well)
• Check this excellent article from McKinsey
• Key Points are
• Set clear objectives
• provide strong leadership support from the top
• setup a clear organization structure for the transformation
• maintain energy and involvement throughout organization 

Who (System Integrator) can help you with the Business Transformation?

• Check this link to get a general idea about the challenges with System Integrators
• Make sure that not only cost dictates what you plan to do! You will work with this team for a considerable time and hence you need to be certain that there is a fit with your companies culture.
• Do you want to work with only one system integrator (SI) or consulting company or do you want to involve multiple SI/consulting companies?

Here are some signs, from my experience, that a business transformation effort has serious challenges

• Large parts of the organization don't understand really what the business transformation effort is about or what it tries to achieve
• Leadership does not actively and frequently support the business transformation effort (an occasional email or video on the intranet is NOT sufficient)
• It takes too long to see any progress (e.g. "PowerPoint transformations" can go on for a year or longer before any real progress can be shown to end users) --> this might remind you of a "Waterfall" Project

Here are some key to-dos, from my experience, that I would propose to any business transformation effort

• Ensure the whole organization understands WHY the business transformation is needed. The majority of company employees should clearly understand and support this effort (see also John P. Kotter "Leading Change" for basic Change Management guidance). This means COMMUNICATE, COMMUNICATE, COMMUNICATE !!! --> everyone should be able to recite the elevator pitch for this transformation.
• Have active, visible and regular Senior Leadership support! (e.g. CEO, CMO, CIO)
• Assign clear Roles & Responsibilities at the beginning. This will require considerable time but is well worth the effort! Instead of stepping on each others toes teams can collaborate instead
• Break the business transformation effort into "digestible pieces"! e.g. a new ERP implementation can be overwhelming and should be broken up into smaller pieces so that the impacted stakeholders better understand what is changing and why it is changing (and hence increase the likelihood of a successful project/program)
• Have 3-6 month release cycles for the business transformation changes. That way it's easier to see and buy into the changes
• Have dedicated Change Management resources assigned to ensure impacted teams understand early on, how they will be impacted (and what the benefit is)
• Actively support team behavior between Business and IT Teams ! They are on the same team and should behave that way! Make sure this actually happens.
• Measure where the transformation effort is compared to the final objective and COMMUNICATE this regularly (e.g. quarterly) to all stakeholders 
• Do NOT build "exclusive groups" of any kind - this is a team effort and needs to be treated as such!

Agile Project Management with SCRUM (based on the book from Ken Schwaber) - a cheat sheet

Several years back I read the book "Agile Project Management" by Ken Schwaber. From my point of view this is a good introductory book to learn the basics of Agile Project Management with SCRUM. I had created a kind of cheat sheet at the time that I share below so that you can use it to become familiar with the basic SCRUM ideas quickly.

First here is the link to Ken Schwaber's book.

SCRUM Roles - check this link to learn more about these roles (scroll down until you see "roles")

1. Scrum Master
2. Product Owner
3. Team

Phases

1. Vision (similar to Project Charter)
2. Create Product Backlog (prioritized) --> check this link to see what a Product Backlog is
• Functional requirements
• Non-functional requirements (QA)
3. Sprint Planning Meeting (1 day) --> check this link to see what a Sprint Planning Meeting is
• Select Product Backlog (4h)
• Prepare Sprint Backlog (4h) --> check this link to see what a Sprint Backlog is
4. Sprint (30 days) --> objective: create shippable code!
• Includes Analyze, Design, Code, Test, Documentation
• Daily Scrum (15min) --> Product Backlog to be updated by Team
• What have you done since the last SCRUM?
• What will you do between now and the next SCRUM?
• What impedes you from performing your work effectively?
5. Report
• Product Backlog at the start of the sprint
• Product Backlog at the end of the sprint
• Changes Report (Difference between the two previous Reports)
• Product Backlog Burndown Chart (measures amount of remaining backlog work)
6. Sprint Review Meeting (4h) --> check this link to see what a Sprint Review Meeting is
• Team presents to Product Owners + stakeholders functionality that goes into production!
7. Sprint Retrospective Meeting (3h) --> check this link to see what a Sprint Retrospective is
• Attendees: Team, ScrumMaster, Product Owner-optional
• What went well during the last sprint?
• What could be improved?

For multi-site projects see this link for SCRUM of SCRUMS.

Additional resources:

• http://www.controlchaos.com                             Ken Schwaber Website
• http://www.mountaingoatsoftware.com/scrum   Mike Cohn Website
• http://www.scrumalliance.org
• http://www.agilealliance.org
• http://www.youtube.com/watch?v=IyNPeTn8fpo (1 hour introduction of SCRUM from Ken Schwaber to Google employees)
• http://www.pmi.org/Certification/New-PMI-Agile-Certification/PMI-Agile-Toolbox.aspx

Idea's for setting up an integration Kick-off meeting after an acquisition

Acquisition Projects are a little different from "normal" projects because one party (the acquiring party) will most likely keep many processes and systems in place while the acquired part will have to adjust their processes and systems.
This is obviously a big change for everyone and needs to be well planned to ensure a successful transition. Below I have put some high level Points together that I consider useful for an acquisition kick-off meeting:

• Setup a Kick-off meeting to clarify scope, objectives and what success looks like
• Example: You might have the following teams from the acquiring and the acquired company: Integration Management Team, Business Team, IT Team and cross functional teams (e.g. Go-to-Market, Quote-to-Cash).  Everyone needs to understand the Roles & Responsibilities clearly!
• Tell Integration participants about the acquired company! e.g. History, Culture, Revenue, number of customers, number of employees, location of customers, company is present in how many countries, any alliances the acquired company has etc. 
• Review/Discuss Integration Strategy  (ensure the impact of this is understood by the acquiring and acquired teams). 
• The following points should be addressed
• Overall Strategy (e.g. Integrate acquired company into Business Unit xyz with minimal disruption within x months)
• Business Model (e.g. apply business model and operating model from acquiring company)
• Organization Changes
• GTM Strategy (e.g. Integration of sales force and reseller channel)
• Partner (e.g. Integration into acquiring company Partner Program)
• Product Integration (e.g. adjust User Interfaces (UI)of acquired companies Software Program to get the same look and feel as the acquiring company)
• Services & Support (e.g. Integrate Customer Support into one team)
• IP Integration (e.g. Intellectual Property transition to acquiring company)
• Operations (e.g. acquired companies product need to be available on acquiring companies systems within x days)
• Business Functions e.g. transition Professional Services from acquired company to acquiring company
• HR e.g. stock options plans for key executives and employees
• Real Estate e.g. consolidation of offices
• IT e.g. Network connectivity
• Finance
• Tax/Legal e.g. company car policy of acquiring company applies
• Review proposed timeline and milestones
• Review communication requirements (internal & external)
• internal: assign contacts to minimize daily operation interruptions for acquired company
• external: designated one communication contact to prevent any confusion
• Review where the Integration Documentation will be stored (e.g. SharePoint)
• Review proposed acquisition project update schedule (and ensure all stakeholders are ok with that.  e.g. all Senior Management stakeholders want to be updated every week, Wednesday)
• Review M&A Playbook (high level review to ensure everyone understands where we are and what we are targeting next)

Take some time to go through this and don't rush it!

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. 

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?

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.

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

Quote-to-Cash Overview Part 2

As mentioned last week I continue the overview of Quote to Cash. Today I will be Order Management and Licensing for Software Products.

1. Order Management: (e.g. SAP eCC, SAP R/3, Oracle ERP, SAP CRM). This is the typical realm of Enterprise Resource Planning Systems (ERP). Let's review the general process flow. After the customer accepted our quote he will send us a purchase order (PO) to order the products we quoted. When this happens we might need to check that the PO matches the quote we issued (e.g. same quantity as quoted, same price as quoted). These checks can happen automatically or manually. The Sales Reps probably also want to know when the order comes in since their Sales Compensation is tied to this order. When the order is created for Software Products the processing is somewhat easier since we don't need to check the availability of the product. This is true at least when the Software is electronically downloaded. When we still ship physical DVD's it's slightly different. But the availability check obviously needs to happen for physical products to ensure our customer receives the products as requested. There are a number of checks that happen during order taking (e.g. Credit Check from Dun & Bradstreet, Global Trade Compliance Check). In some cases there might be different order acceptance criteria for different products (e.g. every region might have other accpetance criteria).  Note that the team that accepts the order might be different from the team that issued the quote, at least in larger companies. One specific note here is regarding professional services. There are two different flavors of professional services 1. pre-packaged services (e.g. training classes, certain services that are always charged the same amount). These services could be added to the configuration tools we reviewed last week. 2. custom services (e.g. consulting services to implement an SAP CRM system). These services will require a Statement of Work (SOW) to agree what services are included and what is not included. If these services are added to a product configuration tool they will require manual follow up (e.g. to link the physical/paper contract to this offering, agree how and when the services will be invoiced). Invoices for these services will most likely require different handling (e.g. VSOE/Revenue Recognition rules) than HW or SW products. One key task to keep in mind is how the CRM and the ERP system (that is where the order management traditionally sits) are integrated.  Generally there are two approaches: Best of breed (e.g. quote in system A, order in system B) or Integrated systems (e.g. quote in system A, order in system A) approach. But that is too much for today's post and will be covered in a future post.
2. Software Licensing Let's first clarify the difference between the Software (the bytes) and the Software License (the key that makes the software useable). By now the standard delivery method for Software is electronic, meaning our customers can go to our website and download the products they need. This can happen for demo purposes (e.g. first month is free, limited functionality for unlimited time) or for a regular download (license is paid from day 1 of usage). In order to use the downloaded software our customers will need (in most cases) a Software License Key. We can further distinguish between perpetual licenses (they don't need to be renewed) and temporary licenses (e.g. Demo License, 2 year license, 4 year license). An additional point is if a customer buys a new license or an additional license. Example: If a customer already has 50 licenses and they buy an additional 10 licenses then the new Software License key needs to be for 60 licenses. There are different ways how this can be handled for end customers and for business customers (e.g. they buy more than one product for more than one customer). All these processes should ideally be available on a webstore so that a customer can trigger the license key generation himself/herself w/o any support from us. Further it is desired to have only 1 License Key Generation tool (many Software companies have more than 1 due to merger & acquisitions etc.). Note that for Enterprise License Agreements (selling of the complete or large part of our Software Product Portfolio) a different handling is needed. 

This was a lot for these two topics and so let's conclude the overview for today and continue this  next week (to come --> upfront Support for HW and SW products, Support Renewal quotes and orders, Consulting and Education Services, Enterprise License Agreements)

An overview of Quote to Cash - first part of a multi part series (starting with Configure/Price/Quote)

I've worked for many years in the Quote to Cash area and this is my short overview of the processes and systems that belong to Quote to Cash. I hope this is helpful since many people who don't work in this area are not really sure what Quote to Cash means.

Before the processes and tools below can be used we need to decide through what Route-to-Market (e.g. High Value Products, High Volume Products) we want to sell our products and services and if we want to differentiate these by Business Unit (e.g. Hardware, Software, Services).

Here are all the processes and systems that belong to Quote to Cash. We start with Configure/Price/Quote processes and tools

1. Product Configuration tools (e.g. used on HPshopping.com, Dell.com)
    - some tools that are offered in this area are SAP Variant Configuration, SAP SSC, BigMachines,
      Apttus, NetformX
    Note: Every tool was developed with a limited number of use cases in mind. Therefore it needs to
    be determined in a thorough investigation which tool is needed for what purpose while we also
    want to avoid double maintenance of tools. For example, we don't want to use a BigMachines
    configurator on our website and a SAP SSC tool for our sales reps. We target to have all the rules
    for these configuration tools in one place.

2. Pricing tools (e.g. List Price in USD, EUR, Purchase Agreement Prices, customer specific
    discounts)
    - some tools are SAP eCC, SAP CRM, a custom developed tool with a DB or a myriad of other
      tools
    Example: There can be one Database for List Prices (in different currencies), one for Purchase
    Agreements, one for Big Deal Customers, one for tiered customers etc.
    All these prices might need to be available at the time the product configuration tool is accessed
    and definitely once the quote is created or maintained.

3. Quote Management (the quote that is handed to the customer needs to be setup in this tool
    - some tools are SAP CRM, BigMachines, Apttus
    When a legal quote is issued we need to be sure that we have for example

• correct customer data (e.g. Customer Number 1234 with address xyz)
• correct product data (e.g. for every SW license we need to have a service product)
• correct and approved prices (e.g. approved by Deal Desk if certain thresholds were exceeded, prices are VSOE compliant )
• Terms & Conditions have been approved (e.g. by Deal Desk)

The quote will be valid for a certain period of time, depending on the region (e.g. Americas, Asia) where it was issued. It could also be necessary that the quote is issued in multiple languages.

These first three processes and tools are also referred to as Configure/Price/Quote or CPQ. These are  sub components of the Quote-to-Cash Process and there are multiple Software companies that offer system solutions in this area (e.g. Apttus, BigMachines, Selectica, Cameleon Software, IBM Sterling, SAP, Oracle).

In order to prevent double work it is important to ensure that the processes and systems in the CPQ area are tightly integrated in the overall Quote to Cash processes and systems. (e.g. if BigMachines is used in the front end CRM tool it needs to flow smoothly to the SAP eCC ERP system). This is not a trivial effort and requires some serious investigation to come up with the best possible solution.

We will continue this overview next week (to come -->  Order Management, Licensing for Software companies, upfront Support for HW and SW products, Support Renewal quotes and orders, Consulting and Education Services, Enterprise License Agreements)