Integrating CRM and ERP in SMB/SME

Carol Smalley
Managing Editor, CRMGuru
Member

Posted 16-Dec-2003 01:48 AM
Posted by Carol Smalley (Editor) on behalf of Hernan Seivane [hseivane@tacticasoft.com]

We have developed a CRM solution for SMB. Some of our customers are asking for an integrated solution that covers ERP and CRM areas.

Should we develop an ERP component for our CRM or should we integrated with already existing vendors?

Hernán Seivane
TacticaSoft

Carol Parenzan Smalley
Managing Editor
www.CRMGuru.com
carol@CRMGuru.com

Vishal Sarkar
Member Council
Member

Posted 22-Dec-2003 04:18 PM
Hernan,

The question you have is similar to build or buy scenarios too.

I would say that this is driven by business requirements of your customers. Can you build a custom ERP that will fit all your customers' need? Is it going to be platform independent? and backend independent? Since it is a business application, it definitely will require customization—how easy can you design it to be customized? Are you going to provide a custom development environment for ERP customization also?

These are just a few basic questions you should ask yourself. Just developing a product is the beginning and not the end. Sustenance, upgrade and maintenance of the product are also key challenges. Furthermore can you achieve the ROI for this ERP?

Now, if the number of customers that require ERP are not substantial, I would suggest you integrate your CRM with different ERP apps. This will allow you to focus on the CRM solution evolution.

If you are intending to build the ERP functionality :

I read this two ways -

Should I expand the functionality of the developed CRM to cover ERP functions—by making certain more 'modules'?

OR

Should I develop a separate application for ERP that integrates with my CRM app.

Both of these may seem the same but there is quite a bit of difference in these statements.

In the first scenario we are talking about expanding the present CRM solution itself by increasing its functionality. The base for this
would be the already made CRM app.

In the second scenario, we are talking about developing an ERP app from scratch with all ERP functional modules, YET giving an interface to the CRM app.

I would suggest that you build a separate ERP solution that does justice to the ERP functionality it can offer and then allow ways for this ERP app to integrate with the CRM.

The reason is that we should keep a scope of the CRM solution. With wish lists coming in it is quite common for the scope to keep slipping and finally the CRM system creeping to the functional aspects like finance etc. This makes the overall solution larger and more difficult to maintain. At the same time it also does not do full justice to either CRM or ERP functionalities.

If it makes any difference, then you could also see this trend with all the big ERP vendors. They have not expanded the base ERP app to include CRM but rather developed and marketed a separate CRM app that ties in well with their ERP as well as other ERP solutions.

Best of Luck,

Vishal

Mihir
Member

Posted 10-Jan-2004 09:56 PM
Hi Hernan
I think that integrating to ERP is a massive task which will involve a fair amount of development and also expertise to develop api's. If you expect fastest ROI and a reduced time from design to deployment then I suggest that looking at EAI vendors will be the best option. Taking an OTS or off the shelf EAI solution has many advantages among which I have already mentioned two above . Other advantage will be ready expertise and fast customisation. Also EAI specialist usually have real time case studies or examples which can relate to almost any kind of integration hence due to this experience problems can be solved before they arise . hence my suggestion is in the build and buy scenario . Buy is always the more advantageous solution when integration to ERP or legacy is involved.
For your information I have more than 2 years of experience in working with a EAI product called iBOLT. iBOLT is projected for SME's and it is an affordable solution. For more information you can login to www.magicsoftware.com

Norbert Dreier
Member

Posted 16-Jan-2004 06:07 AM
Hi Hernan,

three years ago we had the same situation in my CRM-project. We introduced a wide CRM-solution (TPS Oceans) for a utilities-company in northern germany, containing process-support for marketing, sales and service (customer care). On the other side we met an existing ERP-solution (SAP IS-U (industrial solution für utilities)). So the task was to connect the systems, so that both systems (and their users) get the right informations at the right time to do their jobs.

We solved the problem specifying and building an interface beetwen the two big systems. The base of the interface are the business rules (processes). The processes are assigned to the staff an the systems. When, i.e., a new customer is created in the CRM, it will be transmitted to the ERP as soon as he signs his first contract or order. On the other hand, data from i.e. the utility-billing process in the ERP-System is beeing transmitted to the CRM. This process support via the interface ist realised for all processes (functions) in marketing, sales, service and billing, that need data from the other side. Depending on the concrete processes the interface works partly online, partly over night.

So, back to your question. If in 1999/2000 we watched the market for EAI-solutions to find any suiting our requirements. Many of the EAIs seemed to fit from the descriptions. But in closer view they didn’t or werde extremly expensive or extremly difficult and complex. That led to our decision to establish an own solution. From todays view this decision was very good.

On the other hand EAIs in the meantime are and work much better than 2000. However, in my oponion the conncetion of two systems (CRM<>ERP) should be done with individual interfaces, espacially when the system to connect the CRM with is no standard and/or the processes to support are no standard (like accountancy or budget processes). For this themes EAI is not economic.
EAI should be used, wenn i.e. one billing system is to bee connceted with several other systems, because then the building of the middle tier for the first connection should bring great advantage for the next conncetions. But watch the costs for good EAI-solutions (including then big projects AND the products) .....

Building an own interface-solution beetween CRM an ERP isn’t an easy thing, too. But if you use own functions of the other system instead of writing in the database of the other system, your problems will be minimized. I.e.: if the CRM moves a new customer into the billing system, this is done with an original SAP-function. So the interface uses all original rules of the other system and you don‘t threat the other systems with bad or unproofen data. Next advantage: you don’t have to do (expensive) updates on the interface, because the eai-vendor says so. This minimizes the costs for the interface after going live.

So the decision beetwen building an own interface or buying an customize an EAI-solution depends on the the situation and the needed solution and isn’t to be answered the same way in any situation. In our own situation in 2000 the decision for an own interface was right and would be right today too. But this isn’t or musn‘t be the right decision for other situations. If you could describe your concrete situation a litlle more, i would like to tell you my view.

Please apologise my bad english.

With best regards from Germany

Norbert Dreier
Project Manager CRM
NordIT GmbH

Mihir
Member

Posted 18-Jan-2004 09:49 PM
Hi
Well answered by Norbert here and you have mentioned in clear english so no problem there Smile. But I would like to highlight the one line which he mentioned and that is "On the other hand EAIs in the meantime are and work much better than 2000" The EAI tools provided in the market are currently not only user friendly with open source for your customisation but also very affordable. There are cases where there is only one interface required i.e. there are only two applications involved in integration but we have to think of scalability. If there is any level of increase or change in scope then again we need to provide resources and we need the expertise to go ahead.Also one more thing Norbart;currently you have integrated to ERP but if you want to further more integrate to some more system like salesforce automation maybe then again you will have to do build some solution becuase then buying an EAI will not be cost feasible. So if you have an EAI which is currently only talking to ERP then I can assure you that the same tool can be used with its adaptors to connect to some other system.
What do you think Norbert?
Warm Regards
Mihir