OpCon Reviews

We use it as an automation tool to send and receive files and process batch jobs on our core banking system. It can also archive files for us. We use OpCon to automate anything that we can automate.

If I did not have OpCon, I would have to hire full-time employee to do all of the work that OpCon does. We probably save about $40,000 to $50,000 a year by being able to schedule everything. Plus it's reliable. If an employee doesn't show up for work, someone else has to fill in, and things might be late. OpCon works. I wake up in the morning and the first thing I check is my text messages. I see a text message from OpCon that End-of-Day was successful the previous evening. That way I know people can come to work and everything is on schedule.

Another benefit is that, in the past, employees would have to call the IT department to run certain batch jobs in our core banking system. We don't want to give the privilege of running a batch job to an accounting clerk because they could accidentally run a batch job that they shouldn't and cause serious problems. We were able, with an additional piece that we purchased from OpCon called Self Service — a web-based platform — to create a button for the accounting department to click. 

As an example, we have to process ACH and when an ACH file comes in, the accounting department needs to look at it for certain exceptions. And then our support services department needs to look at it for certain exceptions. When each person is done with their job, they go to their Self Service page and push a button. When OpCon sees that two buttons have been pushed, it knows it can continue with the job. So the employees don't need to call IT. We've programmed OpCon to take over the job when it knows the employees have done their jobs.

We have about 40 schedules on an average day and, within some of those schedules, multiple jobs are done. When we moved to our new core banking system, we had to do everything manually. Once we put OpCon in place, it took over doing close to all of that; about 99 percent.

We continue to look for things that OpCon can do. There might be a scenario where an accounting clerk has to download a file and open it up and put files in certain places. When we find something like that, we see if we can work through the process and let OpCon do it for them, or do part of the job for them. I know there are still things out there that can be automated.

OpCon has definitely freed up some employees to do more meaningful work as a result of automation. During our first month on our core banking system, because I was responsible for that system, I or my systems administrator pretty much spent all day manually downloading files, running batch jobs, uploading files, processing things, and moving them to archives. That was good because it was a new system. Neither of us had done those kinds of tasks. So we now understand what's involved. When it came time to program OpCon, we knew exactly what we wanted done. It was very nice to move those jobs to OpCon, one-by-one, and free up our time to go back to our regular work.

We're a small organization, there are only 35 of us. OpCon freed up three people in IT and probably the equivalent of another FTE. Someone else had to deal with getting files from the Federal Reserve and sending files and they don't have to do that anymore. OpCon does it. We're now free to work on other projects or other problems. The things that OpCon does, they're routine; it's the same thing day in and out. Go to this credit card processor and get a file, bring it over here, upload it here, run a batch job, and send out an email. It gets very boring doing that every day. There's more interesting work we can do.

We also have some jobs that take a lot of network bandwidth and we use OpCon to schedule them to run at two in the morning and they're done by four. That way, people aren't affected during the day, so we've made better use of our bandwidth.

Finally, we're in Oregon, so about once a year we might have snow to the point that they shut the city down. My SA or I can remote into the credit union and check on OpCon and make sure that all the jobs are running. We have a couple of managers who can remote in and do their pieces and push the OpCon buttons to tell OpCon to finish up the job. In the past, we had to have at least two people come into the organization to process ACH or payrolls, etc. Now, we have the ability to work remotely if necessary.

The most valuable feature is being able to schedule tasks so that they reliably occur each day, each week, each month, or sometimes several times a day. We are a financial institution so we need to have our core banking system up to date. We also want to make sure that the work gets done. For example, we use it for ACH deposits and payments. So if you are depending on your paycheck to be there on a certain day of the month, OpCon makes sure it's done. The scheduler works as it should.

It is a complex product to use. Programming the schedules is complex. It does require training from OpCon. As an example, I went away for a week of training. The week after I came back from that, OpCon was onsite to set up our initial schedules. At that point, my systems administrator really took over. I should have sent him to the class, but it was good for me to learn the basics. A year later, my SA ended up going to an advanced class.

I haven't been on their website in a while, but I would like to see some online training, some videos. When I bring in a new employee — as an example, my helpdesk person is going to be moving into some network tasks, and she'll be working within OpCon down the road — it would be nice if there was some basic information for her to look at to understand this program. Even for my systems administrator, it would be helpful if there were tips and tricks available. We're always looking for more learning and more education on how we make the most out of this product. Whether it's online videos or periodic webinars that are accessible online at a later time if necessary, that would be great.

The only thing that OpCon cannot do is the following. OpCon runs a batch job on our core system that creates a file. That file needs to go to a third-party vendor. The only way to get it to that vendor is through their website which has a secure login. OpCon cannot log into a website. It only uses secure FTP. So every Wednesday morning, one of my employees has to take that file and manually log in to the website and upload it. We're waiting for that third-party company to come up with an SFTP solution. Once they do that, then things will be completely automated. I don't know how complex it would be for OpCon to log into a website, but pretty much everyone uses SFTP for file transfers these days.

We have been using OpCon for a little over three years.

It's a very stable product.

The only time we have to be careful of is if we have an extended power outage. We've learned that we have to bring our SQL database server up before we bring OpCon online. That's true for several other systems that we run. But otherwise, OpCon tends to work as expected.

I'm sure there's a lot of scalability, but as a small organization, we're using it as much as we can. We've not experienced any problems. 

Our company has about $130 million in assets. I know credit unions that are billion-dollar companies and they use OpCon. So I have no concerns, as we grow, that it will continue to meet our needs.

The support is good. When we run into issues, we can rely on SMA to walk us through how to correct any problems or do something in a more efficient way.

We did not have a previous solution. One of my requirements, when we decided to go with our new core banking system, was that I did not want to spend my time doing these routine jobs and tasks every day. So I went out to my colleagues at other credit unions and asked them how they were managing these things. Everyone said, "You must have OpCon." I researched a little on OpCon. Our core banking platform, Corelation Keystone, put me in touch with the OpCon salesperson. They did a demo for me and I was immediately sold.

Because we had an expert here from SMA, it was somewhat straightforward. He knew what he was doing and we had confidence in him. We didn't have any problems that I recall.

We started automating our first process on the second day of the deployment. We created some schedules and jobs that ran so that we could make sure that they worked.

An example is End-of-Day. That is a program that's done on the core banking system at the end of the day and it closes out a lot of information for accounting purposes and so forth, and then sets the date to the next day. For example, certain accounts might need dividends applied to them or loan interest charged on loans. Late notices and certificate notices need to be prepared. If it's the end of the month, there may be a statement file that goes to another vendor. We need to make sure that End-of-Day is successful. We could see the next day that yes, it was. We immediately kicked in and started getting things done.

After the OpCon person left, my systems administrator started to create new job schedules for some of the other processes that we did. One-by-one, we started moving our manual processes over to Keystone until they were all done.

OpCon assisted us in our initial setup. They were here for three for four days. That's how long it took us to deploy the solution.

OpCon is expensive for us as a small organization, but on the other hand, it's a lot less expensive than hiring another full-time employee.

We pay for licensing annually, including the Self Service module, a connector license to our Corelation Keystone banking platform, and for a license for each server that it's on. A lot of these are rolled up into one, but the initial implementation was a chunk of money. Now, we just pay annual maintenance.

I did not look into other products. The recommendation for OpCon came from most of my colleagues in my industry working at other credit unions. I did not find another solution. Everyone used OpCon, and everyone really liked it and highly recommended it. So it was an easy decision. 

And SMA has a good working relationship with Corelation. They worked with Corelation to write unique jobs that run in OpCon for credit unions. That was also a very good selling point.

The biggest lesson I have learned from using OpCon is that you really need an individual like my systems administrator who understands how a program like this works. Creating these schedules and working with the language that's required to get things done is very specialized. You have to have someone like that. Could I do it? I could, but it would take me 10 times the amount of time that it takes Sean. You do need someone on staff who understands systems, system deployment, systems operations. That's how you're able to make the most of it. The programming side of it is very basic. It's not that complex. But you have to understand how to tell it what you want to do.

Our primary user is our systems administrator; he programs everything in OpCon. I can access it when he goes on vacation and make sure that all of the jobs are working fine. At times there might be a job that failed. For example, a person is supposed to prepare a file from a third-party vendor but if they don't rename it appropriately, OpCon doesn't know what to do with it. Another example is that one of our third-party vendors will send us a file that is incorrectly prepared. OpCon won't process it. It will catch the problem and then we have to reach out to the vendor and ask for a new file. OpCon allows me to catch any mistakes that a human being makes.

We have two people using OpCon. Sean programs it and has overall responsibility for it, including deployment and maintenance. I fill in when he's not here. Luckily there aren't too many issues. I'm going to get my third IT employee involved with it more next year, to do what I do. And 10 or 12 other employees each have access to their department's site in the Self Service program. So if they're responsible for looking at the bounced-check file or ACH exceptions or paper payroll that we receive from small companies, they can do their work and push their button and that allows OpCon to finish the job.

We've been very happy with it. We're always looking for ways to use it more. We ask, "Could OpCon do that?"

I am always careful about giving someone a 10, because there's always room for improvement. But I hate to give OpCon a nine. I give them a 10.

We use OpCon for scheduling batch jobs on the Unisys mainframe. It controls all of the batch work. Therefore, if we want to rerun a job or add a new job in, It is used for controlling this Unisys batch work.

It allows batch work to run as smoothly and efficiently as possible.

If we are talking about a one-off job, it takes roughly five minutes to set that up, which is very quick.

Results are pretty much instantaneous. It depends what frequency you put on the job. It could be a job that will not run for another couple of hours. But, if you set up a job and want it to run straightaway, it will do it straightaway.

OpCon has streamlined operations. 

Going back 20 odd years ago, everything used to be controlled manually before. Now, it's just a flow of jobs. You kick one off, then there are just dependencies, one after the other. These jobs just follow those dependencies and do it all automatically, instead of somebody having to sit there and do it manually.

From when it was first deployed, the solution freed up around 100 or so employees to do more meaningful work as a result of the automation.

It reduced data processing times when it was first deployed. Back then, it probably saved a good six or seven hours on a daily basis. The amount time has shrunk since then, but that is not due to OpCon. It is more due to reduced processing times on the Unisys mainframe.

It is very simple and easy to use, but that might be because I've been using it for a long time.

The things that we use most often are:

• NIST view
• Job Master
• The quick search option.

The way to view a schedule is called perch view, and that's not always the greatest. It can be quite slow.

Any issues we did have with earlier releases have since been addressed in later releases.

We are looking at something called Solution Manager which comes with it, because we don't use that currently. This shows more performance and is an easier way to access them. You can also set trends and do more analyzing.

I have been using it for 12 to 13 years.

The company has probably had it for about 20 years.

The stability is very good. We don't ever seem to have any issues or major problems with OpCon. It's always been quite good.

We have currently been looking to upgrade to version 19. So, we are testing that.

The scalability is quite good. The amount that we have on it doesn't ever cause any issues. I am not too sure how much more it could cope with, but I imagine it's a lot more.

We have approximately 50 scheduled jobs running various different processes. It varies between 20 and 100. Because it's a big organization, these automated process are not a massive part of the organization: Approximately 15 to 20 percent. I don't see this figure going up since a lot of stuff tends to be moving into cloud-based stuff.

Our use of OpCon needs improvement because I don't think we use it to its full capabilities.

There is a team of us who do the maintenance. There are mainly three people on the team with another hundred other people using it for view only purposes, such as viewing data results and what times certain jobs finish. They don't have access to make any amendments.

The technical support is very good. I think we have a designated person who we contact if we ever have any sort of issues, etc. Their response time is fairly quick (within 24 hours).

The initial setup is pretty straightforward. They give you some good user guides and information on how to do it.

If we are upgrading, it probably takes about two to three hours. We start the automation process within this two to three hour time slot. It is pretty quick.

When deploying a new version, we have to do a lot of testing. We have DR boxes which we do our testing on first. That's what we're currently doing it at the moment. Then, we have to run it through our change management to make sure all of the various other areas in the department are happy.

SMA is pretty helpful, if we do ever have any questions. They are pretty quick to respond.

For upgrades, three or four are required. There are three of us on our side involved in upgrading it. Then, there is one person from SMA to help, if need be.

Compared to other solutions that we have in the organization, OpCon is a lot quicker to deploy. For example, Control-M takes almost double the time to deploy.

We use OpCon for Unisys and Control M for more server-based jobs.

it's definitely an application worth considering and looking into. It is a pretty good tool. I don't really have too many issues with it.

My biggest lesson since using it has been to learn how to upgrade it. This is part of the process, as I've gone from the scheduling side of it, where no one else scheduled jobs to the next step of learning how to upgrade it.

I would rate it an eight (out of 10). The product is always available and easy to use. I like the overall general feel and view of it.

It is designed to schedule jobs everyday. We now have 750 automated processes.

Primarily, we use it for everyday jobs spread out among all our IT. Apart from all the benefits that we have from OpCon, the biggest advantage is having a centralized point to check everything happening under IT. Mostly, it is for scheduled tasks, not manual tasks.

A year ago, we had an issue with our financial software and another software. While the two tools were still working together, we were not able to find a solution to manage night jobs without OpCon. We found a definitive solution because we have jobs running during the night. Without OpCon, we would have not been able to make all our jobs work. After five years, it's hard to remember what OpCon wrote because it has changed our everyday jobs. 

The solution has streamlined a lot of our operations. Seven years ago, our everyday tasks were manual with their scripts. After four or five years, this was not so really reliable. The way OpCon is built, it has helped us to improve our scripts, making them more reliable and precise. It was easier for us to assure our colleagues that everything is working. Our everyday view is more precise now. We know precisely what is running and what will be running for our IT. OpCon helps for when we have to manage a shutdown for our systems, which happens once a year, by improving the way we prepare for our shutdowns.

When we have a problem with a job or something else, I always tell my colleagues, "It's not OpCon, it has to be something else." All the time, it is something else. So, we are very pleased with OpCon and how it works. It is really reliable. For us, that is a major point: reliability. 

We are also very pleased with its reports for jobs every day. We don't use monthly or weekly reports. Though there are some requests in the tool for these, we don't use them a lot. To follow our everyday jobs, it's perfect.

The web version has room for improvement. I am still waiting for full web administration in OpCon. While the web part is not the tool that I use every day. My colleagues use the web version, which is great because it is much easier to give them access to OpCon. They can check their jobs way more easily. Overall, the administration of the website could be better, but for everyday life, it's great.

It was hard to automate in the beginning because there were a lot of concepts. I had to learn a lot of things, as I never used such a software before.I learned a lot of the concepts and ideas behind it in the beginning. Now, I find it much easier to create jobs and schedules. I can manage it. I helped other people internally to get access to OpCon after five years of not really having problems with the tool.

We started using it five years ago.

OpCon is really reliable. We take a lot of value from OpCon. It has improved our everyday jobs by a lot.

There are two people needed for OpCon's maintenance because we want a full backup when one of us is not in the office.

We don't scale because we have just one server. We use it with virtual servers, so we have full backup of our database. Because we can miss jobs and it is not a big problem for us, we don't really need a backup server for OpCon.

There are two people working right now on everyday jobs with OpCon. Five of our colleagues use OpCon to check all the jobs being worked on. They check the logs to see if there is something wrong. We have two people assigned for the scheduler, five for everyday operations, and around 20 people who check the jobs to ensure that they work during the night. They are just looking for reason codes or through the logs. They don't do anything apart from making warnings around possible problems. If it's a big problem, it come backs to my colleague or me to correct.

All the people using the solution are part of the IT team.

I have been pleased with the support that we can get from the European partners. I think they are very good. All the time, when we have a question, they have an answer. It is very reassuring to have that support every day. Then, you can concentrate on your job and OpCon is just there to work. For us, it's perfect. 

It was used to replace chrome.tabs or Windows Task Scheduler.

The initial setup was a bit complex, but we had great support which helped a lot. I made a lost of mistakes in the beginning, so I learned the hard way. But now, I think I manage OpCon quite well. We aren't make beginner's mistakes now. OpCon used to be quite difficult but there was a lot to learn.

All the ideas and concepts behind the solution can be difficult to understand. E.g., I hadn't used a scheduler before. This was the first time. But, we had a lot of help, so it was okay. I tried to learn it myself using trial and error. This was quite a good way to learn and understand how it works.

The full deployment was around one year because I didn't want to move everything since nothing would have worked afterward. So, we took our time and did our mistakes, which was really important. After one year, we were fully operational. Our IT moved during that time, so some jobs needed to be canceled or removed and new software needed to be included in OpCon. By the time we had OpCon, all the new jobs were included. We talked with software editors and told them we had a scheduler to run jobs daily.

Every new software is included in OpCon, so it just works. All my colleagues know it's there and rely on it.

Our initial implementation strategy was to start big, but we went slowly. We took the biggest server that includes our biggest data and started to process those jobs. We took time to look at whether the solution was working and to correct our mistakes. After one month, the server was fully integrated with OpCon. We had monthly schedules, so we had to wait for one month to have everything run. So, it took one month for our first big steps.

After that, it was easy to incorporate all other tasks and jobs. Most of the time, it just took time because we had to rewrite the scripts behind the jobs. In the beginning, OpCon worked, but the scripts had to be improved. Therefore, we took time to rewrite them, making them more reliable and able to work with OpCon's written codes. We made great efforts to use the same way to write our scripts. Thus, it took time, not only for the jobs, but for the scripts behind it.

The first day that OpCon was working we had our first job working on it.

I'm very pleased with the people who came onsite to install the product the first and second times. We waited almost five years to move to the version that we have now. The people who came to help us with the installation were very helpful and precise. They added a huge value.

As a regional organization, we don't keep track of ROI.

Our license is for 1000 jobs. Including support, the license and upgrades are 2000 euros a month.

I think we had contact with Parallel Universe and two other products. This was six years ago. We took around six or seven months to make our choice. What was important in our choice was being able to have a contact with people who are working in the exact area as us. So, we were able to go and watch what OpCon did for them, which was very good and important for our choice.

We were convinced by the product to choose it, but we were able to go and see what a client was doing. They confirmed what people from OpCon told us, which was great. Every company can say, "Our support is great. Our product is great." Everybody will say that. However, when a customer says it, then it's way more important.

Our original requirements were what OpCon can do. We don't have big systems. We have only Windows, Microsoft software, and a couple of Linux systems at the time. Now, we have more Linux. We wanted a scheduler that could be moved to a platform, and OpCon was able to do that. We wanted something that was reliable with good support, and I think we found it.

If you are looking into implementing OpCon, go for it.

Scheduling is a proper job. You have to learn a lot.

I would rate OpCon as a nine (out of 10). 

We started using the OpCon product with a contract management application doing migration between Dollar Universe and the OpCon solution. The first time we used the OpCon product for scheduling programs we had around 7,000 jobs running on this application. Today, we have around 41,000 jobs per day. We have around 4,000 host computers in production and we have 618 applications running on the solution.

We have migrated about 90 percent of our information systems to OpCon. We have to finish the project and finalize the migration for the remaining 10 percent or less.

OpCon has streamlined our operations. With OpCon, we have reduced the number of jobs by about 17 percent and we have execution times running on a schedule. It's a good way for optimizing and automating the scheduling of our programs.

One of the advantages of OpCon is the ability to use the API and web services. We couldn't do that with our previous solution. We have been able to change our procedure for ticketing. When a job is down, we can immediately create a ticket from OpCon in our ticketing solution, which is ServiceNow, using the web services.

One of the valuable features is that we are able to automatically manage problems with jobs. The system automatically tries to restart jobs when things go down. That's a good way for us to quickly manage and resolve all problems automatically, without creating tickets.

It is really different than the product we used before, Dollar Universe. The interface of OpCon is really modern and fluid and simple to use. It's really a framework for the user who doesn't see all the complexity behind the product. We have a lot of functionality with the product that we didn't have before. All our users find it simple to use and, after working with it a few times, it does not take them long to know how to use it. We've had no difficulties using the product.

And the web solution, Solution Manager, enables easy access to the application to quickly see if we have problems with our programs. Immediately, with its color code, we know if all is okay or if we have a problem. The web interface is really simple to use and we can put it on a screen on our desks and look. It's really useful for us. When we click on the screen we can immediately see which job is the problem that we have to analyze or restart. It's really easy to identify that and to restart or go quickly to the problem, without having to find or analyze where the problem is. It's efficient for us.

I would like to see them improve the Solution Manager for the web application. It's the future for us. Our customers need a lot of functionality, but there isn't that functionality within Solution Manager. So they have to develop and improve it.

The visualization module needs to be more open for parameters, such as the color of the job status information. For example, when a job is canceled, the color on the visualization module appears as orange and we can't change that color with a parameter. We can't decide, for example, to display the jobs that were canceled in green. I'm expecting from SMA that they will create parameters and give us the opportunity to choose the colors we want for job statuses.

We've been using it for two years.

We didn't have any problems for the first few weeks. When we got to a big volume of jobs, we started to have some response delay. We called SMA's French support and U.S. support to analyze our problem. SMA's solution was that there was a difficulty with the large history. We hadn't deleted and had too many days in history. We had to purge some history and close some days. Today, we do that regularly and it's okay for us now. We have a good response time from the product.

Whenever we upgrade the solution we have support to help us, and we have never had great difficulty in upgrading the system. It is not a difficulty for us today. 

We have not hit the limits of the product. We have a lot of new projects starting on OpCon to develop new scheduling programs. We don't use OpCon for only part of our information system. We use OpCon for our entire information system. OpCon is used for all our scheduling jobs.

A really big change for us was that SMA has French support in Europe. That's a big advantage for us because we are not all fluent in English. And they are open night and day. Whenever we call, we always get support. Support is really good.

One of the good things we have found with SMA is that we have a partnership. They really help us and we are working with them. We really want to optimize the product and give them suggestions for new functionality that we need. We help them to develop it and to optimize the product. They work interactively with us and are quick to develop the functionality for developing our business.

We used Dollar Universe.

The initial setup is really easy. Installing the product is not really difficult.

For all our infrastructure development, integration, pre-production, production, training — for the whole environment — it took about six months, including specifying all the parameters and starting the product, doing the pilot migration, testing the application after migration, and moving it to production. The first migration started immediately after we finished configuring the product.

We had a contract with SMA for support and to help us do the first migration of the pilot application, which was contract management. After we finished configuring the product's parameters, testing the product, and doing the migration on this pilot application, we managed the migrations alone, with SMA's support if we had difficulties doing something or needed help to optimize the product.

We have seen ROI. In the first year, we paid less than the previous solution and, with OpCon, we have reduced the number of incidents and we have an improved quality of service for our customers.

There is also less cost for our teams to analyze and deal with program scheduling. We haven't needed more people to explore the solution. We can have fewer people and do other things. We can invest in projects and not just in running activities.

It costs less than our previous solution, Dollar Universe. We pay annual maintenance but we don't pay anything additional until we hit a certain number of jobs per day.

In 2016 we started to analyze different solutions in the marketplace. We had meetings with vendors of a lot of solutions, with demonstrations, and we evaluated every product. At the end of the analysis, we chose three solutions. We then met with customers using those solutions. Only then did we choose the SMA solution. It's a more complete solution for us and more open and scalable for our needs.

We evaluated the IBM solution, the Automic solution, a French product, and so on. There were other solutions too, but those were the main solutions we analyzed.

Start with a lot of training and develop a good familiarity with the functionality of the product. Do that before starting development on OpCon. Normalize the codification of the schedule of the jobs. Write that clearly and define the rules to develop the objects before starting with OpCon. That is very important because if you start to develop immediately in the product, without doing that phase of analysis and normalization of the codes, you will have difficulties.

We have a team of about 10 people whose job it is to create the scheduling programs. And we have another five external people to reinforce that team. For everyday exportation of the project and all our schedules, we have about 16 people. They schedule jobs and analyze issues or responses from our clients for building jobs.

The solution is for our core system processing, which runs our scheduled programs. We are a financial institution, so it does our postings, reporting, nightly processes, and file transfers for anything which needs to go in and out of the core going to designated places. OpCon now does any type of repetitious work that we would have an operator do.

I have it implemented in our accounting and card departments for their processes, our payment systems, and HR for the onboarding/offboarding of employees. We also have it in IT.

It improved our consistency on how batch jobs are run and their schedule. It used to be left up to me or another operator to do the postings of these jobs. They were not always done on time. If it was supposed to be done at 8:00, then it'd be done at 8:10 or 8:15. Now, 8:00 is 8:00. Jobs are more efficient, and with the schedule, there is no variation on the time. These things will be run.

The other part is some of these jobs have prompts in them. You had to answer those prompts and make sure you were consistent in your answers. If you rely on a person to do it, sometimes those answers are not done correctly. Whereas, with OpCon, it will always be a consistent response to those answers. There is no deviating whatsoever. This reduced the responsibility of another operator who can be moved over to do something else. It went from that person doing the job to monitoring what is going on in OpCon. It also has expanded their job responsibilities to other things that need to be done.

The solution has streamlined operations. E.g., we have at least 20 different jobs in our nightly process. These have been streamlined within OpCon using one master job that does each one of those different batch jobs for us.

It has freed up my time because the other operator and I use to tag team. It also helps because I don't have to come in for month-end or nighttime processing. We don't need a nighttime operator, which is nice.

You can sleep in and get notifications if something fails, which was a nice part of it. If something is processing, and you want to make sure that it processes okay, this is probably one of the best things about the scheduling and automation of the solution. It does free up your employees to do other things. You no longer have to worry about them missing a step or not posting on time.

It gives me more time to program. For others, they now work on other things that we have in our IT department. This goes to some of the networking things that we have going on, help desk situations, and looking at what is the latest and greatest in things out there that we can dive into in terms of home banking products, e.g., if we can add things to those features.

Being able to copy what we already have, then apply it to another task is one of the cool features. It saves time. When I know there is another new process coming up, I can copy an existing one and just change a couple of things in it that need to be changed for it to run the new job process. The nice part about the copy part is I don't have to go back and look at what I had to call it, put in those settings, etc. I already know what those settings are, which is great. I just need to tell it the new job has to run, then schedule a time, and if there is a different time for it.

I am getting into the self-service part of it, which means I can then assign users to kick off odd processes which are not on a true set schedule. They can pretty much initiate it themselves. That is one of the features that I really like. 

I like the notifications of when jobs have completed or failed. This is a big plus because you can either have an email or email and text sent to you. That is very helpful.

There is some difficulty with the ease of use when I don't have some of the templates that were already created. I know they have to make general templates across the board for everyone to use with different types of systems, but it is good to have the templates done. Then, the solution becomes very easy to figure out, and I know that I will always use OpCon in this way or in this different scenario, as it will work for me with these usages.

More templates would be great. Non-core featured templates are my biggest struggle. For example, the PowerShell functionality is really cool, so I dove into that a bit where I wrote scripts using PowerShell for our Active Directory.

We have been using it since 2013.

It's a stable solution.

We require one person and a backup for deploying and maintaining the solution.

It's capable of working with other system, which is very good. It is very scalable.

We have about 4,328 daily jobs with 897 daily scheduled. We probably had about a hundred jobs when we first started. We have been adding them here and there as we go along.

We have at least 15 employees using the solution, plus another employee and me.

OpCon has been implemented 100 percent for IT in what we do at our core. For the rest of the departments, this solution is around five to 10 percent of what they do.

Besides our core, we're trying to see if we can branch out to other types of things that can be automated. There is always room for growth. I think we have tapped out on what OpCon can do for our core. It is now what else can it do for us that is not core. That is why we are looking at our HR department and networking stuff, and being able to automate some of the system processes there. E.g., pinging network servers to make sure they are online, up, and available, and also scheduling any type of tasks that they might have.

They are average for technical support. I still have to do my own research on some things.

I have never used an automation system other than Windows Scheduler, which is probably the best way. You go into Windows, restart your computer every day or run updates at this time. Whereas, OpCon gives us more prompts and things to do where you can set up different PCs or servers to do certain things.

I was involved in the initial setup, but that was back in 2013. I was excited at the time, but wasn't sure what I was getting into. The initial setup was complex because it was something I knew I wanted, but didn't know what it was.

When we first set it up, we requested a book of jobs to be done for us. This was like a set standard of batch jobs that would need to be automated. I have been able to elaborate and expand on those.

It took us a week after deployment of OpCon to automate our first process.

Our implementation strategy was to first start simple, then go into our complex processes. 

Simple for us would be running a batch job that has maximum three or four prompts in it. Then, we go complex with the RACH process, where we receive files, process those files, and schedule times for them to post. Then, we run intermittent jobs in-between to produce a return file that goes back out. 

We had an onsite person come for a week from SMA. Our overall experience was great. He was a nice guy who handheld us through some of the processes, making sure that we were good and explaining everything to us. That was probably the best thing of having him here onsite, and not remotely, because he could see where our questions were stemming from and why we were asking certain things. He then helped us set up the different templates for our processes.

Manual processing has been automated 99 percent by OpCon. With new processes, we give it at least two weeks manual so we can write down the details of how to do the steps, then we automate it. Within a month, it has been automated, then it's no longer a manual process.

It has freed up my time. I don't have to stay late at night. We don't need a nighttime operator, which is one of the biggest things, at least for me. Some places I know, they need to have other employees besides the two basic ones during the day do operations. Now, we don't need an extra person for that. 

It has freed up our time for other things. We get to program a little more.

Our licensing is on a yearly basis.

We did not evaluate other vendors. 

I had seen OpCon a few years ago before at a conference for Coresystems and they were the only ones there. Jump to 2013, I find out that our executives had said, "Yes, we're going to go with them." I was very happy with this.

Have a list of items that they would like to have automated. That way they can sit there, and say, "Yes, I did accomplish what I wanted with the system." Then, what do I want to expand on afterwards? 

The work upfront is great. In the long run, it makes your life a lot easier. You will have to do some work upfront, which is knowing your manual processes, remembering them, and knowing what they are step-by-step. Once this is mapped out, it makes it easier to implement OpCon. You also have a template that tells you where you might have missed a step if something fails within OpCon.

It has made my life very easy. In a way to me, it is an AI. Though, we still have to tell it what to do, it is one step closer.

OpCon is probably about a nine (out of 10). There is always room to grow.

We use it to automate multiple platforms: our mortgage platform, our core platform, and other instances where we're working with third parties to whom we have to move data. It does about 90 percent of our automation. Very rarely do we do anything that's not automated. For example, we do not manually upload anything. It's all done through OpCon.

The biggest improvement is the batch automation. We don't do anything manually anymore; everything is automated. We did have a very highly skilled employee and the job he left for was a job with a bigger credit union to run their OpCon shop. That's how good he became at it. His skill set was at a very high level, where he automated up to 90 percent of what we do. We very rarely have to manually upload.

We've automated about 50 to 60 processes, and that number is growing. We are adding on our mortgage platform to automate that. And that number does not include the OpCon buttons they also use for on-demand stuff.

It has also helped to streamline our operations. We contract out our collection department so they are no longer housed on our system. They're housed on another platform. OpCon is able to not only pull in our data, but it also, on a daily basis, updates that third-party. In addition, if there are any updates coming back, OpCon will check on a daily basis and send it back. That's just a sample of how it automates. 

Another example is how we automate our daily FedLine. The most important job files that we run are our ACH, our Federal postings for credits and debits. We totally automated that where there is no longer any manual intervention. We upload the Fed file; it comes in and OpCon is smart enough to know where to place it and how to run the edits. It's also smart enough to know that there are delay times. Before OpCon, we were posting them the next day, manually, one after the other, because there are four to five that come in and out throughout the day. Because we were able to automate it through OpCon, we can now post them when they actually come in. They are posting throughout the day now. For example, at 12 in the morning there is our major posting, and it's posted right when it should be. Members are actually getting their paychecks or debits and credits right when they should happen. That was a big one which was very member-impactful.

OpCon has also freed up employees to do more meaningful work as a result of automation. They're not having to go into Symitar and run a job. Instead, they can simply run something. They've also found innovative ways to use it as well: "Hey, I have this thing that produces an Excel file. Can OpCon just grab it and send it out to this other vendor for me?" And the answer is, "Sure, that's not a problem." Our employees are thinking outside the box, as far as utilizing it goes. Even though they don't generally know OpCon, they know what it's capable of. In some cases, they're building their own little building blocks of automation themselves.

The main employees who have been freed up are in our accounting, item-processing, and lending departments. In those three departments there are about 15 employees. All depend on OpCon to do something for them. We're not that big of a shop. We have about 100 employees in total.

Our employees expect automation now. Prior to that, it was nice to be able to run something and for them to get their data. It was awesome. Now, as they know that it's a standard process, they're not as excited. They just expect it now. If you would tell them: "Oh, no, you have to manually move this from here to there," they would probably come back and say "Wait a minute, my other thing is automated. Why can't this be?"

If we're counting all the manual intervention, as a percentage, I would say that OpCon has reduced data processing by 90 percent, through automation, the efficiency, and the eliminating of manual errors.

There are a lot of areas that are valuable. Perhaps the most valuable would be the OpCon button that users can select so that instead of having users going into Symitar, they can now just run an OpCon button that works on-demand. That's probably the one that has made the biggest impact. We no longer have users running job processes in Symitar. Everything that they need, we simply have them run on-demand, so there's no access into Symitar. That is one of the most valuable tools we have. Obviously, the batch-automation is a big one, but that button functionality would be the biggest feature.

Usage is a little complex. It's not like you can bring somebody in and they can just use it. They have to be trained. Our main OpCon person left and it's a lot harder for a lot of people. Once you have somebody leave, the next person has to step up and it is a little difficult. As far as complexity goes, it's right up there.

Once you get to know the platform, you do know how to troubleshoot. But there's just so much to learn. If you are properly trained, it is fairly easy to figure out problems and troubleshoot. SMA does offer certification and they also offer consulting hours, which we are using right now.

There is always a percentage of jobs where the batch automation doesn't work or something critical happens within the OpCon server that causes something to stall, and we have to troubleshoot.

Another area for improvement is within the notification and alerts. I'd like to see it get smarter with script-writing within OpCon to make it do more. There is some room for improvement there and that's why we got the consulting hours.

We've been using OpCon for the last five years.

The stability, on a scale of one to 10, is about a seven. We are having some issues with logs. We did reach out to OpCon, but they didn't have a solution for that, so we're having to manually handle that on a daily basis. That was a little disappointing. I'm hoping that one day they will have a list-serve where we can reach out to other OpCon shops. That way, we can reach out to other OpCon users who have a high level of OpCon skills and say, "Hey, we ran into this problem. How did you guys figure your way out of it?"

It's pretty scalable. It can go virtual. They have a lot of options. Right now we are on-prem, but we would definitely look at going off-prem and having it hosted in the future. That's what we'd like, and they do offer that capability. They also offer managed services, which is something we're going to target in the near future, simply because we're a small shop. so they do offer a variety of things that we could definitely take advantage of.

We only have one user using OpCon because the main one left. She is training our other two who are brand-new; they are literally brand-new, even to IT. We are very shorthanded right now. That is why we bought the consulting hours, so that we could get these other two up to speed.

Similarly, only one person is doing maintenance of the solution, which is why we're going to contemplate shifting over to OpCon's managed services. That kind of solution is probably a perfect remedy for a shop like ours. I wouldn't be surprised if, this time next year, we're not even managing it and that they are.

When we had the log problems they weren't very helpful on that. It felt that it wasn't a very helpful solution. From eight to five, they will help. They have some really good people. But if there are really complex problems like the logs, it feels like the front-line support doesn't know, or at least didn't on that one occasion. Thankfully, our network guys figured out the problem. Otherwise, we would have been out of luck. I'd rate technical support at six out of 10.

We didn't have a previous solution. We were doing things manually.

I didn't participate in the setup, but I believe that it was straightforward. OpCon came onsite for training and it seems that soon after my staff got the training they took the ball and ran with it. They got the building blocks in the training and, after that, they caught on fairly well and were able to start automating a lot of the manual processes, one by one.

For the implementation, we had to load the server and we had to have a backup for that OpCon server, which goes out to our Branson site. Any changes to OpCon get passed on. But when OpCon come onsite, they pretty much got everything loaded for us. We were paying them to do that, which is what I would recommend to anybody. It helped us, a company that was brand-new to it, to bring us into it. When they were onsite they handled 90 percent of it.

It wasn't long after the deployment that we automated the first process. Within a week we were already automating some things that we had been manually moving over. And then we road-mapped big ones like the ACH stuff that I mentioned elsewhere. One of our first projects was automating our ACH to the Feds. We had an idea of what we wanted to do once it was implemented.

We have definitely seen a return on investment. The big return on investment was the fact that we lost three OpCon people from our staff and nobody even knew that we had. We went on without skipping a beat. We literally had the worst-case scenario that can happen to an IT staff and we came out smelling like a rose. Everything ran and we were able to continue with a small staff and we did not have to worry about our batch automation.

Yearly, it's around $30,000.

We bought consulting hours for a year at an additional cost. We're getting 85 hours a year for consulting to help us through, for example, with a complex process that we want to get done. Some of those hours might be spent for them to actually come onsite and give one-on-one training to some new people being introduced to OpCon.

We looked at two other vendors. It's been a long time so I don't remember their names. They were enticing because they were definitely a lot lower in cost, but ultimately OpCon had more of a service to provide. OpCon offered more services and more automation. It was a no-brainer after we learned that.

Do your homework. Definitely look at other vendors and consider your staff size. In our case, because we have a small staff, we don't have a lot of programmers. We don't have the luxury of having 10 programmers who can write their own batch scripts. If you're a small shop like us, really do your homework on it because, in the end, if you rely on somebody writing batch scripts to do things and they ultimately leave, you own that. You really need to make sure about your road-mapping. Are your employees going to stay at the credit union? If they are, that that makes a big difference. 

What happened to us was that we lost two valuable OpCon employees within a span of two months who knew how to solve OpCon problems. The third person, who was average but knew it, went down with an ankle injury for a month-and-a-half. We had nobody who knew OpCon for almost two months. The only thing that saved us was that the process was so automated that we didn't have a problem, thank goodness. Everything just ran and we never had an issue.

You have to know your staff; you have to know whether they're content. Are they going to be staying? If you know they're going to leave, you better plan ahead. You don't want to get caught like we did.

But our situation tells you how well OpCon is programmed.

The biggest lesson I have learned from using OpCon is that we have to stay on top of the releases. Every year there are software releases that you have to get done. They are key. But there are also updates, SLAs that come out. We definitely try to keep on top of that because our batch automation is a critical platform. So it's critical that we make sure that everything is up to date. The SQL portion of that is also important. We also use third-party FTP software and that is another thing that we've got to make sure is up to date. It's a definitely a solution with moving parts.

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.