What needs improvement with SEEBURGER BIS?

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.

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.

There might be some improvements they could make to the portal, but they're not anything that stops me from working.

There are some aspects of the front-end GUI, the actual queries that you use, that could be improved. They're all very minor to be honest. It's quite a nice modular system. It fits together quite well. The changes would be to the usability of the system at the front-end. It's not the underlying processing function of the system. It's how we maintain things and being able to see what's going on.

We haven't really found that the solution's unified code base helps with problem resolution. Because it's a code-based system, we don't have much access to the logs or what's happening. So we have to log a ticket with SEEBURGER. We only get a message that something has failed. Sometimes the message is in German and it's very generic, very high-level. That could be improved, to see what's wrong, because often, it can be data-related but we have to open a ticket with SEEBURGER for them to tell us exactly what the issue is. The error-tracking could be improved. That's a big thing. A customer will tell us they have an issue and we have to find out why it failed, because often it is a data-related issue. Maybe a field is too long or too short. I would like us to be able to be more self-sufficient. But I understand it's a cloud-based solution, so they have to own it. It's a shared system with other customers.

We wanted to use API. We were told that in 6.52 we could use API management. Later on, we found that API management wasn't that completely integrated into the 6.52 solution, and if you wanted to have the whole API suite you might have to go to 6.7, the latest one. We are waiting for that. There is talk that next year we might try to migrate to 6.7. Migration is not an issue on our side, but it's the customer migration which takes a lot of time. That involves a lot of concern and hard work because we have to have the customers onboarded as well and they need to do some testing. It's always really hard to get the customers to find time for that.

The speed of development needs improvement. If you acquire any customization, it can be a slightly slow process. I would like to see more flexibility around customizations. The time frame right now depends on the sophistication and customization, but we have to go through a process of getting them to develop, implement, and test it. This might take a couple of weeks. If it was a simpler system to customize, the time could probably be cut by half or down by even 25 percent of what it would normally take.

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.

A true debugger that allows you to step through the process would be a good improvement. Right now, we are limited to reading the log file generated by the test screen in Mapping Designer.

I would've liked, from day one, to learn how to do my own mapping. It would have saved a lot of time and effort if that had been brought forward earlier. It's there, I just didn't know about it. Also, some tidier, easier-to-use interfaces would help.

One thing that comes to mind is the service-oriented architecture. I have seen, in some of the other middleware tools, that you can create one service and then reuse it, without creating a copy. As I mentioned earlier, we create a copy of an existing map. In some of the other tools out there in the market, you can create one service and use that service without creating a copy. That kind of capability currently doesn't exist in this solution. Also, these days, a lot of these companies are providing their solutions on the cloud. I think SEEBURGER has some presence there, but we're not really using it. For the future, they may have to provide more of a cloud-based solution.

The BIS Front End needs a little bit of refreshing, especially when it comes to setting up new trading partners and trading partner agreements or transactions. It can be a bit clumsy to copy and rename and then go in and modify. That could be improved a little bit. Also, on the server side, there are a lot of administration and configuration files that you need to go in and do maintenance on. You have to find them in a certain folder so it's very error-prone and it can be a little time consuming unless it's documented. They could pull some of those individual configuration files into the product itself where there's a better user interface for that. In terms of adding features, they've recently talked about a few. One is a way to manage your web services or your APIs. That would be a big help because, right now, we have four web services and there's quite a lot of setup to each. They're in different areas within SEEBURGER Business Integration Suite (BIS). It's my understanding that they're going to be able to pull that together so you can view that entire setup in a more streamlined manner. That's something we're looking forward to.

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.

The ability to bind a mapping to an agreement seems a bit clunky. It would be nice to have a better way of navigating to a map name rather than using a drop down list.

Their traditional model is a vendor flow. We are looking to do a customer-based flow, which which require significant development from SEEBURGER. We are working with them to do this using their WebEDI. It is a brand new area for them, but it could be an option in the future.

The product can be improved from a support and functionality perspective: * An improvement should be done to align it more towards modern technology. E.g., if according to other systems, like Microsoft, there are upgrades and updates, the system should be enabled to support the latest upgrading systems. * The general support center should have a dedicated person who is familiar with a client's system instead of a general support tech who doesn't really know the client's system.