Tidal by Redwood Reviews

In our organization, we are running scheduled jobs in batches. There are three different uses for Tidal, which are primarily development, testing, and production. It's like the environment that allows you to run batch jobs in those three environments.

I do production, like systems administration, and the development of the batch environment. So, I install Tidal, maintain it, upgrade it, apply hotfixes, or do any type of system admin function. Also, I set up batch environments for development, QA, and production which run in Tidal. I also train people on how to use it.

In terms of deployment, we're on-prem. We've adapters and virtual machines, but everything is on-prem.

It streamlined the batch environments. It got everybody on the same page, and people haven't had to monitor their own jobs. We've been able to centralize the running of batch environments. We've been able to migrate various schedulers into one central location. It has helped with reducing risk by being aware of what's running and making sure that what needed to run did run versus something breaking somewhere and nobody knowing about it. Here, if something breaks, everybody would know about it, and then action would be taken. It has reduced risk and streamlined and centralized operations.

It's very versatile. We generally have SQL jobs. We've SQL, SSIS, PowerShell, C#.NET, etc. So, whatever a program is written in, and whether it runs on Windows, UNIX, Linux, or mainframe, there are just a wide variety of jobs it runs in different programming languages.

I've been an administrator for other schedulers over many years, which includes CA, AutoSys, Control-M, etc. Of all of them, Tidal is the easiest one to use. It's very GUI oriented, whereas a lot of the other schedulers have been command-line-based. It's by far the easiest scheduler to use for creating objects, which would be jobs, events, and things like that. It's all graphical. It's Windows-based. When building a job, most features are predefined. You just have to select where the executable is to run from and the time or event-based settings. You don't have to use the command line. Everything is kind of predefined for you. So, you just go through Windows and fill out different features in different jobs. It's simple. I've trained a lot of people on how to use it, and people who use Tidal for the first time are able to make jobs, whereas, with other schedulers, there are other things that they need to know, such as operating system-level commands. With Tidal, almost everything is already defined. You just tell it where to run the job from, which folder it's in, what's the name of the executable, and then the time when you want it to run. It can be learned within an hour. It's pretty cool.

I've used Tidal Automation to connect and integrate with a lot of different software and systems. I've used PeopleSoft, Informatica, BI, SQL Databases, VMware, Azure, and others. I haven't had any issues. So far, everything has been great. They have a compatibility matrix that ensures that different versions of Tidal will work with different software. They're good about keeping that up to date. Occasionally, you have to apply hotfixes to different software levels, but I've had good luck with the interfaces.

It is easy to integrate other technologies and processes via the REST API. All you need is access and a log-in ability, and it integrates well. You don't really need to do a lot of configuration.

It has increased capacity by manyfold in terms of the number of jobs and/or integrations. I've gone from 500 jobs to 1,500 in just six months. That's really in the first year of setting up Tidal. It worked that way at other companies too, with the same kind of jump.

I find a lot of them valuable. The versatility of being able to run on many different types of servers is valuable. There is also a versatility of different services that you could run jobs on. It's highly versatile. You can run a lot of different types of scripts on a lot of different types of servers. It interfaces with all of them.

The event-driven aspect of running a job when a certain condition is met is valuable. For example, if a file lands on a certain location, you can run a job. There's an interdependency feature where you can run Job 2 after Job 1 is done. You could set up all the jobs to run in a dependent order rather than in just chronological order. For example, other schedulers would only allow you to run jobs at a certain time, but with Tidal, you can have jobs run when files are present, other jobs have finished, or other conditions have been met. So, event-driven and dependency-focused elements of their scheduler are the ones I probably use the most.

Its user interface is great. It's easy to use and easy to administer, and it's versatile. It's not as complex as a lot of the other ones. I've used it at six different companies, and to me, it's the most versatile, easy to use, and dependable. I've had nothing but good luck with it. It's easily the best of the breed. It's the best scheduler for ease of use. I've used 10 of them at least, and it's by far the easiest.

They're among the best technical support teams I've had to work with. Among different software, they're the ones I prefer to work with.

The company is not really big. One of the areas that they are working on is improving the process of migrating jobs from the lower environment to the upper environment. They had used a tool called Transporter, which was a little difficult to use, but they've now released a new tool in August, which I've not yet used, to do that. It's probably called Repository or something like that, but it's a tool for migrating jobs from the lower environment to the upper environment. That's where they needed to improve, and it looks like they may have, but I haven't tried the tool yet.

They can do better reporting in terms of production statistics reporting.

I have used it for 14 years and about 3 months at six different companies.

It has been great. 

We've two data centers and about 20 users, 1,500 jobs, and 100 servers. That's pretty much the environment. We've development, testing, and production with the high availability feature from Tidal.

We've scaled up a lot in a short time, and it doesn't even matter. There is no limit. You could scale up to however many servers you need to, or however many jobs you need to. They don't care if you're running 10,000 a day or 500. It works just as well. You could scale up as much as you need to.

They've been great. They are very responsive. They have a lot of the original people back with them. The new company that owns Tidal is STA, and when they purchased Tidal from Cisco, they hired a bunch of people from the original Tidal software. So, they're very experienced. I often work with them closely, and they're very responsive and very knowledgeable. I've never had any issues with anybody there. It's all positive. I would definitely give them a 10 out of 10.

Their level of product knowledge has been great. It's very high at all levels, from tech support people to the product people. They're very knowledgeable about what is offered now, what's coming down the pipe, and what changes are being made. It has been impressive how much they all seem to know about different products.

A lot of times, I would have a problem that doesn't even pertain to their software. It's about something else and how it integrates, and they would find the person who knows the most about that interface, and then I would work with that person. So far, I've had great luck. They've been very helpful. They go beyond Tidal. If you have an issue with an ERP, they'll find the person who knows the most about that and work with you to get it integrated and working correctly.

Positive

I have used a lot of different solutions such as Autosys, Windows Tasks Scheduler, Microsoft SQL Server Management Studio, CA7, CA11, Control-M, and Maestro. In all cases, we've had all these different companies that we moved to Tidal. It was definitely the right thing to do. We switched because of a lot of better features. Tidal is easier to use, easier to integrate, and definitely easier to administer. It's also versatile. It has a lot of features that some of the other ones didn't have.

It was straightforward. We basically configure the new jobs in Tidal, get them okay, test them out, turn them off in the old schedulers, and turn them on in Tidal. It has been pretty straightforward. The whole deployment has been seamless so far.

We did it ourselves. We knew the legacy systems. So, we knew what the jobs did and we were able to deploy them. It was straightforward. It wasn't necessary to bring in consultants for that.

We primarily had three people. Their roles were database administrator, system administrator, and programmer or developer. Those were the three main functions that were needed.

Its maintenance includes normal monthly update patches. That's about it. Once a month, we apply patches, and there is also an occasional hotfix when there are bugs that have been fixed. I'm the only one who handles its maintenance.

It's productivity. I don't get involved in the financials, but efficiency and productivity have certainly increased. Risk has decreased. So, I'm sure the return has been well worth it.

I spoke with our CTO, and he realized its benefits within three months of deployment. So, within three months of me setting up Tidal and deploying jobs to it, we've seen benefits and reduced risk. That was from the CTO. It doesn't take long. It takes a couple of months to get everything working right, moved over, and set up.

In terms of Total Cost of Ownership (TCO), it has been helpful with infrastructure expenses. It has been an improvement because we've been able to use this tool to more closely monitor the infrastructure environment to take action faster whenever there are problems. By centralizing the jobs, we've been able to reduce the number of servers needed. So, we're simply able to run more efficiently using this tool, which I'm sure has provided a benefit to the overall infrastructure.

The tool needs to integrate with different APIs, which it does. A big part of the business includes other solutions that need to integrate with Tidal. Different business users around the company use different ERP systems and reporting systems, and it's important that those interface with Tidal and that Tidal is dependable, which it has been. It has been seamless. There haven't been any issues.

I'm only familiar with the on-prem licensing. I don't know about the cloud because we haven't done that. So far, they've been great. They're flexible about letting you test out some of the adapters before deciding if you want to buy them. If you buy different adapters, you get better prices on new ones.

They work with you on licensing. So, it has been great. Everybody has different licensing, but I've had good luck with the licensing. They've been very accommodating. You basically need to buy a license for each physical server, but then you're allowed an unlimited number of virtual servers.

There are no costs for upgrades and other enhancements. They just give you the upgrade files. We've been able to purchase more adapters because the cost of the product has been very reasonable. You pay for support, but it has been great.

In terms of flexibility and transparency regarding costs, the licensing that we've been using has been great. There were no surprises. It was as advertised. I don't know anything about cloud licensing because that's probably the next step. We haven't done that yet, but its licensing has been fine. We have no complaints. 

We've evaluated other schedulers. Tidal checked more boxes. The main difference was that it was easier to set jobs up. Everything is Windows-based. It's versatile, easy to administer, and easy to use. It has enough features and APIs to do everything we need it to do.

If you need a scheduler that's easy to use, dependable, and versatile and that doesn't require a lot of complexity, then I would recommend giving Tidal a strong look. Cost-wise also, it has been very reasonable. So, evaluate your needs, and if the needs involve versatility, scalability, and ease of use, then Tidal is definitely a suitable one.

I would definitely give it a 10 out of 10 because I've been working with them for many years at many companies, and I would recommend them to anybody looking for a scheduler.

It's mostly used for batch processing across our entire environment. We have approximately 16,000 servers and about 36,000 jobs defined and we run about 10 million jobs a month.

It's mostly VMs that we're using it on. Our physical footprint is pretty small.

I don't think we could work without Tidal or a similar solution. We do tens of millions of jobs a month, and for somebody to try to manually launch them and watch them would be physically impossible. Given that it was 20 years ago that we implemented this, we haven't lived that life in a long time, and we've grown significantly since then.

Because we've been on it for 20 years, it's pretty easy for us to automate jobs with Tidal at this point. It has become second nature.

It's pretty simplistic to set up and get going, although there are different levels of complexity you can have within the product. It depends on how simple you want to keep it. If you just keep it: Job A, Job B, Job C, Job D, that becomes pretty simple. But when you start integrating some complex calendars that use sub-calendars—and you can go three, four, or five deep to set up schedules—it becomes more complicated. The beauty of it is you can go as deep as you need to. We can get really complex or we can keep it simple. We have some use cases for both scenarios.

The thing that I like the most is the reliability of the engine. The actual scheduling part of the product is pretty much flawless, but the stability of the product is what I find to be reassuring. We are a financial company, we move billions of dollars a day, and if we don't have our transactions processed in a timely manner we can be penalized and our clients can be penalized. It can have a serious financial impact.

The user interface is the place that needs the most work. If and when we find issues with the product, they are usually in that area. If I had to choose, that's where I'd want issues, as opposed to in the engine. But the UI is average. It's a little sluggish at times and there are some bugs in it.

Also, we have a very large environment and the performance, at times, can be a little sluggish.

I've been on the Tidal platform for about 20 years.

The stability is the piece of the product that I absolutely love. The core part of the product works extremely well and I'm very comfortable with how it works and how it's designed. We rarely have any serious, production-impacting issues. We probably have at least four nines of uptime and availability.

Tidal's scalability has met all of our needs up to this point. We're not on all 16,000 servers, because we don't need to do processing on some of them. But we're probably around the 5,000-server mark with no issues at all.

The product continues to grow. We haven't adopted a lot of the new functionality that it has offered, because we're very comfortable with the way we do things and we make it work with what we know. Most of our applications are internally built, so we're not using SAP.

We've had contact with their technical support on a regular basis. Their product knowledge is slightly better than what I've seen with other vendors. If I ask to have something escalated, I normally get the attention I need. If we're dead in the water, their support is all-hands-on-deck and we get all the support we need. But some of our lower-priority items sometimes seem to get lost in the mix. 

Positive

It was quite a while ago, but we did not use another scheduler at the time. We used cron and Windows Scheduler, depending on the platform. They were embedded in the OS, as opposed to some type of fully-featured scheduling tool.

The reason we switched was that we were consolidating processing centers. We were going from 69 processing centers down to one, with one more for redundancy. We were taking all of our external spoke locations and bringing them in-house to one location. We couldn't manage 69 operators. We decided that this made more sense than going with some giant room with a whole bunch of operators in it.

I can't say I remember a lot about the setup, given that it was that many years ago, but I'm going to say it was fairly easy. At the time, Tidal was a very small company and we got handheld through the process by them. It was a slow rollout. We were very careful with how we did it. I can't remember anything negative from that experience.

There was a fairly large team involved, at the time. We are very siloed into what each of us does. We have a platform team, a storage team, and a network team. We had individuals from each one of those organizations around to stand up servers and set up the network. We needed security to set up our user accounts, not the user accounts for the product itself, but the user accounts for processing. It was a fairly decent size group. But it wasn't like we had a full-time security person working on it. That person may have done 10 hours' worth of work and they were done.

We have three admins who manage the environment and they're in the Tidal GUI all the time, every single day. But the general users in our operations center, who are watching for alerts and for failures, are not using the GUI at all.

It doesn't require that much maintenance. We really can't have a lot of downtime, so when we have to have downtime, it becomes a pretty big effort to plan that out and to validate that the processes we need to run can execute in a different environment. The maintenance itself is pretty easy, but we make it hard based on our business requirements. It's that same team of three who handle maintenance. Normally, one person takes on an upgrade.

We feel that the benefit is there for us. There's a good return on investment. There's no doubt. Being on the product for as long as we have, it's harder to quantify because we don't know what it was like without it. But compared to a scenario where we had a go with a different solution or some type of manual solution, the ROI with Tidal is very positive for us.

We definitely have a favorable cost of ownership. We are very satisfied with the product. Are there opportunities for improvement? Sure, like with anything. But we believe that the cost of ownership definitely outweighs the cost of not having ownership.

We think the pricing is very fair. We have been happy with the pricing compared to some of the other solutions in the space. We feel we get a good bang for our buck with this solution.

We're on a three-year ELA so it's very easy for us to budget. We know what the cost is. We can use as much as we want of what we're licensed for, which does not include the integrations with some of the other software products. It makes budgeting very easy. We just budget a number for a year and that's what it is.

The licensing model meets everything we need as far as the flexibility it gives us.

The core of the product is great and I would certainly recommend it. It does what you need it to do when you need it to do it. Are there issues? Sure, every product is going to have issues. But I feel very comfortable with the most important pieces of the product.

We integrate the solution with Oracle and SQL Server, but we don't use its connectors for SAP. The ease of integration via the REST API has gotten better. The API was lacking a little bit in the past. We've seen improvement, but we haven't put a ton of time and effort into integrating via the API. We do have some automation for disaster recovery, but in general, we haven't done a lot with the API.

We use Tidal to automate all the jobs within our IT applications, especially for our ERP, which is JD Edwards, as well as Oracle, and Microsoft. Currently, we execute 12,000 jobs per day through the platform.

It helps us make efficient and maximal use of our servers, from four in the morning until eight in the evening, with the maximum number of jobs executed automatically. We produce lenses for glasses in our factory and it's a 24/7 operation. The automation enables that, according to our requirements. Otherwise, we would need people to take action due to various dependencies, and it helps us avoid errors. 

We have to run about 12,000 jobs every day and the majority of them need to be launched from our ERP, JD Edwards. The native compatibility of the Tidal platform with JD Edwards dovetails with our greatest need. It's directly connected to the heart of our IT system. We couldn't work without it.

Nowadays, the UI is easy to use. Over time, with different versions, it has become better and better and now it's easy. It's very different than it was some years ago. It has improved.

We have never needed to use the REST API. The plugins provided by Tidal meet our integration needs completely. It integrates perfectly with our ecosystem, whether it's SQL Server, Windows, or our ERP.

One thing I would like to see improved is that, currently, when an action is executed and finishes in Tidal, it's marked as either "success" or "failure." I would like more options that would flag a job according to multiple options, rather than just "good" or "bad." We would like to be able to define five different types of results and proceed differently according to each one.

Tidal has told us that it's possible to do so through the product or with a workaround.

I have been using Tidal Automation for about 12 years.

It is very stable, fortunately. 

The scalability is fine for us.

We have not used their support very much over the last eight years. During that time, we may have submitted two tickets, because we are using the product in a very standard way. Generally, when we do need help, we call our partner.

Positive

We had a different scheduler before we started using Tidal but that was 12 years ago. We are very happy with the results of our switch. The product we used previously was Open Scheduler and we switched for two reasons. One was the cost of ownership of that product and the other was the set of requirements around our JD Edwards ERP solution.

The deployment was very simple. It involved the installation of an agent on a server. Nothing could have been simpler to install and use. We do have another data center coupled with our primary data center for high availability, so physically, there are two locations, but logically, they are one.

We currently have two people who work in Tidal, throughout the day, Monday to Friday. At other times, such as overnight and on weekends, we use managed services to work in Tidal.

In terms of major updates, there is only one every two years. There is very little maintenance needed.

We use a certified Tidal partner to help with upgrades and to be sure that everything is okay. It's so important that everything work perfectly that we prefer to use a consultant, even though we could do it ourselves. Our scheduler is in use 24/7. It never stops. It is the central piece of our IT operations. If it does not run properly, everything stops including production in our factory.

We have had a very good experience with our partner. We have been working with the same partner for 12 years and everything is working perfectly with them. We will be using their services again soon. They also help us with level-one requests.

The ROI is okay and that is why we continue to work with Tidal. Overall, the price is fair for the service we receive and the way it meets our automation requirements.

The most important measure, and our basis for comparison, is to look at the number of people who would be required to do the same thing.

There have been pricing increases, but with the reduction that our company obtained from Tidal this year, the pricing has become very acceptable for this type of product. It is fair, today, for what we use it for. If the price is increased, we may have to review things. 

We looked at other solutions but there weren't a lot of choices at that time because only two, Open Scheduler and Tidal, worked natively with JD Edwards. We went with Tidal mainly because of the way it works, with plugins, with JD Edwards.

Because my team has been using it for 12 years, they are used to it and have no difficulty using it. But in general, there is no problem using it daily.

For us, using the Graphical Views feature is the exception. It's not the easiest feature to use. We use it to present job flows, and the way they are organized and their dependencies, to our new people, because it makes things clear for them. But in general, we avoid using it and use the main screen. We know our applications well, so the tabular view is sufficient for us. It's more complicated to use the Graphical Views feature, for us, but that's based on what we have become used to using, day to day.

Tidal Automation is a better tool than Redwood for enterprise-level applications. It is a stable tool and easier to integrate with any product.

We have a lot of custom-made applications within and outside our company. The product helps us connect with all of the applications in a better way than Redwood. It has in-built plugins enabling easy synchronization.

Tidal Automation’s most valuable feature is customization. It can work and connect with any app.

The product’s UI is outdated. They should work on this particular area. There could be better accessibility for the iPhone and other software similar to Redwood.

We have been using Tidal Automation for five or six years.

I rate the product’s stability a seven out of ten.

We have to make minimal efforts to scale Tidal Automation. Its scalability is an eight or nine out of ten.

The technical support services are good, but they should respond faster.

Neutral

The initial setup process is straightforward. 

The product generates a return on investment.

The price is reasonable in terms of the product’s functionality.

I rate Tidal Automation an eight out of ten. It is a very good container if you are looking for a single enterprise-level scheduler to control the entire operation.

Tidal has a great Interface that is user-friendly and easy to use.

It automates loads of tasks and complex workflows. 

The solution has increased efficiency and decreased manual interventions, which results in accuracy and productivity. 

One of the outstanding features is its flexibility; we can automate tasks of all sizes and complexity. 

Tidal integrates with other third-party systems, which makes it easy to connect and exchange data. 

Alert and notification features enable the user to know the status of the task.

It has simplified the complex workload by automating a huge number of tasks. We can configure and design even without coding knowledge. 

Tidal is a platform-independent software, which can be accessed in any browser. 

Error handling feature is amazing in Tidal, this improves business efficiency. A user-friendly interface makes users learn and navigate different modules quickly and effortlessly. 

Tidal is a valuable asset to our organization and will highly recommend it for implementation in businesses.

Tidal is versatile and a powerful automation tool. It has helped to streamline our business and improve the efficiency. It has reduced resource utilization and helps to automate tasks without any manual effort. 

It has great monitoring and managing features that track and respond to dependencies. Errors are identified and notified by the error handling functionality. It fixes the issues automatically, and error downtime is reduced - minimizing the failures.

Initially, it is complicated to understand the functionalities as there is limited product documentation. The setup and configuration of the software is a bit complicated. Providing the training videos for all the modules would be appreciated and It helps to gain more knowledge and understanding of the product. 

Support and assistance of the software should actively provide more service to end users. 

While performing the integration with other third-party systems, we experienced a lag and found it to be slow in performance

We use it in our production environment. We use it to schedule and execute many jobs. It is used by multiple application teams within our organization, such as SQL, Unix, ETL platform, MFT, and our AWS team. Other application teams include front office, back office, and accounting. They all use the Tidal environment.

We use Tidal to connect to other resources and systems through many of its adapters, such as for S3, ServiceNow, and PeopleSoft. We use it to trigger jobs in those applications. The REST API is very easy. Our application users use it to create, rerun, or cancel their jobs. And if they want to update something in the database, they do it with the REST API. It's a good feature.

That direct integration to our applications means we don't need to do other integrations from other applications or create scripts for these integrations. The multiple adapters available for connecting to other software make it easy for users to use the solution.

With other tools, you do not have the ability to schedule jobs on their own. You need to create a group and then assign everything to that group. Only then will the job be able to execute. In Tidal, you can schedule a single job and there is no need to create a group. That's what I like the most.

There are other helpful features as well, like SLA monitoring and the data book so you don't need to maintain other documents.

We also use the Graphical Views feature because our end-users want to see how their jobs are being executed and to monitor flows. They want to see how a job flow is going or where it stopped.

The drill-down into details using the Graphical Views feature is a bit difficult and not that helpful. If you want to go into the details, you have to go to the Job Activity. Graphical Views is not that easy for getting that kind of information.

Also, the user interface could be much better. It's an old-looking UI. Tidal could be much more user-friendly and attractive. I think they are working on that.

Another change I would like to see is that when we face issues or bugs in Tidal, we don't get to the root cause. We are told by Tidal, "Just apply this fix pack and it will resolve the issue." But we need to know the root cause. What has caused that issue? That scenario can be improved and Tidal has to work on it. They should provide us with some root cause analysis about every issue because we have to provide the root cause to our organization. Without the root cause, it is difficult for us to identify the problem.

I started working with Tidal, as an administrator, in April, so I have been using it for six to seven months.

In our non-product environment, it is not as stable for us as it is in our production environment. I'm not sure why it is like that.

It is scalable. It has many features that other tools do not provide. It is very convenient to use and we can scale it up.

Tidal has been widely promoted in our company and we are getting multiple requests to onboard teams into Tidal. They are exploring it and giving us feedback. We pass the feedback to Tidal and then they provide us with enhancements. Our job counts are increasing, day by day.

We have 500 to 600 people using Tidal in our environment.

Technical support is good except for the root-cause issue I mentioned. But they are always willing to help. When we ask them to join a bridge, they usually join it and they try to support us. They have good product knowledge and help us troubleshoot things on the calls.

Neutral

We have two deployment models, making it a hybrid, because we have Tidal on-prem and Tidal for cloud as well. They are two different tools, but they are linked to each other. The cloud environment is based in different regions including US East and US West. We have Tidal in both.

The deployment was straightforward. It was not that difficult because we installed it in a Windows environment. It took three to four months because there was a process we needed to follow. We had a team of eight people involved.

There is some maintenance needed. Sometimes, we face issues with the Client Managers, which is the UI console for Tidal. We need to clear the cache monthly so that we do not face issues.

Our organization has been using Tidal for the past 10 to 15 years. That means it's a valuable tool.

It's cost-effective because it is available at a low cost. That saves us a lot of money compared to other tools.

I have worked with IBM Tivoli Workload Scheduler previously and Tidal has many more features. Tidal is a low-cost tool and not expensive in comparison to other tools.

The ease of use of Tidal for automating is moderate, if you have the proper knowledge and training on how to schedule a job. A new person will need some training on how to get a job scheduled in Tidal.

They have multiple new features coming up in the future. They are going to come up with repositories, for example. If you are going to use Tidal, I would recommend going through their documentation in-depth and only then start using it, so that you are aware of everything. When I joined, I was not experienced with Tidal, so I had to go through the documentation, and then I started working with our live production.

Tidal is used for workload automation, batch jobs. It lets us run financial jobs, warehouse replenishment jobs, and reporting jobs across multiple applications, such as SAP, warehouse management systems, as well as our auditing system. We run something like 11,000 jobs every day across our enterprise.

The types of application middleware that we use it to automate include Azure Data Factory, data warehouse jobs, Azure Analysis Services jobs, our PDM database system, as well as our warehouse system that handles product reordering, picking and packing, and e-com orders.

The biggest improvement, and the reason that it was brought into the organization, is the creation of a cohesive set of job streams across multiple applications. An example would be if you order a coat on our website. That order goes through our e-com system. Eventually, it gets picked up by Tidal, handed off to our SAP financial system and order fulfillment system, and is then sent over to the warehouse management environment. Those applications enable us to collect the money and to know what we need to replenish. We also use them to get the coat ordered and sent to the person who ordered it. All of that is handled by different applications across our enterprise and Tidal gives us the way to schedule those in a single job stream that can be managed with dependencies and tracked.

Tidal has helped increase capacity, in terms of the number of jobs, but a lot of that has followed the increase in virtual machine and database capacity. We've gone from about 2,000 jobs a day to around 11,000 jobs a day. Tidal has been easily able to keep up with that capacity.

It has the ability to not only schedule jobs, so they run within a certain calendar time, but we can also trigger jobs ad hoc, and we can do that via email and file triggers, and in a variety of other ways. That has allowed me to build out flexibility for different team members and different needs throughout the year, depending on our sales cycles and our retail cycles. It allows people to run a job without even having to open the system.

The Graphical Views feature is also very good for helping us to understand a job stream. It's great for providing a visual overview of the status of a workflow, especially the Critical Path view. That is one of our favorites.

I'm the administrator and I keep the system healthy, but I don't monitor specific jobs. We have different folks who do that and they find it really nice to click on a job that's at the end of a long job stream and get an idea of its health, using the Graphical Views. Not every team uses them, but the folks who do really like them.

Tidal integrates with and connects to different systems to run the different jobs and it does that very well. There are connections from Tidal to SAP ECC, the warehouse management systems, et cetera. Not only does it do a great job running the jobs, but we get very valuable information back into Tidal about the health of a job. Did it run well? If not, what happened? It becomes a nice single pane of glass to find out if things are working the way we want. 

We also integrate it with our ticketing service management system, which is Cherwell. That works very well too. If a job fails, we integrate with Cherwell to create an incident that is then acted on and that has been pretty smooth.

If you have familiarity with APIs, it's a matter of just looking over the documentation and understanding Tidal's way of using the API, and then you can build integration with PowerShell scripts. That's something we're doing with the Cherwell integration to bring data from Tidal into Cherwell.

The ease of drilling down into details using the Graphical Views is moderate because there is a little bit of a learning curve. It could be a little easier, but it's definitely not bad.

Similarly, the user interface is moderate. They've improved it but there is room for more improvement. I'm so used to it now that it's second nature, but I do handle the training for our new users and that gives me an idea that sometimes it's confusing as you start to get into it. The company is working to improve it, from what I understand.

I would also like to see more of a cloud/hybrid solution. I know they're working towards it, but I would like to see that sooner. Currently, it is on-prem and that's fine because most of the applications it supports are also on-prem, but there is potential for more applications to move to the cloud. It would be nice to have a hybrid solution.

Also, when we patch to the next version, there is often a little thing that breaks. It has rarely been a big deal, but I always seem to have to follow up on one tiny issue. It would help if they had some better QA testing of their patches. It could be I'm just too aggressive on patching, but at the same time, better testing would be good. Whenever I do open a ticket, they follow up on it quickly and I get great service, but I'd rather not open a ticket.

I have been using Tidal Automation for eight to nine years.

We have only ever had one system outage related to Tidal that was Tidal's fault. That's pretty amazing for a product that we use all the time.

We're a medium-sized company at 11,000 jobs and we're using just one instance for that. My understanding is that it can scale out to hundreds of thousands of jobs, depending on how you implement it. We're in a good space and we would be able to scale out if we needed to. I don't see us needing to, but my understanding is that there are companies that use it on a much larger scale.

Over the years, they have built out connections to different types of systems that they didn't originally support. Azure Data Factory is new in the last eight years, and that means that Tidal didn't always need a connection to that system. They build out those types of connections and they work to stay current and to work with the applications that are out there. I see them striving to stay relevant, in a good way.

Tidal does a nice job of continuing to educate its customers on their solutions and what they're modifying or doing to provide new features. They have quarterly webinars that are very informative. I also find that our customer service rep is very informative. If I have a need for a demo of something that is new, I can reach out, get it scheduled, and they'll do a demo for it.

We have the solution deployed in a single data center where we have our production environment. We also have it in separate QA and dev environments. We connect to about 18 applications across our enterprise. Our total number of users is about 150, but on a weekly basis there are 20 to 30 people who use it heavily, people who are always in the system doing things.

One of their strongest areas is their customer service. Many of the same folks have worked at Tidal over the years. I have gotten to know some of the technical support people and we've built up a relationship. I can ask them questions and get answers that I trust. We've had our customer service rep for years, so I see a lot of consistency with their staff and the knowledge they have. 

If you submit a question and they discover it's a bug, they're good about getting it into a hotfix quickly, depending on the urgency of it. I find them to be really responsive and I find them to be knowledgeable and friendly. On the "people side," there is definitely very strong customer service and support.

I rate their support a 10 out of 10, especially compared to other situations I've run into.

Positive

I wasn't around for building out the original jobs, but I've had to install it on different systems as we've migrated, and it's pretty easy to install when moving to a new system. You just pick up the database, bring it over, and do a little bit of configuration.

Once you get comfortable with the system, it's pretty easy. It's consistent. There's always a learning curve, but it's moderate. It's not hard but it's not easy because you do have to learn things.

The amount of maintenance is pretty low. We patch it about three times, although they have patches that come out quarterly. The patches do two things: they fix issues and introduce new features. I'm usually patching because I'm interested in the new features. We could patch less, but we do it that often as a company choice. But in terms of keeping it healthy, we haven't had a lot of big issues related to Tidal, which is very good. The level of maintenance involved is good. I handle it on my own. It's not a complicated system, from a maintenance and support standpoint. That makes it a lot easier to keep healthy.

We have absolutely seen ROI. It's not just that it's critical to our company, but I also feel that there is definitely return on investment because of the good support.

We are satisfied with the pricing of Tidal. It's in the moderate range and it feels very achievable for us.

The base product itself, Tidal Automation, is licensed by the connections that you have to other systems. We review those whenever licensing comes up. If you want to add something like Tidal Explorer, or other modules, there is an additional cost.

They have modified the licensing model a few times and there has been a bit of a learning curve, which is expected, but in general, it seems to be clear and transparent. And they're very willing to talk to you and answer questions if you have them.

A few years ago we looked at Stonebranch Universal Automation Center, and we've occasionally looked at Control-M, to see what else is out there. 

From a cost perspective, Tidal beats them both, and we've had such good support from Tidal that it makes it harder to think about leaving, especially since the product works very well. Right now, we're not looking at anything else, but I always keep my ear open because you never know.

Work with the folks who own the systems where the jobs will run, so that you understand what your needs are, and leverage Tidal's customer support to come out, give you demos, and to help you get started. Their documentation is actually pretty good, it has improved over the years, so if you want to read it you can, and it will be helpful.

As the only support person for Tidal in our company, I'm very motivated to stay on top of things. That means I do a lot of training to make sure that my users, the people who build out the schedules, are knowledgeable and understand how to respond to issues.

I have also set up a lot of alerts that give me an idea of things that might have issues. All of that is done using Tidal's tools, which is great, to keep me on top of things.

We have multiple ERP systems, and we use it to schedule all of our jobs in those systems. Our biggest use case for Tidal is to automate jobs that we submit through our JD Edwards ERP. 

We also have a lot of integrations using FTP file events to move files around, and we are also using the software to automate all of our manual stopping and starting of services and patching of systems.

Our MRP job stream is very complex, and it has a mission-critical report that needs to run on a daily basis. One of the first things that Tidal gave us was visibility into that report so that we would know how long it runs, and we would be able to monitor it. If there were any issues, we could resolve the issues and not affect the next day's manufacturing because we took care of the issue. 

Awas that the team had a requirement that they needed to submit multiple jobs after a single job ran. They would put them all into one big single-threaded queue, and all those jobs that were dependent on that first job would get queued up and they would run single-threaded. That's because, with jobs, you can't go from single-threaded to multi-threaded and back. With Tidal, we are able to have one job run. As soon as that job is done, we can submit about a hundred jobs. Those hundred jobs spawn and do hundreds of other jobs. After all those jobs are done, we have another single-threaded single job. We would've never been able to handle such complexity with any other scheduler that I know of. So, we are able to solve the business' needs and improve the performance of MRP just by going to Tidal.

Another example is that a lot of times, the jobs were submitted every five minutes. If you asked the reason for that, the answer was that a file might show up, and as soon as that file shows up, I want to kick off the process, and process that file. We changed it from every five-minute job. It now only submits when that file shows up. Using file events removed the confusion of when that job is going to run where somebody would go out there and submit it, and if it was every five minutes, they'd have to wait for five minutes. Now, they submit it, or they put the file out there, and within a minute, they get a response back that says, "We're done with the job, and it is processed." They were surprised at how that was possible. It is just a file event, and it only runs when it is needed. It is not run every five minutes. So, we don't have all this extra processing time or extra jobs out there doing absolutely nothing because there is nothing to do. So, that's another way it has changed the business.

It has made things more efficient. We went from one set of jobs running every five minutes to running just ten times a day, which was the max I had seen that job run. So, we've seen the need go down because we're able to be more efficient with the jobs that need to be processed. An increase in the number of jobs would only be because we've been able to take more jobs that someone was manually submitting. We showed them how to set up the process in Tidal, and all of a sudden, with Tidal, it is just easier to automate it.

We use the Dashboards feature. We have opened up Tidal. Previously, a lot of our other schedulers were very much IT-only. We're the ones who got in there and created weekly jobs, whereas now, we've pushed some of that functionality back to the business. They go out there and submit a job. We taught them how to schedule to submit that job, and then, they maintain that job. If there is an issue, we monitor it for them and help them to resolve it, which makes it much more of a team effort between the business and IT, rather than just IT supporting these jobs.

It is very easy to use the Dashboards feature. Basically, they log in and see their dashboards, and/or they can see all the jobs that are running. One of the key things that we need to do is secure it. I can't have somebody log in and see another system's jobs for two main reasons. The first one is that it would be confusing, and the second one is that I can't have that. I need to have it secured. So, on top of it being easy, it is also very secure where when they log in, they only see their set of jobs and their dashboards.

The Dashboards feature gives information about a job’s status. A lot of times, when there is an issue with a job, this is the starting point to figure out what the issue was. You can then go and see job logs. A lot of times people call and say, "I have a job, and when is it going to be done?" With Tidal, it is very easy to go look at Tidal and say, "This is when it started, or this is the expected time it is supposed to start, and here is the average that it has done for all the other jobs that it has run." So, there is a lot of information that people can get at this all-in-one spot. If they had to manually go look at it, they would've to go to multiple different spots to get all the information. Even then, how you read the data isn't exactly consistent? For example, I submit a job, but it goes into waiting status. According to JD Edwards, it is running, and then, at some point, it'll go into processing status. That's the actual time that it takes to run. If you look at the start time and the stop time, that'll be two hours. If you look at the amount of time it really took to process, it would be only about 10 minutes. It could have spent the rest of the time waiting. That's where Tidal gives you the ability to see the actual processing time of how long it is going to take to run.

The Dashboards feature offers self-service for business users with customized content. As it has become available, it has been used much more. They never had it before. So, they didn't know what they didn't have. Now that we're able to give it to them, they're liking what they see. Being able to customize it gives them more flexibility in what they want to see.

Tidal has a lot of adapters. We use the SQL adapter. We use it to connect to an iSeries. We use it to connect to FTP. We use it to connect to all of our Windows Servers. There is also an agent for ServiceNow. We don't use that yet, but one of our future plans is to use it. We have JD Edwards ReportsNow that, instead of using ReportsNow scheduler, is using Tidal for scheduling jobs and reporting. The power of Tidal is the fact that I can have one scheduler to schedule everything. I don't have to have a scheduler on each one of these systems. I can, but then I have to maintain it on all of those systems. Having it on one, and being able to control everything, makes integrations a lot easier because I can stop processes, do patching, and bring processes back up. If it is all in one system, it is nicer and easier to do.

It is very easy to integrate it with other technologies and processes. A lot of times, there are a couple of different ways to do the same thing, such as with JD Edwards Orchestrator. We found three different ways to integrate into orchestrations. One was by running a command line that makes use of the SoapUI. They also have a web service that's more of a generic web service, and then, they came out and wrote a specific interface into orchestration so that we could schedule orchestrations through Tidal. Because there are so many different ways to do it, that means it is pretty flexible. It was fairly easy to figure out a way to do it and test it. When they came out with the actual adapter for JD Edwards Orchestrator, that made it super easy.

Another big advantage is the fact that when we schedule a job we know that it will submit, and if there are any errors we will be notified and able to resolve them. That way we're being proactive instead of reactive.

If there's an error with a job, there is an alert with a PDF. In that alert, we can customize messaging to assist people in resolving it. If there is a specific file location that they need to look at, we can put a link to that file location. If it's something with logs, we can attach the logs to the email so they have one place to start looking. We can even attach work instructions to that email notification: "Hey, if this job errors out and you received this email, here are the steps to resolve." People don't have to go looking for that information. They can just start resolving it right away.

Tidal has also definitely helped to reduce at-night hours. It's able to monitor itself. If a job fails, we're able to resolve the job and let the customer know, instead of the customer calling us and saying, "Some job failed. Go fix it," and having to research it. It could save my team about an hour's worth of work in each of those situations.

Overall, it saves us about 20 hours of work each week, hours where we would have been stuck trying to determine what the issue was instead of having an alert that tells us exactly what the issue is.

I like the fact that I have control, and I am able to monitor. If there is an issue, I am able to respond to any jobs that fail. With any other scheduler that I know of, a lot of times, when I have a very complex script and there is an issue in the middle of it, I have to let the whole process fail and then figure out a way to recover from it. Tidal, on the other hand, will stop the process and I can resolve that issue. Once I resolve the issue, I can continue the process. This is very important for invoicing, accounts payable, accounts receivable, or any kind of financial reporting. It allows you to recover from an issue much more effectively than anything else that I have seen.

It is extremely easy to automate using Tidal Automation. It is also extremely flexible. Sometimes, its flexibility leads to there being multiple ways to do the same thing. You can do it one way where it is easy and they will often create an adapter that makes it even easier. You get more metrics out of it by using an adapter that has been created for a particular task. An example would be the JD Edwards adapter. I could submit a job by just using a command line, which is easy to use, or I could use the adapter that costs more money but is easier to use. It is more robust in terms of error reporting and letting me know when there is an issue or when it has completed a job successfully, which is helpful in grabbing the logs or being able to do something with the output at the end of it.

I like the integrations they have with ServiceNow and J.D. Edwards. A selling point to me was the fact that they actually have a J.D. Edwards driver and that works the way it should.

My complaint about their pricing model is that every year, or every time technology changes or somebody has a new requirement, I need another adapter. While that usually means that I can schedule using that adapter, it is harder to plan for growth with Tidal because you have to buy a new adapter so often.

I've had this conversation with them. I wish the licensing was a little bit simpler, but I also understand what they're up against. Because there are a lot of different adapters that I don't need, maybe it is a good thing that I don't pay for all those adapters that I don't need. But when there is an adapter I do need, I have to pay for it. I wish the licensing was simpler for me, but I don't know if simpler for me would make it actually more cost-effective or simpler for them. It is a complaint, and/or it is a necessary evil. I love the fact that they seem to be a lot more receptive to looking at creating more adapters for different things that people seem to need. Once you prove that here is the need and here is the business that's going to need it, you definitely see it moving forward.

I've used it overall for 12 years. At my current company, I have been using it for the last three years.

Our instability issues are more on the other systems that it is connecting to and not Tidal itself. Tidal does what it is supposed to do. We do have timeouts. When Tidal is trying to talk to our JD Edwards system, it times out. And every time we increase the timeout value on the E1 side, it seems to resolve that issue for a little bit. Overall, Tidal itself is pretty reliable, but what it is connecting to is what gives us reliability issues, if we see any.

In fact, we ran across a case where Tidal was too smart for us. It submitted a job and was detecting that the job wasn't acting correctly and kicked out an error, even though the job was actually completing. I took it to the developer and he was able to determine there was a problem with the code. Tidal was responding to that error, but we had never seen that before. I haven't seen any other system work as well Tidal's J.D. Edwards adapter does.

I've been impressed with the scalability so far. In terms of the number of E1 systems that I connect to a single Tidal instance, I'm probably in the top 10. I don't think anybody else sets it up quite like this. It has been very flexible. I've been happy with the results that we've gotten.

It is deployed across eight different JD Edwards instances. They are separate JD Edwards systems. There are not a lot of people getting on it, but we do have a lot of reports being generated out of it.

No one is perfect so I would rate them a nine out of ten. They are very willing to help you with any issue. If it is a training issue where I want to set up a script to do X and I just don't know how to do it, they're very much willing to sit down and help you figure out how to set up that script. When we've had a technical issue where Tidal just did something really weird, we have been able to call them and they have walked us through how to resolve what was going on. 

They are very responsive. They're willing to take ownership, even when they probably shouldn't take ownership. They're just extremely helpful.

Their knowledge is great. They definitely know their system. When you're trying to figure out something, they are usually able to help you with it. A couple of times, we've thrown them for loops where we've had an issue with getting a script to do a particular thing. They've done the research and come back and said that the adapter was not set up like that, and therefore, they would create a feature enhancement request. They have then called back and said that it would be in the next upgrade, and I have said, "I guess we're taking that next upgrade."

Positive

There was the JD Edwards scheduler itself and we've also used Control-M. We've used Circular Edge's scheduler. I've even written a DOS command using a Windows scheduler to do all of my job processing. 

At the previous company where I first implemented Tidal, I was like, "Well, I have this free scheduler that does all of this." So, whatever I'm paying for has to be able to duplicate that. I have to be able to justify the cost. If it is going to cost X, what am I getting for X? With Tidal on that particular comparison, it came down to the fact that I would get the ability to report on things and the ability to easily recover from errors. As soon as the business was willing to say that recoverability and error reporting justify the cost, I was able to get them to pay for it.

Another scheduler that we were using was Robot. One of the things that Tidal has is a true JD Edwards adapter and I can schedule jobs into JD Edwards. With the JD Edwards tool, you can submit a JD Edwards job, but you can't really monitor it. I would submit a job and I cross my fingers and hope that it was really running. With Tidal, if there is an error, Tidal will respond back with the error and with the logs of why it failed. The integration is much tighter with Tidal and is probably the reason why I went with Tidal as opposed to any other scheduler. Every solution can schedule a job, so that's not a differentiator. Having an actual JD Edwards adapter is what differentiated them. Smart Scheduler is built into JD Edwards, but because it can only do one instance of JD Edwards. I have a bunch of instances of JD Edwards and didn't want to be tied to a Smart Scheduler for each JD Edwards instance. I wanted one Tidal scheduler that can do everything, and that's what we have right now. So, instead of my guy going to 11 different places to see if a job ran, he can go to one.

I had a technician who did the installation of previous systems we used. When he would do the installation of those other systems, or an update to them, we would always have to hire a consultant to come in and help, whereas with Tidal, we have never had to hire a consultant to come in and help on any update. 

It is super easy to install and super easy to get up and running. I literally showed a colleague once how to create jobs. All you have to do is right-click and then copy and paste. You then make changes to it. He went ahead and did all the other jobs on the system. That was pretty much the level of my training for him. It is extremely easy to use and to set up and get running.

An employee of mine was actually upset with me that I had wasted his time with another product trying to get it to work. We spent over $40,000 having that other vendor come in, and we spent at least two weeks of my employee's time trying to get the integration to work with JD Edwards, the way it should, and ultimately we failed. We were able to do that same functionality within a day with Tidal, start to finish: Load the server, connect the adapter, and submit a job.

We have multiple segments or systems, so our implementation strategy was to get it up and running as a proof of concept on one of our systems and then use that system to show the other segment owners how it works, and what the benefits are. We start off with taking any new requests. For example, "Hey, we need this schedule change." We'll do it in Tidal and it will run there from now on. We'll go back and move all their old jobs over.

In terms of administering it, there is a document out there that walks you through how to install it, so we were able to do that. That document shows, at a high level, how to create different types of jobs. When you get down into the details, it becomes a little harder to know what exactly goes where. That takes a little bit of testing and trying and retrying. For brand-new users the documentation is really good and it gets you to know what you're doing. When you're going to try and do more complex stuff, that's when you start really wishing there was more training.

We had one person to set up the servers for our whole server network infrastructure, and then my technician did the installation. We had someone from Tidal sit there with us while we did the installation, and then, I sat there and watched and answered any questions. So, there were three people involved in its installation including Tidal's installation assistant.

It was done in half a day. We were scheduling jobs and setting up personalizations. Within four hours of the conversation, Tidal's assistant was off the phone. Our interaction with him was great. He knew what he was doing. We got it up and running, and we were off to the races.

We spend eight hours a month on maintenance. That is just maintenance of the software. It depends on the number of jobs that you have out there, the number of jobs that you schedule, and the number of jobs that fail or just need a little massaging, but I can see requiring a full-time person just to maintain the software. I would almost make it two people so that there is redundancy, but again, it depends on the number of jobs and how critical your jobs are. We have eight ERP systems using this job scheduler meaning we have lots of jobs out there.

If I look at absolutely nothing else and just the licensing cost, I'm definitely saving money versus licensing Robot. I get a whole bunch of added features that I never had with Robot. 

We use it to do our patching and that brings down the cost of services and people. People don't have to sit there and do that manual work. It is automated. They just watch it. That definitely saves somebody from having to do work. So, instead of having four or five people on call over the weekend running all of these scripts manually, it is automated and I have one person watching to make sure it works. We've seen a great improvement. 

It is extremely important for our organization. For our MRP job stream, if Tidal can just once prevent an MRP issue from happening or let us recover from an MRP issue quickly, it has paid for itself. We would have paid for the software in just one instance of an outage. If I take that and multiply it against four other systems, I have the same situation. So, the software pays for itself over and over again on a yearly basis.

Their pricing seems very fair. It is more than the other solutions, but the functionality and the support are very much there. You pay for the job scheduler, and then they have certain things that are built into it, such as the FTP processes. If you then want to do JD Edwards jobs, you need an adapter. If you want to do SQL jobs, there is another adapter. Similarly, if you want to do Oracle jobs, there is an adapter. The way it's set up, there is the base and then there are the adapters for the jobs that you want to do, but it seems that's also how they pay for each of those adapters and keep them up to date.

When I first set Tidal up, it was just to schedule JD Edwards jobs. That's what I bought the license for, and then we also had these iSeries jobs. In order to do the iSeries jobs, I needed an iSeries adapter. Similarly, we have the SQL Server for which we wanted to schedule jobs. That's another adapter.  As the requirements change, it means another adapter. That makes it difficult for me to keep Tidal right-sized or right-licensed.  The licensing model is very fair, and it is very easy too. I understand their model. That's why every time someone says that we need to do this, I know that we can do it, but it would require another adapter. 

We also pay for maintenance. Budgeting-wise, that makes it very easy. My trouble with budgeting for it is related to the new features that come down the pipe. It is not really a budget issue from the Tidal side. It is more related to our project. We just have to make sure that in the project, we have money set aside to buy the adapters needed for that project. I wish I had a big enough Tidal setup so that I just had unlimited licensing, or I wish the unlimited licensing was cheap enough.

If you're not sure what license you need, Tidal will definitely give you a temporary license so that you can validate which license you need in order to get something to work, or how that adapter would work if you're trying to figure it out. They've been really great in that way.

None of the other products I mentioned that we used was really good, once you submit a job, at indicating when that job finishes. A lot of them are submit-it-and-forget-it, so you really don't know if that next job can start running, because you don't know if the first job has finished running. And if there's an error that stops a script at a certain point, none of the others do a really good job of alerting you and then letting you try to determine the best next action.

Tidal enables you to FTP and to copy files from different locations. For any other third-party stuff that you may want to do, it is a true enterprise solution.

Also, the calendaring is much better in Tidal. The scripting is much better. You can integrate across multiple different systems and platforms. I don't know that any of the others can do that. I could literally run a job on one EnterpriseOne system, move that data over to the other one, and run another job on another system. I don't know how I would complete that task on any of the other systems, without having to run two separate jobs. Even then, how would I know that it's done before the other one started up? Tidal knows, "I can't run this until this other one is done."

My biggest advice would be to review all of your jobs to determine why they have to run the way they run. For example, we had jobs that ran every five minutes. We started asking why they needed to run every five minutes, and we were able to change it from running every five minutes to only running when needed. Changing your every-five-minutes job to more of an on-demand or as-needed is a good use of Tidal. There is a lot of flexibility in Tidal to do more on-demand or as-needed things or event-based scheduling instead of just time-based.

It is extremely easy to use. We have developers, BAS technical people, and sometimes even a couple of non-technical people who make use of the interface. We give them a little bit of training, and from that training, they're able to go forth and do what they need to do. The only complexity I see is that the users can get hung up on the uncertainty of job statuses. For example, if I do X, what will the job status become? That's probably more an issue of comfort level than one of the simplicity of use. If I take a job that has errored out and I right-click it and resubmit it, while it is going to try to resubmit it, it will go to a processing status. Some people don't want to mess with that one. They want to insert a new one. You have to think about what you're trying to do, and there are dependencies. How complex you make the job schedule affects how people feel about the interface.

We are using its Graphical Views feature, such as Gantt, Kanban, and PERT, in the case of more complex processes, such as our MRP process. For some of the processes, it doesn't make a lot of sense because they're only run if needed and we don't need to see the Gantt side. So, it is used only when it is a highly complex process. For example, for a sales update process for doing invoicing at night, I could make use of the Gantt and other similar charts. Our MRP process is a very complex and long-running job. We use it for that, but for the rest of the jobs, it is not really used.

Don't feel ashamed that you'll wonder why you waited so long. I've used so many other products, gotten them up and running, but I don't know of any other product that works as easily as Tidal does for scheduling jobs for J.D. Edwards. I'm sure there are other people who use Tidal for other stuff, but J.D. Edwards is what I mostly know. I think it's the only scheduler you should use if you run J.D. Edwards.

The biggest lesson I've learned using Tidal is don’t wait so long. It took me five years to convince my boss that he should let me buy Tidal. He even brought in another product, and I sat there the entire time I was getting that other product up and running, saying, "I sure wish I had Tidal." Another lesson learned is to be prepared because the more people see the functionality and the abilities of Tidal, the faster they're going to want to make use of it.

Another lesson learned is that it is truly a product that the end-user can run instead, of IT supporting it. To me, it's no different than somebody logging into production and submitting a job in production. Why shouldn't they be able to submit it through Tidal? If I can give them an easy way to do that, all the better.

I would rate this solution a nine out of ten. Tidal is our product of choice at the moment. If we're going to automate something, we're going to use Tidal to automate it.

Our largest use cases are for the execution of SAP and JD Edwards jobs. Then, there are a lot of other technologies, however, in terms of the Pareto principle, really that's the bulk of our processing. SAP is what we use for our manufacturing and operational type stuff with the actual products. JD Edwards is a lot more of financial reporting and projections and things like that.

We use the solution to run SAP and JD Edwards. Windows and Unix hosts are probably the second most common use case, as well as web services. Any REST API would apply - and we use a lot of REST API technology. Protocol, really.

Primarily the biggest thing is giving visibility to what, in a lot of places I've worked in, are transparent, like invisible processes. You have this massive batch and, unless you have someone watching that and you have a place to have a single point of truth and say this is successful or not, it makes it very hard to trace things. With Tidal, you can say, "Hey, this is the objective notifications," and all the ones you explicitly want are checkboxes. It's easy to add those things in.

Having a single pane of glass, regardless of which technology we're talking about has been great. A lot of time, I'm in middleware, so what will happen is people will want to say, "Oh, it's this part or that part or the other part." You can see all of them side by side in Tidal.

It talks both to web stuff, which is helpful. Everything you want to talk to is there. If you have stuff that's still more 20th century and you want to run it at a command line, you have that available to you as well.

We use the solution for cross-platform, cross-application workloads. That's the biggest use for us and that's the biggest advantage.

Our impression of the solution's ability to manage and monitor workloads has been good. It does what it's prescribed to do.

The solution enables admins and users to see the information relevant to them. One of the other features that we use a lot is really a part of web services. We talk to ServiceNow. We have specific metrics to go with failures for major incidents and things like that.

The solution’s drill-down functionality so that admins can investigate data or processes has been super useful. It allows you to instrument for teams at their skill level. As an admin, I can say, I don't let you see these certain elements as you don't use the other ones and that simplifies how those technologies work. You don't have to have everyone see everything. That part's really helpful.

The solution has increased capacity in terms of the number of jobs and integrations. For example, in one of the things that we run, we actually had to expand how big the queue was as they wanted to run 300 parallel jobs. Historically, we hadn't run three parallel jobs for the whole company. So the scaling of that was just 15 minutes. Then, boom, everything was ready to go. It scaled pretty easily for us.

The teams that are smart about the Tidal usage, that basically will get it to the point of human intervention, save a lot of hours, especially when it comes to log gathering. That kind of stuff now is automatic for them. That saves a lot of hours.

Honestly, the biggest problem we have with it is people's interpretation of the results. It gives you really good information and people sometimes are just not really good at working with that information.

The GUI, the graphical user interface, gets a little bit busy. You have these flyouts that sometimes are a little tedious to get through. They need to look at just ways to simplify the graphical user interface a little bit. That would be good.

I've used the solution since 2009. That's 13 or 14 years.

The stability is very good. Almost every time where we've had an outage, it had not been due to the software, rather, it was some element of our infrastructure failing. The most common failure for us is we lose connectivity between the database and the application. There's not an app alive that's not going to have some problems when you can't connect like that.

We split users primarily into four roles. The viewers can't do anything other than see what's happened. There are also operators, which are people that can rerun jobs, yet can't modify anything. They're a little bit ahead of a viewer. Then you go into being a developer, which can write jobs in non-production. Finally, my admin team uses it. They keep it all running. The fattest part of the bell curve, the biggest user there is, is the developers. Overall, we're between 1200 and 1500 users. The admin team is six people, and the developers are about 800 of them.

We're worldwide. Unless we get some off-world friends to introduce themselves, I don't have a lot more room for expansion. What we're seeing now is people wanting to stand up more masters for more autonomy. I see us expanding into China, which is going to be a pretty nifty little trick since there are a lot of restrictions on communications there. That's about the only expansion I see for us. Obviously, there is increased job usage. However, in terms of expanding the footprint of the platform, that's only in geographic regions.

Technical support is better than average. It's not stellar yet. They're still working out some kinks. They've got it a lot smoother. I've had predominantly good experiences, just not perfect ones.

Positive

We used AutoSys before. I'm familiar with that tool as well. The big factor in switching was the license model being just a lot more predictable. Then, as a result of that, it was for the number of features that Tidal had. It was significantly more powerful at a lower cost. It wasn't just the cheapest. They were pretty close in cost when we got it all down to it. It was still less expensive, however, also had the more advanced features, in particular REST API, which was super duper expensive with AutoSys. It was a license model that made it very hard to predict the growing cost, versus Tidal. With Tidal, at least in the model that we had, it was very, very stable. We just renewed for another couple of years recently.

The initial setup was straightforward. You essentially need two servers and a database. At its heart, it is pretty simple to set up.

The deployment took three weeks. We deployed in three separate geographic regions. We just did one per week and then gave people time to get comfortable with new steps. We just did it in sequence. We installed, for example, for Japan, then for the United States, and then for Europe.

Learning it is pretty easy. It is a narrow learning curve for operators, for people that are just going to run and monitor. It's a little steeper of a learning curve for an admin to instrument new user groups.

Depending on how fast they read, new users can get up to speed in between one and two hours. We have a one-hour interactive training platform called EdCast. They do a one-hour EdCast that says how it works and then there are two other documents they read that specify and call out how their specific technologies work.

We did use a third party for deployment assistance. Our experience was very good. They are very knowledgeable about the product. They were a good partner. They helped us sort out the boundaries between when there's an error and when you've misconfigured it, and it's just telling you about it. They were very good in that regard.

We have seen ROI in the sense that it's primarily about our ability to stay flat in cost while constantly increasing our volume. That's the biggest ROI that I see.

For me, the key aspect was the linear predictability of costs. I know what handles I have to do, what things cost what. When we renewed having a regular cycle of renewal and re-evaluation kept us on track. For the years that we've been using it, we've had an increase in growth, yet we haven't had exponential increases in cost, which is really good.

Just say from 2009, when we started with it, up to now, we've gone from 5,000 jobs to fivefold. We're at 25,000, 30,000 jobs. However, it wasn't like my costs went up fivefold or tenfold. That was really good for us. That was really important.

The total cost of ownership, given its capacity for jobs and our ability to control infrastructure costs, have been very good. Having stood it up in AWS and having a group that's very active and having those sizings be very easy, what I'm finding is that the hardware requirements and thus the cost stays pretty low for the amount of stuff we're doing, and Tidal seems to respond well to our ability at the AWS layer to change that hardware without really having too many problems.

We are a customer and end-user.

I don’t know if the solution helped reduce or eliminate weekend or overtime hours as that doesn’t really apply to me. We're 24/7. There's no such thing as a weekend for us.

I'd advise new users to not underestimate the way that people will want to blame a tool for something they don't understand. Tidal will display errors from other systems and you need to be prepared for separating a Tidal error from Tidal reporting an error. That's the biggest learning point that you want to have in your head at the beginning.

It's a good idea to define the lanes of responsibility. That's been almost the entirety of my career, maintaining the lanes of responsibility through Tidal, as it's cross-platform, it's cross-technology, it's cross-team. You really have to be able to sort out the difference between a psychology versus a technology problem. It's the way someone feels about what's on their screen. It's been very helpful for that, however, it's probably a similar problem for anything like this. Tidal just makes it so easy to see those things yet oftentimes it gets blamed for stuff.

I'd rate the solution nine out of ten.

I am a part of the sales operations team which deals with the pricing of products, getting the pricing set-up up in the system, collecting sales data from sales teams from various geographies, converting the files to a consumable format of Excel, getting the data uploaded on to the database, connect the database to reporting and data visualization tools like Power BI which helps us build reports, dashboards, and analyze business trends.

All of these tasks include a lot of manual processes that take a lot of time and effort.

The data needs to be uploaded to the database every time new data comes in. It could be a single line item or a thousand line item, data upload needs to be done manually and the DB job needs to run later we refresh reports and dashboards so that the new data gets populated. And all the necessary changes are made to the reports before they are published to services.

This is just a part of the daily routine and just this itself includes a lot of manual intervention. Tidal Automation has made it so simple by using time-driven and event-driven job scheduling and management. A significant amount of time and manual effort is now saved without compromising on the quality of the outcome.

Workload Automation has become simplified by Tidal Automation.

Tidal Automation is very efficient and can quickly automate most manual and repetitive tasks. It helps you save a lot of time and provides highly accurate output with minimal or no scope for error. The software has capabilities of handling errors and detecting failures which is a great feature and an added advantage to its users. Tidal Automation has abilities to manage and monitor jobs across various platforms and it is easy to integrate with other applications and services.

The initial set-up of the Tidal Automation is a bit complex and time-consuming; this can be eliminated by fastening the set-up process by reducing the number of steps involved.

The software can be made more user-friendly by producing effective training modules for new users and beginners.

The tool downtime can be reduced.

Understanding and using Tidal Automation could be overwhelming for someone with minimal programming language.

The above are minor challenges I can across, the product is cool and provides great services, and have not observed any major issues.

I've used the solution for less than a year.

The product is highly stable and will remain stable in the long run.

I find the software very useful and solved most of the problems on my team. I believe Tidal will be a great competition to other automation software out there.

My experience with customer service and support is great.

Positive

There were no automation tools used before.

The initial setup is a bit complex.

The initial setup was done in-house.

In terms of ROI, we have witnessed an:

• Increase in Productivity by ~28%
• Increase in Accuracy by ~8%

Tidal Automation licensing comes at affordable pricing and it is worth the features offered.

Microsoft SharePoint and Azure were also evaluated.

It's a great workload automation software that will simplify a lot of manual tasks.