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

Hello community,

I'm exploring the new features of 10.1 (I know I'm not early :) ), especially the brand new "purchases" module.

My first thought was "wow Sugar is now going towards a full-blown ERP and now manages vendor purchases". 

Looking into the docs, I realise we're talking about customer purchases, in other words, orders. 

This generated new questions for me: 

  1. Why call this "purchases" when this term is mostly used for vendor purchases? "Orders" comes to mind more readily. In French it's even more disturbing as "Achats" is clearly the name of the team that handles vendors/procurement. I understand that from a customer's perspective they are indeed purchasing, but this tool is used by sales people who, well, sell :)
  2. For the moment I fail to see the added value of purchases vs RLIs. AFAIK records are not linked to the mother opportunity and do not have a status (ordered, delivery in progress, delivered, retired...). Is this interesting only for periodic orders, such as a monthly automatic renewal? Another use case I'm not seeing? 
  3. The automatic creation of purchases is great but my hunch is that most customers will not use them, so the "generate purchase" should be no by default. Easy enough to change, but it is going to cost minutes in most projects (or useless data storage and processing time). 

These are my thoughts, laid here for open discussion :)

Take care,

Damien

  • PLI in comparison to RLI looks like contract obligations versus forecasts. Those to be treated differently if someone estimates company value ;)

    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

  • Hi ,

    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. 

    Damien Pochon

    CRM & Digital consultant @ ITS4U Group

  • 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 
    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?

    CRM Business Consultant

  • Hi , apologies for missing your response here - only noticed it with Vincent replying below too.

    1 - you are right in saying there is a balance to be found between being a prescriptive good/best practice, and being flexible enough to support a variety of business models. Upon further reflection, and a month more of customer conversation, I haven't found people to be finding the wording confusing (most people I've spoken to are happy with the idea that Orders belong in an ERP or a fulfillment system), so I think for now, I'm going to keep listening on this front.

    2 - an advantage of a separate object here is that for customers who have an ERP integration to bring in actual sales, there is a specific place to put the data, with the knowledge that you're not touching modules which are used for forecasting/quote generation purposes... i.e. clear business demarcation around what purpose the different modules have.

    Should you put contract information on the opportunity or on a separate object?

    Contracts are an interesting topic to explore - and worthy of its own thread really - I've seen many different implementations of this concept, including the variants you've mentioned. I've seen that legal/support/finance often have an interest in this data, so depending upon the needs, the right place in Sugar is variable in my opinion, and there is not a consistent "always the right answer" answer.

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

    A single Opportunity can definitely result in multiple Purchase records. Let's say you sold a single opportunity for 10 CRM licenses and a support SLA. For many companies, both would be considered annually recurring services, and if the Product Catalog was configured accordingly, when you close that Opp, the related Account would gain 2x Purchase records and 2x PLIs as well.

    I cannot speak to why that relationship with the Opp is not set if the records were generated automatically from it... but I don't think PO numbers belong on it - again I see that as being something the ERP/accounting package should own. 

    Regards,

    Adam

  • Hi ,

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

    To your questions:

    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!