SEEBURGER Business Integration Suite Reviews

We primarily use it for standard EDI practice forecasts, firms, ASNs, invoices, etc. We use everything here, including VDA, EDIFACT, and ANSI, but we are also now having our customers send us drawing files, and then we're sending them off to our engineers.

Our business has grown to have 14 major customers, which implies orders of greater than 200 parts per customer. If we include ship-to then we're probably talking closer to 50 new customers that have moved to EDI. I don't think we would have made it through the pandemic, to be honest, without this.

I have a tiny team in Spain that was entering every one of those requirements manually until we switched over to SEEBURGER, and then we could get them added pretty quickly. Now, for the first time in our history, we are adding Asian customers. Branches in India and China are starting to get EDI started, which has never happened before.

BIS provides me with everything in a unified platform and I haven't needed to add any third-party solutions. 

This product helps us to automate processes. Previously, we would have normally manually entered requirements and now, we just let it read them in automatically. As an example, just one customer with a 200 part requirement that goes out over 12 months would normally have taken my team two hours per week, just to enter the requirements. Now, it just happens and there is no work required at all from the team. In this regard, it has absolutely helped us to increase efficiency. 

At this point, automation hasn't led us to reduce the number of employees that we have. As such, I don't think that we've decreased any of our costs. 

SEEBURGER has helped us to enable digital business transformation. Every time we add a new customer, there is a digital footprint. This is no longer a manual process.

The fact that BIS is available in the cloud, on-premises, and as a hybrid deployment is very important because it means that we could take from one to the other. That is amazing.

The product somewhat helps to future-proof our business. I can add new adapters, for example. We're strictly on EDI and I know that they have more offerings than that, but we have not moved past it yet. Certainly, they are not stopping with EDI, which is good.

The most valuable feature for me is being able to make changes on-premises, without having to contact SEEBURGER. It allowed me to work on my timeframes, which is important because if I didn't hear back from a customer then it wasn't wasting SEEBURGER's time. I'm able to work more independently. 

The cost models have room for improvement. There are different licensing models between Europe and the USA, which is something that I don't understand. This is an aspect that needs to be improved.

Java is very old technology and they should move away from it, to anything that's better.

We have been using SEEBURGER since July 1st, 2017, four years ago.

With our on-premises implementation, we never had any issues with uptime or stability.

Scalability-wise, I don't know of any limits for us, so there doesn't seem to be a problem.

At this point, we only have two users, although we need to enlarge that role. I am responsible for the customer setup, connection setup, and map design. My other colleague also does customer setup and communication setup, but no map design.

We plan on expanding our usage because we're going to start moving our Asian colleagues. As soon as we find a customer that's able to do EDI with them, we will turn it on. We're certainly increasing in that world.

We now approach every customer and look for EDI opportunities. Now that we've determined that we can handle receiving CAD-type drawings through it, we are going to send that to different plants. We certainly plan on using it more, and I know due to COVID, we've never experienced the number of customers asking us for EDIs as we are now.

With respect to support, it's best-of-breed for me. I still get to work with my American counterparts at SEEBURGER, but my contract is in Europe. When I do need true support, I tend to get most of it from America, so that works in my time zone. Alternatively, when I use the service desk, it's support from the European side.

I like working with the SEEBURGER support. The service desk itself now has a chat, and that has saved me days because they answer the question right when I was on the phone with them, or on chat. That's been amazing. The service desk is always helpful. I'd say 95% of the time, I only have to use the service desk, which is included in our maintenance.

With my support in America, I have one particular person that the emails go to. Unless it's a big issue, he usually has an answer back out to me that day, so costing me far less than if it had to go to other areas. It's been a dream.

Everywhere in the world used something different before SEEBURGER.

In our American offices, we used TrustedLink, whereas, in Canada, we used Atos. In Europe, they used other packages. In Spain, for example, they used their own desktop version for EDI integration. We have also used SAP PI and others.

I don't know why we switched to the current solutions but it was done in conjunction with our SAP rollout.

In this IT world, it would be classified as quite straightforward.

In America in 2017, we started with a cloud-based deployment. Since then, we have migrated everything to an on-premises server in Europe. At the time, we went with a single point of communication, so we were only using OFTP2 when we started. It was a single server install. 

When it comes to our mappings, we've gotten very complex, especially because we merged the two. It is relevant to note that we have a two-stage implementation. At first, when it was just for Germany, I don't know that it was classified as very complex. When it was just for the USA, it was not classified as very complex. But when you blended the two, we added a lot more complexity to our world. Every process is broken down as "Is this a US EDI or is this European EDI?"

Effectively, we doubled our complexity at that point.

I don't know the original German timeframe but for the US implementation, it took a little more than two months to deploy.

For our first implementation, we asked SEEBURGER to do all of the work for us. I gave them all of my sample files, and all of my specs, and they took care of all of it for me. I concentrated on inbound first and then outbound, as per normal. After that, I would check the flow-through to see that the data went where I expected it to.

In that implementation, they did 75% of the work, and I only did 25% because I was rolling out SAP. I was in charge of two plants at the time, so I couldn't do EDI all by myself. All of the departments were rolled out and they did all of it for us. The support was perfect and it was exactly what I needed.

In 2018 or 2019, we moved back to an on-premises deployment. At that point, they were able to assign the connection guy to us and then one person for the maps. He took care of double-checking and finding a way to merge the current on-premises and our former cloud processes together for us.

At that point, I was able to assist a lot more because I could concentrate on the EDI, and I also had a colleague in Germany that could work with me. That time, it was more a 50/50 process, with us helping to deploy it. We started on January 1st, and we went live with that merge on April 1st. It was a little bit longer of an implementation move but we weren't as desperate for a start date. Overall, we had no issues moving from the cloud back to on-premises.

The US SEEBURGER staff were fantastic with the second one. When we found out that our implementation was not going to work on the German one, because somebody forgot to sign us up on our side, the American people stepped in. They were able to get me up and running with about two months of prep, and then a bit more because I needed them to help me more than they should have had to help me for the summer that year.

It is unheard of to get that many customers up and running as fast as they did for us.

I will be in charge of maintenance when it's time, but I will steal somebody from my operations IT team to assist me with that. Other than making new maps, to this point, there has been no real maintenance that we've been doing.

We do not have exact figures for ROI at the moment but the one example, where we take two hours per week down to zero, is priceless right now.

I wasn't involved in the contract negotiations, but I can say that we pay per site. It is based on the expected usage per month. I would like to find a way to change this and not pay per site because I don't want to pay for a site that has one EDI turned on, and pay the same amount for them.

We pay for a maximum number of setups, then we pay per customer map, and we pay maintenance on each one of those. BIS provides the flexibility to pay as you grow. The price of each customer map is €200 and the hourly rate for maintenance is fairly reasonable.

We budgeted for ten days of maintenance at €160 per hour, for a total of €12,000. We purchased the block so that we wouldn't have to pause our operations but we hardly use it. That contract started in 2019 and we've barely made a dent in it.

I highly recommend that people negotiate strong and hard on their customer map contract. I've decreased our European one in half, and I still will fight to get it down again. I prefer the pricing model out of the USA by far. There is a significant difference between these two pricing models, which is something that I don't understand.

As part of our monitoring, we run checks to see if we're close to where we expect to stay in terms of usage.

In addition, you have to buy each adaptor that you're going to use. These include OFTP2, AS2, SFTP, and others. I highly recommend that you figure out your market and pick the best one for your marketplace, instead of paying for all of them.

We did evaluate other options in 2015, although I can't recall the names of the products.

I am not running the most recent version because I don't have a test environment, so I don't want to upgrade and risk things breaking before I can test it. The plan is to move to version 6.7 in the fall, meaning that I'd be skipping a version. The most compelling reason to adopt the new version is the security. It has a higher security rating than the current one. Also, new tools are available that I want to take advantage of.

BIS could provide real-time data insight for our organization but at this time, we're not using it in that format.

At this point, using this solution has not helped us to decrease the time to market. We're probably too far out in the company to do that. I don't have any customers that are taking business faster because we can do EDI. In fact, most of my customers are the reason that we're not moving faster for EDI.

My advice for anybody who is implementing this product is to fully understand the differences between the on-premises, cloud-based, and hybrid solutions. Also, start negotiating early, especially if you have to do your negotiating in Europe. In America, they're much more flexible. You should definitely start earlier than we did because we were far too late.

The biggest lesson that I learned when using this product had to do with designing my own process maps. It is important to learn the map DB system because you can make it very strong and it makes your life much more flexible. For example, you can have a colleague that never has to touch a design or make changes because you put it into a process map instead. They can just use it within a table and never open the designer. It's fabulous. I would concentrate on getting the most knowledge out of that as a could and in fact, it's still what I've written down for my self-design training sessions that I ask them to do for me.

I would rate this solution an eight out of ten.

We use it to connect via EDI with our trading partners within the EU region and with other regions, including, America.

It's an off-premise solution. We have a secure file transfer server where we are placing the files or picking up the EDI, and then they connect and put the files in or take them away. On the SEEBURGER side, we then connect into their portal so we can then see the information about the message flows, etc.

We don't yet have any examples of how it's improved the way our organization functions because, so far in our deployment, we've just migrated over what we have, as is. We've moved all of the existing connections with our trading partners and messages across from OpenText. In the next financial year, starting next month, we'll start looking at onboarding new trading partners and really making use of the standardized messaging that we have with them, for converting to the other trading partners' formats.

What I can say is that it has met all of our requirements, to date. We are in the process, in the next couple of years, of migrating to SAP, and they have two or three different mechanisms for natively integrating with SAP. But because we're not there yet, we haven't made use of that. Currently, we are using a simple file transfer protocol mechanism, but it's fully meeting our B2B requirements.

We are looking to introduce some new message types this year, such as processing vendor invoices. That would include receiving the invoices via EDI, linking that to our ERP, and SEEBURGER Business Integration Suite (BIS) automatically doing the processing. So we're expecting to achieve some additional operational efficiencies.

If SEEBURGER plans to do something, they will meet their target. We haven't been disappointed by them at all. For example, we had six trading partners to onboard and they said, "We'll make it happen," and they did make it happen. They did exactly what they said they would do. That's a really positive thing.

I have also had a lot of good feedback from SEEBURGER and have really been kept up-to-date about the status. With some companies, a salesperson will say something but then the technical people don't deliver.

We get a monthly SLA report. We have SLA targets with them that were set in the contract, and they report against those. So far, there have been no breaches of SLA. You can also go onto their website and view real-time information so you can monitor the performance if needed. With SEEBURGER Business Integration Suite (BIS) I've got really good visualization.

For the area that we've used them for so far, I don't really see any way that they can make it easier. I can't say enough about how they have delivered exactly what they said that they would, and for the cost and in the time that they said it would take. They're bang-on there.

We implemented in the last quarter of 2019, so we're coming up to around six months in terms of the live environment.

At the moment, there has not been a single problem. We haven't had any issues after going live; 100 percent uptime. They've met all of the SLAs. The message-processing time in the SLA is up to one hour; in reality, it's been about 10 seconds.

There have been no performance issues and no outages. And if they do have an outage, then they've got disaster recovery plans to mitigate.

Scalability was the whole reason we went with SEEBURGER Business Integration Suite (BIS). Our hope is to add 20 to 40 trading partners a year. Because we've done the groundwork, we've done our initial messages, we don't need to do anything more from an integration point of view. Now it's SEEBURGER's job to connect their platform to our trading partners' platforms. That was the whole selling point.

Our entire organization is the intended beneficiary of our SEEBURGER deployment. At the moment, we've only actually got it linked into our Germany and U.K. offices, but we're expanding use in the coming months into our Italy office, for suppliers, customers, and e-invoicing.

I had to raise one ticket during the implementation, and I was using it as a test, really, to see how ticketing works. They were really good and responsive, and I was kept up to date.

The ticket was actually auto-raised by the system because a message had tried to come in, but they weren't able to process it. I then received a phone call because it could have been an urgent situation. It turned out the person's sender ID hadn't been set up correctly. It was my typo when I gave the information to SEEBURGER in the new system. But it was dealt with and resolved fantastically.

So far, I have had no issues with tech support. Nobody receives 10 out of 10 because there's always room to improve, but I would say their support rates a nine out of 10, although I can't say what they would improve.

We were already doing EDI previously and using OpenText as a communication platform, as a VAN (value added network). The problem with OpenText is that they'll pass through your messages and the dealings that we've had with them, but they don't really do the message conversions and the like. And we are looking to expand quite a lot in terms of trading partners in the coming years using EDI. With SEEBURGER Business Integration Suite (BIS), we can just send one message between us and SEEBURGER and they will do all of the hard work with the trading partners. Whereas previously, with OpenText, if each trading partner had a slightly different variant of EDI, we would have to make the adjustments ourselves.

Also, all of the EDI conversion into our ERP was actually done using a bolt-on to our ERP. Because we're moving to SAP at some point, that bolt-on was not compatible. But that is where I gained my experience, because I had to create the mappings between the EDI messages and our core internal procedures.

The move away from our old solution was about the scalability. Previously, I was spending a lot of time doing the mappings myself, as well as the onboarding and dealing with all of the headaches related to that. In addition, because we're moving to a system that doesn't have that EDI bolt-on, which is the SAP solution, we needed to find an alternative. Finally, because we wanted to rapidly increase the number of trading partners that we're connected with, we would have had to take on an additional resource. That's where the price-benefit came in.

For me, the setup was straightforward. We really planned the design out together, how it would work. We had a couple of meetings at our office. They came down to visit us, both the technical people and salespeople, to make sure that the technical people were able to deliver what the salespeople were promising. We had a planning workshop, and we said, "Okay, these are the types of messages," and we described exactly how they'd be coming into the FTP server, the kind of folder structure we had to create, the permissions, etc. Once the planning was done, we implemented according to plan, and it was fine.

We had a kickoff meeting, which involved members of SEEBURGER's sales team and their technical guys. Then, we had a second meeting with the technical guys, a meeting that was a bit more in-depth about how we were going to achieve what we wanted. We had to provide information like the trading partners' formats, the trading partners' mailbox settings, the types of messages we were using when interacting with those trading partners, etc. Then we decided the best method for communicating our messages to them. To establish that securely, we had to create a VPN tunnel directly to SEEBURGER's systems and get all that tested up. Each portion of the build was tested independently and then, as a whole, we did some end-to-end tests. It went really well.

From start to finish, the deployment took about a month. It went really quickly.

After the deployment was ready, we had some additional time with our trading partners to do some end-to-end testing before switching over to live. That way, our trading partners were happy. We only had about seven or eight trading partners that we were migrating across, but from SEEBURGER's side, they just made it happen.

On our side, it was just me, and it wasn't full-time. We did a couple of hours one day, a little bit of time another day. There was more time spent in the weekly progress updates than in actually doing things, from my side. I wasn't involved doing the work.

We worked directly with SEEBURGER. I have quite a lot of EDI experience so I understood quite a lot of it and that may have helped.

Compared to our previous solution, SEEBURGER Business Integration Suite (BIS) is more expensive. But our previous solution isn't compatible with SAP so we would have had to migrate to a solution like SEEBURGER's at some point. It has cost us more money to migrate to SEEBURGER Business Integration Suite (BIS), but in three to five years' time, we should start to reap the benefits.

We hope to start seeing ROI by the end of this year, once we start getting more trading partners onboarded. We're paying for a set monthly amount but we have only reached about 10 percent usage. Once we start approaching in the vicinity of 60 to 70 percent usage, then we should start getting an ROI. That's not SEEBURGER's fault, that's our fault, because we're not ready to be at that stage yet.

In terms of manpower, once we start to get some of these more automation processes in place, there could be a one or two headcount reduction in terms of the related tasks.

The only thing that would be an improvement would be if they had a cost model whereby you could just pay for what you're actually using. Even if it were a minimum monthly charge that they offered, if you're not utilizing all of that then they should consider a lower tier. That way, they could attract more business.

Aside from the standard usage fee there's an onboarding cost. I don't know if our prices were hardly negotiated or whether there is just a de facto price. But, in addition to the normal monthly, system-running costs, when you want to onboard a new trading partner, there's an onboarding cost. 

If you want to do any additional types of messages, there will be an implementation cost related to each message type. If you are onboarding like 10 or 20 trading partners at a time, they also have a project management cost for a defined project manager who's your main point of contact. That's how they make sure that everything gets done according to the time that they said that they were going to do it in. I've used third-party project management before for our ERP provider, and they've been shocking. So we tend to do a lot of project management ourselves. But SEEBURGER delivered. I was super-impressed.

We looked at a company called NetEDI as well as TrueCommerce. There were two more but they were discounted right at the beginning because they didn't have time for us. NetEDI EDI was ruled out quite early on so it came down to two companies.

TrueCommerce seemed really promising but I was reading a lot of negative stuff in the press and online about them; that they promised that they will deliver but they don't deliver. The sales guy was really good, but if the tech people behind it can't do what they say they're going to do... I looked at the review sites, like IT Central Station, to find out. That can sway the impact of your decision-making.

The biggest lesson is to understand the monthly fees and whether or not you're going to be making use of all of the data cap at the time of go-live. If not, try to plan for expansion so that you're maximizing the use of what you're paying for.

SEEBURGER take a lot of the headaches away from you. That was the main point of it. We were very demanding about the contracts. We got them to amend their standard contracts to meet our requirements. Make sure that you read the contacts thoroughly and that you understand all of the implications. Know what's expected of you and what to do in the implementation in ongoing phases.

We haven't really had to do any maintenance since we've migrated to them. I am the primary contact in my organization. I'm trying to bring one of my colleagues up to speed about what EDI is, to start him off from scratch. He has no knowledge of it at all. But the main point with SEEBURGER Business Integration Suite (BIS) is that you don't have to have the knowledge. They take all the hassle away from you. I'm just in a bit more of a privileged situation because I do have the knowledge. But the point is, you say to them, "All right, I have these five trading partners. If I want to reduce our costs, what information do you need me to get from them?" I can then request it and pass that back to SEEBURGER. Or we can pay SEEBURGER a little bit more money and they'll do it end-to-end. It depends on the skills you have in-house and how much you want to do yourself. They'll take it all away from you, or you can still do a bit yourself.

They also have other solutions that we haven't taken onboard as of yet, but we could consider in the future. They have some integrations with the tax authorities, like making tax digital. We have a branch in Italy and SEEBURGER have an Italy e-invoicing solution, in accordance with Italy's government policies. But we already have the solution for that, so we don't need it. Integrating into customs is another one, but we don't really have a case for that as yet. So it's not just the EDI, it's a whole framework of things that they can offer.

If we have any new requirements, they said to send them to them and they'll put together a proposal. It's really an area that they specialize in. When we were selecting SEEBURGER Business Integration Suite (BIS), we were looking at a few different other options. But they really have a high number of trading partners already with them in the automotive business. So that's hopefully something that we can make use of in the future when we're onboarding. Hopefully it will take a lot less time.

I look at the fact that SEEBURGER invests a high proportion of revenue into R&D instead of promoting brand awareness like this: If you haven't got a good product then no one's going to buy it. By putting that money back into the R&D, they're also making sure that they're meeting any new requirements that come up in B2B activity. For me, it's a thumbs-up.

They have a lot of offices globally. One of the good things for us is that we are able to deal with sales and technical people based in the UK, but they do have offices throughout Europe and America and Asia. Some of our company's regional operations are also looking at SEEBURGER Business Integration Suite (BIS) as a solution because they can talk in the local language. That was another really good point about SEEBURGER. And because we want to deploy onboard trading partners throughout Europe, they have people who can talk and work in the same countries as those people. That helps to take away those language barrier issues.

Also, they're a wholly-owned business by themselves. They're not a sub-organization of anyone else. That was quite an attractive thing for us. They've been around for a long time. They've got a lot of integrations into many ERP systems including the one that we are looking to — SAP. They seem to have it all.

Our primary use case is to send EDI documents between our partners and vendors. We're also starting now to use it as a development tool to translate SAP idocs to EDI messages and vice versa. 

When we first started, we had different systems and application, six or seven of them, globally. Using SEEBURGER Business Integration Suite (BIS), we have reduced the number of EDI communication tools. Now, we just have this one.

The solution can support B2B/EDI, EAI, and/or ERP integration requirements. The one thing that they are pushing is that they are a single solution that can meet all those needs. It's nice to have that in one system, versus using multiple systems.

It has also increased the level of efficiency in our company's operations by about 30 to 40 percent because everything is on one tool, supporting many people at the same time, worldwide.

The SEEBURGER solution has saved us money. Although there are other tools out there that do the same thing, if we had to buy those tools it would cost us more. The money that we spend on maintenance, for example, gives us the ability to communicate with other partners without having to use another tool or another partner. That's where our cost savings are. 

I like that the tool has all the adapters — all the possible protocols that are in the industry. You pay for those adapters but at least it's all in one package. You don't have to get another tool or application to support another partner. It doesn't matter if you're in Europe or if you're in North America, the solution they have is global. It can support pretty much anything and anyone.

It's rather difficult to understand, from the application, what's broken and why it doesn't work. We typically need to get support from them directly, and it's usually in a consulting role, to fix issues.

Also, the training they provide is not really adequate. They sell you things that you can use to design things in your own way. To get them to show you how those work is very difficult. To get them to explain how their application works sometimes is difficult (depending on the customization that was done) I would like to see them build training courses and I would have no issue paying for them. Everything I know about the application is self taught.

In addition, if we ask one consultant, we get one answer and if we ask a different consultant, we get a totally different answer. If we ask someone in Europe, even within the same company, we get a different answer again. They're not globally aligned in terms of what their application does and how it's actually installed. Depending on who you talk to, you get a different answer. You could say each consultant or software engineer has their own way of implementing BIS. They could do a better job if they collaborated more internally and talked to the customers and asked questions so that we could give them examples and tell them where they could do better.

Also, their release strategy, in terms of number of updates, is very demanding; it's very quick. SEEBURGER releases an update every month, if I'm not mistaken. It would be nice if they could do semi-annual releases that are not really needed. If something is broken, you can always ask them to provide a hotfix. We can't keep up with the number of patches they have (even though we may not need it). Every time they send a patch, we have to retest everything. They could improve the frequency of their patches and maybe provide a procedure to test everything so that we don't spend hours or days validating their latest update. We don't know what that patch is going to do. We have to test it and we need a team to test it. It's something that we do overnight. We have to check every adapter, every process row, all the modules in their solution.

We've been using SEEBURGER Business Integration Suite (BIS) for roughly 10 years.

It's stable. They're always improving it. Their next release, coming out next year, has a lot of improvements. In terms of stability, they're moving in the direction of selling a standard. That's the right way to go.

The scalability is really good. That's one of the biggest features. Depending on the size of your company, how much data you have or frequency, their solution can manage it. You can grow vertically or you can grow horizontally. It really depends on the business. They have the capabilities to grow and expand and handle all that architecture.

In North America, our company has smaller needs for scalability compared to what we've seen other companies do, although it is bigger than our European side. We do have certain things that Europe doesn't have, different components or boxes in front of the SEEBURGER Business Integration Suite (BIS) server, such as proxy servers. Security is different in North America. We have a second node that handles more of the high-volume transactions, but we really haven't fully utilized it yet. We're just getting it up and running now.

We have two production SEEBURGER Business Integration Suite (BIS) applications, one for Europe and one for North America. Behind them, there are quality environments. Behind them we have another instance for their compliance checker, which is another tool. We also have a development box and a sandbox for initial patches and upgrades.

Technical support is good. The person who answers your ticket is the person who is going to solve it. They don't typically have level-one, level-two, and level-three support. The person who handles the ticket is an expert. They're users of the system. In most cases they can help you. In other cases, they will seek the support of their developers or consultants because it's out of their scope, and that's a normal way to handle those situations. Overall, the support is good.

We had a couple of previous solutions. One was Cleo LexiCom. We also had something called EDI Gateway and that's what we were using mainly, prior to this one. 

SEEBURGER is an SAP partner. When we bought SAP, because we were going with one global ERP system, our operation in Europe chose SEEBURGER at the time. I was not part of that decision but I'm happy to say they made a good choice. 

I wasn't involved in the installing of the solution. I was more involved in the configuration of it. In terms of configuring it, I didn't find it hard. If you know EDI, and you understand how protocols work, you won't find it too difficult.

It took me about nine to 10 months to migrate from one system to a different system. That covered about 40 plants. In terms of deployment, it's quick. It's just a matter of physically doing it, getting in contact with your partners and telling them, "Hey, I'm switching from this IP address to this IP address." I found it easy.

We used SEEBURGER consulting. We already had one instance in Europe. North America had to get its own instance and I was in charge of making sure that that happened: getting it installed, explaining to the consultant that these are all the flows we have today, and these are all the software components we have today. How do we put all that stuff into one box?

Our experience with them was very good. The person that we used is still with the company.

We realized savings after five years. We needed additional development as well as some minor things that we use in our company that they didn't have in their standard solution. It took us time to understand the product. During those five years we were consulting with them and needed their support to understand their tool. After that, a company should be able to be self-sufficient.

We pay maintenance of between $75,000 and $100,000 per year. The costs are based on your original purchase solution. 

As far as I can remember, the company looked at IBM Sterling and at outsourcing.

Have a good understanding of what your business is. Understand what protocols you need to support. Know what your volume of transactions is and what the latency is of those transactions. Do you have to deliver those transactions in five seconds or do you have to deliver them in two milliseconds or do you have to do it in five minutes? If I were buying software that would be my question to the vendor: How long does your tool take to go from point A to point B?

The lessons I have learned from using the solution is that their tool can do many things. It's a full B2B solution, which is nice. They have additional software that you can tie into it. If your company ever needed something really specific to communicate with another backend application, or to convert an email to an Excel, or an Excel to an EDI file, their tools can do all that.

We have around 30 to 40 people using it or who have access to it and different components of it. Their roles range from database administrators to people who monitor the servers themselves. Our EDI analysts use it and managers use it as well. SAP level-two support people use it. We have five people who are involved in updates and maintenance of the solution, including an operating systems administrator, a database administrator, IT operations, and my team that validates that updates were done properly.

The fact that SEEBURGER invests a high proportion of revenue into R&D rather than promoting brand awareness is fine. They emphasize that quite a bit. They don't spend a lot of money marketing, like SAP or Oracle would. I'd rather them spend more money on R&D. That's where the value is. They're spending money to ensure that, with any new technologies and any new security threats or issues that come up, their application stays afloat.

We may look at SEEBURGER'S API feature but it's a little bit early. We have an API management tool already. When we went to them looking for this some years ago, their tool was nice on paper, but it wasn't a reality. SEEBURGER has invested in the last couple of years and has come up with some tools. I don't know how many companies are using it, but I think it's a little premature right now for us to buy it. But it might be something that we switch to. Ten years ago, none of that played a role in our decision. It was more that our company had been using SEEBURGER Business Integration Suite (BIS) in Europe over the last three years and we needed to get the North American side of the business on SAP and to be on the same type of system.

Because I've seen some other products, I'd rate SEEBURGER Business Integration Suite (BIS) a nine out of 10. That's only because I know what they're capable of doing and there's room for improvement. It's not perfect, but their solution is probably one of the best ones out there.

It is primarily an EDI translator for us. We have over 1,000 trading relationships running through it, totaling a couple of million documents. We don't just have EDI flowing through the platform. We have XML documents from some partners, and other things flowing inbound and outbound. But the bulk of it is EDI.

Our deployment is on-premise. We went that way because we knew the cost of doing it the other ways was more expensive. And in general, that is the model that we use.

The benefit of using SEEBURGER Business Integration Suite (BIS), one that we like to tout right now, is the interaction of the solution's front end with the CMA module that we purchased from them. We're able to create surveys around testing processes and the automation of the actual testing. Using that survey, it will link to the SEEBURGER Business Integration Suite (BIS) front end so that partners can actually do testing on their own. They get feedback and data testing, based upon our actual requirements around EDI documents. It works 24/7.

The reason we tout this so much is that we had a backlog of 100-plus partners. It was taking an average of 66 days to get a partner up, from start to finish, through all the documents that we require. This solution has reduced it down to an average of six days, with zero backlog. That's a significant improvement.

We were having to do a lot of it manually before and this is one of the big things that we hype. It's a combination of both suites: the CMA component with the SEEBURGER Business Integration Suite (BIS) front end. That's by far the biggest benefit that we can name.

We use some of their other tools, like the Imart web platform, for some of our smaller vendors. That has been helpful in reducing the cost on their side from having to do EDI.

But the SEEBURGER Business Integration Suite (BIS) front end, in and of itself - having that EDI translator straight out-of-the-box - and being able to move stuff away from IT development into the actual business side, has been helpful.

Also, with the alerting and everything else that we get out of it, we're a lot more efficient. We're able to focus more on problems with our partners, versus reacting to systemic issues. We don't see a lot of systemic problems through the platform, so we're able to respond to our partners in a quicker fashion.

Among the most valuable features are the EDI translator and a lot of the components which enable creating compliance sets. Having something standard, out-of-the-box, and being able to use that has been a huge benefit for us. We came from a system, in the past, where we were having to manually create all that on our own, and it was very time-consuming and costly. Being able to do that out-of-the-box has been great.

Another aspect that we employed in the last year-and-a-half has been their CMA platform component, which hooks to the SEEBURGER Business Integration Suite (BIS) front end. We've been able to set up an automatic testing process for our partners. They can walk through and test all their documents, in the sequence that our company would be expecting to pass and exchange them, without any interaction with someone in our company.

They made improvements to the email error alerts that go out, for the EDI technical. Those typically go straight out to the partners. Those messages are significantly clearer and easy to read. The same messages in the front end are not nearly as clear. It's supposed to be the same error, but the message that goes out for EDI is really easy for anybody to read and understand, but you have to be really solution-savvy to understand the message in the system itself.

That is the component that we definitely have the biggest issue with. Unless we want to go search for an email, trying to read the actual message in the platform is tough.

Also, some of the functionality for retriggering documents, where you have to step through a termination process and then retrigger it, versus just being able to restart or retrigger more easily, is a bit challenging, depending on the scenario.

Three to five years.

We had some incidents during the first year but it seems to have become more stable every year, as we've learned something, or figured out something. During this last year-and-a-half we've had almost zero incidents.

We have no problems with its scalability. We did a performance test where we did about eight times our volume through it in a single hour, for an entire heavy week, and it handled it. We've had no issues with it. Everything we've added to it - multiple documents inside the implementation, different components to it - we've had no issues. It's handled it all.

If I just look at the consultant we have who is dedicated to our company, he's awesome; great.

There are some challenges with the Premium Support. I don't know if it's because they're based in Germany. I know our infrastructure at times has been posing the wrong information questions. But it's been challenging at times, and other times it's been great. Part of the problem is that they always want the logs and those aren't always available. But for the most part, support has been good. For what I've had to use them for, their response times have been fairly good; within expectations.

We had an older version of webMethods, which was not an EDI translator. Comparing SEEBURGER BIS vs webMethods, the latter was just a communications broker. We knew we needed to switch for a long time. We got to the point where we could no longer upgrade that platform or do anything else because of the heavy customization and programming that had been done to it.

Because it was something brand new for us it was challenging, but I would expect that with most programs. Where we struggled the most was with some of the training that we got from the SEEBURGER team. Until we had a more sit-down discussion with them, we were a bit challenged, especially on the business side. That had more to do with the trainers than it did the actual platform itself.

We started the deployment in June of 2015 and finished up putting in the last document in October of 2015. Our deployment went really fast, surprisingly. We actually had projected it to be 18 months, and it took us significantly less, once we got rolling.

In terms of an implementation strategy, once we got through all that, it was getting in the servers. We had a lot of EIP stuff (Enterprise Information Protection) they had to work through. Then we started out by moving over specific documents, based on business processes and then communication protocols.

I can't remember on the IT side how much of our staff was involved in the implementation but we had the Business Operational Unit involved. The operational team had six full-time employees and two development groups. We also had two change-management people and two IT people who directed. They were the IT people we were worked with directly in bringing up the business part of the process. There were other IT focused on the hardware and internet connection changes. We also had one full-time, dedicated SEEBURGER consultant here with us on-site.

For maintenance on a day-to-day basis, the way our EDI operations are set up today, there are four full-time employees and one manager. They work on SEEBURGER Business Integration Suite (BIS) and everything we have flowing through it, as well as all the partners. In addition, we have two development people but they don't use it on a daily basis.

We did it directly with SEEBURGER.

With all the new processes and stuff that we've added, one of the big benefits we've seen is that we've never had to increase headcount. We've been able to accommodate everything. Because of SEEBURGER Business Integration Suite (BIS) our development, and ourselves on the business side, have been able to stand up new documents, new processes, new flows, with a reduced headcount. It's enabled business to handle more of it, as opposed to being an IT function.

There was a big list, including the IBM solution. There were six other platforms but it was three-and-a-half years ago.

Both our US and Canadian operations evaluated the same companies then, and SEEBURGER was chosen in Canada. When we did the evaluation again, here in the US, we ended up with pretty much the same results. The fact that Canada was using it helped make the decision to go with it.

My advice would be to make sure you have a good, strong change-management group which can assist and help along the way. If you're not coming from something like we did, it can be a struggle getting people to adapt and change. It's not so much the system, it's the people that'll be utilizing it. It also helps if you have a strong SEEBURGER consultant there who makes sure that your IT people fully understand what's expected and where they're going with it.

We don't use the Landscape Manager at this time but it is something we're looking at.

In terms of the Active-Active feature, that's part of IT while I'm on the business side. I know it's being utilized. We have had very few issues with the load volume passing through it. It handles it well. Sometimes we see a few spikes, but they don't last and they don't cause any system issues.

When it comes to adding integrations, the way we're utilizing it, a lot of it seems to be pretty fluid. We haven't had a ton of issues. We use middleware. We don't allow direct-connect to any other platforms, at least on the US-side of our operations. We have various file formats that we have to convert the documents into, and putting them through message queues, or through the NAS Exchange, has been pretty easy. If we have issues, it seems to be on the other side of the ball, where they didn't set up their interaction or integration correctly.

We increase the usage every year. To give you an idea, 99 percent of all our purchase orders through our vendor partners run through the platform. The one percent are new partners who are still working at getting their EDI up. For the purpose of trading most documents with us, the bulk of it goes through this platform, whether it's invoicing, shipping notices, purchase orders, changes, etc.

We're looking at what they're offering for the 6.7 upgrade. We're definitely strongly interested in the new Message Tracking upgrade. Landscape Designer is being looked at for our infrastructure group, for being able to handle upgrades and service pack upgrades. And there is the potential move, eventually, to go to 6.7.

I would give the platform itself an eight out of ten. As I said, I have a problem with the error messages that are in the system.

SEEBURGER, along with four or five other big vendors, focuses in the integration space. When you talk about data integration, there are two major aspects of it. There is the transactional messaging side and the batch file-based side. My team is focused on the batch file-based side of things. We have a completely different team (with a different set of software) who does the transactional messaging aspects. We are using it for all secure file transfer use cases throughout the organization with multiple different data patterns: moving data within the company, moving data to and from outside of the company, and ad hoc file transfer. Any type of file-based secure connectivity goes through our team using this product.

Currently, it is on-prem. We have a cloud initiative, which has been rolling for a couple of years now, like most companies. It is on our radar for later this year. We are going to spin up another project to consider either moving to our own AWS or SEEBURGER's AWS and their iPaaS environment.

No matter how much you automate in the file transfer space, there is always more to be uncovered in a big company. Users, especially in the business area, will start doing their own thing and interacting with some external webpage to upload or download files manually every day. They kind of incorporate it into their daily tasks. When we discovered that, we were like, "Why are you wasting all that time? What if you are out?" That has been one part of starting to consume different website APIs, to push and pull files to and from various vendor websites that was historically done by users manually. So, there is an automation aspect to it. Beyond that, application-to-application connectivity, which historically went over protocols like SFTP or batch files, is conforming over to APIs now because everybody wants to be faster and use APIs. Therefore, a lot of these application-to-application data flows have changed over to APIs over the last year. For example, I used to get one API request a year in past years. This year, I get one or two new ones every week or two. APIs are just taking over.

It is good anytime that you can take a user who is doing something manually every day out of the picture and automate a process, e.g., going to a vendor's webpage to pull or push a file every day. Although there was a one-time cost to do the development work, you reap the ongoing benefits because now you don't need to have that user spending time doing it every day. You don't have to worry about if that user is out or gone for a week on vacation. Things can just happen automatically. There is definitely a benefit.

Because we are in the financial services industry, PCI is huge. You have to comply with PCI regulations. That has primarily to do with credit card numbers, but really any account number or sensitive data. What is nice about SEEBURGER BIS is it has made it easy to patch our yearly PCI audits with this thing called PCI realm. You can configure any of your data flows into that PCI realm that you need to. It automatically complies with regulations, offloading the data as soon as the data flows through the system. It doesn't store any copies. It offloads the data encrypted in an encrypted state to our PCI zone to be stored for X days during our backup period. That is all out-of-the-box functionality, so you don't have to waste your time trying to figure out how to comply with PCI compliance rules because it is already built into the software. You just have to configure it in that PCI realm.

We are getting these use cases now that APIs are coming into the picture where, historically in our company, the data integration has been broken into the two major areas. Transactional messaging is on one side and batch file-based transfers are on the other side. Now, you are starting to see those two areas kind of merged together. Because usually when you get a batch file over API, they want us to break that batch file up into individual transactions, iterate over all the records in that batch file, and post them as transactions into our messaging system. 

There is now this interesting sort of convergence between the messaging space and the batch file-based space which is now sort of coming together because of APIs. So, this is another area that I am seeing a lot of requests for lately, "Hey, I want you to still get a batch file like you have always done in the past, but it is going to come over API now instead of over something like SFTP. In the API, I want you to iterate over every record in that batch file and post those transactions individually." This is another big growth area right now. Therefore, I am working on solutions to be able to support that. This would be an area of growth because we will be using these batch files to post into more internal systems and do it more flexibly as individual transactions, instead of as a big batch file. This is an area that we are looking to grow in the next year.

You could make the argument for time to market if there was a user doing something manually every day, then we came along with SEEBURGER BIS and automated that. So, instead of waiting around for the user to load the file once a day at whatever time they do it, we had the system automatically pull the file, possibly early morning, and pass it through immediately into the back-end processing system. There are some cases like that, where historically it took eight hours, because a user had to get engaged, do something manually, maybe convert something manually to transform the data themselves, and then they would have to manually load it. Here, we come along and run a workflow in two seconds that streams it right through. Therefore, you could make some arguments that we sped up time to market by automating previously manual processing. However, as far as just general B2B file transfer or application-to-application, I don't know that you could claim that the software itself has sped up time to market, other than just coding workflows a bit more efficiently to take out seconds or minutes to make them run faster.

The most valuable features are the solution's stability as well as its ease of use and flexibility to configure a workflow with as many (or as few) steps as you need. It offers us more value to our internal customers because we can do so much more than if we had a software that was super rigid. If you are looking for a software that emulates writing a piece of code where you can have as many steps as you want in whatever order you want to, this is the one. SEEBURGER BIS is so much better than other solutions because of this.

Their entire software suite is 100 percent homegrown. Every component that they have built was built to be integrated with another component. It is all one product. Due to acquisition and the integration space being a big thing, other vendors tend to go, "Buy this, buy that, and then buy that." They try to bolt them all together and make three different vendors' products work in concert as one. My experience has been that it usually leads to confusion as well as bugginess and problems. SEEBURGER BIS is all one product, all homegrown, and everything is fully integrated.

API adoption is on the rise everywhere. Even in the file-based space, APIs are being adopted a lot, especially at our company. One thing I like about SEEBURGER and their transformation engine is it is completely integrated with JSON file formats, which are typically used in API calls. I just did an API over the last couple of weeks with a complex data structure and SEEBURGER BIS Mapper handled that with no problems. As we look to the future, APIs are really taking hold. It is nice that SEEBURGER BIS can totally handle whatever comes our way that is API related. 

We occasionally get ZIP files. Sometimes the ZIP file has one file inside of it, and sometimes the ZIP file might have 30 files inside of it. We have been working with SEEBURGER to enhance their PKUNZIP process to be able to unzip multiple files in a single workflow instead of just one file. This is still something that is in process. 

I have been at my current organization for five years and using SEEBURGER BIS during that time. Our company's relationship started with SEEBURGER in 2013. 

In five years, we have never had an unplanned outage that was caused by the software. Every company has outages, but in our case, they have always been caused by our own infrastructure, e.g., a router went down, a cable went bad, or a switch had a problem. It was not caused by the software layer; it was always caused by the infrastructure and things that are under our control, not the vendor's. There is a peace of mind as a developer with not having to worry about having to be up in the middle of the night with software not working like it is supposed to. The stability of this software is by far so much better than other software solutions that I have used in the past.

I have come from a place where other software was up and down all the time. I would have to be up at night, burning sleep, and trying to support outages. To be in a place where we have no unplanned outages is great, you get a lot more sleep, which is good.

It is mostly our team who has access to the front-ends to develop configure processings. We don't make it too widely available across the company. We have a few pockets of people who can log into the portal to view their data on their own kind of self-service. Other than that, we mostly do behind the scenes data integration, moving data between applications and external partners. That is all done by our team. It is not done widely throughout the company, it is just one small data integration team. We serve every application in the company and are connected with a couple of 1,000 external partners as well. The touch points are many, but the people who have access to the GUI to actually do the work are few.

The scalability is pretty good. We haven't had to do a ton of scaling exercises over the years. Our volumes have stayed fairly static and grown at a certain rate every year. We just reassess them with our professional services person once a year and make sure that we are watching our metrics, memory, and storage really closely. We have that in our daily monitoring. As we see it going up, we just go, "Okay, we need to add some more RAM memory or more Java heap space." 

I would say the process of scaling is pretty easy as long as you stay on top of it and monitor your throughput really closely to know the numbers, knowing when something is growing. If you put in a new integration that brings in a whole lot more traffic, obviously you have to reassess and make sure that you are scaled to handle it. I have got a project like that coming up soon which will take us from thousands of files a day up to millions of transactions a day. This is something where we are looking closely at scalability and figuring out what is needed to be able to support that new volume, and not have an impact on the existing.

The fact that the solution is available in the cloud, on-premises, and as a hybrid deployment makes it flexible and scalable for us. Every company has cloud initiatives going on right now. To know that there are options out there gives our company more things to think through and price out. We have done a lot of pricing exercises around those three different options, so we have a pretty good sense now of the cost differential between on-premise versus cloud versus vendor iPaaS cloud. We know where things are going to fall cost-wise, so now it is just a matter of, where do you want to put your money? For example, do you want to have more staff to maintain the system yourself with all your infrastructure people, or do you want to outsource that, pay that money and some more to the vendor to maintain it for you? So, it kind of just depends on where your priorities are as an organization. I think it is a good thing that there are multiple options. It has given us a chance to slice and dice the numbers.

Since the very beginning of the relationship between my organization and SEEBURGER, they have been solid for everything from their support team to account managers and sales to professional services. We have always had a contract with professional services. We have used their developer personnel throughout the year on various efforts, and it has always been a solid relationship. It is one of the better ones that I have worked with. They are just an email away when we need to reach out to them. 

In the case of opening support cases, it is pretty simple. You usually hear back within a day. Even though they are based in Germany, they turn around your request pretty quickly.

You occasionally get a use case that comes along, and it is something new that hasn't been done before. SEEBURGER BIS out-of-the-box might do part of it, but not all of it. In those cases, we submit an enhancement request to SEEBURGER who gets it to their engineering team. Usually, those are turned around fairly readily. 

The enhancement onboarding process at SEEBURGER is pretty good compared to other vendors that I have worked with. We have a monthly meeting with our SEEBURGER contact in professional services. We keep a list of things, and say, "Here are the things that we need help with and our enhancement requests." Then, that person reaches out to engineering and gets an ETA, so we have a date of when that thing will be delivered. It is not like you give it over to SEEBURGER and forget about it, then it never happens. There is ongoing communication to the right people who know the software, what is needed, and when it will be delivered. Even when it comes to things that we don't have but need, like the multi-file PKUNZIP, usually it is a fairly good experience.

Before we started with SEEBURGER BIS, we had as many as 13 different integration software spread out across our company. Over the early years that I was here at my organization, we were able to consolidate that down to just SEEBURGER BIS. We reduced a lot of extra costs from using other software products and having a lot of extra things to support. Our support costs went down for infrastructure, etc. Thus, it is nice to have everything fully integrated into one product that can do everything.

The number one reason why I would not want to go back and use another software after having experienced SEEBURGER BIS is its flexibility when it comes to file transfer workflow. You can configure your file transfer workflow completely customized. You can put the steps in any order that you want. Your file transfer flow might have three or 20 steps. You simply bring in those steps as activities in a workflow in any order that you want. For example:

• If you want to receive a file and immediately transform it
• Call a database, get some data, and bring it into your workflow.
• Do a transformation or adjust the line feed. 
• Write it out to multiple destination systems. 

You can put all those workflow steps in any order that you want. That makes it just like a piece of code which has been abstracted into a front end webpage. If you think about how your code would flow, that is exactly how you can make the software flow. 

Other vendors that I have encountered in other jobs have been a lot more rigid than that. Other vendor software tends to have one canned way that you can run data through the system. You receive a file, maybe call a map and transform the file, and then you write the file out. At the very end of the process, you might be able to call a post-process, where you want to run a shell script. However, usually other software is pretty rigid in nature, such that you have to conform your data flow to how that vendor software works, because it only works one way. Because of that rigidity of other vendors' software, in order to accomplish a full end-to-end workflow, sometimes you have to spin up three different workflows and tie them all together to get all the different steps done that you want. That is not at all the case with SEEBURGER BIS. 

With SEEBURGER BIS, you can string as many different activities together in your workflows as you want. You can put them in any order, like a piece of code. One leads into the next, which leads into the next. It is just very flexible from that vantage point. This makes it so easy to use and reduces the number of moving parts that you need to have. It is just a lot less frustrating not having to conform to how some other vendor software works.

We had a variety of software products, so it wasn't a straightforward effort to consolidate all those different use cases and patterns down to their software, because all the existing ones were hard to discover. Sometimes, you experienced that the people who originally set them up were gone. There was a lot of work trying to understand the existing use cases in order to migrate them into SEEBURGER BIS. 

With any large first time installation of a completely different vendor's product, I think there is going to be some pain. That has just been my experience. You are trying to understand how to fit their product into your custom network. It isn't a one size fits all, so you need to tweak and tune it to get it to fit right in your network. The types of machines and network that you use are usually custom by company. I wasn't around for the original installation, but from what I heard, there were some of those sort of pain points during the initial install. From people that I talked to who were here at the time, it sounded like a lot of it just had to do with getting the platforms that were in use (at that time) to be configured and work with SEEBURGER BIS properly. So, I don't know if it was necessarily that the install of their software was bad or hard to work with. I think it had as much to do with the specific systems that were being used here at that time, so tuning was needed to get it to work right for memory, storage, etc. 

While there was some pain, I think it was equal parts their software compared to our systems and infrastructure and trying to pair the two together. At the same time, we were consolidating 12 or 13 different vendor products down into one. A lot of time went into understanding all those different use cases and how to properly configure them the first time and SEEBURGER BIS. So, there was just a lot of learning and discovery that went along with the initial install.

The relationship started in late 2012 to early 2013. It didn't actually get put into production for usage until 2014, so there was a year to a year and a half of planning that went on between the staff at SEEBURGER and the staff at my organization, from the infrastructure and the integration teams, to try to lay out how it needed to be installed as well as what kind of machines were needed and how much memory. That was a long, drawn-out process. I wasn't here at the time, but I imagine it wasn't the highest priority here at the time. So, there was a good period of time when they were just in that discovery mode trying to understand what they wanted to buy, for example:

• What would we need to install it? 
• What team was going to support it? 
• Were we going to outsource it to a managed services provider? 
• Were we going to hire a staff to do it internally? 

All that type of stuff had to be worked out in advance, so there was a lot of planning that went into it.

They went with an outsource managed services provider at the start because they needed staff quickly to be able to start on the migration work to get all the integrations understood as well as out of the old software and into the new one. There is always this learning when you go full-on managed services, as you don't get high levels of expertise. You mostly get people who can turn stuff around quickly without thinking about it too much. Then, towards the end is when they hired a couple others and me to try to get some more senior staff in to steer the ship and standardize everything that had been configured so far as well as come up with design patterns. So, towards the tail end is when they hired some senior developers to try to get things under control and standardize use cases.

During the migration, because it was a managed services provider, there were a whole lot of resources involved during the big part of the migration, like maybe 20 people just cranking out and moving stuff from the old systems to the new system. As things got closer to being migrated, we got down to a team of four or five people. There was a bit of managed services assistance offshore to kind of help out off-hours, and that has not really changed a whole lot. There are four or five individuals who handle the bulk of operational aspects and support as well as the engineering aspects, so it is a pretty small team.

The two areas of ROI that stand out:

1. User manual task automation because you're reducing manual time.
2. Two or three pockets of different data integration patterns that were outsourced to vendors over the years for various reasons, so there has been a return on investment there to be able to in-house those integrations from a vendor and save on that vendor cost because you have to pay a vendor to do that integration work. Why not use your own software and do it in-house if you can? 

I have had exposure to other big vendors over the years and would have to say the pricing is pretty typical. They all fall into a common pricing range, at least the bigger vendors: Axway, IBM Sterling, Globalscape, and SEEBURGER. They all fall into that mid-tier pricing. So, SEEBURGER is commensurate with other large integration vendors operating in this space. Maybe it is lower than some of the really high-end ones. You can get some of these high-end transactional messaging integration systems, like TIBCO, that tend to be kind of on a higher echelon of pricing. I would say SEEBURGER is more mid-level.

Every vendor has professional services to offer. That is where they make a lot of their money, in PSO time. Different companies feel different ways about using professional services hours. Luckily, for us, our company has always been pretty open to it. We use that professional services time sparingly throughout the year: for critical key projects, things that we've never done before, or if we're doing a major system upgrade or a version upgrade. Those things have to be done right. Although you could probably figure it out on your own with enough time, you can usually do it faster with a professional services person in the mix. That would be the only other cost: If you choose to use some of their professional services labor as a bucket of time throughout the year, like we do.

As you spin up new components or use cases, occasionally more licensing is needed to turn on more features of the software suite, but that is common across all the vendors.

I have been in this field for 25 years. I have worked with a lot of the larger integration vendors over the years. Integration vendor software tends to be fairly similar in functionality. You can pretty readily move from one product to another product and not lose too many steps, as far as understanding and utilization, i.e., user experience. However, there are some things that set SEEBURGER BIS apart from the others. I don't want to go to another vendor software after using SEEBURGER BIS, because it has these "things" that make it that much better and easier to work with. It just makes my life as a developer so much easier.

A lot of the integration vendors have a software development kit that usually looks like an Eclipse plugin for Eclipse IDE. This allows you to code extensions to the base functionality of the software suite. If the software does X, Y, and Z, but you want to add A, B and C to the end of it, then you can build your own extension to the base code and plug it in. Most of the vendors have that these days. Comparing SEEBURGER to some of the other providers, SEEBURGER BIS requires the least amount of professional services know-how. For example, that PSO level of knowledge which is sometimes needed, where you get into your own development effort to write an extension, and halfway and you are like, "What the heck?" Then, you need to have the expense to get professional services involved to help you out. However, with SEEBURGER BIS, I have been able to code many of my own extensions using their software development kit on my own with very little insight from their professional services. It is very usable and user-friendly compared to some of the other solutions.

On some vendor products in order to find logging, especially if they have bolted together multiple vendor's products, you have to go explore here, there, and everywhere. With SEEBURGER BIS, it is all together. It is not hard to find the logging. It is all pretty readable too. You don't have to go through a lot of jargon to find what you are looking for. Probably the best thing about the logging is that you can't necessarily get logging down to the packet capture level in other vendors' products. So, if you're doing an SFTP or an HTTP connection and you want to capture the packets, I have needed to install things like Wireshark or Fiddler with other vendors' software to catch the packets going across the wire to see what is going on. In SEEBURGER BIS, you can turn on the packet capturing ability and just go look at it within the product itself. You don't have to waste time installing Wireshark and getting it all connected to your network because you can get that level of logging right out of the application. 

I have been through migrations a lot over the years. This one was interesting to read about because they were crazy about it. The last vendor had some problems, so they went and actually started with a list of 50 integration vendors. You go, "Holy cow, are there really that many integration vendors even out there?" There are, but they range in size. So they started with this gigantic list that they probably pulled from some vendor, like Gartner. Then, they boil down 50 to 30 then to 15. Ultimately, after looking at all the use cases and what they wanted to get out of them, they boiled 15 down to three, then they had the last three come in-house and give their dog and pony shows along with their overviews of their software. Just based on the use cases and flexibility, SEEBURGER was chosen over all those different vendors. There is some pretty good amount of documentation that was written up on that process. It was pretty thorough.

Among the bigger vendors out there in the marketplace, IBM Sterling, Globalscape, Axway, and Cleo were some of the big vendors in the mix. 

Deciding to go with SEEBURGER BIS was a mixture of the GUI and simplicity for the team to understand. A lot of the team here, other than just a couple of us, are operational-level folks. They don't necessarily have broad computer science foundational skills. Therefore, the GUI interface had to be easy enough to use but these types of folks could work in it without too much trouble. The big things were: 

1. Ease of use in understanding the screens and how to tie together a workflow without too much developer-level knowledge. 
2. The capability to handle use cases. All these different 12 or 13 vendors were doing different data flow patterns, so SEEBURGER BIS had to be able to support all of them.
3. Stability, because the previous vendor had problems with it. That had been a pain point which they were trying to solve at the time. 

So, it was really a mixture of those three things.

Going into the next calendar year, we are going to migrate to some formulation of cloud, which is kind of the way everybody's going, and then we will also be migrating to version 6.7.

I work a lot in our integration for error/fault handling and reporting system metrics, making sure all the components are running, raising incidents automatically if there is a failure, and raising incidents if there is a problem with the software. Because I sort of operate in that monitoring space, I was hoping that monitoring would be easier and better in the new version. They have a new component that they have added, which has changed names a few times. This will allow us to do different kinds of file transfer, failure, and error types in any software. There are lots of different points of failure that you catch when you do monitoring, e.g., conductivity failure or transformation error. This tool will take the error logging for every kind of error and standardizes it into one stream of data into one software component. In the past, I had to read error log messages in a map and pull out very specific error reasons and populate them into the auto-generated incidents. 

In version 6.7, all that code that I wrote to map out those error codes, which are all different for each type of error, is all standardized and common. It is already in the software components. You don't have to do extra code to parse out and find those different kinds of errors and metadata related to each type of error. This is because it has already been standardized and put into the GUI. The GUI can also integrate with ServiceNow and other ITSM systems to auto-generate incidents. Therefore, a lot of that behind the scenes monitoring code that I have written in the past can go away because now it has all been sort of consolidated down and standardized by SEEBURGER. I am really hoping to be able to get the funding to purchase this extra component going into version 6.7, so we can move away from our sort of homegrown code into out-of-the-box monitoring.

We are always looking for new use cases in the broader integration space to try to bring in and automate what our team is responsible for. There are some other parts of the company that have historically outsourced different pieces of integration. So, we are in the process of in-housing one of those now, and then there is another one coming down the road that is sort of more into the SWIFT area. Banking has this concept of SWIFT, which is an integration to the banking network. SEEBURGER BIS has some out-of-the-box functionality to offer there, which is another space where we are looking to expand services.

We use it mostly for behind the scenes data flows. Other than a few cases, we don't necessarily serve up screens with metadata about the data that is flowing through the system to facilitate use cases for data insights. This is an area where this new version 6.7 also has more functionality. It can present more data for what is flowing through the system, bringing the data and important parts of that data up into the GUI so you could reach out to a business team, and say, "Hey, I know you probably use some other product for your day-to-day operations. But, what if we could serve up this data that you care about on a screen? Would you no longer need that other software that you are currently using? Because then you can just log into SEEBURGER BIS and see the data there."

The solution’s ability to future-proof our business is positive because I have a pretty good sense for what is out there in our organization that we are currently not involved in as well as what we probably could be or should be involved in based on what our responsibilities are to the organization. As I look at other areas of things that we are currently not doing, then I look at SEEBURGER BIS, and say, "Can it do that stuff?" The answer has always been, "Yes." You might have to buy some more licensing, but every vendor software is that way. They don't work for free. So, I would say that the feature functionality is very broad, such that any other area of data integration that we have come across in the company that we are not supporting, which is being supported manually or by some other team using some other software, we then look at SEEBURGER BIS and we have always found the functionality there, even if we had to buy an additional license or something to turn on a new feature.

Biggest lesson learnt:I have learned a ton about APIs that I didn't previously know. The software helped facilitate that knowledge because the functionality was there and I had decided to figure out how to use it. However, in figuring out how to use it, I learned a lot about how APIs work. That has been probably my biggest personal area of learning in the last one to two years: Being immersed in APIs and the file transfer space, learning all the different SOAP versus REST, and calling service operations and methods. All of that, I learned by using SEEBURGER BIS to set up API integrations of various flavors.

I would rate this solution as 10 out of 10.

The reason that we bought the product was that we have a very robust healthcare inventory environment in SAP here at the university. That involves huge inventory, purchase orders with 300 lines, electronic invoices, 856s, 855s. We knew we were going to have to have some standalone EDI ability here. That was the main goal of getting it, which we very quickly accomplished.

Coming into the SAP implementation here, coming over from our legacy EDI product, at that time we had 12 EDI vendors. It took us 12 years to get those 12 vendors, due to the limitations of our legacy product. Now, there are many hundreds because of SEEBURGER Business Integration Suite (BIS). We easily have 300 vendors now.

Before, we were completely limited by the ability of our legacy system. Our ability to react has gone up 1,000 percent. What improved was the ability to bring on who we wanted when we wanted to at the pace we wanted to. Before, if our legacy software did not already have an EDI arrangement with the vendor, we couldn't do EDI with them. When we got this, we were off to the races. We were free to connect at will with whomever we wanted to. It gave us freedom.

When we brought in SEEBURGER Business Integration Suite (BIS), we had one hospital, back in 2009 or so. We bought another large hospital and we picked it right up. We put it right on. EDI wasn't even a factor. It added no complexity to bringing in that new hospital.

Certainly, the majority of all of the inventory transactions and all of our PunchOut Catalog for research areas on campus go through EDI. 

We use SEEBURGER Business Integration Suite (BIS) EDI for invoicing for our pharmaceuticals, where they handle the invoicing and invoice approvals. We then bring the electronic invoices into SAP from there and they go to an automatic hold in SAP and then they're released. So we have been able to use SEEBURGER Business Integration Suite (BIS) to provide big invoicing solutions. In fact, here at the university, just for pharmacy alone, we're probably bringing in over $40 million a year in electronic invoices through SEEBURGER Business Integration Suite (BIS). It's easily in the neighborhood of over $100 million when it comes to meds, surgery supplies, and healthcare.

While we use it for EDI, straight up, for electronic invoicing and PO communication and confirmations, it is flexible to where we can bring it in to accommodate specialty solutions for the university such as payments for pharmaceuticals.

Number one, the ease of integration of the SEEBURGER product into SAP was pretty seamless. There wasn't any trouble, there weren't any complexities.

SEEBURGER Business Integration Suite (BIS) also allowed us to connect EDI vendors at will.

We use SRM here as well and it's required at our university that we use EDI for all of those, for that PunchOut functionality, so that we have full-blown automation with it, in and out; for the purchase order going out the door and getting the invoice in, etc. 

What it has really brought to us is the ease of connectivity to the outside world, to do B2B. No paper, everything is electronic.

It's an extremely stable platform. It has no flakiness. We don't have to baby it.

We've been able to flex it where we needed to, to accommodate other silo systems, outside of our core component applications. It's about to be tested again when we get into this new P2P solution we're looking at. I've still got SEEBURGER Business Integration Suite (BIS) on the table as part of that solution, so I would say that it's very scalable.

When I log a ticket, they come back within half-an-hour to an hour, either by email or I'll get a call. I maybe have one ticket a year, if that. There haven't been many, but they've always been very responsive, and pretty quickly.

The response that we get and the knowledge of that individual that responds are high-quality. It's not like we get a phone call back from someone who's appeasing us until they can get the real guy to fix it. When we get a response back from support, it is an individual who understands the issue and provides the solution.

Service and support have been excellent from SEEBURGER. We haven't really needed to use the product for a whole lot of other things - and I'm sure it's totally capable of them. It's one of those products where it's doing a very powerful thing for us, but you just don't hear about it because we don't have a lot of issues with it, unless we have a server that does down. But that would be an internal problem. It wouldn't really be a SEEBURGER issue.

We had a legacy system called Enterprise Solutions, and it was a healthcare-specific procurement and inventory system that was born in the late 1980s. When we decided to go to SAP in the early 2000s, our legacy system was going to be sun-setted. We had to do something because our then-current product was dying. When we decided to go with SAP, it did not natively deliver the EDI functionality. We went and got SEEBURGER Business Integration Suite (BIS), we bolted the two together, and moved forward.

One of our guys was a systems programmer coming into this. When we got SEEBURGER Business Integration Suite (BIS), it was clear that it was going to take more of a technical person. It does take a technically-rooted individual to operate it. It's not something for your everyday guy to do. For what it's doing for us, a dedicated resource is required. You have to put a real technical dude in there to run it.

Like anything new, there's a learning curve, but it wasn't that difficult. It just hasn't been hard.

Our deployment took about a week. We put it in and turned it on in a week, and that's including firing up the box and loading the software and getting our guy up to speed. The deployment was extremely quick, and because it does integrate so well with SAP that made it easier too.

The implementation strategy was that we knew we were going to go big-time EDI when we went with SAP. That was a real requirement for healthcare. They told us they do EDI, we asked a few people about them, and did a bid for it. They came with just an unbelievably great price. The university bought it, and they put us in a room with two guys from SEEBURGER and we figured out how to get it in, and it's been there ever since.

We did have our implementation partners, who were helping us put in SAP at the time, from LSI Consulting, and they did help us with the SAP connections. We also had a couple of other consultants at the beginning.

We went from 12 EDI vendors to 300 in a very quick fashion. We have exceeded the estimated ROI with SEEBURGER Business Integration Suite (BIS).

The pricing is cheap. In fact, when I saw the pricing, I thought, "Really? What's the catch?" But the functionality that we get out of it, for the price we pay, is great value.

We had IBM come in and do presentations. We had Sterling Commerce come in and do presentations. And we had a conversation with SEEBURGER. 

IBM came in here, they sent 15 guys and tried to sell us a solution that was doing 50 things that I did not want, did not need, did not care about. They didn't understand that, no matter how hard I tried to explain it to them. All they wanted to do was to tell you about how wonderful they were and how powerful this tool was that they wanted me to pay a million dollars for. 

Then, the second vendor, which was Sterling Commerce, toned it down some, but it was still a very potent tool. And the price was very high. 

I had specific requirements that I had to meet for EDI. When SEEBURGER showed up on the scene, they said, "Okay, we'll give you EDI, and check out this price." It was everything that we needed to get done, and even today it's still what we need. They didn't overkill it. They didn't try to sell me a whole bunch of stuff that I didn't need. They sold me the right functionality at the right time at the right price.

The first thing I would say to anyone looking at a solution is to make sure you understand your requirements. That's where you have to start with any product solution. Then, make sure you buy what you need to accommodate your solution, but no more. Don't get caught up in the moment and the bells and whistles. Get what you need. For someone who is looking for a killer EDI solution, SEEBURGER Business Integration Suite (BIS), if you ask me, is hard to beat. 

We're not out there doing things like mobile data entry. We're not a power company or a telephone company that's doing billing from work out in the environment. We're not a cable installer sending the bill back to the company for the service he just performed. We're doing invoices from vendors. Natively, that's the root of where SEEBURGER grew from, and it's solid for us.

Regarding the SAP S4/HANA migration, at this point, we are planning on moving to S4 around the 2020 timeframe. We've been very much in a road-mapping process. We've got a number of large initiatives to complete. Right now we're on ECC 6, 7, 8. We're at the point where we cannot upgrade any farther. We're on the latest version of SAP we can go to without going to S4. The plan is to definitely go there in 2020.

We are also in the process of looking at a new P2P solution. We're going to replace our SRM incidence for a couple of reasons. SRM is just not doing what it really needs to be doing and we need a much prettier front-end shopping experience. It's another opportunity for us to look at our business processes too. With that, we're going to probably do a lot of the cXML stuff out the door, to vendors, through that product. However, I do still see the use of the EDI stuff for our hospital inventory solution. I don't see an end to that anytime soon. I still see SEEBURGER very much in the future with S4, here at the university.

We use it for its core native functionality right now. When we move into this new P2P solution that we're looking at, we will do whatever we can to utilize SEEBURGER functionality in that solution. We're at the cusp where we're about to run into a situation where we're going to ask more of SEEBURGER, but that's still in the planning stages.

With SEEBURGER, pretty much what we do is EDI. We don't do a whole lot of other things with it. We do all the standard stuff, 858s, 855s, 810s, 856s. And that's okay because it's doing its job it is doing it well.

In terms of users, we have our EDI guy and he pretty much lives and breathes this solution daily. Then there's the materials management team that handles procurement and inventory solutions for the university and is made up of two functional people and three technicals. We have a chief developer, an interface developer, and our EDI developer, who is our metadata guru guy. So we have three people here at the university who know how to keep the solution going on a daily basis.

Our instance is still very much on-prem. We've got servers in our own data center, the database is onsite. It's not in the cloud. Obviously, cloud solutions are the future, and one day we'll get there, but we still love on-prem here. We do have some cloud solutions, like SAP Ariba Contract Management, but we're not full-blown committed to cloud life yet.

We don't use the Landscape Manager. We'd be very much interested in finding out more about that.

We do plan to increase usage. We continuously add new EDI vendors. It's not uncommon that we get one a week and we do plan to involve this solution as much as possible with our P2P solution, going forward.

Computers are machines created by men. So anytime human beings are involved, every once in a while one of the lights is going to turn red. That's part of life. But as far as a scale of one to ten with SEEBURGER Business Integration Suite (BIS) goes, I give them the ten. We're just not beating down the doors of the SEEBURGER folks saying, "Man, we got issues here." That just hasn't happened. If there was anything like that, that certainly would pull me off of that ten, but it hasn't happened. It does everything, and more, that we've asked it to do and at a very economical price.

We are an automotive parts supplier and we exchange purchase orders, releases, shipment forecasts, as well as ASNs—shipment notifications, one of the most important documents—invoices, and some non-EDI files. We support North America and South America, but we have colleagues in Europe and Asia as well. We are communicating with most of the automotive companies: Ford, Volvo, Magna, Chrysler and we use SEEBURGER Business Integration Suite (BIS) for transactions in the automotive field.

We also use the translator, BIC 6 Converter, and most of the protocols for communication: AS2, FTP, SFTP, HTTP, OFTP, FTPS. We also communicate with some banks.

We have been able to automate processes using SEEBURGER Business Integration Suite (BIS). For example, we have a lot of scheduled tasks or jobs that automatically pull information from other FTP servers, according to a schedule. These automatic flows or processes have reduced costs in a lot of environments, for sure. There are fewer people needed for a specific process in the plant. Also, the timing and accuracy of the information have improved which also helps reduce costs.

It has also helped enable digital business processes in our organization. A lot of processes are now in our BIC 6 system, which helps to improve operations in our plants.

In addition, we only have 30 minutes to send ASNs to a partner, and if this is not achieved we can be subject to fees or lose points in programs, which is not good for the plants. We accomplish this with SEEBURGER Business Integration Suite (BIS). Similarly, payments and invoices are sent using the BIC 6 application and the time it takes to receive payments has been decreased.

All of its features are needed for our business and the EDI we have with all our partners. Among the most important are the 

• BIC 6 Converter 
• communication protocols, which have the newer security features for certificates and encryption
• communication with SAP, which is our core system 
• SEEBURGER BIC 6 front end.

In addition, the B2B portal is a good improvement, a good solution.

It's really the complete system that is the most valuable for us.

There are a lot of service packs during the year. I know that part is the process for updating features, but sometimes it's difficult to update service packs every month.

In my current company I have been using SEEBURGER Business Integration Suite (BIS) for four years, and I used it in another company for five years.

It's very stable. We have not had too many issues with the stability of the system. During the year there may be one or two out outages, but in the last year we haven't had any big issues.

Our company is always growing, so we will need a more robust system and, eventually, we will have to go to the cloud. We are very close to having to grow our SAP system. SAP will definitely go to the cloud at some point, so we will need to grow our system, hardware, and architecture in our data center, and BIC 6 for sure.

The scalability is good.

The support is good. 

There is an issue in that sometimes I try to send all the information in my first email, such as the logs and system information, but the ticket that results is different, and support asks for information that we already sent in the first email. I don't know what helpdesk or system they use, but that delays support a little bit. Since I am in Mexico, I end up waiting for another seven or 10 hours to get an answer in which they ask me for something that I already sent. It's not a big deal, but it's an opportunity for improvement.

We had an issue with a certificate with one of our trading partners on a Saturday. We called SEEBURGER support. It was a little difficult because they needed to contact a developer who was not available. But the next day the issue was fixed, and we got the support.

Also, because sometimes there is a delay in the number of service packs we have, when support is needed, the answer is always, "You need to update your version of the service pack." So a reduction in the number of service packs during the year would help. I think 6.7 and the cloud have something along these lines, but for customers like us who are on-premise, the service pack upgrades are difficult.

But as a company, they are always in touch with us and trying to give us what we need. That is the most important thing. They want to see what our needs are and what our current situation is.

We did not have a previous EDI solution.

The setup is not complex. Sometimes what can make it complex is the number of flows or the amount of information. But in terms of the application itself, it's not complex.

The solution is deployed very quickly, even in minutes. The complicated part is testing all the flows with the new solution. That part can take months. For the last upgrade, it took about five months because we had to test all scenarios and business cases. When we found issues we had to report them to SEEBURGER. They had to fix them and we had to install the solution and test it again.

For upgrades, here in Mexico, there are two people from our company who are involved. In Europe there are another four or five more. The same teams manage it on a daily basis. We have developers, people on the communication teams, and business analysts using it. Overall, there are about 10 people using it in North America, and in Europe there are another 10.

It provides the flexibility to start small and pay as you grow. The flexibility there is good.

The biggest lesson I've learned from using the solution is that integration is always possible. I have learned that there are many ways to integrate and exchange information in a timely and accurate way.

Having accurate information on time is the most important thing for me. That's the way other people can make decisions. SEEBURGER Business Integration Suite (BIS) helps you to do that.

SEEBURGER Business Integration Suite (BIS) provides us with the solutions we need. We will see with version 6.7 if there is something else. I know there are more features in it. But for now, with version 6.5.2, we have all that we need. We want to see if 6.7 will give us other things that we can use.

To be honest, for us, the most compelling reason to upgrade to 6.7 is the end of support for our current version. If we don't upgrade, we won't have the support. But at the same time, the new version should have some improvements that will make things easier in our jobs and daily operations. I have heard that it has many new applications and a new portal. We could survive with the current solution, but there won't be fixes for it any longer. Also, it's good to have a new version with new APIs and new features.

We use it mostly for data integration. We use a module from SEEBURGER called Managed File Transfer or MFT. We move about 30,000 to 50,000 files in a week in our company. The files are moved intracompany but they also move between our company and our external partners. We also have a bunch of stuff on Amazon. We use SEEBURGER Business Integration Suite (BIS) to integrate our data center with Amazon file transfers.

Before this product, we used to use a solution that required us to write code and then go through the process. It would take five to seven days for our development team to do the code, test it, and then promote it. The SEEBURGER Business Integration Suite (BIS) MFT solution is really configuration-driven. It comes with a number of adapters for file transfers. Some of these processes, which used to take five to seven days and cost an average of $5,000 per integration, can now be done in a couple of hours because of the configuration. And they cost less than $1,000 dollars overall. We are able to do faster delivery and it's much more robust, handling large files really well. And it does bring cost savings.

It is also flexible when it comes to adding integrations. We have created some frameworks and we are able to utilize those frameworks very quickly. The solution is really handy in those terms. For example, when we bought the product, we had a requirement for transferring data to Amazon S3 buckets but we did not have a solution in our shop for large data transfers to Amazon S3. We worked with SEEBURGER and created a framework solution and now, using that solution, we can configure the transfer in an hour or two and enable it to go to existing or new S3 buckets. It's a tremendously powerful solution and it gives us a lot of leverage to get things done quickly.

It's a very robust solution and it's very configurable. Before this product we would use an ESB-type of solution which required us to write code and go through a process. We can configure the SEEBURGER solution much more easily, instead of writing code. It does its job very well, to the extent that we do not see failures in the system. It can handle large files very well, which is one of our bigger concerns. We transfer some bank files up to ten gigs in size and it handles them really well.

Larger loads can be handled either by Active-Active or Active-Passive. The Active-Active definitely provides high up-times so if one of our nodes goes down, the other nodes still continue to work and we are not totally down. It meets our requirements for "five nines".

There's always room for improvement. One of them is that the product is not integrated very well with different cloud providers. We did work with the vendor to build a solution for Amazon, but there is no solution for other cloud providers like Google or Azure. The vendor needs to create adapters so that if we have a requirement to transfer data from our data center to another cloud, outside of Amazon, we would be able to do that. 

Another issue is that support for the vendor's operating system is not available. There used to be support for the older operating system over SMB, but they have discontinued the support. They need to come up with a solution to support the new Windows operating system.

It's a very stable solution. We do not see much of a problem with it. We may have to re-start the solution once a year at the most, but that's part of our regular maintenance cycle. The solution is very robust and stable.

I don't think the scalability of the solution is that great because they have tied the solution to their named nodes and it does not allow scalability like some of the cloud products.

We have the Premium Support and we pay extra for that, and it gives us access to their engineers. It also requires the vendor to respond within three hours, if we create a Severity 1 ticket. But we have not had many problems.

We switched mostly because of efficiency and cost reasons. Our previous solution required a lot more development and SEEBURGER Business Integration Suite (BIS) is a much more configuration-driven solution.

It is a complicated solution, it was not a straightforward setup. We leveraged their Professional Services to help us understand and architect the solutions. I do see a lot of room for improvement there, because the solution and the documentation are not very intuitive. There's a lot that could be done there. It's not like you're installing one product, it's a number of products that you have to install and configure. And there are always chances of failure. There's a lot of room for improvement.

From when we bought the product to when we took the first product live, it took us about four months. But after the infrastructure was set up it was much easier.

A lot of the third-party service providers did not have knowledge of this product. We use Accenture as our core SME but they did not have knowledge of, or skillsets in, this product. We had to work with the vendor, hire their Professional Services to do the architecture, do the installation, and to train our engineers on the solution. There was a lot of learning curve there and we spent a lot of time and money with SEEBURGER Professional Services to get to that point.

We have seen return of investment in terms of how quickly we can deliver.

It has a very goofy pricing model in the sense that they have so many components and it's not very clear what components you require to do your work. When you ask for that, you learn that there's a surcharge for them. It's not that you buy a product and you can use all the compatibilities. They have all these different bits and pieces of it and you have to pay extra for all those things.

We did a big PoC. We narrowed it down to three or four vendors and we invited all of them to come on site and demonstrate their products. We gave them a use-case scenario to implement and, based on that, we made our selection.

The only advice I would give is to see that the industry is moving towards the cloud and this solution is an on-prem solution. The vendor does not have a cloud offering, at least not that we're aware of. So evaluate a solution based on your needs.

Right now, we are deployed on-premise and we are migrating it into the cloud.

The product is being used quite a bit and it's meeting all of our needs for file transfers at this point. We are not expecting to increase usage at this point in time. We are looking to the vendor for the cloud migration and, as part of that, we may have to add more cores. The cloud architecture is different than our on-prem architecture so we may have to make architectural adjustments to allow "five nines," and that might force us to buy some additional licensing.

We do not use Landscape Manager, we only use the base solution, the Business Integration Suite. We mostly focus on the Manage File Transfer part.

We do not have any business users using the solution, it is an IT solution. We do have support teams that are the users of the solution and they're supporting and monitoring the processes. We also have a number of software engineers who are configuring processes to take the files and move the files. There are about ten people who provide support for these things, so they have access to it, along with our system administrators and engineers.

Our system administrator is responsible for running the system, upkeep, and making sure that the servers are patched and everything is working. We have a couple of engineers or developers who are using it. Right now, we are turning around about five to eight projects in a month. The developers work on some of these configurations and provide testing. It's a very small staff.

I give the solution a seven out of ten because it's a very robust product and it works well, but architecture-wise it's complicated.