Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘Integration

Sage CRM 7.2 Available for Sage 300 ERP

with 8 comments

Introduction

Earlier this year Sage CRM 7.2 was released for standalone CRM customers. We have competed the Sage 300 ERP integration in conjunction with the Service Pack 1 release of Sage CRM 7.2. We have now released the Sage 300 ERP 2012 integration for Sage CRM 7.2 and this is the integration that will be included in the forthcoming Sage 300 ERP 2014 release.

Generally customers find that combining Sage CRM as a front office solution to Sage 300 ERP as the back office  solution creates a much more powerful combined system than having separate ERP and CRMs. The level of automation, reporting and customer connectedness is greatly increased across the organization. As such introducing a new version of CRM can provide many immediate benefits for companies and this blog is looking at some of the things that are new in this version. We find that customers running both of these Sage products together have much higher net promoter scores than customers running non-integrated systems.

Social CRM

Historically CRM programs managed communications with customers and other business contacts by managing e-mails and phone calls. CRM had all the basic contact information, integrations to help automate these processes like creating e-mails and automatically recording the information in CRM. Auto-dialing phones and logging that you called and letting you fill in some comments. Setting reminders and schedules for performing these tasks.

However, how we are communicating with our business contacts is changing. Many people are using e-mail and voice phones much less than they used to. I ignore most incoming calls from unknown callers because they are usually cold sales calls or scams (like you have just won a cruise vacation). E-mail is getting much noisier with spam and other junk, causing more important e-mails to just get lost. It’s been found that recent high school graduates actually have quite an aversion to actually talking on a phone and don’t use e-mail much.

Now there are many more communication channels. Many people now communicate via various social websites like Facebook, LinkedIn, Google+, Yammer and Twitter. Many calls are made via services like Skype and there are people texting more than ever and even using systems like BBM.

So if we want to get a complete comprehensive picture of all our communications with a customer, we need to see all of these in CRM as well. We added LinkedIn and Twitter connectors to Sage CRM last version and with this version we have added Facebook integration.

socialcrm

With this Facebook integration you can bring Facebook information right inside Sage CRM to better understand your customer. You can associate Facebook pictures and profiles with prospects. Generally this is an avenue to get a more complete picture of your customer, or potential customer’s business.

Getting good leads is usually a big problem for companies. Chances are that for a given customer, his contacts will be related in some way and perhaps offer good prospects to market to. If you do get a response from one of a customer’s contacts then you can use the original customer as a reference to help make the sale, or act as an introduction to get you in the door.

Social Media stores terabytes and terabytes of information on business’s and people. Being able to effectively mine all this information is going to be a huge competitive advantage in the future.

Another social feature added to Sage CRM 7.2 is Yammer integration. Yammer is a social network for collaboration within a company. With this integration your sales teams can collaborate and share information using Yammer from Sage CRM.

socialcrm3

Mobile CRM

People don’t necessarily spend their entire day sitting at their desk behind a computer. They work from home, they travel on business trips and visit customers face to face. You CRM system contains tons of useful information that will help you do your job better if accessible in these situations. Over the past couple of versions and further with this new version, we‘ve been adding mobile features to Sage CRM to make it easier to access from mobile devices.

Sage CRM is a web application and with the previous version we enhanced to work with all popular browsers. This then allowed mobile users (which usually have Safari or Chrome) to browse the Sage CRM screens. Perhaps this works a bit better for tablets, but tends to be a bit of a pain on an iPhone.

As a result we’ve been adding native device apps to complement the web interface to Sage CRM. Plus we’ve been working on improving the web interface so it will work much better on table devices like the iPad.

The picture below shows the Sage CRM web application rendering itself for an iPad:

mobilecrm1

Next we have the iPhone native Sage CRM application:

mobilecrm2

And finally the Sage CRM 7.2 Windows 8 application for Windows tablets:

mobilecrm3

As we move forwards we will be providing more and more functionality on more and more mobile devices so you can instantly get any information you need instantly. Down the road you might be wearing your Google glasses and when you say the customer’s name, all the information on that customer will be right there in your view to reference.

Reporting

With this version of Sage CRM we’ve improved the reporting capabilities. A new HTML5 based charting library has been added, so you don’t need Adobe Flash for charts anymore. You can clone reports to get started with a customization. There are more chart types with more configurable settings. There are new security settings so you can better control who can see what.

Customization

Sage CRM 7.2 adds more codeless customization capability where you can design more powerful screens right in the product without writing code. Sage CRM also doesn’t use frames to hold custom screens anymore. This will affect some ASP based customizations, but generally leads to better ability to control your own web pages (especially the CSS).

Integration

The main change to the Sage 300 ERP integration was changing Quotes to Orders to work in the new frameless Sage CRM web pages. Most other changes have already been released in service packs or hotfixes for Sage 300 ERP 2012, so if you are fully current you won’t see much different. But if you are coming from an older version, you should see a number of improvements.

Summary

Sage CRM 7.2 integrated with Sage 300 ERP make for a powerful front/back office solution. This release is definitely worth checking out especially for the mobility and social features.

Written by smist08

September 7, 2013 at 4:59 pm

A Roadmap for SData Integration to Sage Products

with 4 comments

Introduction

I’ve blogged a few times about using SData to feed data into Sage products and about the general ideas behind SData. In this blog posting I want to look at some benefits to integrating into Sage products using SData and the general reasons behind doing so. A lot of this article is forward looking and so each Sage product is somewhere along this journey and no product has reached the end yet.

Imagine that you are an Independent Software Vendor (ISV) and that you have a great product that satisfies a useful specialized business need for many customers. However it requires some data that is typically stored in an ERP system and generates some financial results that need to be entered into this ERP. Say you need to read all the Orders from the system and then you produce a number of G/L entries that need to be imported. Wouldn’t it be great if you could automate this process by being notified automatically whenever an Order is entered and being able to write the G/L entries directly into the ERP? However, you find that your customers are running all sorts of different ERP systems. As you look into doing these integrations you find that you need to join an SDK program for each ERP and have someone learn and program in all these different ERP’s SDKs and program you integration in all sorts of strange languages from VB to C# to JavaScript to FoxPro. Then you have to maintain all these integrations from version to version as your product progresses and all these ERPs evolve. This is a lot of work. There must be an easier way.

You could take the attitude that you will provide an API and SDK for your product and then, since your product is so wonderful, that all the ERP vendors will write an integration to your product using your SDK. After a few years of waiting for this to happen, you’ll probably give up on this.

Sage has many ERP systems and combined has a very large market share. However all these ERPs have their own heritage and their own SDK. How can Sage make it so this ISV can create their integration easily to a large set of Sage products using their own development tools and programming knowledge?

This is where SData comes in. SData is a REST based Web Service interface. SData is based on internet standards and easy to call from any programming system that supports Web Service calls. SData is a standard being implemented in all Sage Business Solutions. So how will this work in the scenario above?

Method One – Poll for Orders

In this case the ISV application will periodically poll for new Orders on the Orders SData feed, process them and then write any G/L entries to the G/L SData feed.

This method isn’t that different than using the ERP’s built in API in whatever technology that is implemented, perhaps COM, .Net or Java. So at least now for the various ERPs we are using only one API technology to access several ERPs.

Standard Contracts

Generally each ERP has its own heritage and hence its own database schema. Most Sage ERP’s will expose their built in native schema as their native SData schema. So although you can use SData to access a range of different ERPs, you still need to handle multiple schemas to set and return in the XML payloads associated with the calls.

The solution for this is standard contracts. These are specifications for standard SData calls that define a common schema. It is then the job of each Sage ERP to transform their native schema into the schema of the standard contract as part of their job of offering standard contract feeds.

With standard contracts implemented the ISV can then access multiple Sage ERP’s using the same API technology, namely SData, and using the same payload schemas, essentially making the integrations the same.

Method Two – Connected Services

Connected services refer to integrating products whether from Sage or an ISV being located in the cloud and then integrated to an on-premise installed ERP.

Currently there is a concern that on-premise customers don’t want to expose their ERP system to the Internet, meaning they don’t want to manage a firewall and worry about the security concerns associated with an Internet facing web server. This means they do not want to expose their ERP’s SData feeds to the Internet at large. So how does the ISV integrate if they can’t call the ERP’s SData feeds?

Although the cloud application can’t call the on-premise application, the on-premise application has no problem calling the cloud application. This means it’s up to the on-premise application to push all necessary data to the cloud application. Generally this is handled by a synchronization engine that synchronizes some ERP data up to the cloud. The SData specification contains a data synchronization specification for this purpose. The synchronization algorithm is very robust and will catch up if the Internet is down, or the cloud service is unavailable.

We could also provide notifications when things happen, but this is less robust, since what happens when the Internet is down or the other application is unavailable (perhaps offline for maintenance).

Notification Configuration

The above method for connected services assumes that SData synchronization will need to be configured. The core ERP will need to configure a list of SData services to synchronize with (hopefully down the road there will be many), then the ERP will need to ask the service which feeds it wants to synchronize.

Initially this configuration will probably be done by configuration screens in the ERP. However over time it will be nice to move this all to dynamic discovery type services. This will reduce error in setup and allow connected services to evolve without requiring setup changes in all their integrated ERP systems each time something new is added.

If the ERP and ISV solution are both installed together (either on-premise or in the cloud), then it would be nice to configure some direct notifications, basically call-outs from the application when various important things need to be done. This might be for things like requiring a calculation be performed or to notify that an order’s status has changed. These sorts of things will only work when both applications are live and connected, but there are many useful scenarios for this.

Summary

Initial SData implementations are either shipping or forthcoming across all the main Sage business products. We are starting to see integrations of the method one type emerging. We are actively developing connected services using the SData synchronization mechanisms. Then as we continue to roll out SData technology you should see any missing pieces start to fill in and greater uniformity emerge on how you integrate with all Sage products.

As Sage studies the market and determines useful profitable connected services, Sage can publish an SData contract that all our ERP systems will support. Then the chosen ISV can provide this service for all Sage products by supporting this SData contract. Often for connected services we need different providers in different parts of the world, and again it’s easy for Sage since for this one contract perhaps we have one provider for North America, another for Africa, another for Asia and another for Australia.

Written by smist08

February 25, 2012 at 4:04 pm

On the Sage GCRM Contract

with 5 comments

Sage has standardized on a REST based Web Services protocol called SData. This protocol is documented at http://sdata.sage.com/. As a first step this will standardize the technology that you use to communicate with Sage applications. You will be able to issue SData requests to multiple Sage products such as Accpac, Abra and SageCRM. As opposed to using a different technology to talk to each, such as COM, .Net, Java, Soap, DLL, etc. All the products will still maintain their existing APIs, but they will all add SData to their repertoire. Even if you are a reporting type application, crossing multiple Sage products can be difficult as they tend to use different databases or have very different schemas. SData is a nice way to hide these differences and to provide a single consistent programming interface.

The next step is to standardize the actual data that is exchanged via SData. Towards this end, Sage is releasing a number of “contracts” that can be used to interface to a given application. For instance the Sage Global CRM (GCRM) Contract (http://sdata.sage.com/sdatacust_GCRM.html) is a standard contract supported by all Sage CRM products including Act!, SalesLogix and SageCRM. If someone integrates to one of these products using SData and the GCRM Contract, then it will be very easy to integrate to any of the other CRM products.

The GCRM contract was created by Sage for mostly selfish reasons. Sage owns dozens of ERP packages in dozens of regions around the world. Having each of these create a point to point integration with one of our CRM packages was proving to be a huge amount of development effort. Plus the results weren’t consistent, some of the integrations were better than others. This started as an attempt to standardize what was being done repeatedly over Sage again and again. However as the work progressed we realized there are a lot of other benefits. Not only does this save Sage some development time and money but it will:

  • Provide a standard interface for others to do similar integrations. For instance an ISV could integrate another CRM package to multiple Sage ERP’s by taking advantage of the GCRM contract.
  • ISVs will be able to integrate to multiple Sage applications at once (usually part of a suite of products) using only 1 technology.
  • The various application contracts are well documented at http://sdata.sage.com/sdatacust.html making life a bit easier.
  • Using REST based web services is an efficient way to produce a nice lightly coupled integrations.

Each application will still have a native SData interface where you can get at the full functionality of that product. But these standard contract interfaces will make it far easier for ISV’s to integrate their vertical solutions to multiple Sage products.

Many applications have a component of their data that is shared and needs to be synchronized. For instance much of the data that CRM maintains for its companies is shared by the ERP package in its customer’s information. In most CRM to ERP integrations a large part of the integration is keeping this company/customer data synchronized in the two applications. Similarly for an HR application to ERP integration, typically the employee database tables need to be synchronized in the two applications. SData provides a standardized protocol to allow multiple applications to synchronize data in a uniform manner (http://sdata.sage.com/sdatasync.html).

At the core of the GCRM Contract is the specification of how to synchronize the tradingAccount (company/customer), contact, postalAddress, phoneNumber and email tables. The GCRM contract specifies the fields that make up these standard contract definitions (how CRM and ERP expose their native tables) and what the applications need to do to provide the synchronization. In this case the hard part is handled by the CRM application which hosts the synchronization engine. The ERP package just needs to provide an SData feed for each of these tables in the correct format. Then CRM will periodically ask ERP if anything has changed and if so to provide the updated records. The protocol then has the details of how to handle conflicts and how to catch up if one application was unavailable for a period of time.

The GCRM Contract really consists of three parts:

  1. The base customer/company tables that need to be synchronized and the protocol to handle that.
  2. A number of real time data SData feeds in a standard format to access much of the data in the CRM product.
  3. A set of SData feed definitions that allow CRM to provide a basic Order Entry screen, to query pricing information from the ERP and feed orders into the ERP package.

These three parts can be used independently. For instance Accpac could use the GCRM contract synchronization contract to replace the current method and start incorporating CRM data into its own UIs that is retrieved by the real time SData feeds, but then rather than using the CRM Order Entry screen, surface the Accpac Order Entry screen inside of CRM (the quote-to-order feature: https://smist08.wordpress.com/2009/12/17/sage-erp-accpac-6-0-quote-to-orders/).

As Sage moves ahead with adopting our REST based Web Services, SData, you will be seeing more and more new technologies based on this. Generally Sage is looking to develop many SData based technologies that can be shared across all Sage products and can be utilized by all Sage development partners.

Written by smist08

May 7, 2010 at 8:35 pm

Porting Versus Integrating

with one comment

For Accpac we are a large ERP package with all the core accounting modules, and many third party ISV products all written in our SDK. With this approach all the applications have the same look and feel. They all work consistently and share many system services like VBA macros, import/export, data integrity checking, integrated security, shared signon, same database support, etc. Then Accpac also offers a number of powerful interfaces to integrate with other applications not written in our SDK. With this approach the other application and Accpac can exchange data, create source documents in each other’s system, and do all sorts of look ups and inquires. We have lots of such integrations with ISV products as well as other Sage products like Sage CRM, Abra and FAS.

If writing an application for Accpac from scratch, it makes sense to do it in the SDK for all the above advantages. If wanting to integrate with an existing product that runs standalone and has been developed for years, then it makes sense to do the integration route.

There then seem to be a number of more murky cases. For instance if we want an accounting module from another Sage accounting product, then does it make sense to integrate it or to re-implement it in our SDK using their design as our implementation guide? For instance if we wanted a module from Sage Timberline (like estimating or a more advanced PJC) then does it make sense to install both Accpac and Timberline and run the existing Accpac accounting modules and then run Timberline for the one module we want added to Accpac? Or does it make more sense to start with their developed database schema and re-implement it in the Accpac SDK.

Besides the straight implementation of the database, business logic, UIs and reports, then their is the further problem of possibly tight integrations with other accounting modules like Inventory Control, Order Entry, General Ledger, etc. Will we need to add functionality to these to support the new modules? Will we be able to un-entangle the module we want from all its integrations to other modules in Timberline?

As we move to Accpac 6 and our new web based user interface, we would want all our modules to share the same web based interface. Perhaps if the other product can present its data using SData (our REST web services interface), then we can put Orion UIs on that? But that still leaves many problems with the back end integration. Can SData be used to solve this as well, offering standard web based interfaces between the accounting modules as well as between the web server and the browser based UIs? Or would it be easier to just re-implement the whole thing in our SDK?

Anyway just a few interesting questions to consider as we move forwards.

Written by smist08

June 13, 2009 at 3:32 am