What is our primary use case?
The primary use case is that we are now at the point where we are creating workflows and it is allowing us to shorten the time it takes for tasks to go through multiple machines. We wanted something that would give us better visibility.
How has it helped my organization?
We have different systems that do different things very well, and we previously had time frames for when tasks would have to be done. It has allowed us to streamline the workflow so that the machines aren't sitting idle. The work gets done and the information is available through production at a much quicker rate.
It really cuts down the time that multiple machines take to touch a task. We may have our ERP system create a file and send it to our integration server where it will dice and mash up some inventory requirements. We will send an order by FTP to our vendor and, at the same time, we're seeing that we have sent it in and that it should be on a truck and coming in in a few days. We see the specific time and can alert the planning group that we've already done this. It used to be these tasks were done on separate machines and would take 30 or 45 minutes per machine. If everything was clean, it only took 10 minutes from start to finish, but there was a lot of dead time making sure that each machine had time to complete its task in a base scenario. So it has really helped our abilities in terms of where we're at as a manufacturing organization.
Stonebranch has also saved us money because it has kept us from having to over-provision Windows Servers. With this solution we can put stuff in a workflow and get it through as quickly as can be, instead of allocating time on other boxes to do things. I believe it has kept us from having to add Windows Servers and drive up our costs with Microsoft.
What is most valuable?
I like that the users can kick off the tasks that the administrators have allowed them to kick off so that they are more in control of the data that they need. They don't have to contact IT or other people to get the data they need. It makes the users very self-sufficient and they like it too. They don't have to wait on people. When they know they need it, they can just go start the job and whenever it's done they get the data.
We're using the Universal Controller and, while it took a little while to get everything we needed into it, once it was there it became a really nice tool. We can delegate tasks through it or we can delegate all tasks for certain machines through it. It's a really nice, central point to let us know which tasks have failed. I come from a programming background and, as a programmer, I would output a log file from our jobs. After a while, people forget to check log files. With Stonebranch, as long as the error code is there, it displays on the dashboard right away, so you don't have to remember to go check the log file. It gives us a lot better visibility, and a lot more quickly. The Universal Controller, and everything we do with Stonebranch, is on-premise.
The tasks are incredibly capable, and as long as you name them with a nice, uniform naming convention, they are very useful. You can create some interesting workflows through various machines, or you can just have it kick off single tasks. All in all, I really like the Universal Task. You can do some mutually exclusive stuff, such as an "A not B" kind of thing. It has a lot of capabilities behind the scenes. We don't use it to its full capabilities, but it is very strong and a very capable interface.
I really like the agents. We've had no trouble with them interfering with any of our other systems or vendors — and some of the machines they're running on are very flaky. But I've never been able to trace any problems back to Stonebranch. The problems we had after Stonebranch were the same problems we had before we put the Stonebranch agents on those machines. The interoperability is really nice. It has a minimal footprint, it doesn't consume much RAM, and there is very little network overhead unless the machine is actually doing something and sending data back. It's really nice to fire-and-forget. The syscontroller tells the task to start on the remote machine. The remote machine executes it and when it's done it sends back the package of data that the control holds and consumes. It's really a very well thought-out system.
What needs improvement?
There is room for improvement with its connectivity with the Microsoft SRS system. It is very weak. They keep telling us it works with it, and technically it does, but it does not provide a lot of visibility. We have lost a lot of visibility migrating to Stonebranch, compared with just running tasks on the SRS server. That's really about the only thing that is a sore point for us.
We don't really use the Stonebranch Marketplace. We looked at it earlier and management really wasn't impressed. So admin was told not to worry about it. It could be that if we were looking at it now, now that we're smarter, I think we would find things there. But we have gotten used to the way we're doing things now, so we don't want to rock the boat.
For how long have I used the solution?
We started looking at Stonebranch in early 2017. We had everything on, all the machines were connected, by mid-2017, and we had moved all services and scheduled tasks and cron tasks to it by late 2017.
We had been using version 6.3 and we are in the process of upgrading to 6.8 now.
What do I think about the stability of the solution?
It's rock-solid.
The resiliency is very good. It is very solid. If the server shuts down, it will do its best to try and make up what it can, depending on how you have configured it. But it does a really good job of trying to recover gracefully.
For example, a while back we had a Unix server go down and it was going down because of a bad connection with something that was hosted on another box. Stonebranch was aware of the problems that we were having even finishing. Once we got all the problems cleared, instead of it trying to continue running all 800 jobs that had been started but never finished, it only tried to rerun the last job, which I thought was a really nice solution. We didn't have 800 instances of the same job trying to be rerun.
What do I think about the scalability of the solution?
Our production Stonebranch server is interacting with 27 different systems: Unix, AIX, Red Hat, and Windows systems. It's firing off about 1,000 jobs an hour and there's no problem. I don't see it taxing the CPU of the box we've got it running on it. It's incredibly scalable. I cannot imagine what it would take to start getting it overheated.
How are customer service and technical support?
Technical support is very capable. The helpdesk is very responsive and knowledgeable and if they don't know, they will reach out to somebody on the engineering team. About 90 percent of the problems that I've had to talk to their helpdesk about have been through error on my part. Either I thought something was supposed to do something it obviously doesn't do, and I would have known if I had read the documentation better, or I had misconfigured something. They are very responsive and very knowledgeable.
Which solution did I use previously and why did I switch?
We used cron and Task Scheduler from Microsoft and a gut-feel on how long systems should take to process something.
How was the initial setup?
The initial setup was very straightforward. I've come from a programming background, so distributed systems like this are something I'm very familiar with. It seemed pretty straightforward. It was a simple cut-and-dry task. It seemed very basic to me.
It took us between eight months and a year to deploy it across our organization. The implementation strategy was to get it done and make it work as quickly as we could.
What about the implementation team?
We had a consultant from Stonebranch come down for a week. I worked with him a little bit. He did some work and then I would do some work.
I've made a few calls to their helpdesk, but I have done 90 percent of it on my own, including the upgrades. It's a very simple system. It's not complex, but it does allow you to do complex things.
What other advice do I have?
Go at this slowly and methodically. When they came in, they did a lot of things very quickly, and we didn't really understand the implication of the answers we were giving. We have gone back to re-do a lot of that work. Now that we're smarter, and much better at this, we have found that being slow and methodical pays off in the long-run.
The solution has enabled digital transformation at our company but it's been a very slow process, and that is because the people we have are very traditional, old-school people. This is a little outside of the norm for people who grew up using the Windows Task Scheduler. They are having a little trouble with this. The idea of correcting workflows is still new to some of these people. It is allowing us to have the digital transformation — we're able to move things through quicker — but I don't know that everybody is aware of this or is taking advantage of it. New systems are being bought and spec'd out, and we can get Stonebranch to work with them, but it's kind of as an afterthought. They aren't used to thinking of Stonebranch when they're looking at the new systems.
We've got a couple people in engineering that are using the solution but it's mostly IT people who are using it, programmers and their managers. Our ERP coordinator uses it a lot. In engineering we've got CAE administrators using it to shut down and restart processes for their systems. And we have a couple of other users using it, but their use is very limited. We give them the tasks but we don't give them a lot of tasks as they are a small cog in the wheel. You can't give them too much power or they'll be messing up somebody else's job. We're mostly giving knowledge workers the ability to handle their own tasks if they can do it in a vacuum. That amounts to a few people in finance, a few in production, a couple in engineering and most of the people in IT. I'm the only person who handles deployment and maintenance of the solution. But that is not my full-time job. Once tasks get set up, they go and they run and they just work.
Which deployment model are you using for this solution?
On-premises
