What is your primary use case for OpCon?

In this credit union, we use OpCon for automation. That is the main use of it. We have over 3,000 jobs and schedules that process certain procedures that we have. These procedures touch our core system and other systems that integrate with it. The biggest example is for our credit union ACH processing. We use OpCon to make sure that files are moved over automatically. We also use OpCon to connect with the Axway system, which is an application that the Fed uses to make sure that those files get over to them and are processed correctly. If there are any returns, we get those files back from the Fed through Axway, and OpCon helps us with that automation. So, we use OpCon very heavily here. We have over 3,000 processes. We do a lot here. We use our OpCon system to help us with our month-end processes. We make sure that our core system process gets automated in terms of a backup taking place, and then our month-end procedures happen. We make sure that there is an end-of-day procedure and postings and so forth to get us over.

We use OpCon to automate daily operational jobs. We implemented OpCon to remove risks associated with manual processes and improve efficiencies to reduce the time for those operational jobs to complete.

We use OpCon to automate tasks like moving files around, starting jobs on our mainframe, alerts, etc.

We initially used it for core job scheduling, but our focus shifted to managing file movements with vendors through FTP as tasks were outsourced. It now functions as a comprehensive server monitoring tool, overseeing file transfers, scheduling jobs based on received files and managing dependencies. OpCon facilitates efficient updating of our internal database with vendor files and plays a vital role in failure notifications, job holds during issues, and alerts via email or text. Currently, we handle around twelve hundred unique jobs, resulting in sixty to seventy thousand job runs monthly.

The primary reason behind implementing it was its integration with our new core banking system, serving as the designated task scheduler. Our core system lacked this capability inherently, leading the core vendor to incorporate OpCon to address this gap. Initially introduced as part of the package to fulfill the role of a task scheduler, we subsequently embraced and significantly expanded its usage. It is now an integral component of our operations, seamlessly integrated into our core banking system. Its implementation coincided with our core banking system upgrade, and since then, it has been instrumental in managing a myriad of daily routines and schedules. Beyond its role in executing numerous jobs critical to our core operations, we leverage OpCon for broader infrastructure automation. Whether it's handling routine maintenance, conducting audits, or generating reports, the versatility of OpCon enables us to efficiently run thousands of diverse tasks across our organization.

I use OpCon to automate processes in a financial institution.

I use it to monitor long-time events.

We are using it to schedule work across different platforms, including Windows, Linux, and z/OS.

We automate everything we can with our core banking software, including daily and nightly processing and any other recurring IT jobs that can be automated. A lot of our employees access OpCon via its self-service feature. We're a financial institution, so various business units use it, including some people in our mortgage or insurance department. It's mostly used to start processes or run reports on demand and that sort of thing. It's a set-it-and-forget-it solution.

The primary use case for us is automation. This platform has the ability to automate tasks between different operating systems (AIX, Linux, Windows, Apple). We use the products to automate tasks that interact with the Federal Reserve Bank, downloading files to be processed into our core banking solution, which is in an AIX-based environment. The system will also move human-readable report files to a Windows-based server, for reporting and historical-based purposes. The Self-Service Solution Manager allows users to initiate a task after other criteria are met even when that criteria cannot be determined by the automation system.

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.

We primarily use OpCon to manage daily activities, generate reports, and handle FTP jobs for our full-service credit union.

We run thousands of processes/jobs on z/OS (mainframe), Unix/Linux, and Windows. In many cases, these processes have cross-platform dependencies. We also have two separate OpCon databases - one for production and one for development. This is the usual case of implementing and testing new jobs/schedules in development prior to promoting them to production. We literally run our business on OpCon and as such OpCon needs to be, and is a 24/7 enterprise scheduling system. It cannot be down. Thus far, we have found it to be very resilient.

We host OpCon on a virtual server onsite. We do not replicate to a backup database. There are some other redundancies built-in, but we just have a single production server. Working at a credit union, it does all of our back-office processing. We have a smallish IT staff and we wanted to relieve the IT staff from having to do the daily manual processes that were in place at the time. OpCon handles all of our automated loads, uploads, and integration with our core financial application. We have expanded it to use their self-service options so that users may generate reports on the fly, or they might have manual steps along the way in their process. It allows them to check the results, review, work any exceptions and then continue the process just by clicking a button. They really like that part. It also has given us the opportunity to allow users that don't have access to the core to generate reports from the core and have it usually placed in a network share for them or emailed to them.

We have OpCon in our test environment, we're testing that right now and putting it into production next month. Our primary use cases are for our core system that does batch processing for our core system, which is Symitar. We have automated about 90% of our daily processing. And we have started to branch out to utilize it more for Self Service where our other business units can automate some of their processing as well.

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

We use it a lot for file transfers from SFTP sites down to our network folders, and we also use it for other kicking off processes in our core platforms. We also run some PowerShell scripting through it. It does quite a bit. We're looking at eventually using it for some Active Directory pieces, but we haven't gotten there yet.

We have a very small IT shop. I have two helpdesk people, three programmers, and an assistant director. We were running all of our jobs manually. I had a nighttime person and a daytime person in the operations area, and we started getting into more integrations and it was taking a lot of time away from staff to upload data to other vendors. We also use it for resource monitoring when we are waiting for files to come in from other departments. As soon as they come in, we pick them up and process them and that's been a lifesaver, as well, for both the user department and for our department. We also use it to monitor emails. We have the dependency with the Unisys MCP product and two Windows boxes that we have the agent on. So it's for multi-platform dependencies. We're trying to use it to the hilt and get as much bang for the buck from it as we can.

We use OpCon to run a multi-institution environment. It allows us to keep tabs on all our customers at the same time. It's convenient in that way. If anything fails, we don't have to have our operations staff log into a credit union, or a specific institution, to find out what is going on. OpCon will tell us what is going on in each one. Therefore, our operators are free to continue on with their manual work and not worry about what is supposed to be automated. They only look into an institution when something fails. An operator can't monitor 10 screens at the same time and see everything that is going on. OpCon allows us not to need to do that. We are using OpCon's service off the cloud (SaaS).

We use OpCon for scheduling production tasks in many kinds of environments. The main ones are located on i5 i-series, OS/400. But we also use it in our Windows environment and on SAP. It handles around 10,000 jobs a day for us. A lot of the jobs that are now in OpCon were already automated, but they were on other platforms and systems. For example, the world production batch that is running on OS/400 was automated on OS/400, with OS/400 programs. We moved the automation of the system to OpCon. We improved some of the parts, but we kept the main core of the production plan.

We manage all the tasks run on the IBM.

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

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.

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.

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.

We are using it for automating our core processing system. Probably 65 to 70 percent of our operations have been automated by OpCon. It currently runs all of our primary operations throughout the day, as far as we schedule everything through it. Our plan is to continue to automate the remainder of our processes, which are not automated, so we can get as much automated as possible.

Our primary use case is file movement.

We use it for batch job automation and batch processing automation.

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.

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

Primarily, it is used for automation of our daily processing with our core system, Symitar. There are the jobs that we run every day. We also have weekly and monthly jobs setup. These jobs have to do with different departments or reports run on specific days of the week or month. We process all of our ACHs and shared draft or check processing in OpCon. Also, VISA credit card processing is all done through OpCon. We are running anywhere between 400 to 500 jobs a day, on average.

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.

We use OpCon for job automation for our core financial software. The majority of it is pushing files between vendors and our core, for processing, marketing mailers, and reports. We also have their Self Service software, so employees can kick off a job manually and it fires off certain jobs in our core. It then pushes and pulls files and sends them off to vendors. It could be processing file maintenance. There are a whole host of things that we use it for. We're on Symitar's cloud software, EASE, and they have their own OpCon that our OpCon, on-premise, talks to. Before we migrated to EASE, we were running about 2,000 to 3,000 unique jobs a month. Now, we're running about 1,500 unique jobs a month or about 300 jobs a day.

We use it for automation of our nightly workflows as well as automation of our internal processes that are happening all day, including moving files, and running jobs on our core system. We also interface it with a lot of the database servers. We use it for a lot.

We use it throughout the enterprise, company-wide.

We use it for automating business processes.

We're using it to automate our nightly processing work, such as transfers and the actual integrations into our core banking system. We do a lot of file transfers and complicated job processing. We have a lot of processes that have two jobs that have to run before other jobs can run, and based on the output of one job it may need to do one thing or another. OpCon allows us to build complicated workflows that handle all of that. It performs flawlessly. We were able to go live the first night with zero problems.

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.

We use it for pretty much everything. We purchased it when we converted to Symitar and that was the primary reason for using it. But we use it for all different vendors, downloading files, and running Oracle queries and VB scripts, etc.

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.

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.

Over the course of my 15 year use, we automated dozens of processes with easily hundreds of tasks. Then, almost six years ago, we outsourced a large number of processes so we didn't do them in-house, and as a result OpCon wasn't doing very much for us for a time. About two years ago, we started automating new processes. Now, with OpCon, we have automated about half a dozen good sized processes. I am using a very recent version.

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.

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.

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.

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.

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.

We use OpCon to schedule three jobs, repeated ten times a day and five days a week. This solution gives us the ability to look at each job's output online and determine whether it is ok or not. It can restart failed jobs when they are fixed, and it maintains a log history for statistics.

We own the solution ourselves on-prem, but our core system is cloud-hosted. It runs all types of jobs to make changes to our database. From our end, we primarily use it to pull and push information to our cloud-hosted system: moving files around, making changes to files, and those types of things. People use the tool in every job role that we have. Our organization is a financial institution, so we have people in lending, people in member services, people in operations, risk, and marketing.

We use it to run our core system, Corelation KeyStone, as well as all of our batch processing and file movement, automation, and extract processing.

We use it to run all of our batch across seven Unisys mainframes. It's installed on Windows.