If you have read through the buzzword bingo, and ideally the detailed descriptions of the individual concepts too, then you will now have a rough idea of what terms such as EDI, EAIor SOS mean. The question now is whether you would need something like this yourself, and if so, what exactly you need.
QUESTION 1: WHAT DOES YOUR IT LANDSCAPE CURRENTLY LOOK LIKE?
There are still companies whose IT systems consist of a few PCs with MS Office and an email program. Orders arrive over the phone or via fax, the warehouse manager has the inventory in his head, and delivery notes are filled out by hand. Larger-scale IT systems are nowhere to be found. If that works well for you and there aren’t any business partners demanding EDI processes, you can forget about the subject for now and put this manual to one side.
However, most companies nowadays no longer work like this, and once they reach a certain size (or work with big enough business partners), they have no choice but to digitalise one business process after another. And as mentioned in the description of EAI, that often happens bit by bit. Somewhere along the way, you end up with a diverse
assortment of IT systems, all of which have different data formats and interfaces and are unable to communicate with each other.
Perhaps you’ve already gone through this phase, and have spent the last few years cobbling together a mishmash of C programs, shell scripts or even Excel macros that you use to get data from one system to another. Plus, let’s not forget your major customers or suppliers who have recently begun lumbering you with data in a format specified by them. And now those customers are threatening you with penalties for not sending their data back to them in the same format, so your programmer is ready and waiting to rustle up a bunch of new programs and scripts to solve the problem – each of them will somehow carry out a particular task (though it will be a miracle if anyone still remembers how six monthslater). And if a business partner comes along with slightly different requirements then you’ll suddenly need another few thousand lines of code.
Please, pull the emergency cord! If you carry on this way then you’ll end up in a very sticky situation. And that’s not to mention what would happen if your programmer went missing – at least within your organisation. In that scenario, you would be left with endless different sources and absolutely no idea what is going on in the background or how you could ever make any changes to it.
QUESTION 2: HOW PRECISE ARE YOUR FUTURE REQUIREMENTS?
What has been happening so far in the space between your individual IT systems, and between your business and the outside world? You should start by analysing this in depth. Has communication with the outside world virtually ground to a halt? Do data need to be transported and reconciled between your own systems in order for that to change? In that
case, you are looking more at EAI, and possibly also ETL.
Do orders come in from outside your organisation, and do order confirmations, delivery notes and invoices need to be sent? Do you regularly send electronic catalogues to your customers? Do you have lorries on the roads whose locations can be tracked (via GPS services)? Whenever data flows to you from outside your company or vice versa, that falls
under the category of EDI.
What kinds of systems do you have in your organisation? Databases? SAP? Older ERP systems that can only import and export proprietary file formats? All this will determine how and with whom a possible future EAI or EDI system needs to be able to communicate. And how does the outside world talk to you? Do you receive Excel files? Will that remain the case? Shouldn’t your system also be able to handle general standards in order to be future-proof? Standards such as EDIFACT, X12, XML, and so on? Does all your communication take place via email, or are secure transfer paths such as AS2 or SSH-based communication required?
These questions will determine what your future system needs to be capable of. And a lot of different things come together when you start thinking in these terms, don’t they? A specialised EDI or EAI system may no longer be adequate, as the tasks of both areas need to be covered. Oh, and let’s not forget about regular reconciliation between multiple internal databases, which falls under the scope of ETL. And then there are your customers, who would like to send you queries about your current inventory (for example). That problem can be solved brilliantly using web services. Then you can deploy either multiple specialised tools for each specific area, or a single tool that may not match the optimum performance of those specialist tools, but does bring everything together under one roof.
QUESTION 3: WHAT SHOULD EACH TOOL OFFER YOU?
Aside from EAI, EDI or ETL-related abilities, there are a number of additional aspects to keep
in mind:
Is it alright for the tool to require a specific system (Linux/Unix, Windows, or even AS400/iSeries)? Or do you expect it to be platform-independent? Or better yet: should it be installable in just a few clicks via a container-based method using Docker, with no programming required? What’s the operability like? Should you have to learn a sort of programming language before you can get the software working? Or should the focus be on professional matters, with the software operated more intuitively? With the latter, do bear in mind that EDI and EAI involve highly complex processes that even a professional can’t simply patch together in just a few clicks – so please manage your expectations when it comes to intuitiveness!
What role does licensing play in your business? Do you buy licences or rent services? The ideal solution would be highly flexible. In other words, on-premises (cloud provider), with no additional technical expense. For that, EDI experts recommend the option of a dongle-based installation.
What does the monitoring look like? Do you always have a clear overview of whether everything is working, or whether there are any errors that need to be fixed? Does the system actively notify you of any problems?
How important is transparency to you? Why not simply open your browser to display all important system information in a quick and straightforward way in modern HTML5? All under the motto “any place, any time, any device” – whether laptop, tablet or mobile phone.
Data security is also a crucial consideration for business-critical data. For example, can invoices be archived for the period required by law? Are all important data and logs kept available for inquiries at a later date?
Further specialised requirements may also come into play, especially in the EDI field. For example: in some countries, digital signatures are still required for certain types of data (especially invoices). That obligation has long since been abolished in Germany, for example, but you might need to be able to integrate a signature system in your country of business or when you do business with certain other countries.
On top of that, a standard tool often provides you with an endless list of functions – and yet Murphy’s law dictates that you’ll end up with a highly specific requirement for which your tool doesn’t provide an ‘out-of-the-box’ solution. Will there then be options to extend the system yourself? Not everyone has their own in-house programmer – but even if you do, the software you deploy should still offer interfaces that make it possible to manage things and add your own extensions. Or should the manufacturer at least offer to develop those extensions for you?
Last but not least: What’s the situation with support? How quickly does the manufacturer respond to problems? Do they also offer help with more straightforward questions? What do people say about them? Spending hours on hold for the customer hotline is a thing of the past. Why not receive direct support in just one click with the help of detailed explanatory videos or contextual documentation?
When you were reading question 1, did you realise that a tool like that wouldn’t actually be such a bad idea? Then you should think carefully about the points listed under questions 2 and 3 too. If you know what you expect the software you’re looking for to provide then take a look around on the market, have your key scenarios evaluated by different
manufacturers (how expensive are they, and will they even work?), and see which product meets the majority of your requirements. It might not be the cheapest one, but it’s better to make the right investment up-front than to regret buying the wrong program after endless rounds of breakdowns, extra work and lost time.
To round things off, you can also take a look around on the Internet or ask other companies in your industry whether anyone has any experience with your preferred product and find out what they have to say about the product, the manufacturer, the support etc. from their own experience.
The EDI experts at Lobster GmbH will also be happy to help answer any of your questions about EDI and EAI (info@lobster-uk.com).