New Purchases feature in Q3 2020 10.1: name & added value

Hi Damien Pochon,

Thank you for asking an insightful question and prompting discussion. It is a good question. Full disclosure, I'm not in the Products group, but this is my take:

1. I'm sure you already know this - but you are free to rename any module to anything that you prefer: https://support.sugarcrm.com/Knowledge_Base/Studio_and_Module_Builder/Editing_a_Modules_Labels/#:~:text=Navigate%20to%20the%20Developer%20Tools,for%20the%20module(s).
   
   A consideration as to why not call it Orders to begin with - could be to avoid visual conflict with the number of systems which already have a custom module for Order data.
   
   Another reason could be to deliberately to avoid it being confused with order data - as orders do typically have the fields you've referenced, e.g. a status.
   
   
2. RLIs do not always represent Purchases - since every Opp can generate them. Only the Purchases module can be considered an accurate (within the context of the CRM) record of what the customer has bought.
   
   Creating a report of what a customer has bought should be easy - it should not require filters against Opp status etc, which is what reporting with RLIs currently requires.
   
   
3. To avoid automatic generation, you can turn off the "Generate Purchase" field in the Product Catalog for all your products. All RLIs inherit that field and use it for automatic generation. This is definitely recommended for scenarios where an ERP integration has been setup, or as you said, in scenarios where you don't want to use it.

The more fundamental undercurrent in your questions is this: why did we even make this module? Many CRM implementations have an ERP integration and bring in sales data already, so it is already possible to analyse customer spend by category already. Why add something that most people who value it, would already have?

What the Purchases module does is create a consistent schema for all such integrations in the future - which means if we want to run Sugar Discover over it to identify anomalies, or our new AI acquisition to make predictions, the data is already in a recognisable format. One of the big value points of a time aware system is how quickly you can gain insights from that data. A consistent, recognisable schema makes that a lot easier, since we know where the data is, how it'll look and be able to configure our models accordingly.

I'm definitely open to discussing this and understanding how everyone else sees this too!

Regards,

Adam

Hi Damien Pochon,

Thank you for asking an insightful question and prompting discussion. It is a good question. Full disclosure, I'm not in the Products group, but this is my take:

1. I'm sure you already know this - but you are free to rename any module to anything that you prefer: https://support.sugarcrm.com/Knowledge_Base/Studio_and_Module_Builder/Editing_a_Modules_Labels/#:~:text=Navigate%20to%20the%20Developer%20Tools,for%20the%20module(s).
   
   A consideration as to why not call it Orders to begin with - could be to avoid visual conflict with the number of systems which already have a custom module for Order data.
   
   Another reason could be to deliberately to avoid it being confused with order data - as orders do typically have the fields you've referenced, e.g. a status.
   
   
2. RLIs do not always represent Purchases - since every Opp can generate them. Only the Purchases module can be considered an accurate (within the context of the CRM) record of what the customer has bought.
   
   Creating a report of what a customer has bought should be easy - it should not require filters against Opp status etc, which is what reporting with RLIs currently requires.
   
   
3. To avoid automatic generation, you can turn off the "Generate Purchase" field in the Product Catalog for all your products. All RLIs inherit that field and use it for automatic generation. This is definitely recommended for scenarios where an ERP integration has been setup, or as you said, in scenarios where you don't want to use it.

The more fundamental undercurrent in your questions is this: why did we even make this module? Many CRM implementations have an ERP integration and bring in sales data already, so it is already possible to analyse customer spend by category already. Why add something that most people who value it, would already have?

What the Purchases module does is create a consistent schema for all such integrations in the future - which means if we want to run Sugar Discover over it to identify anomalies, or our new AI acquisition to make predictions, the data is already in a recognisable format. One of the big value points of a time aware system is how quickly you can gain insights from that data. A consistent, recognisable schema makes that a lot easier, since we know where the data is, how it'll look and be able to configure our models accordingly.

I'm definitely open to discussing this and understanding how everyone else sees this too!

Regards,

Adam

Hello Adam,

Thank your for your detailed answer. This helps a lot :)

Let's continue the discussion a little bit: 

1. Naming : 

Yes I can rename & add fields based on our customer's needs. I just felt that the naming and data structure we're not entirely clear out of the box. We clearly see that Sugar is on a journey from "all-purpose CRM framework" to "turnkey but customizable CX software". I for one welcome the change in Sell and Serve (not in Enterprise, though), but the needle needs to be set somewhere: how turnkey should it be? If it's "very turnkey", then most of the work should be done already based on best practices and the vision of the platform. 

Finally, how is the term "orders" more confusing with other parts of the system than "purchases"? 

2. RLI vs purchase: 

If an object does not bring additional information, then it's useless. I'd rather filter on RLI status than query another object. RLIs *should* be accurate, or the sales forecast wont.

It's a topic we're frequently discussing with our customers for, for instance, contracts. Should you put contract information on the opportunity or on a separate object? Most often, we use a contract when a different user/role needs to work on the object or there can be several contract for the same opp or several opps for the same contract. 

In the case of purchases, It was not entirely clear if there would be several purchases for the same opp.

Also I still don't understand why the Purchases and PLIs are not related to the original opp? There isn't even a reference for the PO? 

3. Automatic generation

Thanks for the tip, I'll look into this one. 

Adam Frank said:

The more fundamental undercurrent in your questions is this: why did we even make this module? Many CRM implementations have an ERP integration and bring in sales data already, so it is already possible to analyse customer spend by category already. Why add something that most people who value it, would already have?

What the Purchases module does is create a consistent schema for all such integrations in the future - which means if we want to run Sugar Discover over it to identify anomalies, or our new AI acquisition to make predictions, the data is already in a recognisable format. One of the big value points of a time aware system is how quickly you can gain insights from that data. A consistent, recognisable schema makes that a lot easier, since we know where the data is, how it'll look and be able to configure our models accordingly.

Hi Adam Frank
Really like your explanation on this point.

However, isn't this only true when ERP or other Financial integrations and BI reporting are done using Sugar apps (Integrate, Discover, etc.), but not so much if using other connectors and BI tools?

I tend to lean towards more flexible CRM solutions that can interface easily with anything by using any method or connectors.

Although I understand the push to make it easier for keeping it all in-house, it shouldn't be at the cost of losing business when there is a preference to not use all-in-one solutions?