OpCon Reviews

Our use cases for OpCon are expanding. We initially went with it because we're a Unisys mainframe company and they were the only scheduler that did what we wanted it to, and that also supports Unisys. But we have branched out into running Windows SQL jobs, and we will soon be starting up API interaction. Hopefully at some point, because we are going cloud and the mainframe is going away, we'll start interacting with that also. We'll start doing that change within the next three to six months.

I've been here from day one, and it has gone from us manually writing out schedules, and operators having to remember pre's and posts, etc.—all done manually—to getting that automated. Once that was all automated, it was a huge improvement for us because there were considerably fewer errors. The errors are very minimal now. When someone implements a job, if they have a typo or copied a similar job and forgot to change something, those would be about the only errors that we have now. We're down to hardly any. We now have less than one a week.

The improvement with the Solution Manager, so that the programmers can become more aware of what's going on within the scheduler, has really helped us.

OpCon has also saved our IT department time. There is a lot less interaction with the developers. Developers are aware of the information they need to give us to place something into the scheduler. We've set up a template, they send in that information, we get it implemented for them, and they're up and running. We used to ask them to give us two workday weeks to get something implemented for them and, depending on the complexity, that's down to a day or less, at times.

With IT time freed up, we've been able to move forward with other business needs, especially now because of the switchover and the mainframe going away. It has enabled my staff to start studying other aspects of our IT areas.

With the Self Service feature, person-hours have decreased. We still don't use it to its full potential, but it's helped on the development side for testing. It has definitely sped up the developers' testing processes, and it enables them to get things to production a lot quicker. They're happy with that. The Self Service has also reduced calls to our IT department when it comes to testing, for sure. As a result, my staff has a little more time to work on other things, rather than fielding calls left and right from the programmers. That helps a lot.

Now that we can get into the API and we're starting to learn that, it's really nice. 

We're also starting to use its Self Service and Solution Manager. My team in the data center and some of the development team use the Self Service. Developers are using the Self Service for upon-request jobs for their testing. They used to have to go through us to schedule testing and now they can just go on and kick it off all they want. They have also really appreciated that they have access to view and/or submit jobs.

Working with the various APIs has actually allowed us to keep the scheduler, because there were those in our company who were thinking about looking for something else, given that they were considering it to only be a mainframe scheduler. As new options and agents and connectors have come along, that's opened their eyes a little bit more.

It's been a while since we've asked for tweaks. Because we're a little bit of a slower company, they have something out by the time we start checking into, "Hey, can you give us an idea on how this works?" or "This is how we want to use it."

An example is the API. Of course they have a RESTful API within OpCon, but they have that new web services agent that we installed because we have some SOAP APIs and we had to interact with SMA to get things running. Our developers did do some tweaks, but we have now been able to get some test jobs running, and understand how the workflow goes back and forth. 

When they initially set up SQL agents, they helped us set up that too.

I have been using the OpCon for 16 to 18 years.

The stability has been very good.

We haven't had any issues with scalability. I've been to a few of their conferences where there are banks that are OpCon customers and they have thousands of jobs that they run, or even hundreds of thousands of jobs. We've got plenty of room to expand.

I'm hoping, with our moving off the mainframe, that we will have a chance to really branch out. Initially, the company just looked at it as the mainframe scheduler, so we weren't really able to ask for additional instances. Hopefully, as we go along, we may be able to grab some of the other options.

We're running on the order of thousands of jobs monthly. Our future usage depends on how well we can get everybody to jump on the bandwagon, but I see it staying at that amount, if not increasing, as we move towards the cloud and other options.

From our dealings with them, I think they've done an excellent job when we're in a crunch. They get more than one person on the phone and we haven't ever had any bad experiences with them. When new levels come out they've helped us. And the marketing guy, Christian, he checks in all the time.

Deployment would not take very long now, with the way they have the install set up.

We usually do a test server to start with, just to make sure everything went well before we do production. This last one took about an hour or two on the test side. We ran into something with updating the database. It was something on our side that the database administrators had locked down, so it wasn't working quite right between when we installed in test and installed in production; they had tightened the permissions down. Other than that, it takes us about an hour to get through what we need done.

My implementation strategy for deploying it for the first time would be to put it to test in our test database, and then grab a few jobs from each type of job we run and see how it works with the test database. I would then check with the developers that everything looks like it ran okay and then we would take a weekend and deploy it to production. Of course, we would do testing there as well. Since it's VM, we just have the VM guys ramp up a new server, so it's always a new install and, if it doesn't work, we can always fall back to the old version and the old server.

For deployment, we usually bring two of us in, and that's it. For maintenance of OpCon, we only have one or two people, as backup. We have operators per shift who actually run it, but for maintenance there are only a couple of people. One of them is me, in my role as a data center manager, and the second individual is part of my staff.

In terms of the number of users of OpCon, the numbers have dropped now that we're moving off of mainframe, but we'll be picking back up. Currently there are about 100 programmers that could possibly have access. We don't have that many yet in Self Service. And there are 12 on our staff that use it, including a couple of admins, a couple of implementation people, and the rest are operators.

When we first had it installed, there was a really great guy who came in, who doesn't work with them anymore. We had some training onsite while he was here. We weren't really involved at that point in time in installing it ourselves. It was always an OpCon representative showing up. Now, it's more the case that we install and get a hold of them if we have any issues.

We've always been on our own with this scheduler, so it's helped out our department and I feel it's helped out the programmers quite a bit. It has automated a lot of things, which should help our IT as a whole, because we haven't had to have the largest staff.

At the same time that I'm trying to keep it in our company, everybody thinks it's very expensive. We haven't looked at other schedulers or what they can do for us, but that's what I'm always told.

Aside from the standard licensing fee, there aren't any other costs that come with it. We have the enterprise option so it's one annual fee for whatever we can do with it. You have to have the enterprise level for the mainframe, and that gives us room to grow.

It's awesome to have the automation and to let it do things for you, but you need to stick with it and really figure out how to optimize it.

I'm still working on trying to explain to others in our organization that when it comes to server reboots and things like that, OpCon can do that for them too. They may not be interested in that as they have their own third-party software. I haven't gotten a lot of them to hop on the bandwagon yet. Our VMware guys are still stuck to their guns. We'll have to find out how much we do go into the cloud or on-prem to see if we can't help them out in those areas.

We don't use OpCon's Vision feature yet. Our company is very conservative, so it's a slow process. Unless you can get a lot of people onboard, it's hard to get things pushed through. I'm hoping others will see how well it interacts with the various types of systems and how it processes the jobs back and forth, through the various versions, and that they'll see a little more use for it. Another aspect is budget, because right now we're trying to move to the cloud and a lot of people are being trained at the moment and having to run legacy, side-by-side, versus new. So there's a money-crunch thing.

It's a good product. They can run almost anything you need to run, as far as I am aware. And the staff is really great to work with. It's a plus on all sides, in my opinion.

We are an in-house Fiserv Premier bank. This solution allows us to automate a lot of the core processing. 

This is outside a bit of the day-to-day. We recently did a branch acquisition of another bank, though not a full bank. With that, we had to convert all of their ACH transactions. It was a very complicated product that we received from our core provider, Fiserv, for some translation programs. It was very cumbersome to run through the process, convert it out, get output files, etc. Without anyone touching it, I was able to automate the full process from pulling in the files from this other bank, converting everything needed, and posting it to our customer's account 24-hours throughout the day.

We run the ACH process around the Fed window about four times a day: 2:00 am, 10:00 am, 2:00 pm, and 7:00 pm. We are not staffed all those hours. If someone were to actually run through all those steps, it would take maybe 15 minutes per each file.  This is if someone were to manually do it. So, that adds up. The main thing is we can let it run at two in the morning without staff.  It of course ran in less than 10 minutes, since it was automated. 

The product allows our full-time employees to be repurposed, not eliminated. We turn ourselves from operators who used do everything to reacting or being proactive. 

We have a night operator whose whole evening was just initiating, running everything, and watching it. My predecessor and I have been doing a staggered approach, taking these tasks out of the night operator's hands and putting them into OpCon. This still gives her the control where she can initiate via the Self Service portal. Now, we're hitting that phase where I can start to let it run on its own. She's become more reactive with the handful of things that she's still doing.

Our night operator loves it. Granted, she is one of those people who is always up for change and improving things. The way that she used to run things in the IBM mainframe was more isolated. She would see the output as a whole: That process A and process B were running, but she didn't actually know the details. With OpCon, she likes to have it up to watch it (not that you have to have someone watch it closely). She uses OpCon because it is easier for her to troubleshoot if something were to come up by seeing where things are at, what step it is on, and observing colors change.

The team members' reaction to the change has all been positive. Everyone has a different feel for it, but everyone sees the positive. I do my best to put a positive spin on it. It's not so much taking anything away from anyone. It's just converting it into OpCon, running it, then determining, "Is intervention needed? Can it run on its own?" 

Anything that is file movement related is awesome. Whether you are outsourced or an on-prem in-house bank (like us), you're not just fully in-house anymore. There are so many different third-parties that you work with now. With the amount of files going back and forth between end users or simply from the core to different vendors, this is the best part about the solution, streamlining and letting it run. Whether that's constantly throughout the day, certain times of the day or month, or a specific 16th day of the month, that's probably the most helpful because there is no operator that you have to wait on. We can just push it through a traditional FTP or SMTP.

It's very helpful, as we can move quite a few files all at the same time from a server level instead of having someone at their workstation downloading a 100 files. E.g., I created a process with our recent branch acquisition that we did early last year, where files were moving between the acquiring bank (us) and the selling bank. I put on our Self Service portal buttons for execution, that said, "As file's become available..." Then, my conversion team could have access without waiting on me to pull in stuff. If they knew that the selling bank put out some large conversion files, they can go out and simply hit a button. It would go out, grab it, and in a matter of minutes, be available to them on our public shared drive versus trying to pull that down via a secure site. 

The solution is what you want out of it. It's not something you can just quickly grab, try, run, and play with. You have to get the knowledge and train yourself. It was easy for me, but I also took the time to throw myself into it. There is a learning curve to a certain extent. You have to learn the rules. There are so many different ways that you can do things in it. If you were to survey five of my peers and me, I'm sure we all work on it differently. There is no one outcome of it. This is not to say that you can't pick it up out-of-the-box, but the way SMA trains you is on their standards of using it. You have to know the concepts of it, the different terms, and how you apply things. If you are using Windows, patch scripts, or mainframe things, it's not always an apples to apples thing. There's a bit of different translation into the product.

There is a current way to help hone in on detail that you are trying to visually show. For example, they have an add-in product (Vision) that we haven't purchased. The way the add-in product works is taking tagged data and categorizing it into a tiled report view.  It's actually live and constantly updating.  I like the visual / workflow side of OpCon, since I take the time to make it viewable from a visual standpoint.  Right now, I have a hard time if I want to translate what I'm doing to show folks who aren't users an overview. While I know SMA has an option for this, it's just more data. How can I show everything without my CIO needing to login to OpCcon and having me showing him the flowchart? A different way to report visually for other people to see processes would be my only improvement.

I would like to see more connectors to other various things. However, this has more to do with other vendors holding back with their applications.

Custom Templates for common jobs.  I do a lot of copying and pasting for jobs, that it would be easier if I could have my own templates.  Also Custom Documentation, that could flood to multiple job types vs. similar documentation on the same job being typed up.

A little over two years now.

The stability is good. The only time we've ever had an issue was simply due to internal system issues. For example, we recently had something where our SQL Server had connection issue.  All systems were down. I've never (knock on wood) had an issue with any of the agents or application itself. 

70 percent of our manual day-to-day processes have been automated by OpCon. 30 percent of the overall daily and nightly processing take more time to do. Taking individual processes that were standalone and putting them in was one thing, but then taking and tying them altogether is that 30 percent. Basically, if you're taking the human element out of it, you have to build it so you are comfortable with it and can rely on it. That is where the time comes into it. I'm very thorough. I go through it and make sure I can cover common outcomes. For example, "Is this going to make sense? What if this happened?" You build in all this stuff so the way you rely on it, you do not have to worry about it. Whereas, with that human element, they know what to do and where to jump around. Someone who is seasoned will know how to make decisions along the way, and you have to sort of program some of that in. This doesn't apply for everything, but in some cases, it does. 

To get it expanded out to that additional 30 percent, it will probably be done in the next year with everything that is going on. Though, I would love to have it done in the next couple of months, but when an acquisition comes in, that is the priority.

I like going out throughout the entire bank and finding behind the scenes processes that other people are doing which we could help with. If it's just file movements, taking data that they are manipulating, moving things around, or simply just triggering a process, that is the fun side of my job. To sit down, look at a process, take it, and if I can, free up a quarter of someone's day by automating it, that is fun. Working with other departments in the bank, getting to learn a bit about their areas is a fun learning opportunity. Their tasks don't have to be automated either, it can be streamlined by giving them Self Service buttons. It is about making the task more efficient for the user.

The more things that are new and introduced in our environment, they go right into OpCon. It's more understanding, "How do does OpCon help us do that?" and, "Is there a tie in for it?" 

The scalability is huge.

I am the primary who maintains it. There are also two other individuals who are in a similar role to me: my immediate supervisor and another colleague. They both have access. My supervisor just relies on me to train him as needed, then the other colleague is able to jump in and interpret a lot of my stuff. However, we're divided. He's in charge of this and I am in charge of that, but we do cross-train. Beyond that, there is a night operator. She is Tier 1 support. She can help react to job failures and work on smaller things. If it's above her, then she defers it to me.

There are three different departments who use the Self Service besides us. They don't use the automation side of it, though. They use the Self Service to run a process or generate something. This is mainly our accounting department. They are very tied into it, but they don't see the automation side of it. They just know that they need to push a button and things happens. Also, our item processing area and the conversion team use the Self Service.

You have to put the effort into the training and learning. SMA is big on free training. They do monthly training down at their headquarter office. As long as you own the product, the only thing you pay for is your employees' travel expenses. The training is free. They are willing to train people and give them the knowledge. That way, you are equipped to do what you need to do. Then, obviously, they're available for support and assistance from there, but it's only for what you need above and beyond on that.

The technical support is good. I don't use it that often because they're very good about training you. It's more if I have a question, or something small comes up, then I can open a case. Otherwise, I have what they call blocks of hours. E.g., if I'm scratching my head or trying to think through how do I want to develop something? Then, I tap into my block of hours with a dedicated specialist who is assigned for our bank. It all depends on what's going on. If it's something brand new or different that I'm doing, then I'll touch base with them and run it by them. Otherwise, the block of support hours is mainly for upgrades and stuff like that.

Before, we did use file transfer stuff, which was a bunch of "if" and "then" statements. We were executing with that. But, that was very limited to what the application could do. Whereas, OpCon is a whole different game changer of what you can do from an enterprise level.

As a bank, there used to be a lot of full-time employees who would just run checklists all day doing manual steps. Whereas, with this product, we can automate the full day to a certain extent. There is still some intervention or items that are more user driven. Instead of our operators running the day-to-day, they just initiate certain phases of it. Then, we rely heavily on the Self Service portal and building out that stuff for our operators to use. They very much enjoy that.

Prior to OpCon, the organization used a lot of scripting in its own server. A big selling point for OpCon was its automation on an enterprise level. Converting everything to OpCon moved everything to one place. 

The nice thing at Frandsen is management sees the need and results of all the automation. They took an investment with my predecessor buying the product and we continue to see great results.

I was not here for this bank's initial setup, but I was previously involved with the setup of OpCon at another bank.

I've worked at five different banks and each bank operates differently in the way they have things locked down or how things are completed for projects. The setup was pretty straightforward. You just get the database and application up and running, and then, the mainframe agent up and running, which is especially important for a bank,. 

The database and mainframe side of the setup are always sort of tricky no matter what application you're working with, but it was pretty straightforward. It was up and running, then we trained and helped start to set up things for how we wanted to move forward. So, I thought it was good.

The deployment took about a day, but the bank that I worked for was very locked down when, e.g., trying to get things to open up and the right resources from SQL DBA. But, the actual application on the mainframe side, that's a no-brainer and seamless.

It took a couple weeks to deploy our first process because you have to test and get comfortable with it. We only automated a couple core things at the time because the main focus of getting OpCon in the bank was that they wanted a very cumbersome process streamlined.

At my current organization, I know that deploying the first process took them a couple months because they wanted to a lot of testing before they implemented it.

My implementation strategy is going for the easy stuff first to get a feel for it. Then, I can quickly turn things around on a small scale. Afterwards, I will graduate to that larger scale. With each implementation that I did, I evolved myself and how I wanted to do it, what I learned, etc. Because the other bank versus this bank were on two different mainframes, I had to translate a bit and think through things differently. I like doing the smaller things first, but now that I'm two and a half years into it overall, I can chew off the big things right away too. I'm not afraid of them, and they're fun, exciting, and more thrilling than the easier stuff.

We deployed it ourselves.

To deploy OpCon, you just need someone who is fluent on SQL DBA. SMA tells you there are two different approaches: If you want a whole group of people to help or if you want a train the trainer approach. 

When you take the human element out of it, someone is not interrupted nor are they delayed. They are not hung up on another thing that they are already working on. That's the nice thing about OpCon. We have the time to react to things and are not holding things up. So, if you add up those 10 minutes 15 times a day for our processes, that's quite a bit, especially for the repetitive stuff. It's easy to automate it, then it just does what you need it to do. It just runs. 

This has overall reduced our data processing times in our environment by approximately 50 percent. The nice thing is we can spread work out. If you need to have employees onsite for the ACH processing, someone has to come in early, then probably stay a bit late on that end of the shift. Now, we're spreading it out. With the ACH, if you're doing it with just an employee, then you're only doing it during working hours. Now, we can run things over a 24-hour span, spreading it out. 

There are different add-ons, like the Self Service or Vision model. It all depends on what agents you have in your environment. We have a mainframe and Windows, and while I think SQL is free, SAP or anything beyond that has different connectors that might need a license.

At my previous company, we did not look at other solutions because we knew SMA was the most well-known within our industry. 

At my current bank, they did look at HelpSystems. It was between HelpSystems or SMA OpCon. Ultimately, they went with OpCon.

Take your time. Think about it. Once you start to create different concepts and learn them, come up with naming conventions, your own rules, and go by them. This way, everything is similar. It's easier for me to train my operators if it all looks the same.

Ease of use depends on how you set it up. It is there, but it all depends on what you want to do with it and how much time you want to put into it. If you just want to move some files around and keep things looking the same, it is easy to use. But, if you want to do some tricky stuff, you have to put some time into it, making it look clean and understandable for you and everyone else. You also have to document a bit, but that is sort of case by case.

I come up with rules, trends, conventions, prefixes, etc. that I'll find sometimes six months later. Then, I'm like, "Ah, I like this a lot better. I'm going to set this as my own standard going forward." I am evolving myself and constantly making it easier for me to use.

The solution expands my creativity when looking at processes.

I would rate the solution a nine (out of 10). It is in its own league. OpCon makes my job so much easier. SMA is a great company and partner.

Primarily, it is used for automation of our daily processing with our core system, Symitar. There are the jobs that we run every day. We also have weekly and monthly jobs setup. These jobs have to do with different departments or reports run on specific days of the week or month. 

We process all of our ACHs and shared draft or check processing in OpCon. Also, VISA credit card processing is all done through OpCon.

We are running anywhere between 400 to 500 jobs a day, on average.

The biggest benefit, as a department, is it has allowed us to move away our focus from manually processing all daily processes with our ACH and shared drafts, reports, etc. It's allowed us the opportunity to work on different projects and upgrades within our organization. It's given us time back from needing to have someone onsite manually processing everything from 6:00 am until 10:00 pm at night.

We are about 92 percent automated right now.

It has streamlined operations, specifically with the timing of our processes. We don't have to worry about if things are going to run at a certain time. The automation allows us to say, "Okay, we want this to run at this time, and this to not run until that is done." So, it has really streamlined the accuracy and timeline of when jobs run throughout the day.

Employees have been very positive, as far as the changes in their tasks are concerned. For example, our payment services and accounting department use Self Service. This has helped them from their old manual process of taking anywhere from 10 to 15 minutes for a job started to a simple click, then the job is done. So, they have been very excited to not have to go through such a rigorous process just to run one step.

The most valuable process that we use is just the basic automation with the use of Enterprise Manager, which is their user interface. We also use a bit of their Self Service product, but not as much as we want to. Our primary feature is just the Enterprise Manager, which is essentially their basic version. This feature allows us to create, modify, and test different automation processes. It also allows us to be notified in the case of jobs failing to finish, or if for some reason the job doesn't finish in time. It can tell us that information as well, but it gives us a good overall view of OpCon processes and where we are at for the day.

I would definitely rank basic ease of use as very high. It is very user-friendly. There are some processes and functions which are a little more advanced. Overall, it's something that is very user-friendly, as they have designed it to be that way.

I don't think there's a change that needs to be made other than little minor bug fixes here and there.

There are limitations to this product and certain things that it just can't do. It does not have the ability to interact with third-parties via the web/Internet. We have certain processes where we have to interact with a third-party on a website, and unfortunately OpCon just cannot do that.

We have been using OpCon for 11 years.

The stability is amazing. Because everything is on-prem, we control the network environment from OpCon to other servers within our networking environment. As far as the product goes, there has only been one time in the 11 years that we've been using it when the product has gone down. It was due to our networking going down, so it wasn't even the product. It was an internal issue.

Deployment and maintenance really only needs one person. OpCon is that user-friendly. With the right support, one person should be able to build, maintain, and administrate it. This is actually my primary role.

Our department isn't very big. As far as people that this would specifically affect, we only have about four employees. As far as overall in the organization, it has really helped out a lot with our accounting, payment services, and card services departments. Including those departments, we are looking at 45 to 50 employees that OpCon has affected as far as automating their processes.

Its users are primarily in our IT department. We have five in our IT department, but then we also have our payment service and accounting departments who use the Self Service feature. We have about 25 actual users that have hands-on contact with OpCon. Most of those are with the Self Service. Internally, with IT and the Enterprise Manager solution, there are only about five of us who really touch that part of the product.

We are not one of their bigger clients, but OpCon definitely has the opportunity to grow. We have increased substantially from when we first started. We were only running about 200 jobs a month, and now, we are running anywhere from 400 to 500 jobs a day. The allotment for growth is there. We have just gone to enterprise licensing, which allows us to install the agent anywhere on different servers. We are just getting ready to install it on another four or five machines. The scalability is definitely there. With our program or agreements, we have that ability to grow exponentially.

They are absolutely fantastic. Since I've been the primary administrator, I've worked with OpCon support multiple times. Every single time I've worked them, I've not had a bad experience. They've been able to resolve any type of situation that I may have or help with any technical assistance needs. They have been very consistent. Even with changes of support reps there, it's still been very consistent as far as the quality of support that I've received.

OpCon was our first workload automation tool.

The initial setup was quite complex. Because we have been on it for quite some time, the process to initially establish and build OpCon was substantially different than it is now. Now, if we were a new customer going onto OpCon, the process would be much simpler.

We weren't familiar a lot with the solution at the time of the initial setup. Also, it was more of a scripted program when we initially installed it. Whereas, now, even though the scripting is still there, the process of installing and upgrading is much simpler even for an initial install. A few years back, we upgraded from our really old version to a newer version. The upgrade only took a couple of hours. The initial install was two weeks of hands-on writing jobs, scripting jobs, and doing all of that. Now that they've built job functions into the program, a lot of that scripting isn't required. It's already built in.

Our first processes were automated during the initial install, but we were extremely limited at that point. We only automated maybe five percent of our daily processes. As far as regular implementation and automation of those processes, we really started getting into that and getting stuff active from a testing environment within a month or two. After a couple of months, I was familiar enough with the product to where I could start just going in and building automation. To get comfortable with the product, it took about two months.

As far as implementation strategy overall, after the initial install, we really tried to focus on the standard daily processing, such as ACHs and share drafts/checks. From there, we expanded into daily reports running for different departments. Now, we are even to the point where all of our credit card processes are automated. This is an ongoing strategy in which we try to automate as much as possible to alleviate the need for manual processing. The manual processing of files, or even file transfers, is a really big thing that we've been doing a lot recently, e.g., uploading and downloading files from third-party vendors.

Their consultant came onsite and performed the install. We did an initial training on it as well.

We have absolutely seen ROI. It has allowed more time for our staff to work on projects which affect the organization on a greater level than just daily processing. This has allowed us to expand our base. It has really helped out with that.

As far as data processing in the manual entry, we are saving overall two hours a day. This would be instead of manually going eight hours. Therefore, it has saved about 25 percent of data processing time.

Annually, we pay $29,000. This is for a blanket policy that covers everything, like licensing and support. 

If we choose to purchase consulting hours, that is an additional cost. However, we've been lucky enough that we've not used all of our allotted consulting hours. Therefore, that is not something that we have had to purchase a lot of. The last time that we purchased consulting hours was roughly two years ago. We purchased a block of 10 for $2,500. It was $250 per hour.

It's definitely worth the cost. It will help with your time management. It helps take the human error out of some of the day-to-day or mundane things, such as processes that have to be done manually. It gives you peace of mind to know that something that you scheduled will run, and if for any reason it doesn't, you have the support to help get you back on track and troubleshoot any issues.

There is not a whole lot that needs to be changed with the program. I think it's a fantastic program. I wish that we, as an organization, were utilizing it more to its full functionality. Otherwise, their functionality and processing are fantastic. Overall, it's a great product and doesn't need to change.

The biggest lesson that I've learned from using it is to not underestimate it. They have recently changed their slogan to, "Yes, that's possible." That's one of the things that I've really learned and have accepted with this program. There have been multiple times where I was quite resistant to what it could do. It opened my eyes to how powerful it is and what it really can do.

I would rate OpCon as a nine (out of 10). Nothing is perfect, but it's as close to it as you can get.

Our primary use case is file movement.

It cuts down on phone calls from other departments because they can monitor their own work, once we set up their projects.

I've got eight individuals who work for me and, before we had OpCon, I lost about two of them a day to processing our Check 21 files. That whole process is now completely automated. Instead of performing the work, they're just monitoring it through OpCon. I've gained back two full-time employees to use in other areas. Instead of being "button-pushers," they now monitor the processes. Five of my team members, and me, have been through the OpCon training, and they're getting more and more involved every day. They're slowly rolling out some new jobs and learning how to tweak and manage it.

With ACH, I get about a half an FTE back. I haven't had to add anybody to my department, whereas without OpCon, I would have had to add one or two bodies.

In two weeks, OpCon has done 15,677 jobs that an operator would normally have had to do. It has significantly streamlined operations, and it does things right, every time.

All of its features are valuable. We use the heck out of it. I just went to a conference and there were only three of us who had our hands raised every time they asked about a different level of OpCon and how we have it deployed.

One of the things we like about it is that you can open it up to other departments so that they can see their own tasks running. We were one of three at that conference that said they had it deployed to other departments.

At first, it's a little clunky, but once you learn it, it actually is very simple. You have to get over that initial learning hump.

In addition, right now I've got two servers that are using 2008 and that's holding me up from getting to version 19.0 of OpCon. There are key products that I just can't ignore. I can't just upgrade. I wish SMA could go back a little bit further or give a little bit more support for older software, like 2008. I understand their point: The 2008 software is out of date, technically. But trying to get a vendor to update its application to work with something newer is out of our hands. I wish I didn't need to lock up my whole OpCon because of this process that probably does 600 jobs every two weeks. It's a big process that came in about three years ago and, when it came in, OpCon was key in getting it deployed into our bank. But the latest operating system it works with is 2008. I'm at the point now where I want OpCon 19.0, but I'm held to my current version because of that one application. It would be nice if they had a way that you could upgrade and still work with an older version a little bit longer.

We've been using this solution for four-and-a-half years.

The stability of this solution is awesome. It's the only product I've ever seen that you can actually build to fix itself if it has a problem. You'll build something and, if you find an issue, you can say, "Hey, if this happens again, do this to correct it."

Scaling is pricey. We've got 20-something servers and six AS/400s tied to it. If I want to add another five servers, it would be pricey. 

We currently have about 40 users. All they're doing is monitoring. Only five operators and I are actually making the changes, adding new procedures, etc.

In terms of increasing usage of OpCon, at the moment we're okay. It just depends on new products that the bank says it wants to buy. Currently, we have enough work for the next five years to get OpCon built and up and running 100 percent.

Technical support is awesome every time I call. Now, when I call I'm asking more, "Hey, can I do this?" and they'll say, "Yeah, try this or this." It's really simple and I hang up the phone and away I go. At first, I was on the phone with them for quite a bit, but now I might make a phone call once a month.

We used to use Robot, but that was strictly AS/400. It had a lot of limitations. OpCon is way easier to use than Robot was, and OpCon goes across multiple platforms, which makes it an even better solution.

At the time, I was number two in terms of setting it up. My manager was the key person in rolling it out. I was working to keep the lights on and to keep the business going while he was learning about OpCon and doing the setup. He got let go and it became my responsibility.

My manager worked on it for about one-and-a-half years before he was let go, and at that time we probably had 1,000 jobs running, in total, every two weeks. And out of that, we really didn't have a high success rate. He didn't share some of the key utilities with us so that we could work on it. When he got let go we got the entire, "Here's the product. Do it." We were able to figure out the problems. He had set stuff up initially but he had more test stuff in there than he had production stuff. Once I figured out what he was doing, it didn't take me a week or 10 days to start making changes.

He didn't have it working perfectly, and it took me about two months to correct some of the issues that he had and actually make it worthwhile. Now, I've got myself and five others trained, and it's really doing a lot for us.

We're up around 94 or 95 percent success on jobs that run.

We've done a couple of upgrades, and their upgrades are getting simpler. The more stuff that comes out, the easier it does get.

Given that it's running, eventually I'll have to have one person for each shift just to monitor it. When we do deploy some of the new SLAs and some of the new features that are in 19.0, we will be able to even better manage it. Eventually, someday, we'll be a lights-out organization.

We used OpCon consulting a little bit. We paid OpCon to come in to help us with our ACH. When you're moving millions of dollars, you want it to work right the first time. So we had someone come in from OpCon and he was with us for a week. We got ACH to process about 95 percent through it. We still have a little tweaking to do here and there, but it's doing files every day now.

We're licensed by the number of servers we have, and as long as we don't increase that, we just pay the maintenance on it. They've got a new pricing model out where you pay for the jobs. But looking at that, we'd pay a lot more than what we're paying today, so we'll just keep adding servers.

The TCO, compared to Robot, is a little bit more expensive, but it goes across many platforms, so we get more bang for our buck.

If anybody were to ask me if they should buy this product, the number one thing I would ask them is, "Do you know operating systems? Do you know DOS?" If you know file structures, etc., this product will be easy. I started back with the old 8088 PCs. You had to do everything you could just to be able to use the computer. This is a great tool to use if you've got that knowledge.

If you are bringing OpCon in, make sure you have somebody who can spend the time on it to get it implemented. Our company brought it in and said, "Here is a tool you can use." They didn't assign any one person to implement it. If that was my only job, I could stay very busy. Part of my problem getting it rolled out is that I'm an operations manager. I'm running a department that is 24/7 and, for the most part, projects that come into the bank are about 90 percent of what I get to do on OpCon.

We still have a long way to go in terms of the number of processes to be automated. We have automated about 10 percent of our jobs, but we have some other factors that are holding us back at the moment. Our core software has just done a big upgrade, which is affecting the way that we use it. OpCon can work with it, but the screens have all changed. The security is being upgraded in our core product and there are going to be new menu options. This is Jack Henry's biggest security change in 20 years. It's called global security. It's supposed to be fully deployed by March of next year. We're still in the process of waiting for that before we can start building day-to-day processes into it, through our core application.

We probably do between 170,000 and 200,000 jobs a year. Some of those jobs take two minutes and some of those jobs take eight hours. We haven't quite got all our time back yet, but we have been working on key applications, trying to free people up to do other things.

Overall, I'd give OpCon 11 out of 10 if you'd let me.

We use it predominantly, and almost exclusively, for core processing with our financial system.

OpCon makes it so we are lights-out for most of our morning and evening processes. 

It makes it super easy to notify us when something is wrong. It allows us to incorporate a wide range of custom processes or notifications. It's pretty agnostic in terms of how it does things. It doesn't matter how you've been doing things. As long as it can be called and given a command line parameter or interface parameter of some sort, it works really well. The biggest attractor is it allows us to incorporate so many different processes that wouldn't normally work together, making it a seamless schedule of events that happens and is really easy to both manage, update, change, and review. It's just a really slick piece of software that makes things super easy.

From the sixth through the 17th, that is where we have some sort of processes that have been out for the day. We have 324 schedules, 177 subschedules, and 2,996 jobs defined. Everyday, we have about 30 different processes defined. On special days, like end of month, first of the month, etc., we have a lot of stuff to find in there, which means there's no person doing it. It's all done by the system, taking that workload off of having a person. We are able to make sure that we have people concentrate on the things that really require a person and not the remedial tasks. This has been a huge advantage to having the software.

Our manual processing has been automated in the realm of 70 percent by this solution. There are only a few things that we still do which require a human touch.

The solution has streamlined operations. We have written custom jobs to do particular things, but OpCon is definitely the one that manages running them at particular times. Often times, those jobs have to run after hours. So while we still develop and spend time and man-hours writing code, once it's done, OpCon is running that in the afternoons or evenings. This is usually done during off hours when a person would normally be required to be here and do it. Instead, OpCon is available, consistent, reliable and easy to get things in and working quickly once we develop and get them working. OpCon takes care of the entire process, including notifications that we define if something were to happen so we know what to do next. Again, it's simplifies the entire process.

The solution freed up employees to do more meaningful work as a result of automation. However, tasks like managing user credentials, permissions, or access takes a human eye to determine what to do next unless it's something very straightforward. I can't really have OpCon go through and determine that user X needs to be moved to group Y unless it's a scripted piece. That still takes a human eyes and is done by people. OpCon has taken away things that happen repetitively every day, regardless of what's going on. It has definitely allowed us to separate those two process.

We have three employees (four including myself) who have been doing these processes in some capacity in the system. The workload that I would normally be doing, I push a lot of those jobs over into this and define a lot of them. Probably anywhere from 20 to 30 percent of what I do, I've been able to offload in OpCon. For the other staff, the evening and morning procedures are the biggest in terms of freeing up time because these are the things that we do before we open and after we close. Of those processes, nearly 90 percent of what we would normally have done with a person have been moved over.

Our employees are happier doing things that require them to think. When you're doing the same task over and over again, it's pretty remedial. It is nice to have a system take care of that for you. People tend to want to be able to think about what they are doing and have some brain processing going on instead of doing simple data entry. Overall, I expect that they're happier about the piece that they're working on versus doing the things that OpCon never complains about, which is the same thing every day.

• Scheduling
• Job concurrency
• Failover
• Failed job notifications 

The schedule processing is our biggest reason for using it.

As you're doing a scheduler, oftentimes you end up doing some of the same things over and over again as you define jobs. There are generally some well-used use tools available that the system can interact with. My suggestion is try to find ways to have built-in interactions with those pieces of software. As an IT person, and I say this with caution because I know what it means to code something to a piece of software you have no control over, I would like to have an interface with PowerShell.

PowerShell has a lot of functionality. We use it a lot because we're a Windows shop. Having a built-in tool or interface with PowerShell would go a long way. At the same time, it's not like I can't do it externally. This is probably more like a suggestion than it is a complaint. 

The solution was purchased before I got to the company, which was in April 2012,

The stability is near perfect. I won't say it is perfect, but I've never had a database error (knock on wood), corruption, or system loss that wasn't due to something else, like a power failure. The software has always operated. It always returns appropriate messages. It's very reliable.

The director of IT and a data center analyst are the ones who manage it overall. We write the jobs. We do the initial QA, essentially maintaining the system directly.

I know that we use only a portion of what is available. While we do a lot in it, we don't actually do any multinet code. We're very limited on most of our processing, which is sequential, since we are a financial institution. Almost all of our schedules are: job one, job two, then job three. This is versus doing a lot of submitting of maybe hundreds or thousands of jobs at one time every few minutes. We're really linear, so we're not even using the full capacity of the scheduler, which allows for things where you do several different nodes producing different jobs at different intervals which all interact or don't interact. We don't do that. We're pretty straightforward.

We have four people who directly use it. We then have a group of about six individuals who use the extended version. This is an interface that goes through a web browser that then pulls jobs and runs them.

The direct users are called computer operators. They are the ones who run jobs on the core financial system, which is what this is primarily doing. They will interact with failed jobs. They will, in some cases, manually start jobs and review processing to ensure things are working as expected. There are two subsets of those individuals that actually create new jobs and make changes. The additional six people that I mentioned are just users. They will go in and specifically call a select number of jobs to start processing in any particular process.

We have small plans to increase usage. It comes down to whether or not it can be fully automated and does it benefit the institution as well as us to automate it. In some cases, it's a very small task where you're maybe modifying a file and sending it somewhere. That may or may not be easy to automate. In which case, I am less inclined to put it in because it takes too much time to build up. Other times, it's a process that gets filed from a vendor or posted to the core, then sends out an automated report. Those are the things that I like to put in it because I don't want to touch it at all. Therefore, it really depends on the complexity of the process, then the value of automating it. 

Overall, we are primarily focused on things that relate to our financial activity. There are 10 to 15 percent of the jobs that we have defined that don't do something directly related to the financial system. That probably will increase over time, but not nearly as much as what we do for the financial system.

The technical support is very high in terms of quality and response. I have open up maybe four or five tickets over the course of a year. The type of tickets that I open are either clarification on a new feature or a request for support on doing an upgrade, and that's just to make sure I have someone to fall back on since we have never had an issue. The last ticket I open typically every year is a status update on our new license after renewing. So, it's pretty limited on what we ask for. Again, we're sort of a specialty organization. Being a credit union, an automation of jobs is generally focused around the financial system with most of our jobs being linear. This kind of limits the complications that we've run into. For us, the support has been a great resource that we rarely call.

On a scale of one to 10, where 10 is simple, super easy, and effective, that's what I would give it. At my prior work, we had another scheduler, and it was okay. It did its thing, but OpCon is, by far, super awesome.

The solution I used previously was called ISE, and it was related to another core provider and the solution that they provided. This was probably at least 10 years ago. I switched because I came to this institution who was using SMA before I got here. So, I adopted it simply because it was the resource that we had. I don't regret it one bit.

I'm kind of jaded now because I've been using this solution for so long. My previous solution was obviously an older version, so I'm comparing against something from way back when it was more convoluted. It was harder to get the results that I wanted from the interactions with different jobs. Having used OpCon for the last eight years, I'm familiar with how all the different pieces of how I set something up. It's super easy to set things up. At this time, I don't know that I have a good comparison against another software.

The initial setup was pretty straightforward. It's a nice piece of software that gets installed. There's a database configuration with a the support crew. 

We scheduled the deployment for a day, and it took just a few hours.

It didn't take so long to put it together. It was pretty simplistic. It took maybe 30 minutes to an hour to get something in there and test it out to the point where we were happy with how it was operating, then using it going forward and making any changes. Initially, it probably took 30 to 60 minutes to get something in there (the first time). That's mostly going through testing as well as developing. It isn't just putting it in there. Putting it in there, you could probably get a reasonable schedule defined in less than 10 minutes. But, if you're talking about running it, fixing errors, etc. related to scripts, not necessarily related OpCon, it takes probably about 30 to 60 minutes. Nowadays, setting something up, it takes me less than 10 minutes to define a simple or basic process.

The deployment was all internal; it was the staff here. We educated ourselves. We didn't even go through any formal training. We had a few remedial schedules that had been built before I started with the help of SMA just to define a few processes. From there, we used those as an example for QA, testing, etc. to find out what worked best for us. We developed those through actual use and best practices internally.

The way it was initially set up, support crew got in and validated the installation that the database was correctly set up and the interaction between the software and database was good. It was pretty straightforward and smooth. We did an upgrade. We paid for SMA to do a review of our system, as well, to ensure the upgrade was good, and there were no issues with that. It was a pretty clean install, and it worked out really well.

Our implementation strategy was mostly to define the processes that required no interaction from a person to begin with and create those jobs and schedules in OpCon, then test them out. From there, we would move onto more complex processes that may have required file drops or something like that. So, there was a trigger. Initially though, it was just to find the jobs that could be done right now that required no interaction and have those all implemented, tested, and working, then move into a more complex mode. Over the course of three to four months, we moved from having basic jobs to adding in a bit more complexity, then flushing out the defined larger shifts, like morning and evening.

It has reduced data processing time for some processes in the upwards of 50 percent. This is because the amount of time it takes someone to go in and type something or copy/move something over has exponentially increased. It's faster when the system is doing it because you don't have to wait for user input, so it's not necessarily that the overall process has gotten faster because searching for things or making documents still takes time. It's just the system, when it's through an automated scheduler, can go a lot faster because it can do all these things faster, not necessarily because the process itself has improved. There is definitely time savings.

If we're talking about posting a particular file, then that will definitely be done in the system a lot faster because there is no user input. As soon as the next is available, it is off to the next process. Whereas, if your user were doing it, there's evaluation, checking to make sure it worked right, and looking at some of the output. All this can be evaluated by the system very quickly, so it definitely has increased the time. I can think of one example where a morning process, back when we did a lot of it by hand, probably took anywhere from 30 to 40 minutes. Now, we're talking about 10 minutes flat.

The cost of ownership for what we have now means that I don't have to have another full body. What I pay for this software is at least one-third of what I would pay for a full body. That's a direct cost savings.

Before the solution was fully flushed out, we had someone here until well after closing and at the end of every month when we have special processing. So, there is someone always processing at the end of the month. It was a drag on both staff and personnel because anyone who did processing during end of the month or during those off times would not be here during the week at certain times or come in later. Therefore, the scheduling was sort of off. The morning process is still one where we have some additional things required of them, but the evening is totally lights out. Once we close business for the day, it's about an hour, then the staff member goes home and nobody is here. The system takes care of the rest. We've definitely seen that return, as we don't have to have that dedicated person in the evening.

It is a pricey solution. Comparatively speaking, you can certainly find schedulers which are cheaper. In some cases, you can find ones that are free or use free solutions. However, OpCon is by far the superior quality product, and you pay for that. This also has a cost savings associated with an FTE, so you can more than outweigh the cost of the solution if you were to reduce the staff that you have onsite. Plus, this means that you don't need to have someone during irregular hours.

One of the things that I run into is when you have staff that work irregular hours, this means you don't have that same staff (or that same availability) during the time when people are here. When people call on the phone, they don't want to talk to a system. They want to talk to a person. I would much rather pay to have a person here than have a person here during off-hours when there is nobody calling. The cost savings, removing the FTE, and having the system process everything automatically, as well as give me notifications in the same way that it does it everyday and I can always expect it at the same time, that is phenomenal.

I came in after it was already purchased and in place. If I remember correctly, the CIO did the evaluation. This product was making the rounds. It was heralded by other institutions and had a good reputation.

The cost is just shy of $20,000. That's for two licenses annually, production, and failover.

Spend time flushing out the processes that you want. Add everything you possibly can so you don't have to do it.

Look hard at the solution that you want. I highly suggest looking at OpCon. Frankly, that's all I ever tell people about when they talk about the scheduling. I ask if they're on OpCon and if they know about it. 

Overall, I don't really have any complaints. The system does exactly what I want it to do. In this current iteration. If it never changed, it still does what I need it to do, and it does it the way I want it to happen. I'm content with the way it operates. 

I would rate it a 10 (out of 10). It doesn't have to have another version increase. It doesn't have to add any change to complete what I need it to do right now. If it stayed exactly the same, I would still be happy.

We chose OpCon to replace a scheduling package that was controlling approximately 10,000 batch jobs every day. So the main purpose of OpCon, for us, is to replace an aging homegrown solution with a more advanced scheduling product that has more bells and whistles. We use it for job control. We have Enterprise Manager on desktops communicating to agents that are on our mainframe computer.

We haven't yet completed the conversion. We are about 30 percent converted right now. We still running 70 percent of the work through our old scheduling package. We have two main shops. One of them is an upstate shop and one is a downstate shop. I run the downstate shop. We have about 10,000 jobs, of which 5,000 to 6,000 are in that downstate system. We have deployed about 2,000 jobs out of a total of 6,000 jobs, downstate.

The part that jumps out is the notification process. The agent can now notify us, by email or text messages, when any jobs have failed or when any groups of jobs have finished successfully. Previously, it was a manual process where somebody would say, "We finished the work now," or, "A job has failed," and then they would have to start sending out emails or calling people to notify them when we received certain errors or reached certain stages in the work. That part has been automated.

We anticipate, in the future, that it will save us time mainly because, with the old scheduling package, we would have to manually identify and calculate dates for the next 12-month period. We would have to do that every single year. That's a very lengthy and accident-prone area and, by automating, we expect to see a reduction in effort from the staff.

There are three features which are valuable: 

• automated calendar functions
• the notification process for failed jobs or unscheduled events occurring, via email and text messaging
• the ability for the scheduling package to communicate across multiple platforms. 

We have three mainframe computers and our previous scheduling package wouldn't communicate across the mainframes. OpCon gives us that ability to schedule jobs on mainframe A and a job on mainframe B and the latter can be dependent upon a job on A. 

Those are the key components that we've found to be beneficial.

There's a large learning curve which, for some of our less technical staff, has been an issue. It's still new to us. Every week we're finding new ways of doing things with the product. What we miss the most is having an in-house expert whom we can call upon every single day. Literally, every single day, I or my staff have to go to the documentation and work out how a certain function works or why it reacted in a certain way. And that can take a lot of time and effort. But what has been beneficial is having SMA's 800 number which we call if we can't work it out ourselves. But many times we try to work it out ourselves rather than calling them up five to ten times a day.

We're converting 200 jobs at a time or 500 jobs at a time. We'll find out, once they're in place: "Oh, wow. There's a better way that we could have done that." And then we have to go back a little bit and figure out if we should have done it this way or scheduled it that way. It's a very powerful tool and we're not always choosing the right choice the first time through, when scheduling our work. That's why we miss having somebody onsite to say: "No, you really shouldn't have done it this way." We're actually finding out sometimes the hard way.

The calendar interface and the frequency interface is a very powerful, yet complex, section of OpCon in which all our staff have made mistakes. They have implemented what they believed was logically correct and then afterward discovered that their logic was flawed because OpCon did it a different way. That part, which is incredibly useful, is also incredibly dangerous. The interface or the ability to directly do more functions within the frequency definitely has room for expansion. As good as it is, it can be a lot better.

It was first installed in 2018 and we started using it for production work at the beginning of 2019, so we've been going for 10 or 11 months.

The stability has been very good.

The downside is that when something does go wrong, most times it's a networking issue, which tends to get lost in the mix. OpCon will say, "Unable to communicate," and now we have to try and track which part of it has failed. Is it the agent that has failed? Is it the Enterprise Manager that has failed? Is it the network backbone that has failed? Or is it the SQL Server that has failed? A way in which OpCon could be improved is to better analyze things when a failure is occurring to point us in a better direction without our having to check all the different paths.

I love the idea that we can scale it, but what I don't like is that every time I consider wanting to scale it to something else, it costs a lot of money and then I have to jump through hoops with all of my hierarchy in order to get it. So it's good and it's bad. I actually haven't seen any scalability yet because nobody has approved the enormous amounts of money that are needed to put another agent in another area.

We have about 24 active users and their main function with OpCon is purely to monitor and schedule the work on the different platforms. What I would like to see happen in the future, and I know this does exist, is to expand the user group to the client base or to the development group so that they can then see the results of their work in a read-only manner. Because we're concentrating our efforts on deployment, I haven't yet gotten around to getting that part implemented.

Ideally, I'd like to see three people on it on every shift to monitor this amount of work. Their role would be to monitor the workflow, to implement new applications into OpCon, and to ensure the frequencies and calendars are working as expected. As good as OpCon is, we still need to verify that it's interpretation of when we've told it to run the jobs actually matches up with what we really expect it to do. We just don't trust it completely yet.

Technical support has been excellent. We had two people from SMA who were part of the project to do the conversion. Now that they're no longer available to us we miss them tremendously. But we also understand that they had to move on to other projects.

What has been beneficial, and I have no complaints about, is that every time we do encounter a hurdle of any kind, when we call the 800 number, whatever technician we speak to at the other end is extremely knowledgeable and walks us through it. But the hard part many times is that they don't necessarily know how we are set up so there's always that 10 or 15 minutes as we explain, in our terms, how we're doing business so that they can understand what it is that we could have done better or what we're doing wrong. Having an in-house expert would be extremely beneficial but that's too costly.

Having a dedicated tech from OpCon, about three months ago, would have been extremely beneficial. We used up an awful lot of the time and resources of the dedicated people who were assigned to this project when we weren't even fully aware of the questions that we were going to ask because we hadn't implemented anything yet. We had them available to us during a stage when we were still putting all of the jobs into the test system and not into the live system. That's just the way it worked out. And again, when you're trying to convert so many jobs that are mission-critical, it's very difficult to take the risk of it not working correctly, so we're being very cautious about how we implement all of our work.

The initial setup was complex. We had a training course that was given to us back in August but almost everybody who attended the course didn't actually get to use the product, hands-on, for about six months after the course. Nobody could really fully comprehend OpCon when we were first given the course. It was a very different product to what we were used to using. As a consequence, it was like a brand-new language and many of our staff couldn't wrap their heads around. It's not until you actually use it that you start to understand how this thing works.

Our deployment is still going on. I would say it's been a 12-month deployment with about another three months to go before we complete it. We're anticipating having it fully deployed by February of 2020.

The first part of the implementation was that we took a flatfile database dump of our current scheduling product and that was provided to SMA support, to Kevin Adams and Ben Adams. They loaded that into the OpCon database. Then we would project future schedules within OpCon and compare them to future schedules in our in-house scheduling package to see if the conversion had gone as expected. Once we found all of the different nuances, the different parts that had been interpreted incorrectly — meaning either their schedule dependencies or frequencies, probably because we exposed to them wrong — the next phase was to do parallel running.

We continued to run all of our work in our existing scheduling package and each day we would run the same schedules in OpCon but convert all of the jobs in OpCon to null jobs so that they performed no functions. They wouldn't start anything. They would just run and hopefully run in the same sequence as our live system.

The third phase was to actually start the conversion. We identified the least mission-critical jobs, the low-hanging fruit which were the least damaging jobs, and converted those. We turned them off in our in-house scheduling package and turned them on within OpCon. Once that proved to be successful, we then broke down jobs into groups to be converted, initially starting out with groups of about 100 to 200 at a time.

We've now reached the final phase, which is the remaining 3,000 or so jobs. It's a very complex schedule. We were going to implement it in stages and we're finding that it's very difficult to implement jobs that are running it OpCon while still running our old scheduling package when we have dependencies between them. So the final phase is proving to be a little bit more daunting but we're getting there.

After deployment of OpCon, it took about two-and-a-half to three months to automate our first process, between when it was communicating with the agents on the mainframe and when we actually started to run jobs.

It's too early to tell about ROI.

We evaluated Control-M from BMC. Both OpCon and Control-M were going to provide us with the solution that we were looking for. The decisions were then out of my hands because it was then left up to the money people. The final selling point was that there was another state organization that was already using SMA. I believe the Civil Service Department is using SMA. That was the final factor: If we were going to purchase something, let's try and keep them looking the same.

I would highly recommend an onsite evaluation of OpCon that has already been deployed and seeing it fully in action, so that you could be better prepared to ask the right questions prior to getting it. All we saw was a remote demo and that, to me, was a big mistake on my people's part and probably SMA's part. We never got to see it in action so we didn't know all the right questions to ask.

My biggest lesson in using OpCon is that I wish I'd been more involved at the beginning of the project, when they were estimating the need for support. We should have budgeted for a different type of support during the early days.

The second big mistake was that there is a latest and greatest version of OpCon, which I believe is called OpCon Deploy, and we didn't budget for it or know of its existence until after we were doing our deployment. That would have made such a huge difference, because everything that we were doing in our deployment was manual: We had to extract the information from our scheduling package provide it to SMA support. They would manipulate the data, put it into our test system, and then, to roll it across from our test system to our live system, they would have to export the database or export the schedules and import them into production OpCon. Whereas Deploy is fully automated. That would have made a huge difference. We didn't pay for it because we weren't told about it and as a consequence, this is what we got. 

We still wish we could get it but now we can't get it because we have to wait for the budget people to approve it. And to get the budget people to approve it, we have to give them the same explanations as when we were going from our old scheduling package to the new scheduling package and they're not buying it. They're saying, "No, no, you already used that as a reason for us spending a half a million dollars. You can't use it again."

Right now, I'm going to rate it as an eight out of 10, but I believe it's going to be a 10 for us.

OpCon has primarily been used to automate our backend IBM and Windows processing. Largely, this involves file transfers, IBM i job submissions, Powershell scripts, and SQL queries. 

We use OpCon to build workflows of related processes to ensure that things are run in the correct sequence. Logic is in place to ensure errors are handled appropriately, and often automatically. OpCon's Solution Manager is also used to empower other users to initiate processes, where previously tech involvement was needed. 

OpCon is the glue that joins numerous processes and various systems into a single cohesive and centralized experience. 

In my department, OpCon has largely removed the human error from our nightly processing. Clicking or launching the wrong program is a thing of the past, now that OpCon has taken over the processing. When employee turnover occurs, items that have been handled by OpCon are no longer a concern, due to the fact that the process will continue to function as expected. 

Error handling and reporting have also been a great benefit. Often when things in our environment break, OpCon will generate a notification to us of the diagnosed problem. We also heavily use OpCon's IBM Message Management system to identify messages displayed on our i Series and respond appropriately. This ensures critical messages are seen as well as tracked when required. 

Self-service has also been a great benefit to us. We're able to build processes within OpCon and give the end-user the ability to initiate them with inputs. Where previously this couldn't be done due to the security concerns of giving the end user that capability, now we can grant a batch user used by OpCon those permissions. This enables us to keep tight control over permissions, but grant some extended functionality through Solution Manager. 

The self-service is great as it enables users to initiate processes within OpCon without giving them access to more functionality than required. It relieves stress off the technology department, as more users are able to facilitate their own processes without a call to tech.

IBM LSAM has a very robust set of tools to monitor and run the various processes on an IBM i mainframe. It has the functionality to mimic operator input and capture data off of the screen for evaluation. The two most heavily used features of the LSAM in our environment are the Message Management and Scan Spoolfile functions. These allow us to capture information from message logs as well as spool files and launch further processing through the LSAM or OpCon itself. 

The smart email allows us to retrieve emails from a specified account and triggers further processing. Again, it allows another avenue for external users to initiate processes without needing to contact us. 

The script repository enables us to hold "scripts" that can be run on various machines - Windows in our case. It supports versioning and documentation.

The end code response allows us to evaluate how a process finished, set the termination/end code appropriately, and then trigger further processing based on how it ended. 

It's a pricey product. The new license model gave us access to a lot of functionality that we're not likely to use any time soon. The cost of the product is now also determined by the number of jobs you run through the software. There are pros and cons to this method, but now I have to evaluate if a simple function is worth the cost to automate before doing so. 

More functionality within self-service would be greatly appreciated. We're needing to look at other solutions in conjunction with OpCon as the number of user inputs available within self-service doesn't always meet our needs. If self-service could be improved to pull information from OpCon to "pre-fill" inputs, that would also create a much more seamless and powerful experience. 

It would also be fantastic if we could create our own job subtypes. There are quite a few that come with the software, but being able to create your own would mean you could standardize how parameters are provided to executable programs/scripts. 

I've used the solution for more than 4 years.

Very rarely do we experience anything that would make me question OpCon's stability. 

It's very scalable, especially given the new license model which allows installation on "unlimited" Windows machines. However, detailed knowledge of the product may be required to make use of it properly. It takes time and experience to make great use of the software. 

Usually, this is a positive experience, however, occasionally I feel like we're getting the run-around or being offered solutions that don't appear to be applicable to the issue. Very rarely is an issue not resolved within a week. 

We did not look at anything else of this caliber. We made heavy use of Windows Task Scheduler and the IBM Job Scheduler. The process worked, but everything was scattered and we really needed a centralized point of contact for all our automation.

SMA was onsite to implement the software initially. Largely, this was straightforward and any bugs or issues that came up we were able to work through shortly after SMA left. 

We had an internal team that worked with our implementation team from SMA to set up the product. SMA was incredibly knowledgeable of the OpCon ins and outs. Particularly the IBM contact with SMA was extremely impressive in their ability to provide robust solutions and bug fixes to problems in a very quick manner (often within a few hours of reporting the issue). 

In our environment, OpCon is much more expensive than it used to be a year ago. Licensing changes no longer allow us to automate to our heart's content in our "small" environment. Now, the cost to automate needs to be evaluated as new items are put into the software because it's likely you will be charged for them. 

Getting a good handle as to what SMA charges can also be helpful so that new processes can be created in a way that incurs a smaller expense. As an example, using a single script to accomplish what multiple jobs could do otherwise. 

Yes. We looked at Help Systems Robot.

Overall, OpCon has been an amazing addition to our automation toolbelt. While current prices sting a little, given past pricing, it has been well worth the cost and peace of mind. 

The primary use was to automate and schedule batch processes for a banking core system. As OpCon is more capable than our previous job scheduler, we have automated more jobs. 

We quickly found it was capable of doing much more, and expanded the uses. As the ability to schedule processes is so flexible, we now use that to start SQL agent jobs, SFTP processes, file transfers, and backups. 

We also have automated daily processing on a loan servicing system as well, which lets is run batch processes during low usage times overnight without having staff scheduled for those times.

The biggest change was having a robust way to schedule critical processes. Once it was set up, things just worked. Input errors were eliminated and we can quickly see the status of jobs, with instant error reporting in case we have an issue. We were able to automate processes and increase productivity so staff could focus on more complex tasks and project work that move the organization forward. That, and the peace of mind of knowing things run on time, are the biggest improvements for the organization.

Reliability is always important, and the reliability of the system is outstanding. The ability to link processes, have dependencies, and monitor things like file arrival has let us automate some fairly complex processes that previously involved a lot of user time.   

Being able to do this, and present it to staff as a self-service button that takes one click to submit was a big win. We have a large number of files, from multiple vendors, that must be accessed through FTP, and being able to get these files, unencrypted, and process for reporting or ETL processes overnight has streamlined our mornings and lets us deliver reports much earlier than we would otherwise.

We don't have a lot of asks, and the limitations are typically in deficiencies of the APIs or interfaces on other proprietary systems. OpCon would let us, but some vendors don't have that attitude. 

A way to select multiple jobs in the UI for a quick change or to hold, release, et cetera, would be nice. For example, I was testing a process where after a job finished, a multi-instance job for splitting out 12 report runs. When I made my adjustment to re-run, I had to click on each job separately to restart. It was time-consuming.

I've used the solution for about 5 years.

The solution is very stable. We have had no outages that I recall.

It is highly scalable. We can't imagine pushing against any limits.

We rarely contact support. When we have had to, its typically a very fast single call resolution. 

We had a different product, and it was limited. OpCon was less expensive and did more.

The initial setup was straightforward and the learning curve was that after a few days building things in our test environment we rapidly moved jobs to live.

We had an OpCon person on site, and the experience was very helpful.

The ROI is hard to quantify as it is so much a part of what we do, however, it does the equivalent work of a few staff members, for much less than the cost of one person.

We found it was a better value than our other option. I'd advise users to ask a lot of questions when setting up as chances are there is a way to do it. Having a lot of examples of processes was useful in expanding. We could copy a job, modify it, and be off and running. 

We compared this solution to our previous product ISE Enterprise Scheduler and spoke with other Opcon users.

It always works and we rarely need support.