I’ve been thinking about this over the last couple of days. As a developer, I’ve seen the full gambit of CRMs. What have I learned after my 3rd CRM implementation?

I started with a fully “custom” solution written in Classic ASP in the Microsoft Stack. That system had 12 years of development in it. It was extensive!

Next, I transitioned the same working system to an open-source CRM called SplendidCRM, written in C#.Net, again, in the Microsoft stack.

And now, we are about a year and a half into moving the same system into the Oracle cloud and into NetSuite and SuiteCommerce Advanced.

I could probably write about this for hours, but I won’t. Instead, I’ll jot down some of the major differences in the 3 systems/platforms.

Oh… one more preface, and then I’ll get on with it. I commend the leadership of my company for their amazing insight. They recognize that business processes stay in place for a long, long time. Tuning processes has an ROI that pays off over time. And now I’ll get on with it.

We had roughly 12 years of development in a custom CRM written in Classic ASP and hosted locally in the Microsoft stack. We are a distributor that tries to get the best deals for our customers. That turns into an amazingly complicated pricing model, with negotiated deals between us, our suppliers and our customers. We looked at lots of options for a CRM/quoting system, but no other canned system was capable of meeting our needs. We are a company full of computer science grads and engineers. So we wrote one!

The downside to our solution was that we are not accountants. That meant our system was a CRM and quoting solution, but did not handle billing, receiving, inventory and general bookkeeping. For that, we integrated with Microsoft Dynamics GP. And that was ugly. After years of integration, we were still waisting a lot of employee time with double entry and reconciliation. Again, kudos to our management team, they recognized this and addressed it.

That brought about a move to another open-source CRM called SplendidCRM. You’ve probably never heard of it. Since we were a Microsoft shop, we chose the only open-source CRM on the market written in the Microsoft stack.

The great thing about SplendidCRM is that you purchase the source code and there are no ongoing subscription fees. It is fully supported by its author, Paul Rony. I was able to contact Paul with questions about his code for years after we installed with no charges. I often wondered how he stayed in business. But he’s still going strong. His code is well written. It’s getting dated though. We installed in 2012, so at that time, a Windows Forms application was state-of-the-art. Now, most everything has moved to MVC. The security model is better in MVC and it is much easier to incorporate unit testing in MVC. So the code “should” be less buggy. That’s very debatable!

With SplendidCRM, we gained business rules, workflows and credit card processing. We still lacked any integration with an accounting system, although we continued to invest time in our integration with Dynamics GP. I’ll add that we looked at incorporating Microsoft’s eConnect add-on to GP, but that was a waste of time. It was more work than it was worth.

And now we are moving to Oracle’s NetSuite in the cloud. Here are some of the great things we gained with this upgrade. And let me add the one negative before I list a whole bunch of positives. It’s very expensive! And now the good stuff.

In my wildest dreams, I could not imagine a system that is so extensible. There are hooks everywhere that allow us to customize our user’s experience.

It is well documented. So well documented in fact, it actually can make it tough to find answers to questions or solutions to issues. This is a big change from SplendidCRM, which had almost zero documentation.

It is an accounting system! This is good and bad. Having a quoting system that’s separate from your accounting package solves the problem of dual entry or deep integration. But it adds problems too.

In an accounting system, you can’t just change history. Parts (Items in NetSuite) are assigned attributes like “item type.” For-sale items get a type, like “Inventory”, “Serialized Inventory”, “Non-Inventory for Sale”, “Non-Inventory for Resale”, “Service”, etc. There are additional item-attributes that only matter in the accounting world like “Costing Method”, LIFO versus FIFO versus average. All these things get cast in stone and recorded the first time an item is used. Sometimes, mistakes are made. Those mistakes live on forever in an accounting system. This can cause your catalog of parts to bloat and make it difficult to find what you are looking for when putting together a quote or an order. This is actually a positive, read on!

Regarding transactions, again, because NetSuite is an accounting system, a sales order transitions seamlessly to a pick ticket, a packing slip and an invoice. This is great because the transaction flows beautifully through the entire business process with zero double-entry. But the sales order is locked from the time it gets approved and the first down-stream transaction created from it. The only way to back up is to delete all downstream transactions first. This is good because it forces you to do it right. In SplendidCRM, where the CRM and quoting system was unhooked from the accounting system, we were free to change sales orders at will. Sales orders drifted out of sync with invoices and other downstream transactions, a record-keeping nightmare.

Here’s one more thing that has been very helpful after our transition to NetSuite. The ability to create custom fields, custom modules and manipulate screens is much better in NetSuite than it was in SplendidCRM. This is the classic scenario of greater functionality also equates to additional configuration. SplendidCRM was more configurable but also more work to configure. Here’s what I mean by that. In SplendidCRM, if you changed a screen, like the screens to view and edit a quote, you had to change both view and edit screens. They were not kept in sync automatically. If you changed the way quotes or orders listed under a contact, that didn’t change the way they displayed under an account. Nothing was kept in sync by default. NetSuite offers less flexibility, in that moving a field around on the screen in view-mode also moves the field in edit-mode. That’s actually a big plus on the administrative side. Love it!

One more thing about NetSuite. If you are going to write code outside of NetSuite that drives processes inside of NetSuite (like importing data or data synchronization), you have a couple of options. SuiteTalk is a web-services solution. RESTLets are a restful solution. Because I’m a Microsoft developer, I chose the SuiteTalk route. SuiteTalk is a typeful binding to NetSuite APIs. This equates to lots of rules! With RESTlets, there’s more spin-up time involved for developers and more initial coding, but fewer limitations. I’ve found that there are things that I can do with RESTlets that simply aren’t supported in SuiteTalk. An example of this is accessing SCA record types, like Commerce Categories.

OK… enough rambling for today. I’ve got work to do. I hope this is helpful. It was fun for me to think this through.