When Your ERP or CRM is Missing That One Critical Feature: Go Cloud Native!
Too many times have I heard this from CXOs: “My CRM (or ERP) is fantastic, BUT…”. Or how about the countless times I have seen an RFP/RFI with instructions to compare Microsoft Dynamics with <pick your packaged software of choice> — feature by feature, capability by capability. At the end of the day, every single product has gaps and never fits completely with the customer’s needs. So, what happens next? Escalations to the software provider asking for (or sometimes demanding) the needed feature to be prioritized—most often falling on deaf ears. Or worse yet, the customer is forced to compromise on their needs or adjusts their business processes to make the software work.
Why? Because every business is unique! Every customer is different, and no software provider can build software customized for every customer. So, what do you do? Compromise? Continue to compare features and functions? Sometimes that is the right answer…but there is another way.
Cloud Native: Easy and cost-effective custom development in the Cloud
The solution to getting exactly what you need in your ERP or CRM system is to develop the missing features yourself! Don’t let that scare you; “custom” used to be a bad word in IT spaces…expensive to develop, difficult or impossible to find someone with the skills to do it, difficult to support, too expensive to host, a roadblock because your IT department has other projects to deal with…pick your reason. But not anymore. Enter Cloud Native.
“Cloud Native” is a new term in IT spaces, and there has been a significant amount of confusion regarding its meaning and usefulness. According to the Cloud Native Computing Foundation, Cloud Native is defined as the following:
“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.”
What does this mean to organizations like yours? It’s simple: You can build applications or missing features and capabilities without customizing your packaged software in an easy to maintain manner, that is cost effective for hosting, and eliminates the stress of legacy, monolithic application development. Here is an example:
Let’s say you have a CRM system. You enter customers into this system with their contact information, including their address. You will be shipping product to your customers, so you need the address to be USPS compliant. You have 3 options: 1) “hope” your CRM system has this capability built in to validate addresses; 2) “search” for a plugin that will do address validation and likely pay for a third-party service for that privilege; or 3) “build” it yourself.
Assuming options 1 and 2 are not possible (in this example they are, but that’s not the point), let’s say you decide to go with #3 and to “build” it yourself. But how? Modify your CRM system, learn its proprietary technology, and build it directly in the CRM system? Instinctually and historically, that is where most companies go first. It is logical; the need is in CRM, you have the CRM platform, so that’s where it should go, right? NOPE.
Most CRM systems are moving to SaaS, so building custom within the CRM platform is not only challenging (deployment operations, custom languages, release management—all of the painful things IT wants to avoid), but many SaaS providers won’t even let you do it. So, building it in CRM is either eliminated right away, or its just a BAD idea.
Now, in this same example, months later, you open an eCommerce platform that is capturing customers, including their shipping details. If you had built it into CRM, the eCommerce platform would now need to be able to communicate in real time with your CRM just to validate an address. That might not sound so bad, but from a user experience perspective, it would cause a delay on the web site to wait for CRM to process a bad record, only to tell the web site it’s bad, resulting in a horrible user experience. With that, customers decide to take their business elsewhere.
But, what if you had built a new enterprise service, called AddressValidationService, that was neither inside CRM nor inside your website? Both your CRM and your web site could use it seamlessly, resulting in some big benefits:
- Superior data quality
- High web performance, highly efficient, maintaining a positive user experience
- Clean, real-time data in your CRM
- Maintenance of both systems remain focused on the core to what they do
- Address validation remains outside of either system
Sounds pretty appealing so far, doesn’t it?
But now for the biggest benefit: This address service is completely separate, which means it has its own lifecycle, can be deployed independently, upgraded easily, and has a very small but defined set of capabilities. Any system you have that needs this capability can use it. And you can check that new capability off on your needs list…and eliminate it from your CRM feature comparison matrix!
But isn’t cloud native going to be expensive?
The example previously outlined was simplistic, but it captures the very essence of cloud native: Custom-developed services that stay outside of complex systems but provide immediate and measurable benefit to your needs. But companies are slow to accept custom development because of a perceived cost issue—cost to develop, cost to manage, cost to host…$$$ everywhere.
But with the Cloud, that just isn’t true anymore.
Because this is a single, isolated microservice, rather than part of a monolithic, layered structure, it’s small—easy for a single developer to create, test, validate, etc. In the example above, this type of service takes only a few hours of skilled developer to create (pick your technology choice: Java, PHP, .NET, OpenSource, Python…the list goes on). Is your need for this service worth ~$2,000 of development? You were ready to pay 100 times more than that for an expensive feature in your CRM!
Hosting is complicated and expensive, right? No! See my prior posts about hosting. A single microservice like this could cost almost nothing if using Azure Functions for hosting, or as low as $50/month if using a containerized solution like Azure App Services. No per seat costs, no infrastructure to pay for, no license costs, just put it out there and use it. Is $50/month too expensive? Most CRM per seat costs are more than that per user!
IT Release Management is painful! But not with the Cloud. Using Azure DevOps, a developer can check their code into DEV, run automated testing against it per check-in, get immediate results of the performance of the service, and never even need to call IT Release Management. If it works and everything passes, it can push to QA automated, too…heck, all the way to production if you are a mature DevOps shop. So, eliminating that entire IT Release Management process saved you money! If you think that’s scary, companies like Microsoft/Google/Facebook, do releases to production every few minutes and you never notice a thing!
So, if you pull it all together, that feature that was going to drive your CRM price tag though the roof ended up costing you a few hours—maybe $2,000 in development—and could be live in less than a week. It’s a no brainer: Cloud native is where it’s at!!
Stop the feature-function comparison and start getting the features you want. Look to custom development in cloud native. AKA can help. Give us a call and let our Cloud Experts help you solve for that missing feature your business needs so desperately… and look like a hero—who also saved the company quite a bit of money.
Watch this video to learn more about AKA’s Cloud Services: