OpCon Reviews

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.

We use it to run all of our batch across seven Unisys mainframes.

It's installed on Windows.

OpCon has streamlined the batch. It's made it quicker. We're processing work a lot more easily now, given the dependencies and frequencies we have. We don't really have to think about checking things. It's all there in the system and done.

When we first brought it in, we saved on people's time. We freed them up to be able to look at the future. We freed up two or three people who used to have to work on it all the time. In terms of batch savings overnight, we've probably saved a good couple of hours per night on batch scheduling.

Auto-scheduling is the most valuable feature. We have the ability to schedule seven days in advance, so we know exactly how we're running every night. If we need to make any changes, we can make changes to the daily schedule and we don't have to worry about changing masters or quarterlies. Changing our master schedule causes us issues. We have another product that doesn't work quite like this and when they have to change the master schedule they have problems. Because we have the ability to auto-build seven days in advance, we only need to change the daily and not the masters.

Believe it or not, there is nothing that we require. Everything we want is there. Everything we need, we get. The support we get, and the management support we get from SMA — we have a monthly review meeting with them — are fantastic.

The stability is fantastic. It's 100 percent. We've never had a problem with the product from day one.

It's fully scalable. We're currently reviewing moving it into our Windows estate, which is huge, and we're possibly looking at moving it into other areas as well. It's fully scalable, obviously with charges. We pay for a set of licenses to run on the Unisys. If we want it to run on other machines, we would have to pay more for the licenses, which is standard for any product.

We run about 2,000 jobs a day, and we are looking at potentially expanding it to 25,000 jobs a day, if our Windows systems move across. We're just about to go into proof of concept on that.

We were using an SMA product, Scheduler, but they stopped supporting that product and then we migrated to their updated product which was OpCon.

The initial setup was easy, as are the updates. It took us about an hour to do it, given the way that it's all written down for you. You can have a resource from them onsite if you want or you just load the software and it goes off and does it all for you. We've done it numerous times and we've never had a problem.

In terms of our deployment strategy, we already had an SMA product called Scheduler. What we did was we took a copy of our database, gave it to SMA, and they migrated it through into OpCon for us. They gave it to us and let us play with it, test it, and make sure it was working okay and then we migrated straight over to it. It was as simple as that. We couldn't find any problems and we migrated straight away. We've never had any problems with it.

SMA is fantastic to work with. They're knowledgeable, they know the products, and they don't try and force anything upon us. They're happy to work with us. They understand our limitations, and they still do to this day.

We've seen a tenfold return on investment. The relationship we have with SMA now is absolutely fantastic. They don't just do batch scheduling. They've come in and offered other services.

We're processing the batch a lot quicker, so our services to members are not down. The money is available and in people's accounts a lot quicker than it used to be. It gives us 100 percent availability. It doesn't fail; we've never had a problem with it. 

It's not expensive. It's a lot cheaper than competitors. Licensing is annual.

There are only additional costs to the standard licensing fees if we go above what we've agreed to. If we were to add a new Unisys mainframe, or if we add a Unix box or a Windows box, then obviously we'd have to pay for licenses. There's nothing else.

You need to be up-front and tell what SMA what you want. There are different licensing models for different setups. There are a lot of options, so it's really a matter of working out exactly what options you require. What works for our organization, Nationwide, may not work for the next company or the company after that. But they have a lot of licensing options available. And if there isn't one that you want, you can make your own with SMA.

There isn't anybody else that does Unisys. There's no other product for running automated batch on Unisys. Obviously, there are other companies in the market that can do Windows and other systems, but no one out there can really run Unisys. And Unisys recommends OpCon anyway.

I, myself, do not use other similar products, but Nationwide does. We use a product called Control-M from BMC. We can't find any advantages of Control-M over OpCon. The drawbacks of Control-M are that it's too expensive and an upgrade takes ages, days, to do.

OpCon is cheaper and the service we get from SMA is absolutely fantastic. The product is always growing. We're seeing it grow. We're seeing the changes, and we're seeing the changes that we're asking for in the product. We don't see that from BMC. That's why we're looking to move Windows from Control-M into OpCon, possibly.

My advice would be to work with SMA. Don't try and do it yourself. Work with SMA until you're comfortable; until you've got the training and the expertise. Work with them until you're comfortable taking it on without one of them there. Do your first install, your first upgrade, with SMA. It's simple, it's as per the manual, as per the training, but you need that little bit of confidence. That's what we've found. We've got that confidence now, and we don't rely on SMA at all to come in to help us.

The biggest lesson I've learned by using the product is trust it. Trust what SMA says. Believe what they say, because what they say is right. The migration is easy and they can do most migrations. Their training is fantastic, their support people are fantastic, and the support is out of this world. We're UK-based, so we have a UK team that looks after us in our daylight hours, and then we have a US-based team, and then we have an on-call US-based team as well, if we have problems. But we've never had to call them out. We've dealt with them, we've had our little questions and niggles, but they've answered everything, every time.

The product is always improving. The new release 19 has a load of new features for us. I've not really looked at it yet, but I think it's become faster, more slick, and a bit more user-friendly. They've taken on a lot of what customers have been saying about it. They've made some behind-the-scenes changes, but they've also made some enhancements to the way information is presented. My system, the Unisys, is quite old, so there's probably not a lot to change in that arena. It's probably more on the Windows and Unix side, which we don't use currently.

We don't really have users as such, because it's a batch scheduling tool. We have about 30 users who have access to it, but only for support purposes. We've got a team called Schedule and Batch which looks after things and check it. My team has access to it, but we very rarely use it and we're not limited on the number of users. The scheduling team is responsible for making sure all the batch work that is scheduled finishes correctly. We also have an ECC team, whose members are like operators. They look after the machines that run all the batches overnight. And then my team is a support team. We support the ECC in scheduling batch, if they have any problems with the product or with any of the batch jobs overnight.

For updates and maintenance of the solution we need just one person, me. My job is platform manager, but I'm also the OpCon subject matter expert as well.

On a scale of one to ten, this product is a 12. But I'll accept making it a ten.

We are a mid-level financial institution. We specifically used OpCon to help schedule important tasks that could not be trusted to human error. We picked it up as a tool to make lives easier for all of our different departments. We began working with MAS a few months ago as our scheduled jobs became too much for a few people to handle while we were experiencing high turnover. We became bogged down with users who did not understand the system and did not have time to train them. MAS stepped in and made this transition a lot easier for us. 

OpCon has made our lives easier by taking out the guesswork and removing tedious activities from employee's workdays when their time is better spent elsewhere. OpCon also helps because it is easy to "read the job" to know what the job does, why, and how to do it manually if needed. 

Through the use of self-service buttons, we have been able to give the option to run jobs whenever the user needs without having to manually do an entire process. Many of our end users use this without any complaint. It is simple and easy to use. 

MAS is by far the best feature, although not a feature of the software specifically. MAS has more knowledge than our employees, so we have been able to develop schedules that are far beyond our own skillset. 

They have also helped with maintenance so we can be assured if something goes wrong, MAS is there to fix it. Our on-call schedules are easier and we get full nights of sleep. Our team morale has greatly increased since we began working with MAS. Another great feature is the exit codes which help us understand why things are failing so the jobs are easier to fix. 

The only downside to OpCon is that its features can be complicated and really must be taught. Most of our users don't have training beyond the free Basic Training that SMA provides, so for fresh eyes, it is kind of difficult to understand some of the language used. 

Another thing that is difficult to understand is that not all failures explain why they are failing. Some give generic exit codes. 

Otherwise, I have no complaints. Working with the MAS team has really simplified everything for us. They're easy to reach, knowledgeable, and quick.

Personally, I have been using the solution for two years, but our organization has been using it for five or more years.

The software has many features that are even beyond my knowledge, having worked with it for two years. Working with the MAS team, I have learned even more. 

You will often find that you speak to the same people over and over again so you develop a rapport. Everyone is always helpful and very nice.

We did not use a different solution. We were doing all of this manually. 

The initial setup can be complex, however, transitioning with the MAS team was very easy and straightforward. 

We used a vendor team. Our engineers developed a close relationship with them. 

It is not the cheapest solution on the market, but it is relatively easy to use. I absolutely recommend splurging to hire the MAS service to make the transition easier. They can help teach your users how to use the program and they are able to quickly build jobs so you see an immediate impact. 

I am not entirely sure if there was an evaluation as this was before my time, however, knowing management, I assume that they had many demos with other vendors as well but eventually chose SMA.

We currently use Opcon for our daily job scheduling. We also use it to transfer files after jobs have been processed. Being able to let Opcon run these jobs and file transfers have saved us time daily.

It has saved our morning and evening shift time by processing tedious jobs so they're able to get more involved in other tasks. Soon we'll be able to roll it out to other departments and handle some of their tasks.  

The workflow designer is a wonderful feature to show to users. It seems so simple - and yet there's a lot going on which can be easily explained. Having the jobs laid out while attaching dependencies is a nice addition to the program. 

The service that they offer is amazing. Ryan Compton has helped me more times than I can count. He does a great job of explaining things and it has gone a long way.

The logs are a little daunting to look at the first few times, however, as you begin to understand what you're looking at, it becomes easier. 

We've been using Opcon Since February 2021.

We switched to a different core and Opcon was definitely a better replacement for the solution that we were using. 

For anyone interested in Opcon, make sure you have a few users in your company attend the training classes.

Our primary use would be for the enterprise data that we are utilizing, receiving files, and inputting jobs in and out of our core.

We have been using it quite extensively for important things: any ACH processing, remote deposit processing, file transfer protocol, and for any files that we need to send back and forth everyday.

My roles include anything with our core, things relegated to OpCon, and any ATM processing. These three things are my primary function.

It is so simplistic that it gives us peace of mind. Before, we had all these processes that were run manually, such as different file transfers and jobs running for our core at certain times. Now, all that stuff is done automatically.

We watch and make sure it's doing its job, which is mostly good. Basically, we go in and check multiple times a day to make sure jobs are still up and running, even though we get contacted as well. 

One of the manual processes that we moved to being automated is uploading jobs to our statement vendor. Previously, we would have to upload all of our statements manually and get the files physically, then transfer protocol them over to our statements vendor. When we built that into OpCon, we were able to build the job to run it at 7:00 in the evening on the days that statement needed to be uploaded. It will go into run the appropriate core job to pull the core member data that it needs, then pull it out and store it on one of our network drives. At which point, it will get moved, zipped up, and then moved through our OpCon FTP servers.

Our employees are freed up to do more things automation-wise. It also gives us the ability to look at taking on new tasks that we typically didn't think of because we just didn't have the time.

The most valuable feature would be the contact feature. You have this awesome automation tool, but then it also has the ability to contact and page you in the event something goes wrong. This is nice. It gives you the warm fuzzy feeling in IT, if you're not receiving calls, that everything is going well.

I would like more web-based training from SMA. That would be nice. Our primary OpCon representative is phenomenal, but we would like some training opportunities for learning on our own. When I started utilizing OpCon, the sheer breadth of it made for a very daunting task. I was almost fearful to start, not to mention fearful to go change things and possibly hinder a job. 

We've been using OpCon for probably six years. I've been in this department for two years now.

It is very stable. They have a great foundation. 

However, to increase stability, they will need to create more online learning. So, somebody who lives in San Antonio (in my case) doesn't have to drive to Houston.

OpCon takes six individuals to operate and maintain it.

The sky's the limit.

We have six users who are developers in our organization.

We have automated probably hundreds of processes. As a ballpark figure, I would probably say about 60 to 65 percent of our manual processes have been automated.

They have good tech support when you call in. Typically, you can get the answer that you were looking for relatively quickly. 

You do run into people who are new there from time to time, but they still have a good core foundation. As far as their tech support, you can tell that they are good with teamwork because I've had calls where maybe somebody didn't understand what it was that I was referencing. However, they were able to reach out to somebody more senior and we got the answers that we needed.

I'm not sure if anything was used before.

The setup looks complex, but it becomes simplistic relatively quickly. E.g., looking at a job to edit and change things, you have different setups. One of them might be running a core/FTP job, where you have essentially have three to four different selections within those or you can choose command line. 

The implementation was internal.

The solution has very much freed up employees to do more meaningful work as a result of automation. It is really matter of having boots on the ground to keep working to automate more than that roughly 60 percent. 

Our department is relatively small. I would probably say five employee have been freed up.

The solution has reduced data processing times.

We have some plans in the works as far as how we want to utilize this in the future. It really all boils down to just not having to do processes manually, instead making them automated. The only function we utilize it for in this case is to free up more manpower.

I would recommend doing this solution. In the beginning, it appears to be daunting, but it makes a lot of sense once you started utilizing the tool. 

After training, I learned through a sort of trial by fire. However, it didn't take long to pick up. With the scripting portion, everything was simplistic to learn. If I was going to rate ease of use from one being the hardest to 10 being easiest, I would probably rate it a nine.

There are tools like this out there. You don't realize what automation looks like prior to seeing it from the back-end. It's pretty cool. I often call it, "The middleman between two points," because it connects the bridge.

I would rate the product overall as a 10 (out of 10).

They are here to stay as a vendor.

We use it for batch processing and online processing.

I work for a government department which represents 43 sub-departments, so our department literally has thousands of systems. We have about 25,000 automated jobs set up in OpCon, but I don't know what percentage that would represent, overall, of the jobs in the 43 departments.

I can't really provide many metrics showing the way OpCon has improved our organization functions because we have been using the product since 1997. So any metrics we would have had before we started using the product would be relatively useless because of how much we've increased our production loads since 1997.

The solution has definitely streamlined our operations and makes onboarding of new applications very easy. And OpCon has most certainly freed up some 50 to 75 employees to do more meaningful work as a result of automation.

The most valuable features for us are

• job dependencies
• auditing
• notification
• robustness. 

Those are things we rely on all the time.

I find the solution has quite a learning curve for beginners. It's challenging. I wouldn't rate it as super-easy to automate processes. It's medium-weight. I've used more complex software, but I've used simpler software.

I was involved in supporting the solution for about 14 years. When I stopped supporting it, we were on version 16. Our organization still uses it and we're into version 18, in production, now. I installed and fixed any issues with OpCon and was a liaison between the vendor and the users.

It's extremely stable.

We have found it scales very well. We run thousands of thousands of jobs every day, and sometimes thousands of jobs in a few hours. We do use it extensively, and we use it for mission-critical processes.

The tech support has been excellent. They're the best that I've dealt with in 25 years of supporting software.

We've had a close relationship with SMA, the vendor, and they've been very attentive. We have made requests in the past for added features, and they've been very responsive and put them in.

We didn't have a previous automation tool at an enterprise level.

Back then, the setup was complex because of the number of processes that we initially automated. Our initial deployment took about five months. The installation of the software took a day, and then we spent several months creating our automation, within the tool.

We had the help of SMA and used our internal resources.

We have seen a return on investment from OpCon.

We did an RFC and had vendors bid, but I was not part of that process.

My advice would be to invest in education on use of the product and I would recommend planning the deployment, and administrating users and roles, carefully and thoughtfully. A careful implementation of roles and responsibilities for the users of OpCon will save you some issues in the future. 

We don't have a high number of users of the product, although we have a high number of processes that are defined within it. Our actual user base is closer to 50 specialists. 

In terms of deployment and maintenance, we have about two-and-a-half employees involved. Their roles would include upgrading the software and installing the agent software throughout the organization. They are also responsible for identifying any software bugs, memory leaks, or issues within the software itself. And because they know the product so well, they're often called on to troubleshoot automation logic.

The biggest lesson I've learned using OpCon is that you can automate more than you think you can.

Overall, I would rate the solution a nine out of 10. If somehow they could improve the user interface to be somewhat more intuitive, that would help. Our users find it overwhelming and it has quite a fairly steep learning curve to begin automating jobs. It's like sitting in the cockpit of an airplane: You're doing something complicated.

But I love the product and I love the company.

We use it for automating with our core system, Symitar. We've automated some 100 processes with it. Of what we can automate, about half is now automated.

Before OpCon, it was a person's job to just manually run a bunch of things, like file transfers. And someone had to set up nightly processing within our system. Now, nobody has to do those things, and nobody forgets to do them. It just does them. It has improved our efficiency. We don't have to log in and download files and transfer them.

We haven't freed up a full person's job using it, but there are a good handful of people for whom it has freed up about half of their time. And those employees love it. A lot of tasks are based on certain times, and they're no longer stuck doing those things at those times. We don't have to have anybody coming in early anymore. They can focus on the processing part of their jobs instead of the file moving and downloading.

The solution has also reduced our data processing times by about 20 percent. We're still in the building process. We have a lot more to go.

For us, the integration with Symitar is the main reason we got it. But we're also able to automate everything. We don't have to do things manually anymore. It takes out that human error.

I don't really think anything needs to be improved within the functionality. The only struggle I had, when I first started using it, is that it depends a lot on the command line and I didn't have that experience. So more built-in, basic commands or more education on commands would be good.

We've been using OpCon for two years.

Overall the stability has been great.

We've had a few issues but they're not because the system isn't stable. They have been more a case of known issues, but, until something broke, we weren't notified that we should fix things. That was a little frustrating. They knew it was happening, but they didn't tell us, "Hey, this is happening. You should do this before it breaks."

One issue had to do with pulling a file, because you can't use wildcards for file names all the time. SMA had a different FTP solution that they gave us, one that one of their programmers wrote. We're using it, but it's outside of the core OpCon system. Since we got it, things have been good. It just would have been nice if we could have done it all within OpCon instead of having to have a separate process.

SMA's technical support is great. They've been very helpful. What has been a little difficult because is the time difference. They are in America but they're two hours ahead of us. Sometimes things happen at the end of our processing day and their tech support is closed. But other than that, it's been great. Their online system is good and when we call it's good.

There is on-call support, but they make it very clear that unless processing has stopped, there's a fee for that level of support.

We had MOVEit before. The time to implement that solution, versus OpCon, was about equal. But OpCon can do much more than the other one could. In terms of automating processes, they are similar. MOVEit did not depend so much on command lines, so it was a little more straightforward when we wanted to work with dates or file names. But it didn't integrate with Symitar. For us, that was the huge part.

OpCon's TCO is a lot more but we didn't have support with the other solution.

The initial setup was complex. There's so much it can do. But we had a lot of support from SMA, so we got what we needed. That complexity goes back, in large part, to the command-line issue. The simple things, like downloading a file and saving it, are really easy. But if you want to do more stuff, it takes a little while to get through that and to understand how it works.

SMA came onsite for the initial week and set it all up. We went live right away with several things at that point.

Our implementation strategy for OpCon was to get the nightly processing stuff set up. That was the most important initial goal. Then we made a list of all the things that were run by people manually and we went down that list.

Our experience with the SMA techs was great. They were onsite and that was helpful. They're very knowledgeable. They explained everything and they gave us best practices.

We have seen ROI in terms of people being able to work more efficiently, which helps with the cost of employees.

We just switched to task-based pricing, instead of annual agent pricing. There are the licensing fees and a maintenance fee. And we have costs for maintaining servers, our main server and our DR server.

We didn't really evaluate other options because OpCon is endorsed by Jack Henry. We were able to talk to other Symitar clients to get their experiences. OpCon was the logical choice.

The biggest lesson I have learned from using OpCon is that we do a lot of things manually that we don't need to be doing manually. Also, as we're automating people's processes, we're able to analyze what they're doing and find a more efficient, better way to do things.

My advice would be to learn about the command line. Also, start early on making a list of all of the things you want to automate and write out the steps for each process. That's been taking a lot of time: Trying to get people to explain the different steps they do and then trying to figure out the best way to set that up in OpCon. Starting on those things early will help speed up the implementation.

There are about 10 people using OpCon's Enterprise Manager and the Self Service, in our company. There will be more. We're slowly expanding. Among the users are our systems analyst, our system administrator, and some of our accounting, operations, and compliance people use it. We also have a network specialist who uses it for file cleanup on different servers.

We have three people involved in maintaining the solution and each has a role. Some of us create, some of us upgrade it, as needed, and some of us monitor it daily. We don't have our developers using it. They develop something and then we usually incorporate it for them.

Our usage of OpCon is still pretty moderate. We have a lot of plans to increase it. It's just a matter of time. It touches all departments, but we want to utilize it more within each department.

I would rate the solution an eight out of 10. It's pretty good but I don't think it's miraculous. It's definitely better than our old solution and I'm pretty happy with it.

We use OpCon as our central scheduling system. It runs a bunch of automations for our core system as well as for any automated system that needs to be scheduled.

OpCon has eliminated man-hours spent doing repetitive things, and it's also made our execution much more reliable. To do what we are doing currently, it would take at least four or five people, full-time. Clearly, we've cut a bunch of FTEs out of the equation, so that has been a big deal. They have been reassigned to other things. Everybody loves it because they're able to now work on higher-value things.

It also allows us to see metrics of how long our automations take, and control or manage to that to those durations, so we're able to reorganize and rearrange things at a rapid pace to get them completed faster.

We have automated thousands of processes using OpCon. I believe we've automated 100 percent of our processing. I can't think of anything we're doing manually.

In addition, OpCon has reduced our data processing times by, as an estimate, 25 to 30 percent.

The most valuable features are 

• the ability to chain jobs together 
• the integration into Symitar. At the end of the day, that's what makes the big deal for us.

The ability to chain jobs together allows us to create complex interdependencies between our jobs, and the integration into our core system is important because it allows us, through an automated system, to do a huge number of things that used to be done manually.

It is as easy to use as it should be. There is a learning curve, but that's because it's a powerful system.

I'd like to see the product include a view where you can see everything about a specific job on a single screen.

We've been using OpCon for more than 10 years.

The stability of OpCon as a solution is excellent. We never have any issues with its stability.

We have had no issues with scalability. 

We have plans to increase our usage of it. It's primarily used in IT and programming, but it is automating jobs that are requested by, and the results are used by, everyone else in the company. We have automated processes for the lending department as well as branching, account services; everyone.

We have five to seven people who use it on a daily basis. They are either OpCon developers or programmers who are testing new deployments. We need less than one person for OpCon system administration.

SMA's technical support for this solution is excellent. They are responsive, they are knowledgeable, and they've always been able to address our questions, which is impressive.

We did not have a previous solution. Our company went with OpCon because it has a very tight integration to our core system.

I was not around for the setup and it's been so long since it was done that I don't think our experience would be indicative for anybody else.

For the most part, upgrades are pretty straightforward. And they've been pretty solid too. We generally do them with the help of SMA consultants.

We have absolutely seen return on investment with OpCon. We've eliminated the FTEs. We have increased the speed at which our automations run, so we're in nightly processing for a shorter period of time. We've been able to run more fraud tests and to run control reports on the nightly run than we would be able to run manually, so that we can identify problem areas or fraud and address them immediately. We use it for all sorts of things.

I believe our cost is about $150,000 annually.

There are add-ons you can buy, which have an additional cost, including products and Professional Services.

We really have not evaluated other options. It is the state of the art for our core system, and we have been happy with it.

The biggest lesson I have learned is that using an automation system like OpCon forces us to really understand the business object of a goal we are trying to accomplish and to be able to articulate it clearly and precisely.

Automating your operational tasks the way that OpCon does is absolutely a better way to do it than any manual system that you may have in place.

We're a credit union, so we use it for daily operations. We have over 1,700 jobs automated. We are still working on it. The list is growing every day. I add two or three whole, automated processes — schedules with projects — every two weeks.

This isn't our first automated system, so it's hard to say how it's improved anything. The best thing is that the communication with our host system is better. It allows us to have more security. It allows us to have more information and more control than we previously had over the processes that are running in host systems. That has been an improvement.

This solution has streamlined operations by giving end-users the ability to run things without having to get permission within the host system. That eliminated the need for other departments to have to send messages to operators in IT to run processes and host. Now we can give them access to run very specific jobs without giving them access to those systems.

It has also freed up employees to do more meaningful work as a result of automation. There are multiple departments within this organization. We use it throughout the organization so it's huge; it has affected hundreds. The employees, as far as I can tell, are okay with it. They like it. I don't have a lot of contact with end-users after the development is over, so there may be different ideas, but I haven't had any complaints.

All of the features are important. The best thing about it is the communication listing.

There's a learning curve, but it's a fairly easy system to use. It doesn't require a lot of technical skill.

The system needs better communication, better advanced warning, and better stability with SQL database systems. The latter is the only Achilles heel to the software. The SQL database connections are the only time that we've had issues with reliability and stability of the software.

We've been using OpCon for three years.

The stability is really good.

It is vastly scalable. We've grown up to 1,700 jobs and it hasn't had any problems. As we grow, with each development, we're learning more about its capabilities and pushing limits of what we feel is safe, and it has never failed us.

It is used in a lot of ways and it's used every day. It's a critical component of our daily ops, and we are going to continue to expand and include other departments in IT, helping them manage some of their systems.

SMA is great at replying to inquiries. Their support is great.

Before we got OpCon we did have another automated system, AutoMate. We switched due to OpCon's capabilities of communicating with the host system. And OpCon runs faster than the last one. There are some scenarios where it has been more capable and some where it has not been.

In terms of the time to implement OpCon versus our old solution, they're very different. The last system was geared closer to, and was more in tune with, developers than OpCon. It was very capable, as long as you had the skillset. Whereas OpCon is very simple and the GUI is very click-and-point. OpCon is faster at delivering some of the smaller things. But when it comes to more complex things, the last system was better because it was more prepared to handle those systems.

The initial setup wasn't difficult. It was pretty straightforward. The install wizard is easy to follow and there weren't a lot of hidden things to look for. We also had SMA staff on site, so they made it easier.

Our initial install was done in about an hour-and-a-half to two hours.

Because this is part of a conversion project, it's been managed by a PMO, and we follow a scrum-board, sprint-style implementation plan. That's pretty standard though.

Our first process was automated in about 10 minutes after install. The first one we did was one of the easiest things and it was done in a second. It was very fast.

There's a lot to be said about using the embedded script systems and having good error handling. Hopefully, anybody who's doing development with scripts, writing code, is not a novice, because that part is really important.

The biggest thing I've learned using OpCon is convention. With the last solution, it wasn't such a big deal because the UI design was very simple. With OpCon, it handles schedules and jobs differently, so convention is very important with this: Learning to stick to a standard.

When it comes to end-users they are only using the Self Service option to click a button. Their roles vary within the different departments, but it's still the same thing. They log in and click a button. But when it comes to developers, there are only three of us, including me. For maintenance, there are three of us involved. Two of us are primarily developers and one is an operator who will monitor and report.

OpCon is a good eight out of 10. There is room for improvement with every system, of course. As I mentioned, the SQL database is the weakest link. There are some changes that have happened since our initial version that may not have been the best. Those types of things are really hard to improve because it just has to happen. That's an evolution.

We have it running batch processing across our mainframe and Windows Server environments. OpCon also integrates with a third-party SFTP tool and through that we have OpCon driving all of our file transfers as well.

We've automated hundreds of processes with OpCon, representing a good 80 percent of our processing.

One thing that we had to introduce about three years ago in our bank was exchanging high volume monetary files with other banks on a mission critical hourly basis. We would start doing the exchange at about 9.30 a.m. every day and it would go through until 2 a.m. the following morning. It was very time-driven. Our customers were heavily reliant on it because it was money that was coming to fund their accounts. OpCon allowed us to fully automate the process, right down to when it went wrong for any reason, it would alert us. Rather than having to employ three staff members to manage the process over the period, it just runs. It tells us what has gone wrong.  Every day, every hour, we do two full exchanges and they just happen.

Another thing we've been able to do with OpCon is to give our business users a level of self-service and automation for themselves. We don't have to be here to do things for them. OpCon will just do them for them. OpCon has absolutely streamlined our operations. We went from getting requests to do something and the end-user waiting for however long it took us to get around to doing it, to their being able to do it for themselves.

We actually got rid of our third shift with one of the operators going off to work in another part of our IT division. Now, the third shift effectively goes on unmanned. We allow OpCon to run things for us.

In addition, with the automation, the solution has definitely sped things up enormously. There's less human interaction that has to go on now.

We just wouldn't be without OpCon.

The most valuable features are the 

• automation 
• repeatability.

Since we got it configured, it has just done the job day in, day out. Being able to rely on it and know that it's going to happen, whether there's a person over it or not, is really good.

The ease of use and simplicity in automating processes are good. They get better every time they put out a new release. When we first got it, a long time ago, it wasn't as intuitive as it is now. That also comes, a little bit, with our having used it for so many years, so we're more used to it. But I have a guy who started working with me about three years ago, for example. He had never touched anything like this but he was able to pick it up and run with it. And he absolutely raves about it. He thinks it's the best product he's ever worked on - this from a person with many years of IT experience.

I might like to see a little bit more of a seamless user interface. That would be good. They're moving towards a browser-type interface, rather than the Java application that we currently use. Also, a little bit more built-in self-service would be good, rather than a standalone product.

We've been using OpCon for around 15 years.

The stability gets better all the time. Where we've had problems with stability, it's been partly our fault. We run it on a VMware server but we haven't recognized that the workload has increased and haven't increased the capacity of the server it's running on. It's because of things like that that OpCon has had the odd issue. But in general, the product in and of itself is pretty reliable.

It's absolutely scalable. It will just take whatever you throw at it. As long as you make sure that the hardware it's running it on will cope, it seems like it has endless possibilities.

It does all of our batch processing. Absolutely everything is run under OpCon. As we add more processes, it's a no-brainer; we put them into OpCon. We only use it for our ClearPath mainframes and Windows Servers. If we were to move to another operating system, we would definitely take OpCon with us. It has that flexibility to run on different platforms as well.

Technical support is really good.

I brought OpCon into the company. Prior to that everything was done manually by people.

The initial setup was pretty straightforward. We were a very small IT shop when I first came here and OpCon was one of the first SQL databases that we had that had any great importance in our world. We had local New Zealand support to help us. They were really good. We were a little bit wary of jumping in and using it, and they really helped us to step into the product with small steps to start off with. That allowed us to gain a comfort level. It was a good implementation.

We were a little bit shy and timid about automating things. We started out playing with it quite a bit. It took us a while from the time we deployed it until we automated our first process, and that was because I decided to approach it by rewriting a lot of the code that we ran, to make the best use of OpCon. We used to have one great big job that ran everything, and I really wanted to break it down and use OpCon to bring everything to the surface, rather than it being all hidden in one big job. My wanting to do that made it take longer; it was a few months to really get something going "in anger."

The game plan was to try and take away as much of the manual processing as we could. There was a lot of checking that was done every single day.

The fact that we were able to eliminate a staff member entirely from the area and move him to another area has definitely paid dividends in terms of what we pay for OpCon today.

I have worked in an IBM environment, so I've worked with Control-M and the old CA 7. OpCon was the only option that was available, at the time, for a ClearPath mainframe. But it's been a good option.

The biggest lesson I have learned from using OpCon is: Don't try to do things manually. It's a really good automation tool. Really, really good.

Go for it. If your aim is to gain reliability and automation, and making sure that when you want things done they'll get done, then OpCon is a really good tool.

One of the very good things about SMA as a company is that they actively seek input from us as customers. Where it makes sense, they take our suggestions and they develop them and they implement them. There are a couple of features in OpCon I'm aware of which have come from a number of customers here in New Zealand, including myself. They listen and they improve where it's appropriate. There's nothing significant in the product that needs improvement. It's a really good product.

There are four of us who look after the production environment, and we have about 10 or 11 people who are using it in development work, running their processing. There are two of us who do maintenance of the solution. The only reason there are two of us is that people go on holiday. It really is easy to maintain.