Automic Automation Reviews

We use it for batch automation and site switching. It has performed great for us, and we have had very few problems. We have done a full upgrade in the last 12 months where we went from an AIX to a Linux platform, and this was a massive change for us.

We are a big organization. We have 7000 employees. We are spread across Ireland and the UK, with operations elsewhere. Therefore, it is about where can we use Automic to create efficiencies. We know there are a lot of things that we are doing which are time and resource intensive. We would like to leverage Automic for these tasks.

We have been using Automic for more than 10 years.

We have about 40 million jobs and workflows go through our organization's Automic instance every year, from our Treasury functions to our SAP functions. We use it in approximately 30 to 40 applications. It is very important to us.

• Stability
• Versatility
• It is integrated across all our IT platforms in our infrastructure, which is a big plus.

• While the cost is competitive, there is always room for improvement.
• It has a very complicated interface, which could be made to be more user-friendly.
  

It works. It does not fail. If something fails, it is not Automic. It is a script or something else.

We are an electricity company, and we issue hundreds of thousands of bills to customers every month. Automic is key in getting the billing files ready, so they can be sent out to the customers. We are heavily regulated by an Irish regulator. Therefore, if there is any delay with bills going out and the process around it, we can be heavily fined. Thus, it is crucial that we have software that makes everything run smoothly.

One of the areas that we are looking at is using Automic in the cloud. Diversity is actually more important to us than the scalability at this point. For example, where can we leverage Automic to automate and improve efficiencies in our organization?

The technical support is excellent. We have gold support for Automic, and are happy with it. That is really key. If we invest with a company and its product, then we make it a critical condition that it can't fail, essentially. If it does fail, then we need to know that if we pick up the phone, someone is going to fix it for us.

The only time that we needed technical support in the last few years was when we were doing an Automic platform migration. We were on an AIX system and migrating it to a new operating system. For the migration, we relied on Automatic to assist with the transition. Apart from this, we generally do not have issues with Automic. 

Mostly, it is the jobs or scripts that we request Automic to run where we see issues, which is fine. These are fixed elsewhere.

This was before my time. I suppose we had an operations function that was shift-based. We would have a team that worked around the clock, and they would be performing the batch functions manually. Then, when Automic came in, we could operate 24/7 because Automic was doing the automation, but we only needed a team 9 to 5, Monday to Friday, in the office. This cut down on the need for a rolling shift. However, this is probably going back about 10 years ago.

I was not involved in the initial setup.

One of the key reasons for implementing Automic was to cut down on manual tasks: Workflows, jobs, the way it can work across multiple platforms and different operating systems, stop and start services, transfer jobs, and file transfers. This has all greatly increased our efficiencies and productivity, and reduced the amount of human interaction required. The key to this is the stability. 

We feel that we get a good deal with the price.

We recently renewed our Automic contract last year. At renewal time, it is not about looking for an alternative product, because we can't find one. Also, Automatic is heavily integrated in our organization. The cost to change would be a huge factor for us, and we have not found any other product that is better out there.

We have not found another product that can do what Automic can do. 

We are looking for use cases to utilize it within our organization. Basically, what we are looking to do now is to automate as much as we can within the organization.

We are probably not using it as much as we can, but that is on us. Any issues we have ever had with the product have been resolved. We are only using Automic more, rather than less, in the organization. It is as integrated in our company as it possibly can be. It is crucial to us. We would not put that this type of time and investment into a product if we were not sure of its capabilities and stability.

Most important criteria when selecting a vendor: 

The product has to fit. The vendor has to be willing to work with us and tailor their product to suit our needs, then offer that level of support to us. The company that we work in, we can't have downtime or outages. Automic and similar products are critical to our business and our internal business functions. Thus, support is key, if there is an issue, so we can get it fixed quickly.

Do your own proof of concept. Make sure you know what you want. Be clear about what you want the product to do for you. Go out and meet with the vendor, then test it.

We can automate nearly all business processes except for real-time processes using Automic Automation.

Ten years ago, I was first introduced to Automic Automation during a migration project for a major bank. Their legacy system lacked SAP integration, which Automic Automation provided, necessitating the switch.

Our customers utilize Automic Automation in a hybrid environment that encompasses both on-premises and cloud-based infrastructures.

Overall, Automic Automation offers excellent functionality and is an outstanding product in the market. Despite its limitations, it remains one of the best options available. While scripting languages can be used to implement special functionality, this approach is outdated. For more modern and efficient implementation, Python or custom scripting languages tailored to specific workflows are preferable.

Reducing job and workload failure rates across multiple cloud environments is of utmost importance. Workflows and workload engines are vital components for a wide range of processes, not only in business and IT but also in healthcare. Managing resource-intensive workflow engineering businesses also necessitates effective workflow automation. In technical settings, such as clinics, workflows, and processes can be automated using virtual engines. We are at the early stages of these developments, and a unified approach between business, IT, and technical teams is crucial for success. Two key considerations are the flow and dependencies between activities, and the bulk load management, which involves controlling resource consumption.

Automic  Automation has been instrumental in enhancing our compliance processes. The software effectively automates multi-step processes, making them more efficient and streamlined. Compliance processes are particularly well-suited for redesign and segmentation into smaller components. While compliance processes share similarities with other processes, such as login procedures, they hold a unique importance akin to security. Virtual engines have the potential to automate and control a wide range of processes, including security, compliance, and even genetic analysis. However, their implementation in these areas is still in its early stages. Additionally, virtual engines can facilitate complex workflows, such as channel analysis.

With Automic Automation for traditional IT, achieving SLAs is assured. This is because we maintain complete control over our workflow. When an issue arises, we can quickly pinpoint the cause, whether it's a failed job or another factor. Event processing provides similar visibility, offering an alternative perspective on the situation. While some advocate for workflows as the primary means of SLA fulfillment, this approach is not entirely comprehensive. The most effective strategy for achieving SLAs involves a combination of event management and ITSM infrastructure.

Automic Automation is a highly complex yet versatile tool.

Due to Automic Automation's proprietary scripting language, upgrading it can be extremely challenging, unlike other workflow automation products that offer seamless migration. This inflexibility makes Automic Automation the most complex and restrictive solution in the market. Choosing Automic Automation essentially locks us into their ecosystem, making it nearly impossible to switch to a different product. Therefore, I strongly advise against using Automic Automation.

Automic Automation's AI capabilities are limited. Most traditional workflow products lack robust support for AI workflows. Airflow might be a suitable option for AI workflows. However, if real-time AI processing is required, a different product altogether is necessary. For example, in the field of genetics, if a workflow involves thousands of jobs, traditional workflow products such as Automic Automation may struggle to handle such a large workload. The maximum capacity of these products might be around 1,000 or 2,000 jobs. In contrast, a genetic workflow could involve up to 100,000 jobs, requiring a completely different workflow product specifically designed for such large-scale processing.

Mainstream workflow products like Automic Automation offer similar functionalities and are widely used around the globe. These products typically check for process completion every second. However, in high-performance computing and emerging fields like medicine or ophthalmology, we need to control thousands of jobs simultaneously, requiring millisecond-level process completion checks. To achieve this, we can store event data in databases or perform on-the-fly checks. Additionally, we need to integrate workflow control with workload management to prevent machine overload. These requirements make it unsuitable for tasks like controlling genomic workflows.

I have been using Automic Automation for over ten years.

Automic Automation's technical support, like that of many other companies, is inadequate due to their outsourcing practices. In an effort to cut costs, they relocated their support staff to India. The best technical support I've ever received came from Israel. Many Israeli products, such as those from Mellanox, exude a similar level of quality. Mellanox, now owned by NVIDIA, resolved complex issues for me within a couple of days. When I encountered problems with Cisco switches, it took weeks to find a solution. I had to communicate with someone in India, then return to development, and so on. It's preferable to avoid discussing this issue altogether. It's a common problem among IT companies. They want to transfer their first and second-level support to India, with third-level support potentially remaining in the United States or near the product's development location. In general, I would advise disregarding support that lacks engineering expertise. They are incapable of resolving any issues.

The installation of Automic Automation is complex due to the lack of full automation in both the installation and distribution processes.

The pricing of Automic Automation varies depending on the specific contract terms. While one of our customers in the banking industry has secured a favorable contract with Automic Automation compared to other scheduling solutions, new contracts for Automic Automation tend to be on the higher end of the pricing spectrum.

I would rate Automic Automation nine out of ten. The product is very good, but I would not buy it because I would be too limited by the scripting language. I would be locked into using this vendor indefinitely, potentially for the next two hundred years.

Two of our customers are still using Automic Automation because it is too complex and expensive to migrate over to another solution. The main problem is the script language. In order to migrate, the entire workflow would need to be redesigned.

Automic Automation provides exceptional visibility and control across internal operating platforms. Its scripting language offers remarkable flexibility. However, due to vendor lock-in, I would not recommend its adoption. Automic's inability to support migration to other vendors presents a significant drawback. Although the product boasts a wide range of features and is currently undergoing improvement, its inflexibility in terms of migration remains a major concern. For new projects, I would recommend considering alternative solutions such as Control-M or Tivoli, which offer greater flexibility and easier migration capabilities.

While supporting multiple platforms is a common feature among mainstream schedulers, Automic Automation's ability to do so is not a significant differentiator. Even the most widely used schedulers can encounter challenges with Windows, but we can devise a solution to address these issues.

Encompassing all environments, the customer aims to automate their IT infrastructure, virtual systems, and all processing operations. This automation spans from mainframe legacy systems to current Unix and Linux environments. A workflow system will be employed to automate critical processes.

The necessity of utilizing Automic Automation on both cloud and on-premises environments is contingent upon specific customer requirements. While some organizations, particularly those in the government and financial sectors, may prefer an on-premises approach, others may embrace cloud-based solutions or a hybrid model that integrates both cloud and on-premises infrastructure.

As we strive for a comprehensive automation solution, the ability to monitor automation across multiple environments becomes increasingly intricate. This poses a significant challenge, prompting traditional automation products like Ansible and Terraform to incorporate workflow capabilities. For instance, IBM has integrated workflows into Ansible, necessitating the use of a database to store these web flows. To illustrate, IBM enhanced Ansible by incorporating a workflow engine and a database. Similarly, other automation products such as Terraform and others are adopting similar strategies, integrating virtual engines within their products.

Every workflow product requires maintenance.

Automic Automation aims to expand into AI and other emerging fields in the future. However, current limitations hinder their progress. Instead of pursuing these advancements, they should focus on developing new products for AI, genomics, and HPC. These new solutions could potentially replace mainstream schedulers for traditional applications like SAP, Informatica, Automic, and Control-M. While Automic Automation remains a viable solution for existing applications, alternative products are better suited for emerging technologies.

We used Automic for a multinational pharmaceutical client.

In the latest version, we can access the solution through a web browser as well. 

The web-based edition is missing a lot of the most important features available in Automic, we have absence. For example, when I'm scheduling a job, there is normally a flag that you can toggle to activate and deactivate the task, but that doesn't work properly in the web version. It's missing a lot of the calendar and scheduling features. 

My organization used the tool for almost 10 years, but we were dissatisfied when we upgraded to web-based edition because it doesn't provide all the options. It's challenging to create a new job or edit and reconfigure an existing. The web version has to be improved on various levels. 

Previously, we were using Solaris with Automic, but now I think it's Unix and Windows. I don't know what version you are going to provide for the cloud. The cloud always supports Unix and Windows, so it means the tool is cloud compatible.

In the web version, everything is moving from the on-premise server to the cloud. So in this scenario, the Automic tool has to be more cloud-oriented. We are not sure how it will work in the cloud. Since 2011 or 2012, we have been using Automic on-prem only. It would be nice to have more documentation about using the cloud version of Automic. The tool could be more user-friendly as well. Most people consider Automic to be a difficult tool to understand and use.

I've been using Automic for six years, but we just switched to another tool called AutoSys six months ago.

Automic is 99 percent stable. We've never had a problem with stability.

The scalability could be improved because we have three kinds of tools on our hardware itself, and we don't know whether Automic will accommodate the other two jobs as well. We have 200 direct users and probably 1,000 who benefit from the tool indirectly.

It depends on the terms of the support contract, but sometimes it will take two or three days to fix an issue. The impact is high because this type of job scheduling solution is used mostly for finance. For example, let's say there are 3,000 jobs scheduled, and four jobs fail. That could mean millions of dollars lost.

It should be fine If they provide support within eight to 16 hours, but they typically take three days to get a response. That won't work because on the impact side. On the other hand, it's highly stable, so we are generally okay, but we still face some bugs every six months or so. When that happens, we expect a speedy response.

The initial setup was straightforward, but it gets complex when you start using it. It will only be complex if you're a new user. The total deployment time for the original and web version was about three months. That includes installation and testing. During the testing, we found missing features, so it took three months to set the solution up, configure it correctly, and test it. 

The personnel needed to manage and maintain the solution depends on staffing and scheduling. For example, If you are providing 24-hour support 365 days a year, you need six at the most. We need one person per shift, and we have three eight-hour shifts. Including backups, that's three to six people. 

I don't have any numbers about the return handy. We didn't renew the license, and we've already onboarded the other solution and started using it. It's costly and our companies are cutting costs. They consider this an extra cost, so we didn't renew for this year.

The license for Automic is around $7,000 per year, which is somewhat costly, but it includes enterprise support. 

I rate Automic Workload Automation eight out of 10.

We use Automic to coordinate batch processes for Oracle Utilities products like customer care and billing, and work and asset management. It helps us load customer data, meter reads, and process billing. We also use it to make calls to Solar processes and for file transfers across servers.

I like the GUI interface of Automic. We use it to coordinate batch processes and it's beneficial for orchestrating various processes, especially in the context of Oracle Utilities products.

Automic's database structure is not intuitive. When upgrading, the system breaks down frequently and we require a lot of support. More visual aids in the documentation would be helpful.

Probably four or five years, but I started focusing on it more in the last two or three years.

It's pretty stable once you fix the initial issues after deployment.

Scalability is good.

They are good and helpful, but many issues require support tickets due to inadequate documentation.

Positive

The pricing has been increasing significantly over the years, raising operational costs instead of reducing them.

We've been looking into other possible replacements because the pricing with Broadcom has increased significantly.

I would rate Automic a six due to its high price and other issues. For new users, I'd advise taking training courses and learning to read log files effectively.

We use the solution across every business area for site switches, backups, batch scheduling, and other tasks.

We implemented the solution about 20 years ago when we switched from our legacy mainframe systems. We were looking for a scheduler to replace the one in our new SAP systems, as the SAP system scheduler wasn't considered robust enough. The solution was chosen to replace SAP scheduling at that time.

What I like most about Automic Automation is its flexibility to work across multiple platforms, such as Windows, Linux, and SAP environments. The ease of switching from one environment to another is particularly useful. I like its calendars and workflows. 

The support has declined somewhat over the years due to various takeovers. It's not as personal as it used to be.

I've been using Automic Automation since 2005 for about 19 years.

I rate the solution's stability a nine out of ten. 

I wouldn't rate the solution's scalability highly, but that's more due to our company's structure than its capabilities. We often don't know what's coming for our company in advance, so we might not always consider using it for new projects even though we probably could.

We initially bought it for SAP scheduling but soon found it could do many other things. For example, we use it for site switches between our two data centers, testing our critical systems once or twice a year. In the first two years of using it, our usage grew by about 400%.

Currently, we have about 400 agents and three environments: development, test, and production. We have approximately 150 users.

As for scalability, we currently only use about 20% of the CPU capacity, so there's plenty of room for growth. If we need to add more jobs or increase the workload, it's scalable. Increasing memory, disk space, or servers is also easy.

Before Automic Automation, we used a solution called ControlM, though I wasn't with the company then.

The deployment of Automic Automation was fairly straightforward, though we initially had a few minor issues. It took about a year before it went live, and only three or four people were involved in the process.

The solution does require daily maintenance, which mostly involves looking at the database and archiving older data to keep it efficient.

We've seen a return on investment, particularly in terms of resources. For example, when we have an outage for an upgrade, the manual implications would be vast without Automic Automation. If we were to ask everyone to do the tasks it does manually, we would need a lot more people.

The solution seems expensive to me, but it does the job well.

We did face some challenges during the early implementation about 17 years ago. There were occasions when jobs replicated themselves and filled up the database, causing system downtime. However, we've since fixed these issues.

I would recommend Automic Automation to other users mainly because of its ability to work in multiple platform environments. For example, it's effortless to move files from a Windows system to a Linux system.

Overall, I'd rate the solution nine out of ten. I think it's a very good product.

We use Automic Workload Automation to schedule the batch processes for all systems within the University of Colorado. We use file transfer jobs to send or receive files with each incoming file authenticated through Automic. We code Automic jobs to update PeopleSoft run controls automatically, continuously run processes for real-time results, bounce application servers, and we notify all process failures through text and email.

In 2014, we saved over 9000 hours on an annualized basis when we removed the manual updating of Run Controls. Removing manual updating also improves efficiencies, productivity, and human errors.

Another example of how Automic has improved how we function is the ability to automate our abend notifications. This ability has improved our work/life balance during the weekends when we are on-call. Instead of being tasked with monitoring the system during the weekend, the abend notifications are automated to send a text to our cell phones. That enables us to go about our daily lives and only log on if something breaks. This has also enabled us to staff 24/5 instead of 24/7, saving two FTEs who would otherwise work 12-hour shifts throughout the weekend to just monitor batch.

Currently, we are in the process of rebuilding our student information system jobs in Automic. The reconstructed jobs will use Automic capabilities and coding to automatically update college terms, financial aid years, census dates, etc which will fully automate our data processing. The code uses a calendar and variable tables to update the run control values as necessary depending on the date. Fully automating term changes will eliminate 90% of our ticket load and remove the manual updating of 7000 Peoplesoft run controls per year. This will also improve our customer's end experience, they will no longer be required to submit cumbersome tickets detailing run control changes. 

An important feature is the ability to modify PeopleSoft Run Controls at run-time. We run all of the batch processes for the Student Information Systems, Finance, and HCM, which use Peoplesoft in our shop. The ability to modify dates, query names, batch numbers, etc., is paramount to my team. The ability of the Automic script/coding is also a valuable asset as it provides a way for us to meet any customer's requirements, no matter what it is, we can do it with Automic scripting.

There are some scripting elements that could be added like being able to reset a task in a schedule through Automic scripting. 

Also, some of the things we don't use are mainly because we don't know how to use them. Hands-on training can be expensive, so we find other ways to work around things to forgo the hands-on training. It is also an issue because we are a Linux shop and most trainers are Windows-based.

The product itself is very stable; we have not encountered stability issues with it.

No issues with scalability.

The technical support team is fantastic. Any ticket submitted is worked on quickly and professionally. The team is very good about following up to make sure the solution worked and, if it didn't, they will work with you until the issue is resolved. They are hands-down the most efficient support team I have come across and they are the one team that will always provide results.

We ran our Finance, HCM, and CIW processes through Unicenter. I don't believe that Unicenter was very user-friendly and they found it difficult to integrate with other applications.

We ran the Student Information System batch on the mainframe using CA7 as the batch scheduler. We switched from Unicenter to Automic and from the mainframe to Automic, mainly because Automic can integrate easily with any other application or service. When we got off of the mainframe and moved the student side to PeopleSoft, it only made sense to use Automic as the batch scheduler.

The initial setup of Automic is simple and easy. As long as it can talk to what it needs to talk to, there are no issues with the installation.

Initial setup was with a support representative. I can't say the level of expertise because I was not there when it was first installed. I can say that since I have taken over this department, any contact with Automic support has always met or exceeded expectations and any rep has always been well skilled at most things, other than Peoplesoft. 

The overall cost of Automic is minimal compared to what we can do with the product. Our return on investment far outweighs the cost each year.

Certain licenses can be a bit expensive. The PeopleSoft agents, in particular, are a bit pricey. We are using agent groups in our development environment which allows us to switch between the different Peoplesoft instances without having to change the host names in the jobs and without the need for multiple PS licenses.

I believe we looked at BMC and other CA products but chose Automic because of its ability to easily integrate with other applications and services, and because of how user-friendly it is.

It is hands-down the best product out there. You might find others that are cheaper, you might find others that sound better and cost more, but in the end, the best automation product on the market is Automic. Save yourself some time and start with the best first. It is easy to install, easy to maintain, reliable, stable, user-friendly, and versatile. One can achieve great automation with Automic.

During the closing of business processes, it does provide the interface you require to interact with, including various systems, operating systems, databases, customer services, and so forth. It is very, very good. I'm quite pleased with it. I stay in very close contact with bank operators since they have to close the business on a daily basis.

The USB port is okay. 

The product in general, is okay. I do appreciate it from an architecture point of view. 

The most important and critical process business in the bank, including COB, close of business, which has to run on a daily basis, is automated. This is the most critical and the most important business process in the bank. 

The electronic work order combinations have the ability to scale and handle large volumes of data. So far, it's fine, as of right now. We don't have huge amounts of data. The amount of backups involved is quite limited, and for the amount of data exchange, it's actually pretty low. 

It is easy to manage complex workloads using automatic workflow automation. I would rate it above average. It's far from perfect. However, it's above average.

It's good for managing processes that span multiple operating platforms. We have very good integrations between everything. We have multiple agents surrounding only Nutanix. I'm happy with that.

Automic Automation helped improve our compliance processes. For example, we have to prove that we do a backup or daily backup, and so forth. It is very easy to extract the backup report and the enterprise report. Whenever we have a compliance audit, I can simply send those outputs and everything is fine.

The only thing I'm actually not satisfied with is, during the COB, the use of processes makes time estimation for the flow completion harder. Most of the time, it is not accurate, and it's actually very frustrating for the operators since they have to run the COB. They have to connect many people each and every day to run the closed business for the core banking system for the production environment and also for the testing environment. Since they have to work in shifts, the first thing they are looking at is whenever they are going to complete the task. I'm not sure what data they use to make time estimates. However, most of the time it is not accurate. It's either way too long or way too short.

I've used the solution for a while. I've used it for more than three years - almost four, in fact. 

I consider the solution stable. 

We have 20 to 30 people using the solution right now. 

I'd rate the solution eight out of ten. 

To some extent, I provide support myself. Whenever I need additional support, I can go to our business partner, a local company, and they can help. They've been very nice and helpful. 

I'm also familiar with Control M. I prefer Automic as it has multiple interfaces and capabilities to interact with various types of systems - even old, legacy databases. 

I handled the initial setup, including handling the requirements and infrastructure.

When we installed the solution two years ago, we installed the latest versions - whatever was available at that time. 

The implementation wasn't easy. However, I had local partners from a local company to assist with the setup. It would be difficult for inexperienced people to install it alone. They have to understand the concept. They have to understand the architecture and be able to manage the credentials required to authenticate. I had these problems, for example, when I set up the UC port.

I handled the implementation by myself.

I worked with local partners during implementation. They had a very good background.

I can't speak to the exact pricing. I don't manage that. 

While I did not evaluate other options, it's my understanding that my managers did. I don't have any details, however.

We are Broadcom customers. 

We are not actually using them as cloud capabilities. We are only running on-premises.

We have yet to use any AI functionality. However, we are interested in the possibilities. 

I'd rate the solution nine out of ten. 

We use it to schedule our production workload.

We scheduled our database maintenance jobs through ASP and when we did this, we scheduled them in a certain defined way that we expected them to run. And when that was initially set up, there was no consideration for a database not being available so if the jobs tried to run when a database wasn't available, obviously they wouldn't work and an operator would have to intervene.

The plan was that people would open requests to have jobs held at that time. When there were only one or two databases, that wasn't hard to maintain and people did it. When we grew to many, it became harder to do that. Then with the change in how we're doing stuff, everything happens more, servers get booted more, more changes.

We use features of the product that allow us to determine if the database is available and to only allow the jobs to run when the database is available. So that saves a lot of manpower in the one group that was opening requests to hold jobs, and in the other group which had to implement the request to hold the jobs. It eliminated all that and provided a more dynamic environment for when these jobs can run, without operator intervention. 

That is something we started about two years ago. We fully implemented it last year and we've noticed a big savings in manpower.

It's easy to use. When you schedule jobs, if you can speak English you can schedule them easily and correctly.

There's a lot of flexibility because the product allows you to do many tasks, in multiple ways, so you can choose the way that works best for your environment.

How they handle cross datacenter failover, because they have a really good High Availability solution that works well within a single sysplex, but in our environment, since we have two main datacenter locations, we have two separate sysplex. And, while when everything is working ASP can control jobs both here and in the other location, the current product does not support High Availability across datacenters. That is something we would like to see the product have.

Currently, what we have is we have a homegrown solution, because we're required to have that kind of resiliency, because it's our enterprise job scheduler.

When everything's working, we're invisible. When it's not working: "Why aren't you working?"

Stability is a 10 out of 10.

Scalability is a 10 out of 10.

Tech support is a 10 out of 10.

When I started, we were already on this product, but I do know that they were using a competing product before and they felt that this product had more of what they wanted. So they converted from the competing product to this product.

When the company chose this product, it was actually pre-CA, and then CA acquired the product. But for the most part, they've kept it what it was. While it has a new owner, it's still the same product.

I believe it's pretty straightforward. It's a complex thing by nature so it's not going to be super simple, but it's not like you can't do it either.

I believe experience helps. And in our case, we had a lot of help from the vendor, so while we, per se, didn't have the experience, there were people helping to get us going that did have the experience. So maybe I'm underestimating how much that was important, because it was available, even though it wasn't coming from me or one of my team members, but somebody else was providing it.

I'm really the technical guy. Pricing is not something that I deal with so I can't answer that question.

That would have been 20 years ago, so the market is a little different than it was back then. There are solutions today that did not exist back then. Pretty much all of the big players still exist today. But we're definitely in a different place today than we were back then.

No advice other than the normal stuff that you would do when looking at any product: Does it fit what you need? 

I would recommend doing a proof of concept before signing any contract. Everybody's stuff sounds good on paper and everybody's stuff can do everything, but what happens when you bring it in your environment? Does it do what you need it to do? Those are the most important things. The other stuff, while it's nice stuff, if you can't do what the product is required to do, then there's no value to the product.

For us, it gives us what we need so it's a good value. Forget about the price, because if the product doesn't do what you want, it doesn't matter what the price is.

I would rate the product a 10 out of 10. We use the product everyday and it works and, for the most part, every time we have a problem, it seems it's never my product's problem. It's: I have a problem because there's a problem on the system, so guess what? We're not going to be working. I need a stable system to run. 

Or if it is our problem, maybe we didn't do something we were supposed when we found out that we were supposed to do this, and we reconfigure something and then we move forward and we don't have that problem any more. Or we re-architect how we do stuff, because we've had to make tweaks of stuff as we've gone along. We would do stuff and it would work and then we would do something a little differently, and what we did, it didn't work and we'd have to figure out what the problem is and fix it.

Again, the flexibility of the product allows us to do things multiple ways. We might have started doing it one way and that worked for a while and then either something changed -whether we had more volume or we did something a little differently or we had different issues - and then we would address them with different tweaks, solutions.