Process Automation and Forms Digitisation, implementation of organisational wide processes rather than use of COTS.
The easiest route - we'll conduct a 15 minute phone interview and write up the review for you.
Use our online form to submit your review. It's quick and you can post anonymously.
Process Automation and Forms Digitisation, implementation of organisational wide processes rather than use of COTS.
Appian was not selected by any of the organisations I've worked with to date for production use.
Form building capabilities and well thought out process modelling are key points to this product.
Support for complex models really needs significant improvement
Flexibility in the architecture is not there
Management or reusable assets is extremely limited and poorly designed
Business rules are not aligned to industry best practices
Authoring tool slow to use resulted in limitations on how quickly solutions can be built
Integration to devops (such as automated testing, ci/cd etc needs work)
Trial/evaluations only.
This product is targeted to mid size companies and not highly scalable complex processes.
Customer Service:
Average, although a small responsive team Appian has been fast growing stretching their ability to service customer needs.
Technical Support:
Reasonable, stronger than say IBM or Oracle technical support but it is still critical to engage in a full POC activity with this product to ensure it fits your needs before proceeding with an implementation. The closed nature of the platform means there is limited to no help outside of that technical support team which is already stretched based on the ever increasing customer base.
leveraging IBM engine on other jobs with the Blueworks Live for developing processes with business.
Compare this product closely to open source options, IBM and Pega. For simple solutions using simple models Appian may be sufficient and would provide better ROI than investing in building a team to support a more complex tool but for complex models I'd look for a stronger tool-set.
My main business use cases supported by Control-M involve working with healthcare, insurance, telecoms, and banking, both retail and investment, primarily to ensure things are working. Much of this is in regulated industries, so we have established the necessary processes and tools to ensure that Control-M code is properly controlled, allowing us to satisfy SOX audits and other similar regulatory requirements.
Host groups are one of the most valuable (and unrecognised) features in Control-M and allows you to make your code environment agnostic. They allow for load-balancing, simple scaling, and technology groupings. Control-M supports my DataOps and DevOps initiatives by providing a single pane of glass to orchestrate and manage workflows across numerous systems. With the integrations, I have access to all my on-prem and cloud-based applications, and I can write my own interfaces for systems that are no longer supported, such as managing Solaris machines which still run for some of my clients.
Control-M integrates with new or changing technologies within my DataOps or DevOps stack fairly easily. The BMC team consistently develops new integrations at a rate of two or three a month. If they have not already got an integration available, it is very straightforward for me to create one myself, even for older technology through agentless connections to unsupported systems.
Control-M enables new capabilities or business processes that were not previously possible. There is significant capability embedded in the tool, some of which is not immediately obvious. With some creative thinking, I can leverage these capabilities to improve performance and allow Control-M to handle much of the load balancing.
One key element where Control-M could be improved is in providing a better audit trail for converting from development through to test and then to production environments. The process can currently be done, but the XML version is difficult. JSON offers an easier approach and is going to be the standard moving forward, so some XML-related issues will resolve naturally. For those still on XML for source control, it is an ideal opportunity to review procedures within Control-M to ensure compliance.
I joined JP Morgan in 2007, which introduced me to Control-M, and I have essentially been working with Control-M ever since then, marking 18 years this year.
The stability and reliability of Control-M in my experience is commendable; it simply works if set up correctly. Proper analysis of infrastructure requirements, source code control, and growth expectations should be carried out before commencing the migration. Once those factors are right, the conversion should run very smoothly. It is important that the conversion is carried out by a collaboration between teams that understand the old and new systems.
Control-M orchestrates workloads across multiple environments quite easily. I find that the graphical interface is very user-friendly, and although I have traditionally used the desktop interface, the web interface in version 22 is now nearly as effective as the desktop.
My experience with pricing, setup costs, and licensing for Control-M raises interesting points. Pricing is often perceived as high, and the licensing model can be unclear. However, in the end, it is clear that I am paying for a top-end tool which rarely experiences issues, with most problems stemming from the applications being managed rather than the tooling itself.
Regarding other solutions considered before selecting Control-M, I have seen conversions from Redwood and witnessed attempts to convert out of Control-M into a cheaper product. These attempts often ended in failure, leading to a reversion back to Control-M. Currently, I am looking at conversions from TWS into Control-M SaaS, and Axway into Control-M SaaS, along with several other potential conversions.
With proper planning, setuo is straightforward.
The biggest return on investment I have experienced with Control-M is the reduction in support time. If I set things up correctly with appropriate alerting levels, my support team can proactively prevent incidents rather than waiting for something to go wrong. The most significant metric is the number of support tickets prevented, rather than the number of support tickets closed.
My experience with pricing, setup costs, and licensing for Control-M raises interesting points. Pricing is often perceived as high, and the licensing model can be unclear. However, in the end, it is clear that I am paying for a top-end tool which rarely experiences issues, with most problems stemming from the applications being managed rather than the tooling itself.
When considering the overall experience with the migration processes of my customers, I find that if they approach the process with proper planning and due diligence, it typically goes very smoothly. A common mistake is trying to lift and drop what they had in another tool into Control-M without considering process differences, as the tools do not function the same way.
My advice to other companies considering Control-M is to conduct due diligence, examining not just initial costs but also ongoing expenses. It is essential to consider anticipated usage duration and growth patterns, as a correct setup facilitates easy growth, whereas a faulty setup complicates matters.
I would rate Control-M overall as a 10 out of 10.
