The Truth About Front Office / Back Office Integrations
Front office / back office integrations set my teeth on edge. For anyone that has spent a significant amount of time working on them, you know that they often elicit fear from those involved. There are some good reasons for this. First of all, they’re one of the few areas of a larger project that have to be 100% on day 1 of deployment. This type of integration is also typically the most visible component of a larger project, and it usually is the most challenging technically (as you may only have expertise in one of the 3 applications involved). The flip-side of this wariness is excitement at the challenges ahead, but it always pays to go into integrations of this type with the right mentality.
Most customers we deal with either already have, or need to institute, a model whereby their sales application talks to their accounting application. The reasons for this are many, but they shouldn’t be taken for granted either. Neglecting to ask about the key drivers for an integration, and a failure to receive clear answers, is where you get tripped up. Here are a few reasons:
- Accounting owns customer credit information and needs to make the sales team aware of credit limits, credit status, payment terms, and so on…
- Invoicing is done from the accounting application (therefore customer addresses need to be stored, or at least available, within the accounting application)
- The fulfillment (sometimes called shipping) aspect of a company is done via the accounting system
- Sales commissions are almost always calculated in the accounting system
- Reporting regarding revenue (including recognized revenue) is done based upon data in the accounting application
- Accounting usually is the system of record for inventory and product specifications, including prices, units of measure, availability, status (active or obsolete)
So far, so good. Forgive me for outlining the obvious, but here are a few functions of your sales application that bump up against the above accounting functions:
- Product selection and pricing
- Credit status of customers (sales people generally like to know what the credit status is of their prospective customers)
- Current customer contact details
- Sales orders are frequently created and managed in the sales application. The building and submission of a sales order to the fulfillment and invoicing team can be done either in the sales application or in the accounting tool. In today’s duplication-of-effort conscious workplace it often makes more sense to have the salesperson building the order (they know the most about what the client wants, after all)
- Invoice history – many sales teams want to know exactly what a customer has paid for. What if the order you submitted was changed during fulfillment? Do you want to know how much commission you got on a particular order? Sales teams want this information, and more often than not can only come from the Invoice system-of-record; the accounting application
The functions outlined above provide an initial list of why the front and back office need to interact, but each client is completely different in their history, process and goals. For those reasons, it is absolutely key when approaching an integration of this type to ask, and get answers, for ALL those scenarios. Clearly, as a project manager you have to work within your scope, but finding the answer to those questions is fundamental to delivering an effective integration between the front and back office (even if you are only owning a section of the overall integration process).
The client requirements of an integration of this type can have a major influence on how complicated things get. I note a handy list of confounding factors below. Generally speaking, for each of these conditions that is true then the more challenging the project.
- Client does not currently have a programmatic integration between front and back office (meaning they are using paper and pencil methods to submit orders / invoices to accounting)
- Client is supporting a web-ordering function in addition to traditional sales order
- Client is instituting a brand new application either at the front end or the accounting side
- Client is instituting new applications on BOTH sides of the integration
- Client is deploying the integration in multiple office locations nationally
- Client is deploying the integration solution internationally
- Client is deploying with multiple languages
- Pricing and Product inventory is unique for different locations (Japan has higher prices, but deeper discounts, for instance)
Then there are the complicating factors involving the technical landscape:
- Is there an off-the-shelf* integration platform to link the two?
- Is there a piece of middleware that has an interface that links with both ends of the integration?
- If there is none of the above, does the application have an interface that can be used to insert, edit, and remove records? These are usually referred to as web-services
- Finally, if a direct SQL integration is identified as the only way forward, what are the characteristics of the two applications from a SQL standpoint (are they on the same SQL platform, how transparent or complicated is the database schema)
*By the way, there is no such thing as an off-the-shelf integration package. They ALL require lots of loving attention to get them working. To give you all the different issues you might encounter would require another blog posting.
Once you’ve figured out the landscape in terms of the client process, the technical situation, and the deployment scenario you can start to work with the client, the other partners in the project (the accounting team, or maybe the middleware developers), you can start to plan the project timelines, test scenarios, development schedule, training and so on (that’s another blog!). Are you still wary? Good!