Clarity SM Reviews

The most valuable feature is its integrated nature. Compared to other service catalog and business process management suites, which are highly flexible, what you give up in those is the integration with other feature-set functionalities, platforms, and modules that would make up the rest of your IT organization. Hands down, the premier feature of the CA platform is the integrated nature of that platform. It's designed to work together.

Try managing the expectations of 180,000 users as if they were just one. That's how much it's improved our functioning.

I'd like to see CA continue to invest in the initial engagement of my end-users with Service Catalog. I would like to see CA continue to invest in form, design, and functionality.

From a developer's perspective, the biggest weakness is what you can and cannot do. I'd like to see CA continue to invest in reducing a need for technical staff to engage in process automation, vehicle limitation, and product design. I don't like to see developers in 2015 writing code for things that other companies have already figured out for a while.

Service Catalog and the Business Process Management suite over the last 20 years have gone through unbelievable instability. Over time, you have all these vendors that are consolidating up into the large players. Provision was bought by Metastorm, Metastorm was bought by OpenText, Lombardi was bought by IBM. That's instability. CA needs to invest.

From our end-users' perspective, it's fairly, very IT. This is obviously coming out of IT's solution. If you're looking comparably and relatively across Service Catalog that runs in the process management space, CA fell behind. They need to invest. They have been and they may need to continue to, so there's huge weaknesses in form functionality. Form design, form functionality. There's huge weaknesses with respect to your general approach to a committed processes to automation. I still require very technical developers where I shouldn't have to in 2015. This is nothing that they haven't heard, and they're already responding. They are investing. They need to. If they're going to play in the States, they're going to need to keep investing.

I don't get involved in that. That would be more the development team and support team.

I wasn't involved in the implementation.

Understand what you're buying.

If you're talking about just implementing Service Catalog and committing service delivery processes and automation, the organization can take the approach and adopt the strategy of, we're going to go and listen to our customers about what services they want and listen to our operations staff about how they want to operate and how they want to speak and how they want to do things. And that's a very highly flexible Business Process and Management suite. This is not that. This is, essentially, an ERP system for IT. There's going to be a certain element where the delivery team is almost informing, I know that's a horrible word, but informing, influencing the conversation of what we are doing to adopt a CA-driven data module. We are going to adopt the way in which CA intends IT to run its IT organizations, and we are going to implement a framework here. That's a very different approach. It needs to be an executive-supported and executive-understood.

We already have a service catalog in our IT department and one of the problems that we had was that we had several interfaces to users. The user had to know when to go our catalog to ask for something from IT and when they had a problem, they had to go to another interface to report an incident. One of the things that we're trying to do with the service catalog is to have it so people don't need to know in advance if they have a problem if they're asking for something new. Our idea was to remove that decision from the customer so customers can put in whatever they want and we decide if it's an incident or new requests. That's the way we're transforming our catalog to work that way.

In the background we have Service Desk where we fulfill the requests from customers whether they are incidents or new requests. It's a big transformation and I think that the customers quite like it.

I don't know if it's uniquely good, if it had to be CA. It's just that since we had some problems with our previous service desk platform because we made a lot of changes to it. It was very difficult to upgrade to the new versions because we had a lot of development put on top. This was one of the things that we did when we adopted Service Desk is that it had to be configurable and it would work out of the box and only with the configuration. We don't want to develop anything on top. That has been very good with the decision that we made because we've been able to upgrade the software versions in one month which is amazing. It's nice that they have a video interface.

Customers don't have to decide where to go to report something and they don't get those answers that we sometimes do, the technical people do. If you report an incident then they decide it's not an incident they'll tell you this isn't an incident so go to the other screen and just put in your request.

It's technical aspects. In fact, there was some technical issues in the way the product was built that in the long run could get us into trouble. We didn't actually have any problems but the new releases have redesigned the way things are and so I think it's much better now.

Most of these products are bits and pieces and when you bring them all together you bring them as bits and pieces. If you want something to be robust there are some aspects that you have to redesign some of the parts so that they can glue together.

Sometimes we would like things to be a bit easier. I think the reporting could be something that would help and I think this happens with most of this sort of product is that you need a lot of reporting on these sort of solutions. It's not as agile as we would like it to be.

I think reporting is always something that I think we feel that these products are short on. The problem with reporting is that you need to know the data model that's behind it so that you know what objects you need.

We've had no issues with deployment.

It's been stable for us. 

It's scaled just fine.

Right now we actually have a contract with them for Service Desk support. They're the ones that are bringing in people to get support to the Service Desk.

They are helping us evolve our Service Desk. It's a long-term contract for that, sort of a professional services thing.

I was not part of the selection process. I know that HP was one of the vendors. I don't recall if IBM was in there as well. We previously had BMC.

Compared to others, I like the ease of Service Desk. It's easy to maneuver around in. It's very user friendly. Things make sense where some other products we looked at, they were very confusing.

We found that there's plenty of things that this tool does that we frankly aren't utilizing. Other tools looked neat, but when we got to really looking at it we just have it. We're not using it to it's potential to be honest with you. We do have the CMDB, but we're not utilizing a lot of the integrations to the potential like the IT workflow. A lot of the automated processes we're just not using and I'm sitting here looking at this stuff going, "We are barley using this tool."

We could be doing a better job, but unfortunately out hands are tied because it takes our system administrators time and effort to implement these things for us. Whether we want them or not, it's whether their team has time.

The thing that gets me is they sell it as a customizable tool, but the more customizations you add to it, the less stable it becomes. So over the last few upgrades, we've tried to come out of box as much as possible, and that has worked for us. Sometimes, people want and want and want and change and change and change and we find you really can live without all those customizations and it works just as well, I mean, works better. We're getting ready to upgrade to 14.1 and we were talking about that. Really, the last few years, we haven't really had to use the word outage very often.

I've suggested a couple of improvements. It might not mean anything to you specifically, but I have joined one of their communities and suggested that, when it comes to groups, they need to have a separation of groups so that you can have a separate group for work flow tasks in the change side than you do on the other side. The problem is, we have business people and different approvals on the change side that need to approve change orders, but they don't need to be involved on the ticket. But what happens on the incident problem request side, when people are playing hot potato trying to get the ticket out of their queue, they're looking for a group and they're picking it whether it's a my work flow group or not. We've tried to creatively name them so people won't use them, but there needs to be a separation. You ought to be able to select what modules you want that to be available in.

One other thing I can think of. I've noticed with this latest upgrade they're starting to change their terminology. They're calling incidents issues in the service catalog and I'm really curious to go talk to someone about that. We have what we call an issue module for our business side and that is for our external customers. When we plan to bring about the service catalog, they're going to be really confused when it says open an issue. Why did they do that? Why did they change that terminology and I've heard them use it in here. You know, "When you go to open your issue." I'm like, that's an incident. That's not an issue. That's two different worlds.

We've had no issues with deployment.

It's reliable.

It's scalable.

That would be the tier above me, so I haven't had to deal with them.

ServiceNow we also looked at. I would have been okay either way. In all honesty, it was more of a cloud solution and we wouldn't have needed our system administrators for as much as the upgrade work. That was kind of one of our driving things that did lean us towards that. The other tools were way too expensive compared to what we had. When we did the comparison, again, the new tools looked tiny and new, but we weren't utilizing what we have. We have some of the same features. We just haven't used them.

You don't have to go for the newest item out there. There's reliability, stability in maybe some of the older tools as well.

We love the CMDB, it's a very good functionality. The whole ITO process is very well-defined. Problem management and SDF management are great features and really improve our day-to-day functions.

The software asset management is a feature for which we don't find the correct functionality. It's something we could potentially use, but it needs to be improved.

We've been using it for six years.

We don't have any problems. It's been very stable.

We are provisioning other clients in the platform, and it's scaled just fine for us.

We have a lot of experience with this type of software and manage on our own. We haven't needed to use technical support.

Last year, we looked at other solutions on the market and found some that were cheaper than CA. However, we decided to stay with CA because we already have a partnership with them.

Yes, but we decided to stick with CA because of our partnership and knowledge of the product.

CA is very good in both the implementation and operation phases. We've been very pleased.

For me, the best feature is the powerful tool to integrate all processes for IT to monitor. I can integrate process management, release, and change into our programs.

It’s in a language that everyone in the business can understand. It uses not only depictions but also symbolic language, as opposed to language that only IT personnel can understand.

It has some stability issues, and it can be complex to implement. The last implementation took us about two years to complete.

The main problem is the one-point failure, where if one part of the application fails, the application as a whole fails. We need a bigger solution for our tree environment with two servers on which we run 15 services and for which we need service management.

It's scalable, but we try to control the number of users with licenses, which right now stands at 900.

The initial setup and integration was very complex. At the moment, we have an upgrade that is going to take eight months.

I don't know as I wasn't involved in the decision process.

First and foremost, when we talk with our customers about the CA brand, they immediately feel comfortable. That's an incredibly valuable thing.

From a technical perspective, we work and integrate with PMO offices, and they've all integrated Service Desk Manager, so it's something that's widely used and known.

We've improved as an organization very quickly because of it, especially when it comes to self-service capabilities for our customers. It's been a fast, easy, and reliable tool to use, so much so that we've even had auditors who credited us with the quality of the implementation.

We need financial solutions for all projects we undertake, and Service Desk currently doesn't offer this. It would be of great benefit if it did.

I think that we need financial solutions for all projects, currently we do not have this and it would be of great benefit.

We've had no issues with deploying it.

It's a very stable product.

It's scaled just fine.

I am very happy with our partnership with CA. Technical support is very good. Since the very beginning of our relationship with them, they've provided us with great support and information.

We chose CA because we had previously used CA Spectrum.

The initial setup was very easy. We're quite happy about that.

It’s very simple, fast, and has great support for the tools.

The customer service portal allows customers to put in their ticket themselves, especially on the application side because sometimes you don't interpret it right when you're on the phone. So it's helpful to be able to to provide and collected that information from the user side.

We do a lot of applications, so we support a lot of applications. When a client or end user calls in, we have to consistently maintain the case number, the information, the client. It's a lot of details on different applications, so to be able to get that into their own terms is a lot easier for as we help troubleshoot the ticket.

The product itself gives you a lot. If you use it correctly and enter the information correctly in the fields, you can get a lot of data out of Service Desk, including trending information, to be able to help us troubleshoot what's going on. It also allows us to be able to determine trends in our issues and to manage those trends to train our end users.

You can always find a pattern with trending data. If you set it up correctly, you're going to find the patterns, and you're going to be able to resolve issues quicker and be able to improve on your services.

Reporting is not the easiest. We just purchase extraction features, but again, people need training. It wouldn't be so bad if you could get more information when you do a query within Service Desk and to be able to drop that information into an Excel spreadsheet.

Right now, you're limited to what is exported, and there's only a certain number of fields, but there's additional fields that I'd like. If I could just add those to export real quickly, it would be a lot easier than have to create a report each time.

We're pretty stable because when we came into it, we knew the number of end users we had. We might start growing it by doing more of our customer-based call center and by adding more of a case management system. That would increase it some, but right now, we've been pretty stable.

Overall, we get pretty good response back from them. When we have issues, we bring it up with our TAM, Mandy McGee, but we also set up monthly meetings, so if we are having any issues, at least she can go and get the research done and get us a resolution right away. It's gotten a lot better than when we first had it, when you wouldn't get anything back. Now, it's a lot better than it was three years ago.

We had Service Desk, and then we went to the cloud version. We tried to do it as SaaS, but then moved it back in-house. We went to the cloud, but some of the other products we wanted to use from CA aren't hosted in the cloud, so to make it an environment to where it's all in one environment, we brought it back in-house. It was working OK in the cloud.

I helped start that project and got it going, but then I moved on to a different job. I was involved in all of it, especially with the pricing and making sure we got enough licenses.

We used a vendor to help with that, and then our infrastructure team. Some of the notes are not really clear. They did run into a few issues when expanding across servers. There was a few little bumps, but it's no different than any other system.

It's more expensive in the cloud because you had to purchase per user, but by bringing it back in-house, we can have concurrent licenses. We have over 800 analysts in the system, so it gets cheaper pricing.

We had Service Desk. When we consolidated the IT departments from all the agencies into OIT, Office of Information Technology, some of them had Remedy, some of them had Heat, some of them had Excel spreadsheet that they were capturing all the stuff on. Since we already had Service Desk in the cloud, and we already had been trained on it, it was more just, "Go ahead and move to that," instead of really trying to move everybody off onto something else.

Just make sure when you are putting the project together, especially on the server side, that you have the right people in the room to ask the right questions because sometimes not required personnel are there. The right people are your server people, specifically, management-level server people.

I've stood it up and I've configured it and got it working.

What I like about it are the features that allow me to integrate with Service Desk Manager and Process Automation, and to build creative solutions based on the integration with other CA products.

Although we've implemented Catalog, we haven't used it in production yet. We built a prototype and what we want to use it for is to take over our request management system, because right now we do requests in Service Desk. I think Catalog is going to provide us more of a cart-type system.

Catalog gives us that cart view if you want to submit a request for service. Right now we are using Service Desk, but we would like to put the request management system in Catalog. It gives us a better buy and it gives us a more friendly view of ordering requests.

I can't think of any areas for improvement with the product itself, though when I stood it up, the documentation was not as straightforward as it could have been. But I figured it out without much issue.

No issues with deployment.

There's really nothing for me to talk about in terms of stability as it's not yet in production even though I've stood it up and configured it.

We haven't tried to scale it yet, but I don't anticipate any issues.

I've never opened an issue with regard to Catalog.

We're using Service Desk as our request management system, but we'll be moving away from it to Catalog.

I don't think I needed anybody's help to stand it up. I think the documentation walked me through what I needed to do.

I stood it up myself.