Connecting Safefood 360° and your corporate IT platforms

Writing in 1624, nearly 400 years before the age of SaaS applications, the famous English Metaphysical poet, John Donne observed in his Meditation XVII something that is reflected through the centuries –

“No man is an island entire of itself; every man

is a piece of the continent, a part of the main;

if a clod be washed away by the sea, Europe is the less”

What, you might think, does this have to do with the integration of cloud-based software applications in the 21^st century?!  At a technical level, not very much, but at a conceptual and philosophical level, quite a lot! In the world of business applications, individual software platforms covering specific operational domains (such as accounting, CRM or food safety compliance) all form part of the overall IT universe in a business; “mankind” or a “continent” in Donne’s terms.  The problem that exists, as expertly summarised in my colleague Philip Gillen’s article on this same subject back in December 2015, is that connecting individual IT solutions in an enterprise to its IT universe (i.e., the sum of its technology platforms) is a lot more complex than subsuming a man within mankind or a clod of soil into Europe.

The reason for this does not need to be explained through complex technological analysis but can clearly be comprehended through John Donne’s imagery.  A man is a homogenous, albeit very small, part of mankind and a clod is a homogenous, albeit very small, part of Europe.  Now, this is precisely the problem with software platform integration; a food safety management platform like Safefood 360° is certainly a very small part of an enterprise’s overall IT estate, but it is certainly not a homogenous part of the whole.  Unlike men or the continent, the IT universe within a business has grown up from completely different directions and is not a contiguous whole at all.

Whilst this may be the case, the requirement to try and make different platforms an embedded, seamless whole still remains, and, in fact, has definitely grown over the last 3 years.

From a commercial perspective, then, here are the 4 key factors I think that enterprises should consider when implementing Safefood 360° and determining how it will integrate with the overall IT universe in the business –

1. Implement the “vanilla” version of the application first of all.

By this I mean focus on the actual solution itself and the line of business operational reasons that you purchased it for in the first place.  The reasons for this approach are simple enough – if, for example, you are implementing Safefood 360° to manage your food safety compliance environment, the biggest productivity gains that will accrue to your organisation are from moving from your legacy systems (typically a mixture of paper, Word, Excel, SharePoint etc.) to a single, holistic solution.  Focus on getting these vital business benefits right first.

Secondly, from a risk management perspective, attempting to do two projects at once, namely implementing a line of business application and simultaneously looking to connect it with the other platforms in your organisation’s IT universe increases the complexity of the process significantly and consequently the possibility of delay or even failure of the project.

Thirdly, from a purely practical perspective, how do you actually know what all the critical points of integration will be and how they should work with your other solutions until the initial implementation has been completed and has been live for several business iterations (e.g., month ends, audits etc.)?

2. Understand and define what you are going to integrate.

In a number of IT projects the “sex and sizzle” (such as integration) is what makes the internal headlines, but the reality is that the big commercial gains are often found in much more pedestrian areas of the project.  The marginal cost of the sex and sizzle components is also, interestingly, quite often somewhat greater than the marginal gains in productivity they deliver.  Thus, to affect a complete end to end integration is a complex and expensive process, so a detailed assessment of where the most value is going to be delivered must be undertaken before the integration process begins.

An important part of this exercise is to clearly understand the nature of the data concerned.  In most business applications there are essentially two kinds of data – permanent/static and transactional.  The essence of these two sets of data is different and so is how they can be connected to the wider IT universe within a business – certainly as far as Safefood 360° is concerned.

Permanent data is integral to the setup of any new system and is to the fore when loading information from the array of disparate legacy systems which are generally being replaced by the line of business application that is being implemented.

As a purchaser, you need to ensure that the supplier you are choosing has the necessary skills and experience to do this quickly and efficiently for you.  This process can usually be defined as an ETL exercise (Extract Transform Load) and a smart supplier can frequently add value in this phase by perhaps cleansing or verifying the data in some ways that you can define with them.  Of course, permanent data is not actually permanent, it just changes less frequently than transactional data!  So, for example, in a food safety management system suppliers and customers do not stay the same forever and they will need to be updated on a regular basis – whether that is every hour, day or month depends on the nature of your business.

In hierarchical terms, transactional data is data which in some way appends to master data.  Thus, a supplier might deliver many products and it is the delivery of these products which is transactional whilst the supplier is permanent.  Transactional data operates at the intersection of different applications – a raw material that is delivered to a factory for processing will be recorded in an accounting platform but also in a food safety management platform.

3. Decide where your data resides.

This is the critical question that has to be answered and, based on this, the integration that might be required can be designed.  In many businesses, permanent data will be held in their ERP (Enterprise Resource Planning) platform and this should be the “one version of the truth”.  Other systems in the company’s IT universe should have their permanent data updated at the necessary frequency from this platform.  This is easy enough because the nature of, say, the name of a supplier is the same in whichever platform it appears – in Donne’s language it could be considered part of the homogenous mankind!

However, it is not so simple with transactional data.  Take the raw material in point 2. above.  When this arrives at the factory it is, in the ERP system, primarily an item of stock which has a cost attached to it.  However, to the Food Safety Management system, it is an item which has a risk profile against it which needs to be tested – it probably doesn’t have a cost attached to it and may not even have a volume (because the risk is not necessarily a function of volume).  In other words, the same exact material is treated in similar but definitely not homogenous ways in different applications.

Because of this, no one platform exists where all of the properties of that material (cost, volume, risk profile, etc.) are natively stored.

So, if you want one version of the truth where should the amalgamated data be stored?  In our experience, many Food Business Operators want all the information stored in their ERP system and this is the scenario where some transactional information has to be sent to and from the other platforms in the IT universe.

By way of example in a food safety context, the delivery note attached to a trailer of raw materials received at the factory is scanned and reconciled to the relevant Purchase Orders by the ERP system, which then transmits a list of materials and volumes received to the Food Safety Management Platform.  This system then generates the required receiving tests, which are then conducted and the results sent back to the ERP system.  If the goods pass then they are allowed into the factory for processing, if not they are held for further analysis.  This idea of a seamless and integrated production process linking accounting, compliance, risk management, and manufacturing is exactly what businesses are looking for but I would be very surprised if this exists in a completed format anywhere in the world today.

Why?  Surely the technology is available – Web Services, APIs, JSON responses, couldn’t these be combined to deliver this Utopian connected universe?  The answer, again, can be more easily expressed in Donne’s imagery – “mankind” is a homogenous concept but imagine if one tried to make mankind up out of men, lions, zebras, and cows – they are all mammalian vertebrates but there are a lot of differences between them.  This is the issue with business applications, the underlying nature of much of the data (cost centric, risk-centric, etc.) is heterogeneous.

This means that it is a much more complex exercise than just passing bits of data from one application to another – the differing properties of the data have to be properly mapped out first.

 

4. Specify and deliver achievable integration projects

By this I mean don’t ask for a continent and deliver a clod!  On several occasions, I have worked with global sized businesses who have the technical capability and budget to deliver the integrated universe.  However, by the time the project has been precisely specified and the necessary resources gathered to complete the program, other factors in the business have moved on and it has never been properly executed at all.  Start with small but clearly value-adding elements of integration – such as simple connective processes which avoid duplication and transposition errors, and implement these effectively.  Note that this can apply to both permanent and transactional data.  Once the initial integration has been delivered and value demonstrated to the business, the budget and appetite for larger and more complex projects will start to become available.