Control-M SaaS Starter Pack

Our primary use case for BMC Control-M is enterprise job automation and scheduling. We use Control-M to centrally manage and monitor a large number of jobs across the organization, including scheduling, execution, failure handling, job resumption, and alerting. It provides end-to-end automation and centralized control of critical batch workloads.

Control-M has improved operational efficiency by automating and centrally managing job scheduling, reducing manual intervention, minimizing failures and downtime and providing faster alerts and recovery of failed jobs.

The features I appreciate most about Control-M are its user-friendly interface and simplicity. It is not overly complex and the built-in APIs make it easy to use and integrate with other technologies.

For DataOps and DevOps processes, integrating Control-M with other technologies is relatively easy with an overall medium level of integration complexity.

The version of Control-M I was using did not have AI capabilities. Control-M would benefit from stronger AI integration that can analyze error messages, identify the root cause and take appropriate corrective actions without human intervention. Currently, some basic errors still require manual intervention, which AI could help minimize.

I have been working with BMC Control-M for more than 15 years, with my first implementation experience being for a leading Saudi telecom operator.

I rate the stability of Control-M as a stable 10. Control-M is a stable product.

The number of users using Control-M is around 50 plus. We have a centralized administrator who has a team working with different stakeholders, making this a centralized tool.

Control-M is scalable. We can do both scale-out and scale-up. Both options are available.

I rate Control-M support around nine out of 10.

We have been using Control-M since the beginning. We explored other products in parallel, but this was a fresh installation with no migration.

Regarding ROI with Control-M, we have not quantified it, but it has definitely saved manual work. A lot of human work has been automated through Control-M, although we do not have quantification of the exact savings.

When I compare Control-M with other solutions such as Apache, ActiveBatch, Broadcom, and HCLTech HWA , I find that Control-M stands out, particularly in terms of product support and global support capabilities.

I definitely recommend Control-M to others and some customers have already purchased Control-M based on our recommendation. I give this review an overall rating of 10.

My main use case for Control-M is that we use it for DevOps jobs.

A quick, specific example of a DevOps job I run with Control-M is that we patch servers often, and we have a sophisticated deployment process for different packages in our on-premises servers. We do not just use an out-of-the-box package manager; we have a Control-M process that handles pushing these patches into these controlled environments.

Regarding my main use case or how I use Control-M for these deployments, that is everything I do. We have lots of different Control-M jobs for doing different things, but we mostly use it for patching.

My main business use cases or services supported by Control-M include DevOps and management of devices used for deploying our application at different environments.

Control-M's reliability is its big appeal to me, as it has consistently worked for the organization since long before I got into it. Its simplicity in that way and its user interface are the big appeal, but that is about it.

That reliability and simplicity have helped my team when it works correctly and as desired, as the little task box turns red when it has failed, which is a good indicator for us that it is something we need to look at. It is an easy way to review a large number of jobs through a kind of world view of all the jobs, allowing us to see if anything has failed and letting us know what has failed in a nice user interface, making it very accessible to a lot of teammates. However, it has the drawback that just because a job has not completed successfully does not mean it has returned an error that turns the box red.

I do not have any metrics regarding how Control-M has improved the way my organization functions. It seems to have been picked a long time ago for its nice UI, but I think we made poor use of it. Good use of it is not very intuitive, and the lack of integrated version control makes people afraid to change things to try and improve them. Due to its proprietary nature, we lack environments to test adjustments on, which leads me to believe it has not been particularly helpful.

The best features Control-M offers, in my opinion, include the ability to selectively hold and run different jobs and the nice user interface, although I am not really keen on Control-M myself. It is not version controlled, which I really hate, or at least our implementation of it, but it is lacking in a lot of features. That is why I also use Jenkins.

The UI helps my daily workflow by giving us a quick visual way to establish what kind of progress a specific job is making.

I would appreciate Control-M providing better logging on the output of different jobs because sometimes a job completes and it thinks it succeeded, but it did not. There should be more programmability around error logging and better integration with version control. We are not really using Control-M as well as we could because we are not parameterizing all of our jobs and their steps, which I think can be done better, but that should be a lot easier to do. It is very hard to update these jobs, especially since we do not have something such as a JSON file for it that we can update.

To improve Control-M, there needs to be more programmability around how and when we log errors, and it would be nice to have some tools that actually allow us to interface with Control-M with scripts being run by the task steps. I think it would be beneficial to have some kind of configuration file that we could read, representing each job, giving us the ability to text edit these jobs instead of having to drag these boxes around, which is inconvenient. Additionally, better integration with version control, a web view, and improved resizing for the desktop application would be awesome. I also find that when I search jobs, the search bar does not order them in the order they are actually executed in, just alphabetically, and better searchability for these jobs is needed, especially when you have a large number of them in queue simultaneously.

It is very inconvenient to integrate Control-M with technologies for my data ops and DevOps processes as things change.

I would assess Control-M for building, scheduling, managing, and monitoring production workflows as not very effective. I use Control-M at least every few days, but it presents a kind of unhelpful user interface. While we have more senior people on my team familiar with all these functionalities, I mostly just run patches when needed, which is not very convenient. Coming from a more Linux-heavy world with depth in Jenkins, I find that these processes are much more convenient and the user interface for actual configuration and programming is much easier. Overall, Control-M comes across as very low-tech and clunky.

Using Control-M has made it pretty much impossible to create, integrate, and automate data pipelines across on-premises and cloud technologies. We almost never make new Control-M jobs because it is so inconvenient, and it is just a very clunky and tough tool to use. I would almost always prefer to do my work with Jenkins or simply write a Python script that logs its progress rather than use Control-M due to the cumbersome process of breaking steps into little boxes without version control.

I have been using Control-M for just a year.

I do not really know how many users are using Control-M in my organization, but my team consists of about ten people using it on and off, depending on our needs at the time.

I do not know how long the deployment of Control-M took, as that predates me by a long time.

I did not participate in the migration to Control-M, and I assume that over time, we will migrate more to Jenkins, as much as we can in the probably distant future.

I would rate Control-M overall a two out of ten.

I rate it that low because it is really very low-tech for what it does, and it has really fallen behind a lot of DevOps tooling. I use Jenkins here and there, which has version control and the convenience of managing credentials, making it easy to add agents and nodes, and it facilitates connections between those nodes more intuitively than what Control-M does. Control-M just makes you SSH into target machines; it essentially runs scripts and lacks built-in configuration compared to a tool such as Jenkins. Even though Control-M seems general-purpose, that just means it is not very well applied to the DevOps work I do, making it a clunky, proprietary piece of software. Its user interfaces are not really that valuable to actual technical people who just want good logging and good integrations for their automation.

Regarding Control-M's AI capabilities, I have not seen any governance and security features.

I have never used Control-M's AI capabilities to assess the accuracy and reliability of output.

The biggest lesson I have learned from using Control-M is that it is good to have code in front of you. Many organizations have followed trends onto tools that are very WYSIWYG, and I have used several such as Telerik Reports in the past. If you do not have code in front of you, you do not really know what is going on, and it becomes hard to facilitate integrations and log specific technical and business functionalities. Buying higher-level proprietary tools can lock you out of your own workflow due to the lack of customization and access.

My advice to others looking into using Control-M is to not do that because it is a proprietary product that overlaps a lot with newer open-source technology that is more accessible and paradigmatic for modern software development. Since it is a commercial product, the company likely offers consulting for best practices on how to use it, and getting training for its intended users along with documentation within the organization could help prevent other companies from falling into the same un-paradigmatic usage we have experienced.

I have been using Control-M in my career overall for quite some time. I joined this company about five years ago, but Control-M has been used there for way before, perhaps eight years, nine years, or more than that.

What I like the most about Control-M is that it is very reliable and works well for scheduling and even monitoring. The best thing I could say is the good visibility of jobs and their dependencies. When something fails, suppose when multiple jobs are affected, it would be useful to quickly identify the original failure and what was impacted because of it. Otherwise, it has very good visibility, scheduling jobs, and status is everything is good.

When something fails, as an improvement, it would be useful to have a clear explanation of what actually went wrong. The interface can sometimes feel a little busy for us. Finding the right information can take some time. It is not that we cannot find it, but it takes a few clicks. It is always helpful to have something very clear that quickly identifies what went wrong.

Regarding stability, there is no lagging and no issues with stability; it is pretty good.

Regarding scalability, I can say ten out of ten because it gives very good visibility of all the jobs and stability. There is no crash or downtime. It runs pretty well.

I have contacted the technical support or customer support of Control-M;. If we have any issues or need any help, we do contact them and raise tickets.

Regarding the quality and the speed of the support, as of now, I can say that it is acceptable. The response time is quite good. When we need them to be on call to help us, we decide on time and they come online to assist us. So it is acceptable.

I have never used any alternatives or something similar; we have been using Control-M for quite some time.

Regarding how easy or difficult it was to learn how to use Control-M, we have been using both web client and fat client, and I feel that the fat client is easier than the web client. There are a lot of options in the web client. With the fat client, I get more visibility and a more user-friendly interface. In terms of easiness, since it was already deployed and the functionality was there, it was pretty easy with some training from my team. It was not so hard to get through Control-M.

Control-M does require some maintenance on my end; we have periodic updates and patches. However, that is regular and that is needed to patch the vulnerabilities. Other than that, there is not much maintenance required.

I am not familiar with the pricing;I think it is still in discussion with Control-M.