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."
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.
