Share your experience using Control-M

The major use cases we have are batch processing and MFT. We are heavy users of the MFT plugin.

One of the benefits of Control-M is that it's helping to give business users visibility into and control over their jobs, and freeing up IT personnel to focus on other operations. Here, I'm mainly thinking of MFT. Our MFT end-users did not have access to our prior MFT tools at all, so they couldn't see the jobs. They would just request a job be built and then we would publish job reports so that they could see what was out there. Now, in Control-M, we're able to give them job-control access. We still lock down the building of file transfer jobs, but they now have the ability to see a job and see how it's built. They can run a job and hold a job if they need to.

But even for some of the batch jobs, we've written some orderable services that are allowing them to run jobs on-demand, jobs that they used to have to log in to a server and go through a menu to do. Our business users definitely have much higher capabilities in our product now.

And while we are primarily on virtual servers, we are in the process of standing up some agents in the cloud. We have our first agent in AWS up and we're getting ready to do some testing on it. That's pretty critical. There's a really big push within our organization to move into cloud. A lot of our next-gen apps that are going to be replacing the current ones are being built in the cloud. We have that first agent out there, but I assume there are going to be many more to follow as these new applications are stood up in the public cloud. Today we're on-prem, but I definitely envision us moving the entire Control-M stack to the cloud. Eventually, it will be in the cloud and we'll just have a couple of agents on-prem, versus being on-prem and having just a couple of agents in the cloud.

Control-M has also helped to make it easier to create, integrate, and automate data pipelines across on-premises and cloud technologies. It's due to the ability to orchestrate between workflows that are running in the cloud and workflows that are running on-prem. It gives us the ability to have end-to-end workflows, no matter where they're running.

The automation is one of the most valuable features.

New plugins could be tested better. We've had a lot of problems with the MFT plugin. We've been working through a lot of issues with BMC on it.

The functionality that has existed for long periods is very stable. But the problems with the MFT plugin specifically, and problems we've had with MFT in general, have unfortunately caused the entire stack to be affected enough that our end-users couldn't even log in to the application. 

I wish we would have known better about how MFT impacts the application as a whole, and I wish they would have done more load testing around that. That seems to be where most of our issues have been. The issues have been so bad sometimes that the entire app goes down, not just MFT.

I've been using Control-M for about two and a half years.

The stability of Control-M has Not been great. A big thing we've been trying to work on with BMC is observability. Modern applications should be observable and resilient, but we're finding that sometimes Control-M is not very resilient and many times Control-M is not very observable. We're working with BMC to try and figure out how we can externally monitor this application. 

We are using Dynatrace because of the problems we've had with Control-M. If we stood up Control-M and never had any problems, we probably wouldn't be too worried about being able to observe the processes and the queues and the communication between processes. But because we've had so many problems, it has forced us to dig in. We can't wait for a problem to happen and wait for a week for support to tell us how to fix it. We can't do that in a production environment. We have to know before a problem happens so that we can be proactive and not reactive. That's been a big struggle that we're continuing to work with BMC on.

It's pretty scalable. You can stand up a ton of agents and you can stand up a ton of servers, if you need scheduling servers. Scheduling and agents are definitely very scalable.

There isn't the ability to really scale the EM (Enterprise Manager) a ton, although the GUI can be scaled somewhat. I don't know how much of a need there is to be able to scale the EM. We don't seem to have issues on the EM side, for the most part.

We're definitely having issues with the gateway between the EM and the scheduling server, but BMC is telling us that it's because we're running too many file transfers on the scheduling server. They say that if we stand up more scheduling servers, that should resolve that issue. We'll see if it does, if we still have any issues after we spread the load of MFT, not only over more agents, but also over more schedulers. If we still have issues after that, I think that would mean you're pretty limited in how you can scale your EM. That is the one thing about which I'm not sure how well it scales.

Technical support is very back-and-forth. That's one of my gripes about the support. We open a case, they ask us for logs, we upload logs, and they come back and ask us for something else. 

At times, there isn't a lot of what I would call working together with them. We do now, but that's because we had a ton of support cases piling up and we started escalating with their internal leadership. Now, there are weekly meetings between our leadership and their leadership and our account managers, as well as weekly meetings with the support team and the dev team, to talk through our cases and any updates on them.

It took a lot of pushing from our end to get them to work with us. Otherwise, they just asked for logs and then we were waiting for a couple of days for them to look through all the logs and get back to us. We can't be doing that, especially if the issue is a production problem. We can't just upload logs every time we open a case and wait around for two weeks to get an answer.

Another gripe is that they're very siloed in what they know. Something that I've been asking for for a long time, from BMC, is somebody who can take a look at our environment as a whole, and not just in pieces. Every time we open a case with support, they want to assign it to a specific area. If it's a problem with the agent, then an agent person will look at it. If it's a problem with the EM, then an EM person will look at it. But nobody is looking at the environment as a whole. That's an issue because a lot of our problems, as I've mentioned, with MFT, are impacting the entire environment. It's not just one component. It's the entire environment and how those components relate and how they communicate that have been impacted. Nobody has really looked at the environment as a whole, in support. I think it would benefit BMC to have more experts on the entire application and not have everybody so siloed.

Neutral

The initial setup was a little complex, due to some of the requirements. It requires that you have C shell as it doesn't work with the regular BASH shell. There are some old mainframe requirements that have carried through the product, even though we don't run it on mainframes. For example, the user that you use to run it has to be under seven characters long. We had to modify the account we use because the name was too long.

We're still really trying to get our environment squared away. We started two and a half years ago, but we've got a laundry list of applications that we're migrating out of and we've only completed one of those migrations. We're having to modify our architecture now because of the load that we are running. I'm working with professional services at BMC to review our existing architecture so that they can give us a BMC-supported design recommendation.

One of the competitors we are migrating from is Broadcom/CA. Broadcom bought a couple of products. They own both AutoSys and Automic, and we are migrating out of both of those solutions. AutoSys has been pretty straightforward to migrate into Control-M because the job configuration is pretty simple. However, the Automic workflows are very complex. They utilize certain features that only Automic offers, things that we can't replicate in Control-M. That is causing a lot of issues and has caused us to put that project on hold for the time being, until we can work through some of the problems that are being presented. We've been migrating Broadcom for at least a year now.

Some applications are pretty straightforward. MOVEit is an example of one that's a pretty straightforward conversion. However, another tool we have, Diplomat MFT, has a backup file structure that is not what the conversion tool was expecting. We ended up writing a custom Python script to do that conversion for us. The ease of migration really depends on what application you're migrating out of. It could be very complex or very easy.

The migration process is a very high concern. We selected Control-M due to the ability to migrate everything into it and have everything in one tool. If we can't get our migrations completed, then Control-M will just be another tool on top of all the other ones that we have to support.

We used VPMA for the deployment. Our experience with them went pretty well. They're definitely very knowledgeable about the product

I don't know that they, or really, as I said earlier, even BMC had all the knowledge around how MFT could impact the application as a whole, back when we originally bought this. MFT was very new back then. VPMA did their best and guided us as much as they could, but I just don't think the plugin for MFT, specifically, was very mature yet. There were probably a lot of unknowns there.

We had a pre-sales team from BMC that helped us in the very beginning, before we worked with VPMA. They were nice, but I wouldn't say they were very knowledgeable. They had a very surface-level knowledge of the application. They didn't know anything that was deep. They would have to find out for us and get back to us.

It's not my realm, but I would assume Control-M has not helped us realize any savings on renewal costs after switching from Broadcom. The cost of an agent is significantly higher for Control-M than it is for Automic or AutoSys.

We are paying way more for Control-M than we've paid for any of our other scheduling tools. We have an inside joke that Control-M is sold as the "Bentley" of schedulers, but we feel that we got a "Pontiac" because it's falling apart half of the time.

BMC has two licensing models. One is where you pay by job execution and the other is where you pay by endpoints. I'm sure the specifics vary depending on the customer, but we opted to go with endpoint licensing. I'm not sure if that was the best decision, knowing what we know now.

With endpoint licensing, we pay per server. That means it behooves us to run as many jobs as we can on each of those servers. But we're very much finding that even if we make those servers very large and give them a ton of resources, they're still not able to perform because Control-M doesn't scale very well vertically. If you make the agent bigger, if you double the CPU and RAM, that doesn't necessarily mean you can run twice as many jobs. It's going to choke in other areas. 

We will see if we end up switching our licensing model. I think the endpoint licensing model we chose is quite a bit more expensive than an equivalent model where we would pay per execution. We would definitely have to change a lot about our environment if we were to change our licensing model from endpoint to execution, because today we give all of our end-users the ability to run jobs on-demand. If we were to change our licensing model to be based on executions, we would probably want to restrict that a little. 

The way you license is a very large consideration when moving to Control-M.

We really haven't taken advantage of some of the features that Control-M offers yet. The main thing I'm thinking of is SLA management. We haven't implemented that yet on a lot of our business-critical workflows because we just lifted and shifted everything into Control-M from the old app. As of today, things are pretty much equal until we are able to implement some of those additional features.

There are capabilities that Control-M offers that are good and I can see it being a very good product. BMC, as a company, has some maturing it needs to do in a lot of its processes. They have a very good sales team, but a lot of things after that can use some work.

We definitely haven't bailed on it, but I've heard a little bit, back and forth, from people at BMC that they might not be too upset if they lost us as a customer because we've been having so many problems. We've been on them about helping us get this environment corrected and functioning as we expect it to. But in a year from now, it's possible we could be in a really good place. I'm excited to see where it all goes.

We have several SAP systems such as IBP, S4HANA, SolMan, etc. By implementing Helix Control-M, we wanted a tool that monitors different activities on these platforms and launches jobs.

Each company has a different number of jobs. We have thousands of jobs, but we have selected the most critical jobs of the company that normally run in the early morning. We wanted a platform that allows us to launch the job, for example, from point A until it finishes, and then there is also the possibility of being able to launch another job from another tool, which could be a SaaS tool, such as IBP so that several jobs can be executed and finished in parallel. If there is a failure in the system, we send an email, and for much more important things, generate a ticket in a tool called SolMan so that the support team can attend to the case that has arisen due to the failure of a job.

All those human errors that we were facing did not occur again. All these processes are critical for the company. We have implemented 22 processes. One of the processes starts at eleven at night. The process runs in S4HANA. It sends data to IBP, and IBP makes an optimizer and then it becomes a request that specifies the national transfers of the products that are going to be distributed. In other words, these are requests that indicate how many products should be sent from one point to another point for the customer at a national level. At six in the morning, another team, which is the distribution team, waits for this request to assemble the trucks and get them ready to leave. If they do not have this request, the trucks will remain stationary. By having the trucks stopped, there is no distribution, so there can be a loss of sales. There can be a drop in stock. You accumulate inventory in the warehouse because the plant continues producing, but where are you going to put the new products? There are a series of consequences that can cause the process to fail because we did not have immediate action to create that request. This tool has helped us positively impact the company's processes. We could get its benefits immediately after the implementation.

Helix Control-M’s ability to build, schedule, manage, and monitor application and data workflows in production is good. When we went live and throughout the first stage of the project, I thought it was great because we received full support. Now that we have the tool live, I have presented more cases, and I feel that they are a little slower. I have to try harder to get their attention.

Helix Control-M has affected our ability to orchestrate data pipelines in production. It has been a great benefit. Little by little, users' trust is increasing. When there is just one small failure, they usually stop believing in the tool. With a more solid tool like this, we have fewer errors, which means more trust of the users.

Helix Control-M has given our company’s business users visibility and control over their jobs and freed up IT personnel for other tasks. It has freed us up a lot because previously, IT used to coordinate meetings with the company that gave us the manual service. We had to meet and discuss failures and issues, but we no longer have these meetings because that third-party company is no longer there. We replaced them with this solution, and it has freed up a few hours. Being able to free up the company's IT team is important because we have so many issues to deal with. Nowadays, technology and innovation are in full swing, and users are constantly asking for new things, so the more we focus on those things, the better.

Helix Control-M has affected collaboration between IT and our business users. Previously, our business users only complained about process failures, and now they themselves can reprogram. Before Helix Control-M, we had to send emails with the reprogramming. Despite that, they did not do what we had specified in the email, so it was all a waste of time. We wasted time with the business, and we wasted time meeting with this company. In the end, they did not do what we had told them. Nowadays, the user interacts directly with the tool because they have access. They themselves can reprogram those processes. There is less need to have a meeting, and there is also a reduction in the email replies and forwards. We have reduced everything. They directly interact with the tool to launch and relaunch.

First of all, the shift from manual to automation has been valuable. We have a tool that can automate.

The second valuable feature is that there have been many benefits, which we have been utilizing little by little.

The third valuable feature is that there is a good support team. They have solved things that other companies have not done. When it comes to IBP, because it is SaaS, it was not easy for our team, but we received good support. At first, there were also issues regarding the functionality of SolMan. We saw that it was not going to work, so we did not go live with that, but they told us that there was going to be a new version where the ticket would be generated almost automatically. Because they were releasing a technical issue that would allow us to generate a job automatically and generate a ticket in a simpler way, we waited for that upgrade to be released, and it indeed was like that. Such continuous support is very valuable because it is not a tool that does not progress. They are constantly releasing things and allowing it to grow and cover more functionalities.

There can be an improvement in the area of finance.

I contacted the BMC team here in Lima and mentioned the things that can be improved. For example, S4HANA jobs are something with which BMC has already worked in several companies. Whenever I pull an S4HANA job to the Helix Control-M tool, it pulls it naturally with all the steps. A job can have several steps, and in this case, it is very easy to control the steps taken. However, in the case of the SaaS IBP tool, it can pull the job but cannot identify the steps. So, when I want to take an action in a step, I have to split the job. We are having to work longer because we have to split the jobs from, for example, 52 steps to 12, depending on where I want it to have an action. We would like the tool to be able to identify the steps so that we are not continually splitting them as it generates more executions for me.

The other improvement is that in, for example, S4HANA jobs, when the job fails, you have the status of the job. It recognizes them perfectly. In the case of IBP, it also has status but at a more minimal level. Sometimes the step fails, but the job does not fail. It ends with an error in a step without identifying it for me.

Another thing that we have asked to improve is that Helix Control-M can be integrated with more tools such as Odoo. Odoo is a tool for all these companies that are not with SAP. They use it as a small ERP to generate their sales. Odoo integration will help us receive inventory reports.

The communication and details related to the upgrades that are going to be happening also need improvement.

The implementation began in 2021 and went live in February 2022.

It is a powerful, stable tool.

I have had a very good impression. I have been to the events where BMC shows its new products. I see that there are more things that are going to help a lot. We will be able to get much more out of it.

Alicorp is at several locations and in several countries. These processes have only been launched here in Lima, Peru. They have been divided into the demand planning, distribution, production, and supply areas by the planning team, but it is only done by a team here in Lima. The result is at the national level, but the configuration made in the system is only done in Lima, Peru. Later, we will surely also move internationally.

We started with a small planning team that is gaining confidence in the tool, and the next stage is to cover more areas of the business because currently, it is a small group with a small number of processes being executed. The idea is to make a massive change in the other areas as well, such as the finance department, and then the analytics department. This requires us to look at this implementation from various angles, so we can optimize the dissemination and execute it massively. Before taking that step, we wanted to be in a solid position with the team that is working on Helix Control-M. We wanted to have confidence in what the tool does, and now that we reached that step, the next step is greater use.

Our first-level support is with the GrupoCONTEXT team. They have the knowledge for all cases. There have only been 2 or 3 times where they did not know about the issue and involved BMC. There have only been 3 complex events. There have not been more complex issues. Normally, there are problems when maintenance and upgrades are carried out because sometimes the system changes.

Positive

We previously executed this process manually. It was a third-party company that had 9 people in the early hours. They manually launched one job and then relaunched the other according to a document that we gave them. The document said what things should be done depending on the case that arose. The problem was that there was a lot of shift rotation. For example, if one job ended at 2:00 a.m., in theory, the other should start at 2:01 a.m., but it started at 2:10 or 2:20 a.m. It took 20 to 30 minutes. This time was wasted because the person was not there all the time monitoring. They either made a mistake in launching another job that was not the one we had indicated, or they simply did not launch, which was much worse. So, because of the shift rotation of people, since they were early morning jobs, we constantly had those problems. We had a loss of time, no precision, and a lot of human error.

I was involved in the process of evaluation and implementation, and now, I am also involved in monitoring the development.

Its implementation is among the simplest I have done. SAP tools are more complex. Helix Control-M was live within a short time. We configured it in 2-3 days. We tested it one day, and the next day, it could go live with a process right away.

Our implementation strategy was to divide the implementation into stages. We did it by area and configured the jobs. That was it. We had workshops to understand what the user wanted, and then we did configuration in the test environment to see that what they requested is actually what is being done and executed in that environment. We then moved that to production, so for each user group, we followed: demand, distribution, supply, and production. It was super simple.

In terms of maintenance, from time to time, they notify us that there are upgrades. We receive notifications about agent upgrades, tool upgrades, and some system maintenance. Because it is a SaaS, they tell us everything. We coordinate internally so that if there is a process that is running at that moment, that program is executed manually.

For the server and agent part, we have outsourced the maintenance to the CJG company. They are in charge of doing that maintenance. On the operations side, there is a person in charge. Every time something happens, he is in charge of the event.

For the integration, we received assistance from GrupoCONTEXT. They were in charge of doing all the configuration and programming.

From GrupoCONTEXT, there were two people with constant support from BMC. On our side, there was an architect and a few other people. All the suppliers were contacted so that they were present during configurations, integrations, and testing.

We have seen an ROI. In theory, this third year, we will recover what we invested. It has helped us replace the cost of human resources.

For this tool, as we made the three-year contract, the cost of the licenses is maintained. If we had to hire people for this work, we would have had to increase their salaries every year.

They are expensive. If we were a small company, it would be complicated because we have to have strong sales and operations to be able to afford a tool of this level. Being a large company, the cost-benefit is covered, but it is not within the level of cheap solutions.

The dilemma for us was whether it is worth paying for a monitoring tool or whether it is better to pay people for the work. Helix Control-M was more beneficial because we had problems with manual monitoring, and these problems were expensive.

I was in charge of evaluating all the tools. Because we already had SAP, I first evaluated the SAP tools, such as SAP PI/PO and SolMan. All the SAP tools do these functions. They do them well, but they have limitations. For example, in SolMan, you can monitor and do all the operations, but when it comes to IBP, which is SaaS, it does not work. It is better to not manipulate the programming settings. It is better to leave the standard programming settings because it is simpler.

I was also told to evaluate external tools, so I evaluated Helix Control-M and the IBM solution. Helix Control-M won there. It is the first time that we have used a tool for this type of control. Previously, this work was done manually by a team of people. We used the tools only when monitoring a single platform. For example, for S4HANA, we only used SolMan, but we wanted to integrate several systems and find a solution that does all the activities efficiently and safely.

I would advise you to challenge it. We made an assessment to challenge it to see that it covers all of our use cases and we can trust it. It is a solid tool. Go for it if you can afford it.

The most important lesson that I have learned from using this solution is to not be afraid of automation. Sometimes, because you have been working manually for many years, migrating everything to automatic processes is risky, but I learned to not be afraid of doing this.

In terms of the measurable business impact of Helix Control-M, we are working on that. I just had a meeting with the commercial team on the subject of the month-closing report process. Currently, the month closing process is 5 days, and they want to reduce it to 3, for example. What they have told me is that if orchestrated right, Helix Control-M could help reduce the process time. We are in the middle of the evaluation process to precisely take care of its business impacts. With the finance department, we are evaluating the possibility of reducing time.

Overall, I would rate Helix Control-M a 9 out of 10.