The setup is getting a lot smoother. It's reasonably easy in the latest versions. Our previous system was generally Unix. We're now on to virtually a wholly Windows setup, which brings different sorts of problems. I'm actually quite impressed with the way that the SEEBURGER team is able to put out patches. It's very smooth, which is quite refreshing.

It took about four or five months from starting the build to actually getting off of customer migration.

We are currently migrating from 6.32 to 6.52. The initial migration was reasonably good, but we have an awful lot of customers — individual companies that we connect to — and some of them are pretty difficult to get off the old system. We're getting close to the end. There are some IT departments among our customers where they will put the initial product in for connecting to us and then everybody leaves and there will promptly be a problem. But we'll get there. We do have a plan to move to 6.7 fairly soon but we need to get rid of the old one first.

We haven't found that many differences between 6.32 and 6.52 — the two versions that we use. We have had to change some of the transformation codes to fit in.

For our migration, the strategy was basically to build a brand-new system, which is what we had to do anyway. There was no getting away from that. With our current system, we may well do an in-place upgrade from 6.52 to 6.7. We just have to add a few servers and then we're good to go.

I did not install the solution myself. I wasn't a part of the deployment. 

We have a few different use cases, and we have about three people that can maintain the solution to facilitate that.

We set up the solution 15 years ago. It was so long ago, that I can't recall if it was easy or difficult or what was involved in the process. 

The solution's initial setup is neither easy nor difficult. You need to have knowledge and experience in order to do it.

The initial setup was complex because we were migrating from multiple solutions.

In general, the setup doesn't take that much time. It's straightforward. They introduced Deployment Manager a couple of years ago and Move-To-Production was introduced about four or five years ago. But we have had this tool from 2008 and back then there were challenges in deployment. It was time-consuming and more manual. But now, with recent changes, deployment is straightforward.

The amount of time it would take nowadays would depend on what type of deployment we are talking about. There are different components. One of  them is map deployment and that doesn't take more than a couple of minutes. The deployment for process is less than a minute, but it depends if you are changing the entire form of SEEBURGER Business Integration Suite (BIS). In that case it might take like more than a minute. But if it is a lightweight project that doesn't touch the built-in forms, it should take less than a minute.

But to deploy the entire suite would take time because you have to have a database before you go ahead with the deployment. You need to allocate the schema for the specific instance and then you need to start working. If you have the database ready, and you have the network setup between the database and the firewall in place, I don't think it would take more than 30 minutes to deploy a new SEEBURGER Business Integration Suite (BIS) instance.

It could be handled by a person. But usually, when you talk about an enterprise, there are different teams for handling the database and the application. If the database and the operating system and the network and firewalls are ready, I can go in as a SEEBURGER expert and SME, and install their product. As part of the installation process, it will ask if it is for a process engine or for Adapter Engine and what the database is. It will ask what port it's listening on, as well as what the service name is, etc.

Because everything is on-prem, we take care of the deployment. SEEBURGER is not involved in anything. They just release regular patches and upgrades to the system. We download the patches and software from their website and we install it. We upgrade the system and we manage the entire SEEBURGER suite in Ingram.

They are only responsible for severity tickets. We have a premium-level agreement with them for support, just in case we have a production issue and we are not able to figure things out. We can raise a "critical" and then they join a call or discuss resolutions via email. That is the only place where SEEBURGER is actually involved.

SEEBURGER is moving to a more containerized architecture with Kafka. So if you want to move to a more containerized framework, that is with version 6.7. If we move to 6.7, that is when we might involve the vendor to lay down the design and provide the integration strategies.

In terms of maintenance of the solution, there are six people involved, five working from India. I'm the one in the U.S.

When we're upgrading patches, it's straightforward. Although, updating to 6.5 from our previous version (6.2) was a little challenging. We needed to create a big project to move the consulting services. The planning took a few months and we still have a few hiccups after the upgrade. We have had upgrades that were easier, but going to 6.5, it took a little effort.

We have only a specific window for maintenance, which is monthly. That was agreed upon from the start of the year with our businesses. Therefore, we like to have the maintenance hours controlled by us versus the providers. That is one of the reasons that we are not considering the cloud yet.

The deployment was not difficult. It's user-friendly, and once it's configured, it runs fine. For each vendor, it's a manual process because there is no other way to go. However, you just need the time to put it altogether. They have tools and default maps which are helpful. It took probably three to four months to complete everything and merge everything together. For our last upgrade, the planning and implementing of the upgrade on our development system plus the testing with finding issues and fixing them, then upgrading it to production, took three months altogether.

Because it is a client-installed application, we installed the updates on top of the existing ones.

When we started with SEEBURGER, we used a version called SEEBURGER Business Integration Suite (BIS) Version 5. The setup for that was a little bit complicated. 

With the newer versions, like 6.7, it is easy because they guide you with a lot of wizards and good documentation. If you do a setup now, you can use the BIS Landscape Manager, which is a tool with which you can control your complete landscape. You might have several components inside such a BIS environment. You might add another server, for example, to handle demand. The Landscape Manager is a tool that gives you a full overview of your landscape. From there, you can set up new components. If you book something in addition, you can add it from there. You can do service pack updates. You can install hotfixes from there and all potential third-party components you might need. For example, you can install components to connect between SEEBURGER Business Integration Suite (BIS) and SAP. You can even handle licensing topics over the Landscape Manager. This was a significant improvement, over the years, because it helps us to fully automate even the basic administration, when we are not thinking about interfaces concretely.

We started at a point, 20 years ago, when some of the mechanisms were not there. Now, when you start with SEEBURGER, if you have a clear idea about what you want to do, the initial setup could be done within less than one hour, because of their guided approach. That includes installing the system base with all its components and even deploying a standard solution which provides a lot of integration functionality on more of an abstract level. That way, you do not have to deal with technical details. You just input whatever is required to run your interface, but you do not have to deal with any technical topics.

The initial setup was straightforward. A person whom I work with, and is not very technical, found the setup complex, as there are a lot of steps. I put down the steps for her, and she was like, "Oh yeah, this is pretty easy". You just got to follow the guidelines.

I have converted 95 maps. I probably have another 100 to 200 more to go. I use the mapping tool every day. 

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 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.

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 recently switched over to the cloud-based version and that process went on for a long while. It seemed like an initial deployment because they had to rework everything. They didn't lift and shift a lot of our mapping which was done in SEEBURGER Business Integration Suite (BIS). They rewrote it from scratch because they have this new method where they convert everything to XML and then they convert it to an IDoc. There's some standard process for that, but it seemed to take an awfully long while to move from our on-premise to SEEBURGER Business Integration Suite (BIS) 5 in the cloud. Elapsed time was about nine to ten months. There were a number of changes in the solution as well.

We found it complex because we did have to involve SEEBURGER's senior management at one of the stages, regarding how they wanted to transition. We did find it frustrating.

Our strategy - and the main reason we went with SEEBURGER Business Integration Suite (BIS) - was that we would take "as is," and bring that across to SEEBURGER Business Integration Suite (BIS) 5. That was the plan. From my understanding, they already had mapping for some of our customers, the larger, well-known ones, but it did seem to take an awfully long while to implement our solution.

And then, we did have complexity with the SEEBURGER Business Integration Suite (BIS) 5 system where it wouldn't work with our VAN here in Ireland So we had to move to AS2. That could have accounted for some of the delay in implementing our project.

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 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.

We have our own technical resources onsite. We have a server group and a firewall group and I'm the EDI application guy. We were used to a lot of the terminology and stuff from the past. With that in mind, I thought the setup was quite straightforward.

They provided us with a hardware-sizing questionnaire, which was really helpful in determining our server requirements. Thinking back - it's been six years - it really seemed to go a lot smoother than it could have gone, especially since it was a brand-new product to us.

Regarding our implementation strategy, what we wanted to do first was move all of our communications with our VANs and our direct trading partners into SEEBURGER Business Integration Suite (BIS). That meant we weren't doing the translation and the mapping within the solution, but all of the communications were done through it. What that allowed us to do was to pull all of our trading partners together from Europe and South America and North America into one place and have all the communications flowing through one area. That allowed us to support it a lot more easily and to take advantage of that AS2 protocol.

That was our initial strategy, to do communications, and then follow that up by doing the mapping, one trading partner or one transaction set at a time. And that's what we've done.

With any new product or implementation, usually there's a driving force. One of the things we were asked to do was to implement a web service in Europe that we had no expertise in and we had no platform to run it on. SEEBURGER provided both of those. They showed us how to use SEEBURGER Business Integration Suite (BIS) and we used their consulting services to assist us with the back-end integration. So, rather than put this web service or API in another place which would eventually have to be moved to a central location, we were able to incorporate it right into the SEEBURGER product.

Our first phase with communication for all of North America only took three months from the time they loaded it onto the system initially until we were cut over. And then, to pick up Europe, we didn't want to do everything at once. We worked on Europe after that and that was another three months. So, within six months we had our communications moved over and we were then moving onto the other phases.

When we deployed, we had one SEEBURGER consultant who was dedicated to us for that first three-month period. Then we had another one who came in and did some training and some of the planning with us. As far as our own internal resources go, there were three of us who identified all the trading partners and all the nuances of what needed to be set up and tested in the new system. All in all, it was about like three internal people and two SEEBURGER people.

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.

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 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.

The tool's installation was easy. 

The initial setup is complex, but for good reason. Of course, I would like to have a simplified process and a customer map that really matches my needs as well as follow their central global team. We have to work with them. That leads to delays and we cannot ask for any changes. It is complex and tedious, but I understand that it is for the good. On the flip side, they are very reliable on the technical end because it's complex at the beginning and they can solve most of the issues.

The deployment time depends on the size of the project. For a simple project, it could take a month to deploy.

The initial setup is not the straightforward. It took couple of months for us to set up.

We had planned to do it in a month and migrate all the file transfer interfaces into this new platform, but it took us two months for installation, then another two months to move the interfaces. It may not be a software issue, because there are so many other factors, e.g., resources, dealing with partners, etc.

The initial set up was done by SEEBURGER consulting. It can be complex due to various factors, such as server settings, database settings, and security settings. 

The initial setup was before my time.

People who worked on the initial setup told me that the initial setup was pretty slick.

I was involved with upgrading from five to six. They are completely different technology sets. It was as straightforward as it could be moving from one full technology to a different one. They had very well defined paths for converting our mapping procedures, but we had to rebuild all the entities from the ground up. There wasn't an option to import those or an explanation of why the technologies don't work together. It makes total sense why they moved from five to six. So I would say that it was as straightforward as it could be.

The migration took four to six months. 

We had 90 days to convert all our maps and then the next 90 days or so spent building our entities and testing. Then we went live when we had two-day downtime. Transfering the databases was a lengthy procedure of about 20 hours. We had to have a two-day downtime but we did that over the holiday weekend. So we did the same thing: module import, building new entities, testing QA, approval, and then the implementation go-ahead.

The training you receive is not that great. A lot of it is self-taught. They could do a better job of explaining the inner workings of the logic used, so that one can relate to what is going on.

It was more about learning the system and how it operates with a separate database (Oracle) in our case. You have to know very well what kind of transactions you will do, how frequently, and what volumes are going to come to the system.

We utilized the Professional Services of SEEBURGER. They came and did all the installation for us. We had some of the solution architects from our company design what the system landscape should look like but, all in all, it was SEEBURGER that did the installation of the product.

When we bought SEEBURGER, at the same time we acquired another company. So it was like an SAP implementation we were trying to do and, on top of that, we acquired that other company. For us the project went pretty long because of all the complexities and all these other developments. It took us around a year or so until we first put something into production.

In terms of the implementation strategy, we just had the SEEBURGER consultants initially do some training for us. They did all the installation, and after we got the training, we did all the development and the implementation of the solution, as such.

The setup is complex but we get the SEEBURGER implementers to come out, the consultants who do it the first time, whenever we have a major upgrade. Recently, we have tried to do all the service packs ourselves, but if there is a major upgrade - and most probably when we migrate to 6.7 - we require some consulting time from SEEBURGER because there might be a major change in the way some of the interfaces or communication might be working. That might be when we require a lot of consulting time from SEEBURGER, to understand the product and what features it has and what capabilities we can use.

Major upgrades are as demanding as an initial deployment, but if it's just a service pack, it's okay now. They have made it much simpler. Because we are on Active-Active, we can do patching while the service is still running.

Our initial deployment, back in 2009, took about two days. The software deployment only takes a day or so. But we also had to get all the hardware, the machines, and network service. Those took time. But the software deployment and configuration took just a day-and-a-half.

For that deployment, SEEBURGER people did not just do the deployment, they also worked on initial interface development for us. There were new mapping tools and we didn't have any experience with it, so they did that also. We had a contract with them for three months or so to have them do a lot of work for us. They had two or three consultants who basically converted a lot of the old IBM maps into the new SEEBURGER Business Integration Suite (BIS)-format maps.

At that time it was a big project because after installation they had to do the maps etc. Everything had been in IBM until that time. They had to replicate that into SEEBURGER Business Integration Suite (BIS).

Now that we have more experience and good resources on our side, we do it ourselves. But at that time it took a total of six months, of which three months were for the initial consulting where we had two or three consultants. After that, it was only one consultant.

At that time it was a new thing for us so we were not in a rush. We installed and tested everything and we migrated one customer at a time. We had an old, IBM-based integration tool. The installation was done as a "blank canvas," and then we migrated our customers.

For a major upgrade, we set aside a period of seven days because we've got quite a few systems: a development system, a test system, a UAT or business integration system, and the production system. We go by step-by-step, so the whole process will take a week. On the first day, we'll do the development system and let it run for two days. Then we will upgrade the test system and let it run for two days to see if there are any issues. Then we will go to UAT, and after two days or so, the production system, which might be on a Sunday. It's an issue of timing because we have to get our change-control times allocated, especially when doing an upgrade to the production system.

I'm sure the product is set up in a straightforward way. The maps that we set up per customer or per customer's site are all customized. That's where the complexity is. The complexity is the not in the product. There is certainly a learning curve for becoming an expert mapper and using the tool to do the maps, but the software in and of itself is not complicated.

We did our deployment gradually because we couldn't handle the "big bang," so we did it in six to nine months. We had all those maps in existence in another tool and we had to migrate them and then get them all working individually. We had several hundred maps to do and we did them over six to nine months. Our strategy was a slow cut-over as we tested each map using the new software.

I won't lie. The setup and the configuration were both complex because it is a powerful tool.

The biggest complexity was one of the biggest benefits. Namely, you can run SB BIS components on multiple inter-connected servers, which we do.

The initial setup was quite straightforward. Depending on the amount of data that you need to take with you from the EDI platform that you’re already using, Seeburger also provides consultancy services to help with the transition. Their documentation is easy to read and understand, making the platform easy to setup.

The initial setup was pretty straightforward. I gave them an Excel and they did the work. I liked that.

Due to SEEBURGER jumping right on board for us in America, we did it fast. We didn't start talking until about the end of March, and we went live July first. So the workload was heavy from the end of May and June. There was some cleanup of some stuff after that, but they really pushed hard for us.

We were supposed to have set it up with SEEBURGER Germany, but somehow that got missed. So our implementation strategy was to jump on with SEEBURGER America. They were super-flexible and they helped us get all the information and make sure we were ready for the first plant, and then we went live in the second plant in October.

The only problems were caused by us because we didn't have enough manpower here.

The initial setup was somewhat complex. I would say you need SEEBURGER Professional Services to help you through it.

Deployment took a couple of days for each environment. Our implementation strategy was to deploy to our Dev/QA environments first and production at a later time. We deployed on-premise as we prefer to control the environment of our mission-critical systems.

The setup was a little tricky, but the vendor always helped us with the installation.