By: Mathieu Bassaic I can't count the number of times CIOs of larger software or OEM companies have told me, “We're doing entitlement management in our ERP system.” My typical response is, “So I bet it hasn't worked so well for you because it's like using your stove as your furnace. It can be done—but it's far from ideal.” There are some basic architectural reasons why ERPs aren't suited to entitlement management. Most entitlement management implementations are done in ERP's install base. You'd be amazed how much SAP and Oracle's install base look alike – so this issue isn't about one vendor vs. another. It's about the fundamentals: Install base is a component of the asset management “modules” of ERPs They were created to track large assets and the impacts on financial books Let's say you're a big printing company, you've got 20-30 printers that cost millions – you want to track those assets as they depreciate, etc. Install base is perfect for you. Install base architecture is based on assumptions like: Few assets (in the 1000s not in the millions) Don't need interdependency between assets (because that doesn't affect depreciation) Any change to those assets has potential financial impact Detailed knowledge of those assets isn't required Ownership of assets is assumed to be the person running the ERP—not a customer or a channel partner So here is what happens when you try to use an ERP install base for managing software entitlements: You can't link asset records together – so when features of a base are upgraded, you have to remember to make changes to multiple records You want to upgrade 100s of thousands of entitlements/assets to a new release because your customers are on maintenance – it takes literally days to run jobs to do this You want to move an asset/entitlement from one organization to another, you have to go through dozens of screens because the ERP thinks that it's moving depreciations around (even if the organization is in the same company) If you want to generate licensing keys or serial #s or… you'll end up doing a lot of coding There is no place to put meta data about licensing structures – more coding Sending emails or files is a foreign concept – more coding Handling concepts like changing fingerprints/machine identifiers doesn't exist – more coding You want to share entitlement (asset) information with customers / channel partners so that you can all agree on a single “source of truth” – more coding please In addition to the fundamental architectural issues with ERPs, there is another flaw with trying to put entitlement management functionality in an ERP: ERPs are core to the business. They are large. They are the vital center to large organizations. They can't /shouldn't change frequently – and usually don't. Typically ERPs are upgraded every 3-5 year years. Entitlement Management reflects licensing/marketing rules. They need to react to new product and program introductions – which happens 2-3 times per year. So confining fast moving, highly responsive requirements into a, by intent, slow moving solution is like putting a jet engine in a truck. At some point, the truck will break the jet engine or the jet engine will force the truck to become aerodynamic – either way – not a pretty sight. Someone will then come up with a hybrid solution: why don't we feed the entitlements from the install base to a CRM. This isn't any easier – I've seen it fail. CRM architecture isn't much better than ERPs and now integrating the two is doubly difficult. Unfortunately System Integrators make a lot of money from doing these changes – so they have no incentive in providing the right solution: Entitlement management should be a build-for-purpose solution which integrates into an ERP and CRM infrastructure With a build-for-purpose entitlement management solution , you get the best of both: