What is our primary use case?
We are a third-party logistics company. We work for a lot of people. We've got SEEBURGER Business Integration Suite (BIS) because we needed an SFTP server. We have a lot of customers at various levels of IT maturity. Originally it all started off with just FTP, but we now use AS2 and SFTP an awful lot, and we're now moving into the API world.
There are some common interfaces here and there but, generally, it's all bespoke to each customer, of which we have about 75 to 80 and that's changing every month. We run in the realm of 800,000 processes a week. There is about a 50-50 split between internal systems talking to it and external customers sending files in.
The solution is on-premise.
How has it helped my organization?
We now have everything on a single system, which is nice. We got rid of a lot of the legacy, although we now have a legacy SEEBURGER system.
The solution's capabilities in fulfilling our existing B2B integration requirements are brilliant. Among our multiple customers we connect to SAP systems, JDE, all the various ERPs that you can possibly get, Oracle procurement systems, etc. We haven't come across anything yet — and customers are trying to trip us up — that we can't do.
Using the solution, we've created our own processes such that we have our own building blocks. That has made it a lot quicker to deploy interfaces. I would estimate our efficiency has increased by 50 percent as a result.
I don't know if the solution has saved us money, but it has given greater capabilities and therefore we can make more money because we are able to connect to different customers' systems.
What is most valuable?
Its flexibility is the most valuable feature. We can hook up using any protocol that's out there, to anybody. We've got a good in-house team that can work out with all the parts of it, including transformations for the bespoke processes that we sometimes need.
We're not using half of its capabilities at the moment so haven't hit the edges of it yet. We're not particularly leading edge, nor are most of our customers.
What needs improvement?
There are some aspects of the front-end GUI, the actual queries that you use, that could be improved. They're all very minor to be honest. It's quite a nice modular system. It fits together quite well. The changes would be to the usability of the system at the front-end. It's not the underlying processing function of the system. It's how we maintain things and being able to see what's going on.
For how long have I used the solution?
We've been using the solution for about ten years.
What do I think about the stability of the solution?
The stability is generally pretty good. We used the first version we installed and we just left it, which is where this aspect of then not doing reviews of the current technical solution came in and tripped us up a couple of times.
The new version is very stable. We haven't had any issues at all. At one point our database disappeared for ten minutes and it didn't notice. The system stayed up, which was rather nice. It didn't cause any major outage, which it should have done. It's a well-thought-out and implemented system, from what we can see.
What do I think about the scalability of the solution?
We have no issues with scalability at the moment. The old version was really creaking at the seams when we eventually migrated everything, or most things, off it of it. That was a bit touch and go for a couple of months. The new one has not got any issues at all.
The usage is increasing all the time. It is the integration tool within this company. It's a central part of all the internal processes that we have. It's the glue that holds the company together as such, in a lot of cases. It is being invested in quite heavily.
How are customer service and technical support?
Their technical support is okay. It doesn't blow you away. They will come back with an answer. It won't be the answer you would like, generally. For the first seven years, and since we got 6.3.2 in, the answer was always, "You need to upgrade." That was kind of annoying, but to be expected I suppose.
We've been landed with a consultant from SEEBURGER who doesn't know the system inside and out, which is a little bit frustrating sometimes. Other than that, they generally come back with answers to queries reasonably quickly and accurately.
Which solution did I use previously and why did I switch?
We were previously using Mercator as the transformation tool, but it was very old at the time and needed replacing as it was unable to provide SFTP.
How was the initial setup?
The setup is getting a lot smoother. It's reasonably easy in the latest versions. Our previous system was generally Unix. We're now on to virtually a wholly Windows setup, which brings different sorts of problems. I'm actually quite impressed with the way that the SEEBURGER team is able to put out patches. It's very smooth, which is quite refreshing.
It took about four or five months from starting the build to actually getting off of customer migration.
We are currently migrating from 6.32 to 6.52. The initial migration was reasonably good, but we have an awful lot of customers — individual companies that we connect to — and some of them are pretty difficult to get off the old system. We're getting close to the end. There are some IT departments among our customers where they will put the initial product in for connecting to us and then everybody leaves and there will promptly be a problem. But we'll get there. We do have a plan to move to 6.7 fairly soon but we need to get rid of the old one first.
We haven't found that many differences between 6.32 and 6.52 — the two versions that we use. We have had to change some of the transformation codes to fit in.
For our migration, the strategy was basically to build a brand-new system, which is what we had to do anyway. There was no getting away from that. With our current system, we may well do an in-place upgrade from 6.52 to 6.7. We just have to add a few servers and then we're good to go.
What about the implementation team?
If we were going to jump a major version, which effectively would be an upgrade, then we would get a SEEBURGER guy in. One thing we have found over the years is that we probably do need to keep in contact with their consultants a bit more, checking with them occasionally just to make sure that we're not doing something that has been discovered as being not the ideal solution. We've been tripped up a couple of times with that. That's just something we've learned.
We had a consultant in this year to be able to install some new aspects of the system. We will probably get them in next year to go through a review of the system to make sure that we are currently doing everything as they would recommend. They do seem to change their recommendations but don't actually get in touch with us about them sometimes.
We're having to manage them, or certainly will, going forward.
What's my experience with pricing, setup cost, and licensing?
On an annual basis, our support costs, which are based on the licensing, are about £120,000.
As you increase the size of your system, the per-CPU usage goes up. You're licensed for CPU and any modules that you may require, such as API management. The maintenance cost, going forward, is 20 percent.
There are no additional costs to the standard licensing fees, other than consultancy, which is usually required to install a new aspect of the system.
What other advice do I have?
The fact is that we use it for everything. It's pretty good really.
My advice would be: Don't hand the initial development over to SEEBURGER itself. When we first put the product in, the SEEBURGER consultants that came along wrote very complex interfaces for things that didn't really need to be that complex. We're only just removing some of those complexities, because it's not really very supportable. The best thing would be, if you're doing it the way we do it, to either hand it all over to SEEBURGER and let them look after it, or if you're keeping it in-house, get your people trained to the eyeballs so that they can do the initial system setup themselves.
In our environment, there aren't really users, per se. We allow some users within IT to view the front-end, but that's ten people at any one time. However, as I say, the number of processes that run through it in files, that's what we consider to be our user base, and it's in the vicinity of 300,000 per week. We have a team of four to deploy and maintain the solution. We call them the integration specialists or EDI specialists.
The fact that SEEBURGER invests a high portion of revenue into R&D, rather than promoting brand awareness, is good for us. Some local companies use SEEBURGER & they usually take it on because they need some aspect of the system that isn't provided for by any other systems.
We have plans to use one of the solution's additional services, the API management. We use our own, in-house MFT, which we don't require to become cleverer than it currently is. It's a very simple sort of system. But the API, that's the new kid on the block, which we will start working on. We're starting on that path. That will be work that happens this year, probably when we migrate to 6.7. That's when the API management will come in, in a major way. It's not so much our customers who are driving that, it's more suppliers.
Which deployment model are you using for this solution?