My advice applies to the implementation of any automation platform. Have a solid plan for what your approach is to automation and develop a common approach to workflows. That is what we did. We took a step back and looked at what our workflows actually do. We really only have four fundamental workflows so we built templates for those, and all but a couple of our workflows fit into those templates. So analyze your workflows, understand what they do, build templates to do that, and then go off and do the automation once you've got the templates built up.

I'm not getting any complaints from my automation team about the platform. The guys are really happy with it.

I really haven't spent a whole lot of time in the Stonebranch Marketplace.

We looked at Stonebranch's file-mover product for internal file movement in our workflows where we're moving files. We did a PoC with it and we decided to go with another product. We have three managed file-transfer platforms in our enterprise. The biggest one that we move most of our files with is IBM's Sterling File Gateway. One of the biggest challenges there, when you're moving data across the enterprise and doing workflows, is managed file-transfers platforms. They drop them in in the landing zone where processes will consume them. What we found was that those files were just sitting there waiting for somebody to manually do something with them. In the meantime, we've automated all that. We moved it from the landing zone to a retention zone where they sit in tier-two storage for 60 days. We then move them off to the data domain, which is tier-three storage, archives. The automation really helps slow down the eating up of tier-two storage platters at $40,000 a pop. Everybody's has this problem, but we've automated that process. We've even automated deleting those files off of tier-three storage and realized a savings with our Storage Spend.

We have an automation team of three employees. We have another six members of that team who are offshore contractors. We have four users and the analytics team which are actually doing workflows on their side as well. The way that works is that we have a dev, a test, and a production environment with Stonebranch. We have a Controller running in each of those environments. The analytics team builds its workflows up in dev. We do basic testing there and then push them to the test environment where the automation team makes them work. Then we push into production. We're mostly working with the analytics team, the dev environment, with them developing their triggers there.

For deployment and maintenance of the solution we need three people on the automation team.

My advice to others is that if there is a migration project they have to be thorough. The planning phase is really important when the migrations are happening. However, for a straightforward implementation, it's an easy process. If you are doing it as a vanilla installation, then it will be easy. If you are migrating from one automation to another, then the Stonebranch Universal Automation Center is going to be challenging because much of the terminology and the way of automation is going to get changed.

I rate Stonebranch Universal Automation Center a seven out of ten

The solution can complete most of the requirements we need with our SAP system.

If it's a fresh implementation, I'd recommend the solution to others. 

I'd rate the solution seven out of ten. There are still a few features missing, like having a mobile app. 

If you're looking at this or a similar solution, get with a company that's done it before. We have consulted with other companies and helped out a number of them to go to this solution.

We've already done digital transformation, so Stonebranch is part of our continuous improvement. I'm not going to say it's transformational, it's just continuous improvement, using our tools to exploit them for the betterment of supporting company goals.

In terms of the solution's users, we have people who build things in order to use it. We have a core of about five people who set up workloads to use them. They perform somewhat traditional scheduling roles. For deployment and maintenance, we do it all with those five.

The agents are a ten out of ten, the Controller is a nine. The agents are top-notch, Controller has some room to grow.

Look at also having the database solution be HA as well, because the product is highly available and you can stretch it to also be your BCP where you just fail over from one data center to the other. We suffer because our database solution is not. I would urge everybody to go down that path and set it and forget it. If you lose a part of your data center, this thing will stay up.

The universal task is something that we started dabbling with. We haven't used it fully yet.

We don't rely on the Stonebranch Marketplace a lot. It was something that we discussed with Stonebranch over a period of time. It's something that we, as a culture, need to look into internally as a company. We tend to trust the things that we write, versus looking into things like a marketplace where we can extract thoughts or automation or universal tasks that other people have put out there. If it breaks, we need to be able to call somebody when it does.

At last count we had around 650 defined users, and around 50 logged in at once.

Right now, to do the scheduling and maintain the environment, it's two bodies, and we have one to help support the file-transfer piece. Those three bodies are responsible for administrating the environment. If somebody needs to be onboarded, that's all automated. You come in, AD groups are created, the security stuff is in, it's all automated via ServiceNow. All that those three guys do, from an admin perspective, is troubleshoot production issues. If something breaks, the app goes, they sit down with the application and explain why it broke. The other roles that we have are operators, schedulers, and the read-only users. The applications are broken into dev and production teams. Dev teams usually have access to schedule and promote to production. Operators only have access to production, and they do the operations role. The scheduler basically has read, write, delete, update access to everything. The operator only has that access on the tasks so operators are able to rerun, stop, that type of role. Those are the four roles that we have defined.

I would estimate that ten percent of the business uses this product. Are we going to expand it? Anybody is welcome to use it. It's slowly growing by itself. As soon as you mention the file transfer solution to people, they say, "Okay, I'm on board. Let's go." Are we going to make it a strategic tool that everybody has to use? It's just one of the many tools that we have in the toolbox. I think within our organization, we probably have in excess of 500 tools.

I would rate Stonebranch at nine out of ten. I would never give anybody a perfect ten. I always want people to work harder. I'd give them a nine because, if you deal with all the other vendors, you're used to a sales guy coming in with an agenda - that he needs to maximize the sale. I didn't get that from this vendor. It was very weird dealing with them because all the other vendors act a certain way, except them. They show up, very transparent, very honest, and they're always willing to negotiate.

I'll rate Stonebranch Universal Automation Center eight out of 10.

If I were to go to another company, this would probably be the tool I would push for. It's a very sound product. I feel Stonebranch is on the technical edge. I've been to a couple of their conferences. They are going into areas and blowing my mind with where they're going with some of this stuff. They're trying to stay on top of the cutting edge.

When you go to their conferences, you hear how other people are utilizing the tools. Something might spark a concept, where I say, "Maybe I can do that."

We use ServiceNow as our problem management tool, so I'm trying to automate tickets to go into that, but we haven't made it that far yet. We send an email on every task failure over to a public folder, and that's what our operations team copies and pastes. Then they update another gauge in our dashboard so they know that somebody's working on that. Then we have some warning issues. We have things that go into define states, because they could be a sub-apple of a main workflow. Or we have workflows that stack up behind each other because they're the same name. We use resources to control everything. If we do have a maintenance window, I'm using a resource to set it to zero, so any workload coming in after that is waiting for our operations team to release or get the okay after a maintenance window has been performed.

I'm the primary for the maintenance. I have a backup, but he's more my MQ guy. I support MQ as well. I do all the maintenance and controller, so it's one person primarily doing it all. We have three production-control people who do batch scheduling, for new schedules, obsoletions. They reverse their procedures every week. One's doing scheduling, we have one doing user-requests, ad-hoc requests that are coming in on a daily basis to insert into the schedules to run. We have a schedule that we call Production Control and that's where all our user requests go; users who want to run this or that today, that's where they would insert it and run it.

We have about 120 users. They include our DevOps team. We used some business services to lock down some of their pseudo test schedules. We run a production internet environment, and the data that comes out of that actually goes into our development environment, for their testing. We use business services to lock that down. They have eight people who can update tasks, create tasks, etc. That's the only place we're using business services.

We have seven groups. The Administrative group and the "Everything" group comes with the tool. But then we created seven more groups. We strayed away from the default groups and made our own. We have ops-wise-admin, which is the administrative group. We have an ops-wise-all group, which is just readability. Somebody can get into that group and they can see ops-wise, they just can't make changes. Developers is our biggest group. In production, they only have read access, but in our development areas they have full-blown access. We manipulated the permissions to help control production over development. Ops-wise-IT is another group similar to ops-wise-all. I don't know why we had to have that one to give IT some extra abilities, but that's what we did. And we have an operations group for our system operators. They have capabilities to restart workload based on a programmer's request, a plan of failure. They can make modifications to the active instance, but they can't make modifications to the definition. That's how our change control comes into play. Product control has the same access as ops-wise-admin, but they just can't do upgrades.

In terms of the prospect of increasing our usage of the solution, we're looking into the cloud situations, but I haven't been asked how to go that route. Doing it would be a matter of putting an agent out there in the cloud world. Security is the biggest hurdle for me, sometimes; trying to get access. Some of our servers are behind firewalls. It's usually a matter of talking to the right people to get the job done, but I probably have seven agents that are behind firewalls and working just fine.

I run four controllers, but I have six in place. I have two that are high-availability. We were struggling and this is probably an issue with Stonebranch. We had developers who were making changes in our test and development areas, and then we would promote them up to production, but we started having conflicts with sysids. What would happen was that a developer would make a copy of what he wanted to change, and he would go back and rename the original task to "old" or something like that, and then rename the new one to the originally named task. The sysids were now out of sync. Sometimes they would bundle up okay, but once we started seeing a larger volume of them, we started having bundling issues and failures. We elected to go with what we call our change-control environment. It's almost a mimic of our production environment, but now our production control team actually updates the original task upon request. They make the changes in their development and then they submit a change request to have this copied into production or updated into our change-control environment, so we can keep the sysids from getting out of sync. Sysids were probably one of our bigger hurdles, after the fact.

There are no agents running on our product-control system. We variable-ized all our agent definitions and we variable-ized all our credentials. With scheduling, if you hard-code the agent name or the credential, it will actually bundle it up like that, but if you variable-ize them, you can keep them unique between the two systems. In production, this is a production credential, but in test they use an LE-dev credential name. When we go to move that up, it still thinks it's just LE, because we variable-zed it.

Especially when going to a new server - if they want to rebuild a whole new server - all I do is install a new agent as "_new," and the alias name will be whatever, and then, go-live, I just swap the names and scheduling isn't impacted at all. It's pretty sweet the way that works, using the aliases.

I can remember with ESP, we had to have tons of schedule changes and agent name changes to the new one, whereas ops-wise took a lot of that away with the use of variables.

I would rate this solution 8 out of 10. 

My advice is that it's very easy to use, and you can schedule the jobs on all applications, Informatica, and SAP, and it will run fine.

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.

Keep up the great work and awesome support!

The project using Stonebranch has finished. I don't have access to the Stonebranch environment now. We last used it six to twelve months ago.

It was not complex for me, but you have to follow the documentation. Spend some time to learn about it, then it's no big deal.

I would rate this solution an eight out of ten.

Try it out, get to know the product and see how it works.

We have two system admins or schedulers, master schedulers, me and my co-worker. In our test and dev environment, we have four staff involved, counting me and my co-worker. Since everything was cut over to production and stabilized, we have had to spend about ten hours a week on it. We have operators monitoring it 24/7.

I would rate it at nine out of ten. I work with it every day and it does what I need it to do. I can't think of anything off the top of my head that I need as an enhancement at the moment.

No.

UAC is a wonderful product, and as an end user, I would fully suggest looking into this product.

No additional comments.

No.

We are a reseller. We are a software company.

So far, we've had a pretty good experience using the solution. We need a bit more time with it, however, to get more comfortable with everything.

Overall, I would rate it at an eight out of ten, as so far the experience we've had has been positive.