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

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?

Hi Vincent Amari,

Thanks for thinking about this (and for replying - as I admitted to Damien, I missed his notification!)

To your questions:

Vincent Amari said:

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

Let's break down this question to Sugar Integrate vs other integration tools, and then think about Sugar Discover vs reporting/analytics/BI solutions.

Sugar Integrate has no requirements of what the schema should look like in Sugar. You have complete freedom to store ERP data however you wish - whether in custom modules, core modules etc.

However, given that one of the strengths of Sugar Integrate is the templating that comes from common resources and procedures, there are advantages to building integrations in the same way and if you get used to using the core modules for that purpose, it lowers the cost of building an integration the second time around. This is less relevant for an individual customer that uses Integrate (not common for a single company to do multiple ERP integrations)... but for a company like yours which supports many other customers, reusability of these patterns would lower cost of building integrations, and more importantly, lower the ongoing support cost (as your engineers know where data always goes).

Now - that's for Sugar Integrate. What if you were using something else as an iPaaS/integration solution? Let's say - Dell Boomi / Talend / Mulesoft? The answer would be identical. Just like Sugar Integrate, none of these products have a requirement to see ERP data stored in a particular way. And they all have their own approach to templating, which would see benefit in a consistent schema in Sugar to leverage too. Having that consistency has the same impact again in both initial setup, and the ongoing support.

What about Sugar Discover? Yes, Discover definitely benefits from a consistent schema. The more that is familiar, the less custom the implementation becomes - so no doubt about it, the preference there would be to use a consistent schema. Having said that, Discover can be configured to look at any data stored in your CRM - so even if you chose to have your ERP data in a custom module, that doesn't make it inaccessible - it just means that the initial implementation can leverage less of the prebuilt assets and mappings.

And what if you're using Power BI, or Tableau or any reporting / analytic services? Well, they don't really care where the data is stored, as you'll be building that report/schema from scratch anyways. So if you're designing this for yourself, there's no real difference either way. But what if you happen to look after many customers who have similar needs? Then you could design a visualisation for one customer in Tableau, and find it a lot easier to port that report over to the next customer - because you know their ERP data is consistently stored in the same way.

Everything here points to consistency of schema. But what if you designed your own structure for storing ERP data, and you did that for every one of your customers? Well, then you'd get most of the benefits of the above too. I say most, because while you'd be able to share prebuilt templates amongst your own customers, you could not as easily leverage the content generated/shared in the community. eg imagine someone posts some really cool Tableau visualisation about customer buying patterns across a Sugar Sell database - and they are based on the core Purchases module. If you've used your own custom modules to store this, you won't be able to (as easily) pick up someone else's work and bring it to your own customers.

In summary: having a consistent schema provides benefits in lowering both upfront cost (by leveraging prebuilt assets/templates) and ongoing costs (support know that problems are solved the same way consistently). While this is easily true in Sugar products like Integrate/Discover, it also is true for other products when you are a service provider to other customers (as you can reuse these templates/patterns from one customer to the next). Consistency can be created by doing things your own way amongst your customer base, but if it isn't the "core" approach, it makes it harder to leverage work/patterns that others outside of your company have designed.

Wow, this post ended up a lot longer than intended, sorry!

Hi Vincent Amari,

Thanks for thinking about this (and for replying - as I admitted to Damien, I missed his notification!)

To your questions:

Vincent Amari said:

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

Let's break down this question to Sugar Integrate vs other integration tools, and then think about Sugar Discover vs reporting/analytics/BI solutions.

Sugar Integrate has no requirements of what the schema should look like in Sugar. You have complete freedom to store ERP data however you wish - whether in custom modules, core modules etc.

However, given that one of the strengths of Sugar Integrate is the templating that comes from common resources and procedures, there are advantages to building integrations in the same way and if you get used to using the core modules for that purpose, it lowers the cost of building an integration the second time around. This is less relevant for an individual customer that uses Integrate (not common for a single company to do multiple ERP integrations)... but for a company like yours which supports many other customers, reusability of these patterns would lower cost of building integrations, and more importantly, lower the ongoing support cost (as your engineers know where data always goes).

Now - that's for Sugar Integrate. What if you were using something else as an iPaaS/integration solution? Let's say - Dell Boomi / Talend / Mulesoft? The answer would be identical. Just like Sugar Integrate, none of these products have a requirement to see ERP data stored in a particular way. And they all have their own approach to templating, which would see benefit in a consistent schema in Sugar to leverage too. Having that consistency has the same impact again in both initial setup, and the ongoing support.

What about Sugar Discover? Yes, Discover definitely benefits from a consistent schema. The more that is familiar, the less custom the implementation becomes - so no doubt about it, the preference there would be to use a consistent schema. Having said that, Discover can be configured to look at any data stored in your CRM - so even if you chose to have your ERP data in a custom module, that doesn't make it inaccessible - it just means that the initial implementation can leverage less of the prebuilt assets and mappings.

And what if you're using Power BI, or Tableau or any reporting / analytic services? Well, they don't really care where the data is stored, as you'll be building that report/schema from scratch anyways. So if you're designing this for yourself, there's no real difference either way. But what if you happen to look after many customers who have similar needs? Then you could design a visualisation for one customer in Tableau, and find it a lot easier to port that report over to the next customer - because you know their ERP data is consistently stored in the same way.

Everything here points to consistency of schema. But what if you designed your own structure for storing ERP data, and you did that for every one of your customers? Well, then you'd get most of the benefits of the above too. I say most, because while you'd be able to share prebuilt templates amongst your own customers, you could not as easily leverage the content generated/shared in the community. eg imagine someone posts some really cool Tableau visualisation about customer buying patterns across a Sugar Sell database - and they are based on the core Purchases module. If you've used your own custom modules to store this, you won't be able to (as easily) pick up someone else's work and bring it to your own customers.

In summary: having a consistent schema provides benefits in lowering both upfront cost (by leveraging prebuilt assets/templates) and ongoing costs (support know that problems are solved the same way consistently). While this is easily true in Sugar products like Integrate/Discover, it also is true for other products when you are a service provider to other customers (as you can reuse these templates/patterns from one customer to the next). Consistency can be created by doing things your own way amongst your customer base, but if it isn't the "core" approach, it makes it harder to leverage work/patterns that others outside of your company have designed.

Wow, this post ended up a lot longer than intended, sorry!