ActiveBatch Review

Reduction of coding and development costs are substantial


What is our primary use case?

ActiveBatch controls just about everything in our organization. We do server monitoring with our EDI feeds being inbound and outbound. We do Oracle processing with it. 

It is very comprehensive for what we do and a central point of everything in our organization at this point.

How has it helped my organization?

We have some things coded out to execute processes on systems internal to us, but nothing out of the cloud. We have web based products that are internal and made available to our internal users. We have some external users who use these web based products. We control those from within ActiveBatch where we do remote logins and can control some of the processes. This is for internal and external clients' availability.

It reduces the load and manual efforts on everybody's parts. With a thousand jobs running on a daily basis, it allows our programming staff to focus on other things rather than deal with manual programming efforts, taking quite a load off our programming staff. 

The nice thing about ActiveBatch is once we have created a specific job that can be easily be replicated to another job, then minimal changes have to be made. Reduction of coding is substantial in a lot of cases. The replication of one job to another is just doing a few minor tweaks and rolling it into production. This decreases our development costs substantially. 

Automated integrations have helped us build end-to-end workflows. When we send an ACH to the bank, it used to be that a report would had been generated, then somebody had to call the bank and provide the bank with the totals. We are calculating all that now within ActiveBatch, then sending an automated email to the bank informing them of what is contained within the actual ACH. This has eliminated the need for several people in accounting or finance to have to deal with this work. It runs flawlessly. Though, it took a while to develop, it's a good case example.

We do have FTP file triggers and file triggers internally. We don't have to wait for somebody to say, "Hey, we've posted a file. Can you process it?"  The nice thing about ActiveBatch is we can specifically look for triggers, pick stuff up, and process it the minute it hits. So, it takes that step out of the equation of using internal or external people, and asking, "Something's been posted. Can you take care of it?" Instead, it's done and out of the way. This reduces delays.

What is most valuable?

I find all the features valuable. 

A lot of our server monitoring has becoming more critical. We monitor CPU loads and disk space requirements. Those are becoming more helpful to us from an automation standpoint, where it makes business decisions on returns. It really helps out the entire IT department and the entire company, as it takes a lot of the manual effort away from a lot of people.

It takes a lot of the manual effort off a lot of people from having to continually look at information. We make business rules within jobs. If something is wrong, it will get somebody out of bed in the middle of the night and let them know there is a problem. Rather than people coming in the morning, we have people who get up in the middle of the night and start working. Because when there's a server issue, that just creates a whole problem. This eliminates a lot of that since we catch these problems. We're taking a proactive approach to our internal structures.

The solution provides us with a single pane of glass for end-to-end visibility of workflows. The nice thing about ActiveBatch is you can see at a glance what is running and what's going to run (future runs). It gives us a good snapshot of everything that's going on, which is something that was lacking for years. With our window pane, we can see exactly everything that will happen at a glance.

The console is extremely flexible. We have incorporated things into ActiveBatch that a lot of people never thought possible, e.g., a lot of the server monitoring stuff and we have over a 1000 jobs that run out of it on a nightly basis. From an automation standpoint, it is really reducing the need for so much manual effort, which creates its own problems because we have a thousand jobs. Somebody has to look to determine if there are any issues. So, we have business rules put in place in all our jobs which try to make it easier for everybody. We do banking information, EDIs, specific automation for other applications, service monitoring, and reporting. A lot of the stuff is called from other systems and imported into ActiveBatch, then manipulated. It's so comprehensive.

What needs improvement?

It may require some weird programming of things. However, most of the time, we can solve the problem and set solutions in place, then it's carried forward to other jobs. 

I would really like to get into Active Directory stuff with it, but that creates a problem in our security audits, etc. We have to tread carefully down that road.

Moving to version 12 will be a real challenge for us because we have to put in a whole new server, as we are on one now that is obsolete. Plus, when we build the whole thing out, we will need to: 

  • Build out a test environment. 
  • Go through every single one of the jobs, then test out everything on maneuvers.

We will have to engage ActiveBatch in a contractual relationship to help us with this because it will be a huge project.

For how long have I used the solution?

Eight years.

What do I think about the stability of the solution?

I have a great impression of the stability. We just keep adding to it, and this thing never fails. It just runs. Comparing that to our back-end systems where there are always problems, ActiveBatch just continually runs. That's what I've told our executive team. I said, "The only time there's a failure in this company is when your back-end systems screw up."

What do I think about the scalability of the solution?

We have limited users in this product. We have a couple of developers (EDI specialists) who look at some of this stuff. We probably have several hundred people who end up with the end result (report distribution) of ActiveBatch via email. We distribute mainly via phones.

How are customer service and technical support?

I have emailed Active Batch about a couple of things. I have always had great experiences with the technical support guys. Some of them just go above and beyond their call of duty. They are fabulous to work with.

Which solution did I use previously and why did I switch?

Everything was a manual effort before ActiveBatch.

How was the initial setup?

There are so many different components that we had to integrate with Oracle. There was a lot of back-end work which had to be done when the server was originally built out. Missing those steps would have ended up creating some problems. We had to go through it a couple of times before we got everything straightened out. With the Oracle integration, there are a lot of components that have to be installed correctly. Even when migrating to version 10, we had some issues with that too. There are a lot of internal components with Oracle.

This is sort of where ActiveBatch system falls down just a bit. While it's easy to say, "Your Oracle people need to deal with this." Our Oracle people know nothing about ActiveBatch. There is this back and forth, where ActiveBatch says, "Your Oracle people should be dealing with this," and Oracle people say, "No, we don't know anything about ActiveBatch." Then, it all falls back on me as to what happens. Nobody is taking responsibility. This is the biggest failing for ActiveBatch. It would be nice if Advanced Systems Concepts, Inc. could just say, "We'll help you with this entire process."

What about the implementation team?

We contracted with ActiveBatch to help move us from version 9 to 10. It took us two or three times to get it right because there were components that ActiveBatch wasn't clear on about needing to be installed. They finally came back and helped us on this because we had an engagement contract with them. However, it took a couple of times to do this. The problem in a production environment is you don't have a lot of leeway for downtime. The jobs that we have, they run 24/7/365. Trying to find an open slot to do migrations is pretty difficult.

What was our ROI?

With the automation efforts that we have done over the years, we have gotten our money back. We save thousands of man-hours annually.

The use of the solution resulted in an improved job success rate percentage of 90 percent. It reduces manual efforts. Once you take manual efforts out of the equation and put business rules in, we find the failures that occur are usually external to the company, not internal anymore. Job failures during the day are a handful out of a thousand jobs, and usually an external issue. It is external vendors not following their rules, though we have business rules and alerts set up to inform them. We send emails back to external clients, and say, "Something was supposed to be posted, and it wasn't posted." In that sense, it has eliminated a lot of those manual effort steps as well. It is all self-contained in ActiveBatch.

Use of the solution has resulted in a 60 to 70 percent improvement in workflow completion times. 

What's my experience with pricing, setup cost, and licensing?

I don't think we've ever had a problem with the pricing or licensing. Even the maintenance fees are very much in line. They are not excessive. I think for the support that you get, you get a good value for your money. It's the best value on the market. I've worked with a lot of products in my career, and this is by far one of the best products I've ever seen. You're getting your value.

Which other solutions did I evaluate?

We did evaluate other products before purchasing.

We asked for a proof of concept on this solution that ActiveBatch provided. We looked at the scalability, integration, ease of use, and constructing automated jobs. Those were the driving forces in the selection of these products. Their job libraries are so nice. You don't have to be a rocket scientist to figure some of this stuff out. 

What other advice do I have?

It is a great product. I can't speak enough about it. We haven't found anything that we can't overcome in ActiveBatch. When they put this product out, they thought it out and put a lot of nice stuff into it. There are features we haven't touched yet, even though we have been on it for so many years.

We have never really uncovered anything that's a problem. It is a well-thought-out product and one of the best that I've ever worked with. I would rate this product as a 10 out of 10. I really like this product.

Think about what you want to automate, then put a process flow in place. For somebody who wants to start this, take one job and put a process flow in place, then develop it within the system. Once you get one product in place, it is pretty easy to replicate it. Initially, to get started on some of this, it can be a horrifying effort. It looks overwhelming, but once you get going on this stuff, get one job in place, and figure out what to do, then it's pretty easy to replicate across the board.

All our back-end systems are Oracle driven from an integration standpoint. Oracle interfaces are very nice which helps us a lot because we can do a lot of coding and take care of a lot of the back-end Oracle stuff. However, we don't use external things, like Amazon, as that is against our security

We just started looking at email triggers, but have not implemented any at this point.

Which deployment model are you using for this solution?

On-premises
**Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Add a Comment
Guest